🩺 Docker Health Checks

Health checks позволяют Docker определить, жив ли сервис. Это критично дляdepends_on сcondition: service_healthyи для автоматического восстановления при падениях.

Сервисы с Health Checks

🐘
PostgreSQL
pg_isready
✓ healthy
🧠
Ollama
ollama list
✓ healthy
🌐
Selenium
curl /wd/hub/status
✓ healthy
🎤
Whisper
curl /
✓ healthy
⚡
n8n
HTTP GET /
🤖
Bot
HTTP GET /health
📊
Prometheus
HTTP GET /-/ready

🔄 Как работает Health Check

Start
container starts
→
starting
wait start_period
→
healthy
check passes
→
unhealthy
retries exceeded
interval

Как часто проверять (default: 30s)

timeout

Макс. время на проверку (default: 30s)

retries

Попыток до unhealthy (default: 3)

start_period

Грейс-период при старте (default: 0s)

📋 Конфигурация по сервисам

🐘PostgreSQLКритичный сервис
healthcheck:
  test: ["CMD-SHELL", "pg_isready -U clowbot -d clowbot"]
  interval: 10s
  timeout: 5s
  retries: 5
  start_period: 10s
interval: 10s
timeout: 5s
retries: 5
start_period: 10s

pg_isready — стандартная утилита PostgreSQL для проверки подключения. Быстрая и надёжная. Бот ждёт healthy перед запуском.

🧠OllamaМедленный старт
healthcheck:
  test: ["CMD-SHELL", "ollama list >/dev/null 2>&1"]
  interval: 20s
  timeout: 8s
  retries: 10
  start_period: 60s

Почему retries=10 и start_period=60s?

  • Ollama грузит модель в память при первом запуске
  • Модель phi4-mini занимает ~2GB RAM
  • На медленных дисках загрузка может занять 30-60 секунд
  • retries=10 × interval=20s = 200s макс. время до unhealthy
🌐SeleniumОпциональный сервис
healthcheck:
  test: ["CMD-SHELL", "curl -sf http://localhost:4444/wd/hub/status || exit 1"]
  interval: 15s
  timeout: 5s
  retries: 5
  start_period: 30s

Проверяет Selenium Grid status endpoint. Chromium внутри должен быть готов к работе.

Response example:
{
  "value": {
    "ready": true,
    "message": "Selenium Grid ready."
  }
}
🎤WhisperGPU/CPU зависимый
healthcheck:
  test: ["CMD", "curl", "-sf", "http://localhost:9000/"]
  interval: 30s
  timeout: 10s
  retries: 5
  start_period: 120s

Почему start_period=120s?

  • Whisper грузит модель при старте (whisper-base ~150MB)
  • На CPU первая загрузка может занять 1-2 минуты
  • На GPU — значительно быстрее (~10-20 секунд)
🤖Bot (FastAPI)Основной сервис
healthcheck:
  test: ["CMD", "curl", "-sf", "http://localhost:8000/health"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 20s
Endpoint /health response:
{
  "status": "healthy",
  "postgres": "ok",
  "telegram_polling": "active",
  "version": "1.0.0"
}
⚡n8nWorkflow engine
healthcheck:
  test: ["CMD-SHELL", "wget -q --spider http://localhost:5678/ || exit 1"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 30s

n8n не имеет специального health endpoint, поэтому проверяем корневой путь.

🔗 depends_on с condition

Health checks позволяют запускать сервисы в правильном порядке:

services:
  bot:
    depends_on:
      postgres:
        condition: service_healthy
      ollama:
        condition: service_healthy
    # bot не запустится пока postgres и ollama не станут healthy

  n8n:
    depends_on:
      postgres:
        condition: service_healthy
    # n8n ждёт только postgres
✅ Правильно

Бот стартует только когда БД готова принимать соединения.

❌ Без condition

Бот может стартовать до БД → ошибки подключения при старте.

🔄 Restart Policies

Все сервисы используют:

restart: unless-stopped
unless-stopped

Перезапускать всегда, кроме явной остановки. Рекомендуется.

always

Перезапускать всегда, даже после docker stop (при перезагрузке host)

on-failure

Только при ошибке (exit code != 0)

no

Не перезапускать (default)

# restart_policy с лимитами
restart:
  name: unless-stopped
  max_retry_count: 5  # После 5 рестартов остановить попытки

🔍 Проверка health статуса

docker compose ps

Показывает статус всех сервисов (healthy / unhealthy / starting)

docker inspect --format={{.State.Health.Status}} postgres

Точный статус конкретного контейнера

docker inspect postgres | jq '.[0].State.Health'

Полная информация о health check (последние проверки, ошибки)

docker events --filter 'event=health_status'

Мониторинг изменений статуса в реальном времени

🔧 Troubleshooting

Сервис unhealthy

  1. Проверить логи: docker compose logs postgres
  2. Выполнить health check вручную: docker exec postgres pg_isready
  3. Проверить ресурсы (CPU/RAM) — возможно таймаут из-за нехватки
  4. Увеличить retries или timeout если сервис медленный
  5. Проверить start_period — возможно сервису нужно больше времени

Сервис постоянно restarting

• Проверить docker compose logs --tail=100 service

• Возможно приложение падает сразу после старта

• Проверить конфигурацию (env vars, volumes, ports)

• Проверить зависимости (БД, внешние API)

Health check работает, но сервис не отвечает

• Health check может быть слишком простой (проверяет только процесс)

• Добавить проверку реальной функциональности

• Например: не просто curl /, а curl /health с проверкой зависимостей

✅ Best Practices

Рекомендуется

  • Использовать start_period для медленных сервисов
  • Проверять реальную функциональность, не только процесс
  • Устанавливать разумный timeout (5-10s)
  • Логировать ошибки health check в приложении
  • Использовать unless-stopped для production

Избегать

  • Слишком частые проверки (interval < 5s)
  • Слишком короткий timeout (< 3s)
  • Слишком много retries без start_period
  • Проверки, которые нагружают сервис
  • restart: always для development

🔗 Связанные страницы

Docker Services•Docker Compose•Docker Backups•Process Overview