Моя служба деплоится, но никогда не становится здоровой

Сборка проходит успешно и запускается новый под, но деплой помечается как неудачный или новая версия никогда не начинает принимать трафик.

Что это значит

Проверка здоровья платформы — TCP-проба порта вашего приложения — никогда не проходит, поэтому трафик никогда не переключается на новый под. Lizard ждёт около 30 секунд, затем помечает деплой как неудачный. Служба, которая уже работала, продолжает обслуживать предыдущую версию, если к ней не подключён том: тогда её старый под останавливается первым, и служба недоступна, пока какой-нибудь деплой не пройдёт. Первый деплой отображается как упавший.

Почему это может происходить

• Ваше приложение не слушает ожидаемый порт. Lizard внедряет переменную окружения PORT (порт контейнера по умолчанию 3000) и проверяет, что ваше приложение доступно там. Если ваше приложение жестко задано на другой порт или никогда не привязывает порт, проверка здоровья никогда не проходит. Типичный случай — Python-приложение: gunicorn и uvicorn привязывают 127.0.0.1, если вы не скажете им иначе, а проверка приходит извне процесса. В хостинге Python-приложений указана строка --bind 0.0.0.0:$PORT, которую требует каждый фреймворк.
• Порт службы не совпадает с образом. Когда lizard up создаёт службу из Dockerfile без строки EXPOSE, он задаёт порт 3000, даже если базовый образ слушает другой, например nginx на 80. Переменная PORT этот порт не меняет. Выполните lizard port <n> и переразверните службу или добавьте строку EXPOSE. См. на какой порт Lizard направляет трафик.
• Служба случайно перешла в рабочий режим. Установка containerPort=0 переводит службу в рабочий режим, который полностью пропускает проверку здоровья и регистрацию в балансировщике нагрузки. Служба, которая должна обслуживать HTTP, но получила containerPort=0, будет деплоиться «успешно» и просто никогда ничего не обслуживать — рабочий режим скрывает базовую проблему запуска вместо того, чтобы выявить её.

Возможные решения

Проверьте текущий порт

lizard port --service api

Если это выводит worker mode, у службы установлен containerPort=0. Верните его на реальный порт, если эта служба предназначена для обслуживания HTTP:

lizard port 3000 --service api
lizard redeploy --service api

Убедитесь, что ваше приложение слушает там, где ожидает Lizard

Прочитайте логи среды выполнения на предмет ошибок запуска и адреса, который приложение указывает как прослушиваемый. Сравните его с портом службы, который Lizard передаёт приложению как PORT:

lizard logs --service api
lizard port --service api

См. также

• Фоновые рабочие процессы — когда containerPort=0 уместен, а когда нет.
• Деплойменты → жизненный цикл — где проверка здоровья находится в деплойменте.

Обновлено 21 октября 2026 г.