Bobcares

Docker Swarm Health Check

by | Apr 27, 2022

The Docker swarm health check ensures that the Docker service is running properly. A faulty service can cause a major incident!

At Bobcares, we offer solutions for every query, big and small, as a part of our Docker Hosting Support.

Let’s take a look at how docker health check is used to determine the health of a container that is running.

Docker Swarm Health Check

A health check is exactly that: an examination of the health of a resource. When we create a health check command, it tells us how to test a container to see if it’s working correctly. If we don’t define a health check, Docker won’t know if the services running inside our container are actually started.

Why do we need Docker Swarm Health Check

We don’t need a health check for a simple website running on nginx. However, in a production environment, multiple processes may crash.

Because the container is running and the service is running within a Docker Swarm, the Swarm will believe that everything is fine. As a result, the Swarm believes everything is fine and will not restart the container, causing it to stop working.

There are five properties in the Docker Compose Healtcheck:

  • test: This property is the container’s health check and specifies the command that will be executed. If everything is set up correctly, this command MUST be available and working.
  • interval: This property specifies the number of seconds to wait before performing the health check, as well as the frequency with which subsequent health checks will be performed.
  • timeout: This property specifies how long Docker waits for an exit code from our health check command before declaring it failed.
  • retries: The number of consecutive health check failures required to declare a container unhealthy is specified by this property.
  • start_period: This property specifies how long our container will take to boot up. Health checks with an exit code greater than zero will not mark the container as unhealthy during this time; however, health checks with a status code of 0 will mark the container as healthy.

For example , we have created a docker-compose.very-simple-web.yml which will use curl based health check.

Please keep in mind that this health check is based on curl. To use this health check, make sure curl is installed on the image that will be used to run the service.

If curl isn’t available, another popular health check is wget, which looks like this:
wget --no-verbose --tries=1 --spider http://localhost || exit 1

Simply replace the curl command in the compose file that was previously defined.

Often used Docker swarm health checks

 

  • WGET

    healthcheck:
    test: wget --no-verbose --tries=1 --spider http://localhost || exit 1
    interval: 60s
    retries: 5
    start_period: 20s
    timeout: 10s

  • CURL

    healthcheck:
    test: curl --fail http://localhost || exit 1
    interval: 60s
    retries: 5
    start_period: 20s
    timeout: 10s

  • What should we do if we don’t have access to CURL/WGET?

    If we’re using an image that doesn’t include curl or wget, we’ll need to install them. Add an install command to our Dockerfile to accomplish this.

    curl

    RUN apk --update --no-cache add curl

    wget

    RUN apt-get update && apt-get install -y wget

    However, keep in mind that if we add curl or wget, we may also add all of their attack surfaces. A good workaround is to write our own programme, which we can then include in the docker health check test command.

    A custom Docker swarm health check

    Compared to curl or wget, the custom health check avoids all of the drawbacks of using an external tool:

  • Because we’re using the same runtime as our main app, we don’t need to install any additional prerequisites for our health check.
  • We can choose which logic to include in our health check and keep it private, so that only the Docker platform can run it.
  • The disadvantage is that we’ll have to write and maintain our own code. However, because this will be written in the same language as our app, it should be a lot easier to accomplish than writing a complex curl or wget command.

    [Looking for a solution to another query? We are just a click away.]

    Conclusion

    In short, starting a Docker container does not necessarily imply that our application is running and performing as intended. Docker health checks can be quickly implemented to identify potential software bugs before they become a major issue.

    PREVENT YOUR SERVER FROM CRASHING!

    Never again lose customers to poor server speed! Let us help you.

    Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

    GET STARTED

0 Comments

Submit a Comment

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

Never again lose customers to poor
server speed! Let us help you.

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF