<span id="my-service-deploys-but-never-becomes-healthy" />

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

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

<span id="what-this-means" />

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

Проверка здоровья платформы — которая проверяет доступность порта вашего приложения — никогда не проходит, поэтому трафик никогда не переключается на новые реплики.

<span id="why-this-can-happen" />

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

- **Ваше приложение не слушает ожидаемый порт.** Lizard внедряет переменную окружения `PORT` (порт контейнера по умолчанию `3000`) и проверяет, что ваше приложение доступно там. Если ваше приложение жестко задано на другой порт или никогда не привязывает порт, проверка здоровья бесконечно проваливается. Типичный случай — Python-приложение: `gunicorn` и `uvicorn` привязывают `127.0.0.1`, если вы не скажете им иначе, а проверка приходит извне процесса. В [хостинге Python-приложений](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) указана строка `--bind 0.0.0.0:$PORT`, которую требует каждый фреймворк.
- **Служба случайно перешла в рабочий режим.** Установка `containerPort=0` переводит службу в [рабочий режим](https://lizard.build/ru/docs/deploy/workers), который **полностью пропускает проверку здоровья и регистрацию в балансировщике нагрузки**. Служба, которая должна обслуживать HTTP, но получила `containerPort=0`, будет деплоиться «успешно» и просто никогда ничего не обслуживать — рабочий режим скрывает базовую проблему запуска вместо того, чтобы выявить её.

<span id="possible-solutions" />

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

<span id="check-the-current-port" />

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

```bash
lizard port --service api
```

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

```bash
lizard port 3000 --service api
lizard redeploy --service api
```

<span id="confirm-your-app-is-listening-where-lizard-expects" />

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

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

```bash
lizard logs --service api
lizard ssh --service api -- env | grep PORT
```

<span id="see-also" />

## См. также

- [Фоновые рабочие процессы](https://lizard.build/ru/docs/deploy/workers) — когда `containerPort=0` уместен, а когда нет.
- [Деплойменты → жизненный цикл](https://lizard.build/ru/docs/concepts/deployments#lifecycle) — где проверка здоровья находится в деплойменте.