PyCharm debugger stopping containers after "Waiting for connection" ends - debugging

I am trying to debug docker-compose containers in PyCharm.
Here is how my run configuration looks like:
Note that it is a Django app. When I try to start the debugger it is successfully starting all containers and I can access the app on the browser for a short amount of time. Also there is a background task running "Waiting for connection"
Right after it ends, the containers are suddenly stopped.
What am I doing wrong?

Here is what I did to fix this:
Moved the entrypoint to the docker-compose file instead of the Dockerfile
Changed the port to 8000 from 8050
I have no idea why this matters but it fixed it.

Related

How to automatically start docker container on windows boot ~ Wait for docker to be running

I have a container that I pretty much need every time when starting my development PC, so I am trying to get it to autostart.
I have already written a .bat file that works fine for starting the container once docker is up, and have put that into the autostart folder on windows but...
...when starting my PC, that .bat executes before docker has started running, and thus terminates without starting the container. Once docker is up and running, I can use the .bat manually to start it just fine.
So here's my question: Is there anything I can add to my .bat to tell it to wait for docker to be running before trying to start the container?
Currently, the bat simply says docker-compose up and nothing else.
Add
restart: unless-stopped
or
restart: always
to the container in your docker-compose.yml, then use docker-compose up manually once more. This will make Docker to start the container after Docker itself is started.

Fail to start tasks/services in Docker Swarm: hnsCall failed in Win32: The parameter is incorrect

I am trying the Docker Get Started tutorial, Part 3 (Services). So the part where I need to init a swarm and deploy a stack, all my service status is rejected:
The full error (using --no-trunc) is:
hnsCall failed in Win32: The parameter is incorrect. (0x57)
Here are the steps I am doing:
Ensure my image is correct (the docker run works well, I accessed localhost:4000 successfully). Then I stopped the container to make sure it does not interfere.
When I init the swarm, it says I have multiple addresses, so I chose a random one (I tried with either of them, same result) using --advertise-addr.
docker stack deploy works, but when I check the status with docker service ps, none of them are up. localhost:4000 has no listener.
Note: I switched Docker to a Windows container.
I am new to Docker and this is beyond me. Can anyone please suggest a solution/debug way?
I tried everything but cannot get it to run on a Windows container so I switched to Linux container. The Get Started part 3 runs well.

AWS ECS trouble - Running shell script to boot program

I am trying to run a Docker image on amazon ECS. I am using a command that starts a shell script to boot up the program:
CMD ["sh","-c", "app/bin/app start; bash"]
in order to start it because for some reason when I run the app (elixir/phoenix app) in the background it was crashing immediately but if I run it in the foreground it is fine. If I run it this way locally, everything works fine but when I try to run it in my cluster, it shuts down. Please help!!
Docker was supposed to keep track of your running foreground process, if the process stop, the container stop. The reason your container work when you use command with "bash" because bash wasn't stop.
I guess you use she'll script to start an application that serve in background like nginx or a daemon. So try to find an option that make the app running foreground will keep your container alive. I.e nginx has an option while starting "daemon off"
for some reason when I run the app (elixir/phoenix app) in the background it was crashing immediately
So you have a corrupted application and you are looking for a kludge to make it looking like it somewhat works. This is not a reliable approach at all.
Instead you should:
make it working in background
use systemctl or upstart to manage restarts of Erlang VM on crashes
Please note that it matters where you have your application compiled. It must be the exactly same architecture/container as the production one, with same Erlang, Elixir, OS versions, otherwise nobody guarantees it will be robust or even working.

Docker container stop when mac sleep

Since a few days my docker containers are all stopping when the computer sleep for something like 20min.
It was not doing that before, I have no logs in my containers, everything seems fine.
Do you have any idea why this is happening ?
I have the same, but I found solution at Github: https://github.com/docker/for-mac/issues/85#issuecomment-314054172
I'm now running 17.06.0-ce-mac17 (18432) and after changing the settings to "No proxy" I haven't had any problems.

Running an docker image with cron

I am using an image from docker hub and it uses cron to perform some actions after some interval. I have registered and pushed it as described in documentation as a worker process (not a web). It also requires several environment variables.
I've run it from command line, e.g. docker run -t -e E_VAR1=VAL1 registry.heroku.com/image_name/worker and it worked for few days, then suddenly stopped and I had to run the command again.
Questions:
Is this a correct way to run a docker (as worker process) in Heroku?
Why might it stop running after few days? Is there any logs to check?
Is there a way to restart the process automatically?
How properly set environment variables for the docker in Heroku?
Thanks!
If you want to have this run in the background, you should use the -d flag to disconnect stdin and stdout, and not -t.
To check logs, user docker logs [container name or id]. You can find out the container's name and id using docker ps -a. That should give you an idea as to why the container stopped.
To have the container restart automatically add the --restart always flag when you run it. Alternatively, use --restart on-failure to only restart when it exited with a nonzero exit code.
The way you set environment variables seems fine.

Resources