dockerdocker-composehealth-checkdocker-healthcheck

Set the 'start-interval' of a healthcheck in docker-compose.yml


I am deploying some services using Docker Compose. I want to check that my containers are healthy using healthcheck (see Docker Compose documentation here).

Let's consider the following code. It works fine, except when I uncomment the last line:

# docker-compose.yml

version: "3.8"

services:
  postgres:    # this is just an example, please don't focus on that particular image
    image: postgres:15-alpine
    healthcheck:
      test: pg_isready -d my_db -U my_user    # again, the command here is not my point, nor the env, feel free to change it
      interval: 60s
      start_period: 30s
      # start_interval: 5s # → this line is commented because it raises an error! Why?

This page of the Dockerfile documentation describes the difference between various settings in the HEALTHCHECK instruction. It details the difference between the option interval and the option start-interval.

Uncommenting the last line would raise the following exception, but why? Admittedly, I haven't seen start_interval mentioned in the Docker Compose doc, it just felt intuitive...

validating /my_path/docker-compose.yml: services.postgres.healthcheck Additional property start_interval is not allowed

The start_period option has been added in file format 3.4 (release note). Am I right assuming that start_interval hasn't been introduced and cannot be parsed by Docker Compose yet? Am I the only one needing this feature?

Any alternative solution? My docker-compose.yml gathers many services that I want to healthcheck. I'd like to avoid having a Dockerfile for each of them: wherever possible, I lean on environment variables to custom default images and I'm simply putting the healthcheck instructions in my docker-compose.yml.


Solution

  • Answering my own question for future readers.

    This is a new feature in Docker Compose. It has already been implemented but a few days ago. I was definitely not the only one frustrated by this lack!

    Here is the corresponding pull request which has been merged and released (release note of compose-go and release note of docker compose).

    Thus, updating my version of Docker Compose to v2.20.2 fixed the issue.