Docker Container Lifecycle and Inspection - Part 2: Container Persistence and Restart Policies
Master container data persistence, restart policies, and bulk operations. Learn how data survives container restarts, configure automatic recovery, and manage multiple containers efficiently.
Container persistence and automatic recovery are critical for production environments. This tutorial covers how data persists across container restarts, configuring restart policies for automatic recovery, and efficiently managing multiple containers.
🎯 What You'll Learn: In this continuation tutorial, you'll discover:
- How container data persists across restarts
- Different restart policies and their use cases
- Bulk container operations for efficient management
- Container behavior differences with and without commands
🔄 Container Data Persistence
Understanding how data behaves when containers stop and start is crucial for application design and data management.
Prerequisites
Before we begin, make sure you have:
- Completed Part 1: Container Lifecycle Management
- Understanding of basic Docker container operations
- Familiarity with container inspection techniques
Creating a Persistent Container
Let's create a container and add some data to test persistence:
docker run -d --name persistent-container ubuntu sleep 7200
Output:
24860d0e47c13b69470c652d42fd6180d7301a2f013ef1c4a778a2fc1004cf23
This creates a container that will run for 2 hours (7200 seconds), giving us time to test persistence.
Adding Data to the Container
Enter the container and create some test data:
docker exec -it persistent-container /bin/bash
Inside the container, create various types of data:
echo "This is persistent data" > /home/data.txt
echo "Container restart test" > /home/restart-test.txt
mkdir /home/test-directory
echo "Directory content" > /home/test-directory/file.txt
exit
This creates:
- Text files in
/home/
- A directory with nested content
- Different types of filesystem modifications
Testing Container Restart
Now let's test what happens when we stop and restart the container:
docker stop persistent-container
Output:
persistent-container
Check the container status:
docker ps -a
Output:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
24860d0e47c1 ubuntu "sleep 7200" 3 minutes ago Exited (137) 6 seconds ago persistent-container
41ffeef865a4 ubuntu "/bin/bash" 12 minutes ago Exited (0) 12 minutes ago short-lived-ubuntu
Restarting and Verifying Data
Restart the container and check if our data survived:
docker start persistent-container
Output:
persistent-container
Verify the container is running:
docker ps
Output:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
24860d0e47c1 ubuntu "sleep 7200" 3 minutes ago Up 6 seconds persistent-container
Checking Data Persistence
Now let's verify that all our data survived the restart:
docker exec persistent-container ls -la /home/
docker exec persistent-container ls -la /home/test-directory/
docker exec persistent-container cat /home/data.txt
docker exec persistent-container cat /home/restart-test.txt
Output:
# Directory listing
total 8
drwxr-xr-x. 1 root root 68 Sep 10 21:03 .
drwxr-xr-x. 1 root root 30 Sep 10 21:00 ..
-rw-r--r--. 1 root root 24 Sep 10 21:02 data.txt
-rw-r--r--. 1 root root 23 Sep 10 21:02 restart-test.txt
drwxr-xr-x. 2 root root 22 Sep 10 21:03 test-directory
drwxr-x---. 2 ubuntu ubuntu 57 Aug 5 02:14 ubuntu
# Test directory contents
total 4
drwxr-xr-x. 2 root root 22 Sep 10 21:03 .
drwxr-xr-x. 1 root root 68 Sep 10 21:03 ..
-rw-r--r--. 1 root root 18 Sep 10 21:03 file.txt
# File contents
This is persistent data
Container restart test
✅ Data Persistence: Container filesystem changes persist across stop/start cycles. The container's writable layer maintains all modifications until the container is removed.
Monitoring Container State Changes
Track container state transitions:
docker inspect --format="{{.State.Status}}" persistent-container
docker stop persistent-container
docker inspect --format="{{.State.Status}}" persistent-container
docker start persistent-container
docker inspect --format="{{.State.Status}}" persistent-container
Output:
running
exited
running
This demonstrates the state transitions: running → exited → running.
🔁 Container Restart Policies
Restart policies define how containers should behave when they exit or when the Docker daemon restarts.
Available Restart Policies
Policy | Description | Use Case |
---|---|---|
no | Never restart automatically | Default behavior, manual control |
always | Always restart on exit | Critical services, daemon processes |
on-failure | Restart only on non-zero exit | Applications that may exit normally |
unless-stopped | Always restart unless manually stopped | Services that should survive reboots |
Creating Containers with Restart Policies
docker run -d --name auto-restart --restart=always ubuntu sleep 60
docker run -d --name restart-on-failure --restart=on-failure ubuntu sleep 60
Output:
f7752b1afff069a5a97476b9d05897bb828265deda5008a8d1b696915c212d46
9672ce9d1e6acab8a0142766d1421064d3afb1688234aa321359af4233c9a992
Inspecting Restart Policies
Check the configured restart policies:
docker inspect --format="{{.HostConfig.RestartPolicy.Name}}" auto-restart
docker inspect --format="{{.HostConfig.RestartPolicy.Name}}" restart-on-failure
Output:
always
on-failure
Observing Restart Policy Behavior
The containers above will behave differently when their sleep 60
command completes:
- auto-restart: Will automatically restart when sleep exits (exit code 0)
- restart-on-failure: Will NOT restart when sleep exits normally (exit code 0)
💡 Restart Policy Logic: The always
policy restarts regardless of exit code, while on-failure
only restarts on non-zero exit codes (errors).
🔄 Understanding Container Command Behavior
Let's examine how different commands affect container lifecycle:
Container Without Explicit Command
docker run -d ubuntu
Output:
961fd11bd38252a33ab1b69e4461784f334cbe6db5b59c87d3b49f0866104996
Container With Long-Running Command
docker run -d ubuntu sleep 3600
Output:
b3619700c89302e7e86fb8ef86f60a9b357bd0a6a629429afa960b18f4be0ebe
Examining the Difference
docker ps -a
Output:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b3619700c893 ubuntu "sleep 3600" 6 seconds ago Up 6 seconds naughty_feynman
961fd11bd382 ubuntu "/bin/bash" 14 seconds ago Exited (0) 14 seconds ago modest_keldysh
9672ce9d1e6a ubuntu "sleep 60" 2 minutes ago Exited (0) About a minute ago restart-on-failure
f7752b1afff0 ubuntu "sleep 60" 2 minutes ago Up 45 seconds auto-restart
24860d0e47c1 ubuntu "sleep 7200" 9 minutes ago Up 3 minutes persistent-container
41ffeef865a4 ubuntu "/bin/bash" 18 minutes ago Exited (0) 18 minutes ago short-lived-ubuntu
Key Observations:
Container | Command | Status | Reason |
---|---|---|---|
ubuntu (no args) | /bin/bash | Exited (0) | No input to bash, exits immediately |
ubuntu sleep 3600 | sleep 3600 | Up 6 seconds | Sleep keeps container running |
auto-restart | sleep 60 | Up 45 seconds | Restarted automatically after exit |
🗂️ Bulk Container Operations
Managing multiple containers efficiently is essential in production environments.
Stopping All Running Containers
docker stop $(docker ps -q)
Output:
b3619700c893
f7752b1afff0
24860d0e47c1
This command:
docker ps -q
lists only container IDs of running containersdocker stop
receives these IDs as arguments- All running containers are stopped simultaneously
Removing All Containers
docker rm $(docker ps -aq)
Output:
b3619700c893
961fd11bd382
9672ce9d1e6a
f7752b1afff0
24860d0e47c1
41ffeef865a4
This command:
docker ps -aq
lists ALL container IDs (running and stopped)docker rm
removes all listed containers- Cleans up the entire container environment
Verifying Clean State
docker ps -a
Output:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
The empty output confirms all containers have been removed.
🎯 Key Takeaways
✅ Remember These Points
- Data Persistence: Container filesystem changes persist across stop/start but not removal
- Restart Policies: Choose policies based on application criticality and failure handling needs
- Command Behavior: Containers exit when their main process completes
- Bulk Operations: Use command substitution for efficient multi-container management
📖 Further Reading
Official Resources
🎉 Comprehensive Mastery! You now understand the complete Docker container lifecycle, from creation through persistence, restart policies, and bulk management. These skills are essential for production container deployments.
💬 Discussion
I'd love to hear about your container persistence and restart policy experiences:
- What restart policies work best for your application stack?
- How do you handle data persistence in your container deployments?
- What bulk management scripts or tools have you found most useful?
- Any challenging scenarios with container lifecycle management?
Connect with me: