10 Docker Healthcheck Best Practices

Docker containers have revolutionized the way we deploy and run applications. They are easy to use, portable, and offer great performance. However, running containers in production can be challenging, and one of the biggest challenges is monitoring the health of containers and applications.

Docker containers are ephemeral, which means they can be created and destroyed at any time. This makes it difficult to monitor the health of containers and applications. To address this challenge, Docker introduced healthchecks in version

1. Use a healthcheck to determine if your container is healthy

If you’re using docker containers in production, it’s important to be able to determine the health of your containers. A healthcheck is a great way to do this. By default, docker will not check the health of your containers. This means that if your container crashes, you will not be notified.

A healthcheck will help you avoid this by periodically checking the health of your containers and reporting any issues. This way, you can be sure that your containers are always running smoothly.

There are many ways to configure a healthcheck, but the most important thing is to make sure that it covers all of the important aspects of your container. For example, you may want to check the status of your application, the database, and the network.

You can also use a healthcheck to monitor the resources of your container. This is especially important if you’re running multiple containers on the same host. By monitoring the resources of your containers, you can be sure that they’re not overloading the host.

Finally, you can use a healthcheck to trigger an action when a problem is detected. For example, you could send an email or Slack message to the team. This way, you can be sure that someone is always aware of the problem and can take action to fix it.

2. Use the HEALTHCHECK instruction in your Dockerfile

The HEALTHCHECK instruction tells Docker how to test a container to check that it’s still working. This is important because, even if a container is running, that doesn’t necessarily mean it’s healthy.

If you don’t use the HEALTHCHECK instruction, then Docker has no way of knowing whether or not your container is healthy. This can lead to problems down the road, such as when you try to scale up your application and new containers are created from an unhealthy image.

When using the HEALTHCHECK instruction, you need to specify two things:

1. The command that will be used to test the container
2. The interval at which the command will be run

For example, let’s say you have a web server container. A good healthcheck for this type of container would be to make an HTTP request to the server and check the response code.

Here’s how you would specify that in a Dockerfile:

HEALTHCHECK –interval=5m –timeout=3s \
CMD curl -f http://localhost/ || exit 1

This healthcheck will run every 5 minutes, with a timeout of 3 seconds. If the curl command fails (i.e. the server is down), then the container will be considered unhealthy.

It’s important to note that the HEALTHCHECK instruction is not a replacement for a proper monitoring solution. It’s simply a way to tell Docker whether or not a container is healthy.

3. Make sure you have a working CMD or ENTRYPOINT defined

If you don’t have a working CMD or ENTRYPOINT defined, your container will not be able to start properly. This is because the Docker engine needs a way to know what command to run when starting up a container. Without a CMD or ENTRYPOINT defined, the Docker engine will not know what to do, and the container will fail to start.

Additionally, it’s important to make sure that your CMD or ENTRYPOINT is actually executable. If it’s not, then the container will also fail to start.

To sum it up, making sure you have a working CMD or ENTRYPOINT defined is one of the most important best practices for Docker healthchecks.

4. Don’t use shell form for the HEALTHCHECK command

The shell form for the HEALTHCHECK command is simply a string that is executed by the shell. This means that if you use shell form, and your command fails, the healthcheck will also fail.

Instead, you should use exec form, which executes the command directly, without going through the shell. This way, if your command fails, the healthcheck won’t necessarily fail.

There are other benefits to using exec form as well. For example, you can use multiple commands in exec form, whereas with shell form, you can only use one command.

Overall, using exec form for the HEALTHCHECK command is a much better practice than using shell form.

5. Check that your application is listening on the correct port

If your application is not listening on the correct port, then it will not be able to accept connections from other containers. This can lead to a number of problems, such as:

– Your application will not be able to serve requests.
– Other containers will not be able to connect to your application.
– Your application will not be able to connect to other containers.

By checking that your application is listening on the correct port, you can avoid these problems.

6. Test the actual functionality of your app, not just its process

When you test only the process, you’re not testing whether the app is actually doing what it’s supposed to do. For example, let’s say you have a web app that needs to connect to a database. If you only test the web app’s process, you won’t know if the database connection is working. But if you test the actual functionality of the app by trying to access the database, you’ll be able to tell if there are any problems.

This is important because it’s often the case that an app can appear to be running fine when its process is up, but it’s actually not doing what it’s supposed to do. By testing the actual functionality of the app, you can be sure that it’s really working as it should.

7. Avoid using curl unless absolutely necessary

Curl is a great tool, but it’s not designed for use in healthchecks. It’s a general-purpose utility that wasn’t created with healthchecks in mind, so it doesn’t have any of the features that make it ideal for use in that context.

For example, curl doesn’t have any built-in retry logic, so if a website is down or slow to respond, curl will just keep trying until it times out. This can cause false positives in your healthcheck results, which can lead to unnecessary restarts or even worse, missed failures.

Additionally, curl doesn’t handle redirects well. If a website redirects to another page, curl will follow the redirect and return the contents of the new page, instead of the original page that you were trying to check. This can also lead to false positives or missed failures.

Finally, curl is very verbose by default, so it will output a lot of information that you probably don’t need in a healthcheck. This can clutter up your logs and make it more difficult to debug problems.

For these reasons, it’s generally best to avoid using curl in docker healthchecks unless absolutely necessary. There are many other tools that are designed specifically for use in healthchecks, such as HTTPie, which can be a better choice in most cases.

8. Use –interval and –timeout flags

The –interval flag defines how often the healthcheck command is run, and the –timeout flag defines how long the command is allowed to run before it is considered a failure. By default, the –interval flag is set to 30 seconds and the –timeout flag is not set, which means that the healthcheck command will never time out.

It’s important to use both of these flags because they give you more control over when the healthcheck command is considered a success or a failure. For example, if you have a healthcheck command that takes a long time to run, you can use the –timeout flag to ensure that the command doesn’t take too long to complete.

Similarly, if you have a healthcheck command that is only successful occasionally, you can use the –interval flag to ensure that the command is run more frequently so that you can detect failures more quickly.

9. Run multiple commands with &&

If you have a long-running command that you want to run as part of your healthcheck, it’s important to include && so that the next command in the sequence only runs if the previous one succeeds. This is especially important for commands that launch other processes, like starting a web server.

For example, let’s say you want to start a web server as part of your healthcheck. You might be tempted to just do something like this:

CMD my_web_server.py

However, if my_web_server.py fails to start for some reason, the healthcheck will never get to the point where it can check the status of the web server. By adding &&, you can make sure that the second command in the sequence (in this case, curl) only runs if the first one succeeds:

CMD my_web_server.py && curl -f http://localhost:8080/

This is a much more robust way to write a healthcheck, and it will save you a lot of headaches down the road.

10. Use –retries flag

When a container is started, the healthcheck command is run to determine if the container is healthy. If the healthcheck command returns a non-zero exit code, the container is considered unhealthy and is restarted. However, sometimes the healthcheck command may return a non-zero exit code even when the container is healthy.

For example, if the healthcheck command is checking for a file that hasn’t been created yet, it will return a non-zero exit code. In this case, you don’t want the container to be restarted because it’s actually healthy, just waiting for the file to be created.

This is where the –retries flag comes in. It allows you to specify the number of times the healthcheck command can return a non-zero exit code before the container is considered unhealthy and is restarted. By default, the –retries flag is set to 3, but you can change it to any value you want.

For example, let’s say you have a container that is running a web server. The healthcheck command is checking for the existence of the index.html file. When the container is first started, the index.html file doesn’t exist yet, so the healthcheck command returns a non-zero exit code. However, once the web server creates the index.html file, the healthcheck command will return a zero exit code and the container will be considered healthy.

If you didn’t use the –retries flag, the container would be restarted three times before it would be considered healthy. However, if you set the –retries flag to 5, the container would be restarted five times before it would be considered healthy.

Using the –retries flag is a best practice because it prevents containers from being unnecessarily restarted.