Automatically Start Docker Containers on Server Restart or When Stopped

Karthik S
3 min readOct 9, 2024

--

In the world of containerization, Docker has emerged as a powerful tool that allows developers and organizations to run applications in isolated environments. However, one common issue many users face is the need to manually restart Docker containers after a server restart or unexpected shutdown. This can be problematic, especially in production environments where uptime is essential.

The Problem with Stopped Containers

We have encountered a significant issue related to Docker containers being stopped due to server interruptions, whether from memory issues or other unexpected errors. When our servers stop or restart, the services (Docker containers) do not automatically resume operation. Instead, we need to manually start these containers each time the server is rebooted or halted. This adds unnecessary overhead and potential downtime, which can affect user experience and service reliability.

Prerequisite

Before implementing the automatic restart policy for your Docker containers, it’s essential to ensure that Docker itself is configured to start on boot. You can do this using systemd. Follow the instructions provided in the Docker documentation to enable Docker to start automatically when your server boots up. This step is crucial to ensure that your containers can restart as intended after a reboot.

Why We Need Automatic Restart Policies

Implementing an automatic restart policy for Docker containers is crucial for several reasons:

  • Uptime Assurance: In production environments, maintaining uptime is essential. Any downtime can lead to lost revenue, decreased user satisfaction, and damage to reputation.
  • Reduced Manual Intervention: Automating container restarts reduces the need for manual intervention, allowing your operations team to focus on more critical tasks.
  • Consistency: Ensures that services are consistently available, regardless of underlying server issues.

Understanding the unless-stopped Policy

The unless-stopped restart policy is particularly useful for ensuring that your containers restart automatically unless you have explicitly stopped them. This means that if your server goes down or the Docker daemon is restarted, your containers will come back online without requiring manual intervention.

How to Implement Restart Policies

Using Docker CLI

If you’re running a Docker container directly using the command line interface (CLI), you can set the restart policy with the following command

docker run -d --restart unless-stopped my-container

This command runs the container in detached mode and ensures it will restart automatically unless you stop it manually.

Updating an Existing Container

If you want to change the restart policy for an already running container, you can use the following command

docker update --restart unless-stopped my-container

This command updates the restart policy of the specified running container, ensuring it will follow the unless-stopped policy going forward.

Using Docker Compose

For those using Docker Compose , you can easily set the restart policy in your compose.yml file. Here’s an example of how to do that

version: '3'
services:
app1:
image: my-app1-image
container_name: app1-container
ports:
- "8080:8080"
restart: unless-stopped
# Other options like environment, volumes, etc.

In this configuration, the restart: unless-stopped line ensures that the container will restart automatically after a server reboot or Docker daemon restart, keeping your application running smoothly.

Conclusion

Automatically restarting Docker containers is a vital practice for maintaining uptime and service reliability, especially in production environments. By utilizing the unless-stopped restart policy and ensuring that Docker is configured to start on boot, you can ensure that your containers come back online after a server restart or if they were stopped without requiring manual action. This not only saves time and effort but also enhances the overall stability of your applications.

--

--

Karthik S
Karthik S

Written by Karthik S

🚀 DevOps Engineer | Exploring cloud, automation, and infrastructure

No responses yet