I have binary file compiled using mix release: bin/app.
How can I run it using iex so that I will be attached to process console and will be able to call functions from bin/app?
There are two ways:
bin/foo start_iex
connect to the running remote from iex (for this the application should have been started named.)
Assuming the application was run as foo#192.168.1.42, and local host is 192.168.1.10, this would open a remote shell:
iex --name remote#192.168.1.10 \
--remsh foo#192.168.1.42 \
--cookie COOKIE
Related
docker run -it --name mc3 dockerhub:5000/bitnami/minio-client
08:05:31.13
08:05:31.14 Welcome to the Bitnami minio-client container
08:05:31.14 Subscribe to project updates by watching https://github.com/bitnami/containers
08:05:31.14 Submit issues and feature requests at https://github.com/bitnami/containers/issues
08:05:31.15
08:05:31.15 INFO ==> ** Starting MinIO Client setup **
08:05:31.16 INFO ==> ** MinIO Client setup finished! ** mc: Configuration written to /.mc/config.json. Please update your access credentials.
mc: Successfully created /.mc/share.
mc: Initialized share uploads /.mc/share/uploads.json file.
mc: Initialized share downloads /.mc/share/downloads.json file.
**mc: /opt/bitnami/scripts/minio-client/run.sh is not a recognized command. Get help using --help flag.
dockerhub:5000/bitnami/minio-client - name of the image
It would be great if someone reach out to help me how to solve this issue as I'm stuck here for more than 2 days
MinIO has two components:
Server
Client
The Server runs continuously, as it should, so it can serve the data.
On the other hand the client, which you are trying to run, is used to perform operations on a running server. So its expected for it to run and then immediately exit as its not a daemon and its not meant to run forever.
What you want to do is to first launch the server container in background (using -d flag)
$ docker run -d --name minio-server \
--env MINIO_ROOT_USER="minio-root-user" \
--env MINIO_ROOT_PASSWORD="minio-root-password" \
minio/minio:latest
Then launch the client container to perform some operation, for example making/creating a bucket, which it will perform on the server and exit immidieatly after which it will clean up the client container (using -rm flag).
$ docker run --rm --name minio-client \
--env MINIO_SERVER_HOST="minio-server" \
--env MINIO_SERVER_ACCESS_KEY="minio-root-user" \
--env MINIO_SERVER_SECRET_KEY="minio-root-password" \
minio/mc \
mb minio/my-bucket
For more information please checkout the docs
Server: https://min.io/docs/minio/container/operations/installation.html
Client: https://min.io/docs/minio/linux/reference/minio-mc.html
I have a Docker container that handles an application. I am attempting to write tests for my system using npx and nightwatchJS.
I use CI and to run the tests for my entire suite I docker-compose build then run commands from outside of the container like so:
Example of backend python test being called (this works and is run as expected):
docker-compose run --rm web sh -c "pytest apps/login/tests -s"
Now I am trying to run an npx command to do some front-end testing but I am getting errors with something I cannot seem to diagnose:
Error while running .navigateTo() protocol action: An unknown server-side error occurred while processing the command. – unknown error: net::ERR_CONNECTION_REFUSED
Here is that command:
docker-compose run --rm web sh -c "npx nightwatch apps/login/tests/nightwatch/login_test.js"
The odd part of this is that if I go into bash:
docker-compose exec web bash
And then run:
npx nightwatch apps/login/tests/nightwatch/login_test.js
I don't get that error as I'm in bash.
This leads me to believe that I have an error in something with the command. Can somebody please help with this?
Think as containers as a separate computers.
When you run on your computer pytest apps/login/tests -s and then I run on my computer npx nightwatch apps/login/tests/nightwatch/login_test.js surely my computer will not connect to yours. I will get "connection refused" kind of error.
With docker run you run a separate new "computer" that runs that command - it has it's own pid space, it's own network address, etc. Than inside "that computer" you can execute another command with docker exec. To have you command to connect with localhost, you have to run them on the same "computer".
So when you run docker run with the client, it does not connect to a separate docker run. Either specify correct ip address or run both commands inside the same container.
I suggest to research how docker works. The above is a very crude oversimplification.
This is driving me crazy:
I created a new .Net Core Web App from VS2019, adding support for docker (linux containers).
Everything works fine: if I start the debugger from VS the image is built, the container is started and the web app is available at http://localhost:32772/weatherforecast.
Then I clean it all up, and try to build and run manually:
docker build -t webapp2 --file webapplication2/Dockerfile .
docker run --name webapp2 -p 5000:5000 -t webapp2
(or even docker run --name webapp2 -p 5000:5000 -e "ASPNETCORE_ENVIRONMENT=Development" -t webapp2)
Build runs successfully, and (apparently) run command works fine too:
But...surprise...This way I cannot reach the app anymore (at http://localhost:5000/weatherforecast)!
Tried almost anything, use internal ip address from inspect, changing ports and run commands, adding -e "ASPNETCORE_URLS=https://+:443;http://+:80", nothing seems to work.
So the question is: what kind of magic we have behind the VS debug command?
I tried to see what's there but I don't see anything useful:
docker run -dt -v "C:\Users\carlo\vsdbg\vs2017u5:/remote_debugger:rw" -v "C:\Progetti\prove\docker\API\WebApplication2:/app" -v "C:\Progetti\prove\docker\API:/src/" -v "C:\Users\carlo\.nuget\packages\:/root/.nuget/fallbackpackages2" -v "C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" -e "ASPNETCORE_ENVIRONMENT=Development" -e "NUGET_PACKAGES=/root/.nuget/fallbackpackages2" -e "NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages;/root/.nuget/fallbackpackages2" -P --name WebApplication2 --entrypoint tail webapplication2:dev -f /dev/null
Thanks!
Passing the port to docker run doesn't somehow override the port he application is running on. All you're saying is that you want port 5000 on the container exposed as port 5000 on the network. However, you app is running on 80, so that buys you nothing. You'd need -p 80:5000.
The ASPNETCORE_URLS environment variable is just way to configure the URLs of your app, which in a container is going to bind to https://+:443;http://+:80 by default. Setting the environment variable to the same thing again does nothing. You could do something like http://+:5000, which would then change the internal port to 5000 instead of 80, and then your original docker run command would have worked, because there's something actually running on port 5000.
I've been trying to debug a phoenix application.
To do so I used the following instructions:
- To set a break point: require IEx; IEx.pry
- To start a debugging server: iex -S mix phx.server
The problem comes when starting the server, the above instruction leads me to the elixir interactive shell (iex(1)>) and does not allow the server to run, from here if I execute the code manually it stops in the prys but I was hopping to have the server running and stop whenever a request hit the pry. Is there any solution?
I am currently using earlang 1.20, elixir 1.5 and phoenix 1.3
It is common behavior that the iex -S mix phx.server command opens an IEx shell. It runs the web server on the port configured for the Phoenix endpoint within the respective MIX_ENV simultaneously to that. For each IEx.pry() breakpoint it executes, it should prompt on the command line whether you want to open an IEx shell there.
Check which MIX_ENV your server is running in, e.g. by typing the following in the IEx shell:
Mix.env
And then find the configuration in the files within the config/ directory. The line should look like this:
config :nameofyourapp, Web.Endpoint,
http: [port: 4000],
Maybe something other than 4000 is configured there? Or maybe some other application, or even a previously started instance of your web application already listens on that port and therefore prohibits the debug server from binding on that port? In that case, shutdown other running mix phx.server processes.
I have an elixir (mix) application running on heroku
I'm having issues attaching a remote iex shell to this application
The application is launched via this command :
web: MIX_ENV=prod elixir --sname server -S mix run --no-halt
I have no trouble attaching a shell locally
MIX_ENV=prod elixir --sname server -S mix run --no-halt
iex --sname console --remsh server#mru2
However, when trying it on heroku I'm having the following issue :
heroku run "iex --sname console --remsh server#41959264-bef2-4d2e-b5de-6dcf618efa44"
Running `iex --sname console --remsh server#41959264-bef2-4d2e-b5de-6dcf618efa44` attached to terminal... up, run.4421
Erlang/OTP 17 [erts-6.4] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false]
Could not contact remote node server#41959264-bef2-4d2e-b5de-6dcf618efa44, reason: :nodedown. Aborting...
It seems like the instance launched by heroku run cannot connect to the one running the server. I tried enforcing a common cookie, but to no avail.
What am I missing?
I'm almost positive that nodes running on Heroku dynos aren't permitted to communicate with each other. But as long as the cookie is shared between the two nodes and you are connecting to the right fully-qualified name, then the steps you took above are correct.