Проверки здоровья и последовательные обновления

Nanocl использует проверки здоровья Docker для определения готовности обязательных контейнеров приложения в реплике Cargo. Задайте проверку для именованного контейнера приложения либо используйте проверку из его образа.

ApiVersion: v0.18
Cargoes:
- Name: api
  Containers:
  - Name: api
    Image: ghcr.io/example/api:1.2.0
    Healthcheck:
      Test: ["CMD-SHELL", "curl -fsS http://127.0.0.1:8080/health || exit 1"]
      Interval: 5000000000
      Timeout: 3000000000
      Retries: 3
      StartPeriod: 10000000000

Длительности задаются в наносекундах, как в Docker. Проверку, объявленную в образе, повторять не нужно. Проверка Docker NONE отключает унаследованную проверку.

Запуск контейнера и готовность Cargo — разные состояния. Обязательное приложение без включённой проверки готово, когда Docker сообщает, что оно работает. С проверкой оно должно сообщить healthy. Для общей реплики с несколькими контейнерами песочница также должна работать. Необязательные контейнеры не блокируют готовность.

Последовательные обновления

Nanocl последовательно подготавливает новые реплики и до пяти минут ожидает готовности обязательной топологии каждого кандидата. Если сеть и порты хоста позволяют, сохранённое поколение работает и обслуживает запросы до готовности кандидата. ncproxy передаёт маршруты только после готовности подтверждённой замены.

Если кандидат отказывает до продвижения, Nanocl удаляет его и восстанавливает сохранённое поколение. При отказе подтверждённого обновления также предпринимается восстановление прежних связей и процессов, а Cargo получает состояние unhealthy/failed.

Это не безусловная гарантия отсутствия простоев. Фиксированные порты требуют удаления сохранённого поколения перед привязкой тех же портов кандидатом. Сеть хоста требует предварительной остановки сохранённого поколения, хотя Nanocl может запустить его снова при отказе кандидата. Процесс без проверки здоровья считается готовым сразу после запуска, поэтому готовность приложения требует проверки Docker.

Та же логика готовности применяется при перезапуске Cargo. Перезапуск сохраняет песочницу реплики и завершённые init-контейнеры, перезапускает контейнеры приложения и ожидает готовности обязательных приложений.