I have docker container with installed and configured software.
There is no any programm supposed to be started/runned all the time.
What I want - its ability to start some command depending on external events. like:
docker exec mysupercont /path/to/mycommand -bla -for
docker exec mysupercont /path/to/myothercommand
But "exec" impossible when container is stopped, and also this container have some "working" data inside, which used for that commands, so I can't use
docker run ...
each time, because it recreate container from image and destroy my data.
What is the "right" and the "best" way to keep such container runned?
Which command I can start inside?
You do not need to perform each time
docker run is actually a sequence of two commands: "create" and "start".
When you run the container, you must specify the "
-i, --interactive=false Keep STDIN open even if not attached
-t, --tty=false Allocate a pseudo-TTY
docker run -it debian:stable bash
After the work was completed command specified at startup (in my example bash). For example, you perform the "exit". Container stops:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1329c99a831b debian:stable "bash" 51 seconds ago Exited (0) 1 seconds ago goofy_bardeen
Now you can start it again
docker start 1329c99a831b
The container is started and again executes the command "bash".
Connect to this session "bash" with the command
docker attach 1329c99a831b
To sum up: you have to understand the difference between the
Besides, look at the documentation for the role of parameters "
-i t" and "
-d" for the "Run"
Since you mentioned periodic tasks and you are probably using something like cron because of the way you want to use
docker exec, I have just the medicine for you. At least I ended up doing something like this.
FROM <some base>
CMD tail -f /dev/null
Run with the usual
docker run -d .... (I used
Setup host machines crontab, for example:
* * * * * docker exec mysupercont foo >> /var/log/foo.log 2>&1
* * * * * docker exec mysupercont bar >> /var/log/bar.log 2>&1
I find this solution nice as we get to rely on the ancient and proven crontab in a pretty default linux environment, while Docker handles your business logic's more exotic deps and environment variables. You can also set some limits if your periodic tasks get stuck & have memory leaks or whatever.
Tail will still causes some file operations from time to time.
Sleep Forever, without any side effects
# Ah, ha, ha, ha, stayin' alive...
while :; do :; done & kill -STOP $! && wait $!
How it works
while :; # Run an endless loop,
do :; # of do nothing,
done & # as background task.
kill -STOP $! # Stop the background task.
wait $! # Wait forever, because background task process has been stopped.
This whole business of whether or not you can start a stopped container, is dependant on how the container was originally created, i.e. run. If you ran a command that ended, or you exit an interactive command, e.g. bash, you can't start, restart or exec the stopped container. All you can do is remove it. It's junk.
But taranaki's last comment, use '-itd', seems to be what the docker ordered.
The container keeps running, and you can exec whatever you want, and you can stop, start or restart the container. Of course, this is just a preliminary finding based on the alpine image. Note, if you attach to the container, it will stop when you exit, but you can start it again.
I've used all of the proposed solutions here myself, but all of them do not handle SIGTERM signals coming from the Docker daemon when it wants to shut down the container (e.g.
docker stop $containername).
So I propose the following:
CMD sh -c 'trap "exit" TERM; while true; do sleep 1; done'
It is basically a short shell script that first intercepts ("traps") SIGTERM signals and then goes to sleep for a second in an infinite loop.
I mainly use it together with docker-compose and ofelia to supply side-car containers to backup some other service in another container (e.g. MariaDB databases).
docker run -d --name=name container tail -f /dev/null
This is a very well explained question. See another similar post here.