Docker Compose Restart options allow us to manage our Docker Containers. Basically, these are the containers that we create using Docker Compose YAML file.

If you are not aware of how Docker Compose works, you can check out a detailed post about the same.

Understand how Docker Compose Works

>>How to create multiple containers using Docker Compose?

In this post, we will take a look at how to use Docker Compose to restart containers automatically.

So let’s start.

1. The Docker Compose Restart Policies

With Docker Compose, we have four restart policies. Basically, each restart policy can help us take care of a particular situation with our Docker containers.

Below is a table summarizing the restart policies.

“no” Never attempt to restart a container even if it crashes or stops altogether
alwaysIf the container stops for any reasons whatsoever, always attempt to restart it
on-failureOnly attempt to restart the container if it failed because of an error code
unless-stoppedAlways restart the container unless we (the developers) stop it explicitly.

Note here that the “no” restart policy explicitly has opening and closing quotes. This is because in a YAML file, a plain no is interpreted as false. Hence, to avoid the confusion, if we use the no restart policy, we have to always specify it as “no”.

2. Adding the Docker Compose Restart Policy

To see one of the policies in action, we will simulate a situation where our Docker container should be restarted.

In order to do so, we will make a slight change in the NodeJS Application from the previous post.

//defining the root endpoint
app.get('/', (req, res) => {
    process.exit(0)
    client.get('visits', (err, visits) => {
        res.send('Number of visits is: ' + visits)
        client.set('visits', parseInt(visits) + 1)
    })
})

Basically, we using process.exit(0) to exit our container process as soon as we hit the root end-point for our application.

In this context, 0 is the status code and typically means that the application stopped without any issues. Anything greater than 0 as a status code denotes an error status code.

Next, we add the restart policy in our Docker Compose YAML file.

version: '3'
services:
  redis-server: 
    image: 'redis'
  node-app:
    restart: always
    build: .
    ports:
      - "4001:8081"

As you can see, the restart property is added at the Docker Compose services level.

Currently, we have two services in our Docker Compose YAML file. The first is a Redis container. The second is the NodeJS application. We just want our NodeJS application to use restart: always property. Hence, we add this property under the node-app section.

3. Testing the Docker Compose Restart Policy

Now we can test our Docker Compose Restart Policy.

To do so, let’s first bring up our containers using Docker Compose Build command.

docker-compose up --build

We need the –build flag here since we made a minor code change in our NodeJS application. This will cause a Docker Compose force rebuild of our application.

docker compose restart nodejs app

At this point, if we hit the docker ps command we should see two containers running.

docker ps

To simulate a restart, we can now hit the end-point http://localhost:4001 from our browser.

As per our application login, the container will exit with status code 0 and the restart policy should kick in.

See below screenshot showing the NodeJS application starting up again.

docker compose restart nodejs

Also, if we check the running container using docker ps, we can see that the NodeJS Docker Container started recently.

docker container ps restart

Basically, our restart policy is working as expected.

Conclusion

With this, we have understood the various restart policies successfully. We have also experimented with Docker Compose restart always policy and how it can be leveraged in a real requirement.

Typically, web-servers do well to use the restart:always policy. Usually, these applications are public serving and we want them to be always up as much as possible.

However, worker processes can use restart:on-failure policy. This is because, we don’t want them to be always trying to restart even if they have finished their back-end process and stopped with status code of 0.

If you have any queries or comments, please sound off in the comments section below.

Happy Learning!


Saurabh Dashora

Saurabh is a Software Architect with over 12 years of experience. He has worked on large-scale distributed systems across various domains and organizations. He is also a passionate Technical Writer and loves sharing knowledge in the community.

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *