Is there any way to tell docker not to start previously-running containers at startup?
I mean: I do know about the restart policy setting, and in fact I want it set to “always”, as I want docker to automatically restart my services (started via compose) in case they fail. However, I don’t want them to be started again automatically at system boot, even if they were active when docker was shutdown.
Some more context, in order to better understand the situation: the problem is how to deal with a non-controlled shutdown of a server running docker services (i.e. because of a server failure or a power loss), when this server belongs to a redundant cluster in which another server will immediately take hand and start the services itself (this is done using corosync / pacemaker).
This part works fine, but when the failed server is restarted, it automatically restarts all containers, as they were active when server got down. I don’t want this to happen, as services are yet running in the redundant server (and they are publishing their functions via individual IPs each, so having services active in both servers at the same time causes network problems).
What about “unless-stopped” or “on-failure” instead of “always” ? If none of them is acceptable for you, the only solution I can think of is disabling the docker service in Systemd the system has systemd. You could start the docker.service manually or programmatically but it would not start on boot.
The containers would still start when you start the daemon unless you remove the docker data folder.
Other solution is running each docker compose stack as a systemd service. This is actually how podman works
Hi, and thank you for the answer. I already tested the “on-failure” setting, and it’s not helping because, upon reboot, from docker’s daemon perspective the containers ended with error, so it starts them again. I haven’t tested the “unless-stopped” yet, but I’m 99.9% confident that it will do the same.
Regarding the “cleaning docker data folder” option you mention: cleaning up the whole docker data folder is not an option, as I would then also lose the loaded images. ¿Is there a way I can only remove the containers’ information from the data folder? I’ve seen that there exists a /var/lib/docker/containers folder but I’m not sure if emptying this folder is a sane thing to do…
Regarding setting the docker stack as a system service, I’m not really sure what you mean by that: I’m already using a service file to tell docker-compose to start up the services. The problem is that docker service, which is started before my service, is yet automatically restarting the containers, which is precisely the thing I’m trying to avoid…
I just wanted to mention those restart policies, but I suspected that wouldn’t be enough for you.
You can keep an exported version for each image if you want so you can load them again later without downloading everything again. /var/lib/docker/containers contains some metadata but not the containers filesystem. I wouldn’t touch those folders unless there is an emergency when you take the risk of making the situation worse. Actually I don’t think that would happen, but if you have other option, don’t try it in a production system.
If you have a service I don’t see why you need the restart policy. I would try to use the restart parameter in the systemd service file: systemd.service
I haven’t tried it yet but my guess is if you start each service after the operating system booted, the service would keep the containers running but would that service would not start automatically if it were disabled. Docker would not start those either without the restart policy “always”.
I am not sure, how you could do this with the docker-compose command which is not a service process so there is a chance I didn’t understand your current solution.
Can you describe that with more details? How those service files look like?
You could also consider using Docker Swarm or Kubernetes instead of just Docker Compose.
OK, thanks for the answer. I think that, for my case, I will need to stick to use “no” as restart policy, and then having some kind of external monitoring that locally restarts services in case they crash.