Налаштування Docker Health Checks для надійного моніторингу контейнерів

Налаштування Docker Health Checks для контейнерів

Уявіть: контейнери висять у статусі Up, а додаток не відповідає. Розробники витрачають години на дебаг, не підозрюючи, що проблема — у відсутності health checks. Без них канарейка не свистить, і трафік іде в нікуди. Ми виправляємо це за один-два дні, залежно від складності стека. Відсутність health checks коштує годин простою та втрати клієнтів; налаштування окупається за перший же тиждень за рахунок скорочення інцидентів.

Головна проблема: розрив між «контейнер запущено» та «сервіс готовий»

Java-додатки з Hibernate та Liquibase можуть стартувати 40–90 секунд. За цей час Docker Compose піднімає залежні сервіси, які починають слати запити — і отримують Connection refused. Логи заповнюються помилками, розробник перезапускає docker compose up вручну і не розуміє, чому «іноді не працює». Або завислий worker: процес живий, CPU на нулі, але завдання не обробляються. Health check з реальною перевіркою бізнес-логіки зловить це там, де ps aux нічого не покаже.

За даними Docker HEALTHCHECK, це єдиний спосіб reliably визначити готовність сервісу всередині контейнера.

Чому start-period критичний для Java?

Параметр --start-period дає додатку час на ініціалізацію до початку перевірок. Без нього JVM не встигає завантажитися, і контейнер іде в restart loop. Оптимальне значення — на 10–20 секунд більше реального часу старту додатка. Для типового Spring Boot додатка з міграціями Liquibase це 60–90 секунд.

Як правильно налаштувати HEALTHCHECK?

Синтаксис HEALTHCHECK у Dockerfile

HEALTHCHECK --interval=30s --timeout=5s --start-period=60s --retries=3 \
    CMD curl -f http://localhost:8080/healthz || exit 1

Параметри важливі. --start-period=60s говорить Docker не враховувати перші відмови до закінчення періоду ініціалізації — без нього Java-додаток оголошується unhealthy раніше, ніж встигає запуститися. --timeout=5s обмежує час очікування однієї перевірки. --retries=3 — скільки послідовних відмов потрібно для переходу в unhealthy.

Для сервісів без curl можна використовувати нативні інструменти:

# PostgreSQL HEALTHCHECK --interval=10s --timeout=5s --retries=5 \
CMD pg_isready -U postgres -d mydb || exit 1
# Redis HEALTHCHECK --interval=10s --timeout=3s --retries=3 \
CMD redis-cli ping | grep PONG || exit 1
# Простий TCP-порт (коли немає curl) HEALTHCHECK CMD nc -z localhost 8080 || exit 1

Health Check у Docker Compose

Іноді зручніше визначати перевірку в compose.yaml, не чіпаючи Dockerfile — особливо якщо образ сторонній:

---
services:
  api:
    image: myapp:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/healthz"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 60s
    depends_on:
      postgres:
        condition: service_healthy

condition: service_healthy — це і є правильний спосіб вирішити проблему з race condition при старті. Сервіс api не запуститься, доки postgres не перейде в healthy. Без цього depends_on лише гарантує порядок старту контейнерів, але не готовність сервісу.

Що перевіряти в endpoint /healthz

Мінімальний health endpoint повинен перевіряти готовність самого додатка, а не просто відповідати 200. Для stateful-сервісів має сенс розділити /healthz/live (процес живий) та /healthz/ready (готовий приймати трафік). Docker HEALTHCHECK достатньо перевіряти /healthz/live — оркестрація в Kubernetes використовує обидва, але для Docker Swarm та Compose вистачає одного.

Для Worker-процесів без HTTP: скрипт, який перевіряє timestamp останньої успішно обробленої задачі у файлі або Redis-ключі, працює надійніше, ніж перевірка просто живості процесу.

Що входить у налаштування

Ми привозимо:

• Аудит поточних compose-конфігурацій та Dockerfile
• Підбір параметрів HEALTHCHECK під кожен сервіс (start-period заміряємо реальним секундоміром)
• Прописування condition: service_healthy для всіх залежностей
• Тестування на стенді: validate через docker inspect та логи
• Документація по заведених health monitoring (Runbook)

Таблиця параметрів HEALTHCHECK

Порівняння підходів: Dockerfile vs compose.yaml

Вибір між Dockerfile та compose.yaml — компроміс між єдиним джерелом правди та гнучкістю. Dockerfile зберігає параметри версійовано разом з додатком, але будь-яка зміна вимагає перескладання образу. Compose.yaml, навпаки, не змінює образ і зручний для сторонніх контейнерів, але параметри розкидані по конфігурації оркестрації. Для production-сервісів ми рекомендуємо комбінувати: базові перевірки в Dockerfile, а специфічні перевизначення в compose.yaml через healthcheck.

Типові помилки та як їх уникнути

• Занадто великий timeout (>10s) — блокує планувальник Docker, знижує чутливість. Оптимум 3-5с.
• Відсутність start-period — JVM не встигає завантажитися, контейнер іде в restart loop.
• Перевірка лише порту — якщо додаток завис, порт може бути відкритий, але запити не обробляються. Краще endpoint з бізнес-логікою.
• Ігнорування condition: service_healthy — без нього depends_on лише черговість старту, не гарантує готовності.

Строки та вартість

Вартість розраховується індивідуально після аудиту compose-конфігурації та архітектури сервісів. Оцінимо ваш проект за 1 день — зв'яжіться, отримайте консультацію та пропозицію. Звертайтесь — допоможемо усунути race condition і досягти стабільного старту всього стека. Замовте налаштування health checks і забудьте про «сірий» простій.

Чому ми це робимо? Тому що бачили, як відсутність health checks валить продакшен: в одному проекті через race condition втрачали до 30% запитів щоранку після деплою. Наші інженери мають 7+ років у DevOps та 50+ проектів з Docker. Гарантуємо, що після налаштування ви забудете про «сірий» простій.

Зв'яжіться, щоб ми проаудитували ваші конфігурації та налаштували health checks під ключ — від Dockerfile до CI/CD. Оцінимо проект за 1 день.