Container Lifecycle Management and Restart Policies

1. Understanding the Container Lifecycle

A container isn't just "on" or "off." It moves through several distinct states from its creation to its final removal. Understanding this lifecycle is key to managing your containers effectively.

The diagram below provides a complete map of the container lifecycle, showing the states and the commands that trigger transitions between them.

Let's break down the most common commands and states:

• docker create [image]: This command prepares a container from an image but does not start it. The container exists in the created state, with its filesystem ready. You can see it with docker ps -a.
• docker start [container]: This starts a container that is in the created state, moving it to the running state.
• docker run [image]: This is a convenient shortcut that combines docker create and docker start into a single command. It creates and immediately starts a new container.
• docker stop [container]: This sends a SIGTERM signal to the main process inside the container, giving it a chance to shut down gracefully. After a timeout period (default 10 seconds), it sends a SIGKILL if the process hasn't exited. The container moves to the exited state.
• docker restart [container]: A handy command that is equivalent to running docker stop followed by docker start on a container.
• docker rm [container]: This permanently removes a container. It can only be used on containers in the created or exited state. To remove a running container, you must first stop it or use the force flag (docker rm -f).

For a quick demonstration of these core commands, the following video is a helpful practical walkthrough.

The distinction between commands that manage processes (start, stop) and those that manage the container's "file" on disk (create, rm) is a core concept. To explore this and practice these commands with hands-on challenges, the "Docker 101" skill path from iximiuz Labs is an excellent resource.

2. Automatic Recovery with Restart Policies

Manually restarting failed containers is not a scalable or reliable strategy in a production environment. Docker provides restart policies to automate this process, significantly improving the resilience of your applications.

A restart policy is set with the --restart flag during docker run or can be modified on a running container using docker update.

There are four main policies:

• no: The default policy. The container will not be restarted if it stops.
• on-failure: The container restarts only if it exits with a non-zero exit code (indicating an error). You can also specify a maximum number of retries (e.g., on-failure:5).
• always: The container will always be restarted if it stops, for any reason. This includes when the Docker daemon itself restarts (e.g., after a host reboot).
• unless-stopped: Similar to always, but with one key exception: if you manually stop the container with docker stop, it will not be restarted automatically, even after a Docker daemon restart.

The video below offers a clear demonstration of how to apply and test these policies.

3. Choosing the Right Restart Policy

Selecting the correct restart policy is crucial and depends on the container's role. Your DevOps experience with service management will make these choices intuitive.

Here's a summary of best practices based on the resources:

• Production Web Services: Use unless-stopped. This is often the best choice. It ensures your service recovers from crashes and reboots but gives you the control to stop it for maintenance without it popping back up unexpectedly.
• Databases & Critical Infrastructure: Use always. These are services you almost never want to be down. always ensures that even if a container is accidentally stopped, it will restart when the Docker daemon does.
• Batch Jobs & One-Off Tasks: Use on-failure. This is ideal for tasks that should retry if they fail but stay stopped once they complete successfully. Limiting the retries (on-failure:3) can prevent a faulty job from getting stuck in a restart loop.
• Development & Debugging: Use no. When a container crashes, you often want it to stay in the exited state so you can inspect its logs (docker logs) and final state (docker inspect) to diagnose the problem.

An Important Caveat for Kubernetes

The OneUptime article correctly points out a critical consideration for your goal of working with Kubernetes: you generally do not use Docker's restart policies when an orchestrator is involved.

Kubernetes has its own, more sophisticated mechanisms (like ReplicaSets and Deployments) for managing the container lifecycle and ensuring the desired number of replicas are running. The orchestrator takes over responsibility from the Docker daemon, so you let Kubernetes handle restarts.

docker run -d --name my-db --restart always postgres:14

docker run -d --name my-job --restart on-failure:3 my-processing-image

Conclusion

In this lesson, you've gained control over the entire lifecycle of a container. You now know how to manually move containers between states and, more importantly for a production environment, how to configure them for automatic recovery.

Key Takeaways:

• Containers progress through a lifecycle of states: created, running, exited, and removed.
• Commands like docker start, stop, restart, and rm allow you to manage this lifecycle manually.
• Restart policies (no, on-failure, always, unless-stopped) are essential for building resilient applications by automating recovery from failures.
• The choice of restart policy depends on the container's purpose, with unless-stopped being a common default for services and on-failure for jobs.
• When using an orchestrator like Kubernetes, you rely on the orchestrator's controllers for lifecycle management, not Docker's built-in restart policies.

In our next lesson, we will cover another practical runtime management skill: Copying files between the host and running containers using docker cp for debugging. This is an invaluable tool for inspecting state or injecting configuration into live containers.