Healthcheck Nginx и PostgreSQL: готовность сервисов в Compose
Автор: Казачкин Даниил Михайлович · Обновлено
Запущенный процесс ещё не означает готовую услугу. Nginx может отвечать собственной страницей, пока база недоступна; PostgreSQL может принимать соединения до применения схемы…
Запущенный процесс ещё не означает готовую услугу. Nginx может отвечать собственной страницей, пока база недоступна; PostgreSQL может принимать соединения до применения схемы приложения. В этом уроке настроим две разные проверки и разберём, что именно означает зелёный статус.
Проверка Nginx должна проверять HTTP
Создайте default.conf рядом с Compose-файлом:
server {
listen 80;
server_name _;
location = /healthz {
default_type text/plain;
return 200 "ready\n";
}
location / {
root /usr/share/nginx/html;
}
}В отдельном compose.yaml используйте Alpine-вариант Nginx, где доступен wget:
name: yk-health-demo
services:
db:
image: postgres:17-alpine
environment:
POSTGRES_PASSWORD: local-demo-only
healthcheck:
test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U postgres"]
interval: 5s
timeout: 3s
retries: 10
start_period: 10s
web:
image: nginx:1.28-alpine
ports:
- "127.0.0.1:18082:80"
volumes:
- type: bind
source: ./default.conf
target: /etc/nginx/conf.d/default.conf
read_only: true
bind:
create_host_path: false
healthcheck:
test: ["CMD-SHELL", "wget -qO- http://127.0.0.1/healthz | grep -qx ready"]
interval: 5s
timeout: 3s
retries: 3
depends_on:
db:
condition: service_healthyЭто демонстрация последовательности, а не архитектурное требование: статическому Nginx база не нужна. В реальном проекте depends_on следует ставить у приложения, которое действительно обращается к PostgreSQL, а proxy направлять к приложению.
Прочитать статус и результат
Выполните docker compose config -q, затем docker compose up -d --wait --wait-timeout 90. curl http://127.0.0.1:18082/healthz должен вернуть ready. Для внутреннего результата проверки сначала получите ID командой docker compose ps -q web, затем передайте его docker inspect --format '{{json .State.Health}}' ID.
Не считайте отсутствие curl в образе неисправностью приложения. Команда healthcheck исполняется внутри конкретного контейнера, поэтому все её инструменты должны находиться там. JSON-форма CMD выполняет программу без shell; CMD-SHELL нужна для переменных и конвейеров. Коды, вывод и таймауты проверки дают более полезные сведения, чем один цвет в интерфейсе.
Чего эта проверка не обещает
Ответ /healthz доказывает работу этого location и HTTP-процесса. Он не проверяет базу, внешнее API и бизнес-функцию. Для readiness приложения спроектируйте отдельную небольшую проверку нужных зависимостей; не превращайте её в тяжёлый отчёт, который сам перегружает сервис. Семантика location.
В обычном Docker healthcheck помечает контейнер unhealthy, но сам по себе не перезапускает его. Restart policy реагирует на завершение процесса, а не на любую неудачную пробу. Условие service_healthy в Compose помогает при запуске; дальнейшие сбои требуют поведения приложения и выбранной эксплуатации. Правила зависимостей.
Намеренно сломать и объяснить
Замените в probe /healthz на /missing-health-page и пересоздайте web. Через несколько интервалов он станет unhealthy, хотя корневая страница может продолжать открываться. Верните правильный путь и убедитесь, что статус восстанавливается. Выберите timeout, interval, retries под реальное время ответа: бессмысленно требовать готовности раньше завершения инициализации.
Этот пример базы не задаёт named volume и предназначен только для диагностики. После опыта выполните docker compose down -v, сознательно удаляя его анонимные данные. Для постоянного проекта используйте [полный пример с томом](/lessons/without-university/docker-containerization/docker-developer-23) и проверяйте восстановление отдельно.