I run a handful of Docker containers on a single home-lab host. I previously wrote a manually triggered script that stops all the containers before updating the host operating system, then starts them again afterward. I originally did this in case Docker itself was updated during the process. Is this shutdown step actually necessary? If the Docker package or daemon is upgraded, will it stop and restart containers gracefully? What is the usual approach for handling host updates when a few minutes of downtime is acceptable?
3 Answers
If you were managing several hosts and needed near-continuous availability, you could move workloads between machines before updating one of them. For a small, single-host lab, that is generally overkill. Use restart policies, make sure important data is stored in persistent volumes with backups, and accept the brief outage during normal maintenance.
For a single home-lab machine, manually stopping everything usually isn't necessary. If the host update includes a reboot, the containers will go down either way. Set each container or Compose service to use a restart policy such as "unless-stopped" or "always", and Docker should bring them back after the host is online. A Docker daemon upgrade may briefly interrupt containers, but that is generally fine when a little downtime is acceptable.
Upgrading the Docker package normally restarts the Docker daemon, so containers can be interrupted during that operation. Enabling Docker's live-restore option in daemon.json can allow running containers to continue while the daemon is unavailable, reducing the need for a manual shutdown. It is still worth testing this with your setup, since not every daemon or container-related change behaves identically.
The important distinction is that the Docker service itself usually does restart during an upgrade. Containers do not simply keep running in every configuration unless live restore is enabled.
That is basically my approach too. I would only introduce multiple hosts or orchestration if the downtime actually becomes a problem; running a cluster just to avoid a short maintenance window can add more work than it saves.