Контейнер собрался, но приложение не работает: диагностика в Inquir

«Сборка зелёная, а сайт не работает» — это несколько разных ситуаций. Образ мог собраться, но процесс не запуститься; процесс мог ответить на health check, но production всё ещё обслуживает предыдущий релиз. Разберём проверку по этапам, используя CLI Inquir Compute.

Сначала зафиксируйте приложение и релиз

Работайте с одним приложением и временем проблемного деплоя. Вместо my-api подставьте его имя или идентификатор:

inquir apps status my-api
inquir apps describe my-api
inquir apps instances my-api
inquir apps builds my-api

status показывает адреса и релизы, describe — условия и события, instances — состояние реплик. Сопоставляйте идентификаторы: здоровая старая реплика не подтверждает запуск новой версии. Если идентификатор production-релиза не изменился, сначала выясните, был ли новый релиз повышен до production.

Ошибка на этапе сборки

Возьмите идентификатор нужной сборки и откройте её логи:

inquir apps logs <build-id> --no-follow --tail 200

Проверьте первый значимый сбой, а не только финальное сообщение. Типичные причины — отсутствующий lock-файл для npm ci, неправильный путь COPY, несовпадение регистра имени файла и установка production-зависимостей до шага, которому нужны devDependencies.

Секрет для обращения к приватному реестру нельзя просто добавить в Dockerfile как ENV и закоммитить. Разделяйте данные сборки и runtime-переменные; используйте поддерживаемый механизм секретов сборщика. Принцип описан в документации Docker.

Образ готов, процесс не отвечает

inquir apps logs my-api --no-follow --tail 200

Проверьте команду запуска, обязательные переменные, установленный runtime и права пользователя на нужные файлы. Затем сверьте фактический порт процесса с портом приложения. HTTP-сервер обычно должен слушать 0.0.0.0, а не 127.0.0.1 внутри контейнера.

Для работающего production-контейнера можно проверить runtime:

inquir apps exec my-api -- node --version

Это пример для Node.js, не универсальная команда для любого образа. exec обращается к production-приложению: он не поможет исследовать ещё не запущенную preview-реплику. Не выводите все переменные окружения ради диагностики — среди них могут быть пароли.

Health check проходит, но запрос падает

Убедитесь, что проверяете реальный сценарий: /healthz может возвращать ok без обращения к базе. Проверьте отдельный безопасный запрос, который использует нужную зависимость, и сопоставьте его с логами по времени или request ID.

Если ошибка возникает только в браузере, проверьте URL API, CORS, cookies и ответ сетевого запроса. Если только после обновления фронтенда — не отдаёт ли сервер HTML вместо отсутствующего JavaScript-файла. Не делайте вывод о состоянии базы по одному успешному запросу к статике.

Проверьте promotion и границу отката

Когда нужный релиз здоров и проверен, переведите именно его в production:

inquir apps promote <release-id>
inquir apps status my-api

После этого откройте публичный маршрут и проверьте отличительный признак версии: изменённый ответ или номер сборки. Успешная команда promotion без проверки маршрута не подтверждает пользовательский результат.

Если новый релиз ухудшил работу, inquir apps rollback my-api возвращает предыдущий релиз приложения. Эта операция не отменяет SQL-миграции, отправленные письма или записи во внешних API. Сначала проверьте совместимость старого кода с текущими данными.

Сохраните время инцидента, ID сборки и релиза, несколько строк ошибки без секретов и результат запроса. Это полезнее общего скриншота «не работает». Команды и состояния подробнее описаны в документации приложений и CLI.