So, your container is up and running, but is the application inside really working the way it is supposed to? While dependencies are fine to make sure that your apps are started in the appropriate order, health checks take things a step further and enable you to check if an application is really working and in case your application is unhealthy it will be restarted.

Health Checks are also important for rolling deployments. When you restart an app, first the new container will be started and when it is in "running" state, the old one gets killed. 

The problem here is that "running" means docker ps says it is "running" but sometimes that does not mean that the app is ready for connections. Maybe a database first imports data or npm install is triggered first. Health Checks make sure the app is really ready and only when this is the case the old app will be killed and you have no downtime.

How to configure health checks using the UI?

Let's assume we want to deploy ghost a lightweight CMS. Under "Basic Setup" that's all we need to do:

As you can see this app is exposed on port 2368 which is an important info for health checks. Now go to the "Health Checks" tab and enable this feature:

You can choose between HTTP and TCP checks. For HTTP you can configure a path like /health.html (file must exist in your app). TCP takes the exposed port from the "Basic Setup" tab and will periodically knock on that port. An example to use a TCP check would be mysql.

Usage

You can configure your sloppy.json or sloppy.yml to run the following health_checks on your application:

timeout_seconds
Time (in seconds) until the health check will be marked as failed.

interval_seconds
Time interval (in seconds) between repeating the health check.

max_consecutive_failures
If the maximum amount of failed health checks is reached, the application will be restarted.

path
HTTP checks only: Defines the path that is supposed to be checked (e.g. /index.html).

grace_period_seconds
The time (in seconds) before the first health check will be performed, after your application has started. Especially useful if a Docker pull request is needed in order to start the app.

type
Setting this value to “HTTP”/”TCP” it will check if the application is answering the requests.

Examples

version: "v1"
project: "ghost"
services:
  frontend:
    booh:
      image: "ghost:1.16.1"
      instances: 1
      mem: 512
      domain: "$GHOST_BASE_URL"
      port: 2368
      volumes:
        - container_path: "/var/lib/ghost/content"
          size: "8GB"
      env:
        - URL: "$GHOST_BASE_URL"
      healthchecks:
        - timeout_seconds: 10
          interval_seconds: 10
          max_consecutive_failures: 3
          path: "/"
          type: "HTTP"
          grace_period_seconds: 3

Let’s say, you want to check if your Apache web server is answering to a HTTP request. The following example JSON does the trick:

{"health_checks": [
    {
        "timeout_seconds": 10,
        "interval_seconds": 10,
        "max_consecutive_failures": 3,
        "path": "/",
        "type": "HTTP",
        "grace_period_seconds": 3
    }
],}

Is your MySQL server answering on port 3306? Have sloppy.io check it for you. With the following JSON, the application will be restarted automatically if max_consecutive_failures reaches the defined value.

{"health_checks": [
    {
        "type": "TCP",
        "grace_period_seconds": 300,
        "interval_seconds": 60,
        "timeout_seconds": 20,
        "max_consecutive_failures": 4
    }
],}
Did this answer your question?