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 -qlists only container IDs of running containersdocker stopreceives 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 -aqlists ALL container IDs (running and stopped)docker rmremoves 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:
