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.
A health check is considered passing if (1) its HTTP response code is between 200 and 399 inclusive, and (2) its response is received within the timeout_seconds period.
Usage
You can configure your sloppy.json or sloppy.yml to run the following health_checks on your application:
• timeout_seconds (default: 20)
Time (in seconds) until the health check will be marked as failed.
• interval_seconds (default: 60)
Time interval (in seconds) between repeating the health check.
• max_consecutive_failures (default: 3)
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 (default: 300)
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 (default: HTTP)
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: 3Let’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
}
],}