Контейнер healthy, а релиз не проходит: как проверка Host сломала readiness
Компания Nginx сообщила, что проверка готовности релиза в деплое перестала проходить, хотя контейнер имел статус healthy. Проблема оказалась не в приложении, а в том, как запрос проходил через инфраструктуру. Это не ошибка разработки — это сбой в понимании, что значит «готов к работе».
Контейнер здоров, но релиз не прошёл
Разбор Nginx показал, что проверка готовности может сработать на техническом уровне, но не на уровне реального запроса клиента. Контейнер был запущен, PHP-FPM слушал порт, Nginx проходил проверку конфигурации — всё «здоровое». Но приложение не отвечало на запросы с правильным Host. Я считаю это важным, потому что в бизнесе так же: сайт может быть «здоров» по метрикам, но клиент не видит его, не может перейти, не может купить. И выручка уходит не из-за ошибки, а из-за несоответствия ожиданиям.
Как проверка готовности сломала деплой
В системе использовался blue-green деплой. Новый слот запускался, проверялся через внутренний адрес, например, web-blue. Запрос шёл с заголовком Host: web-blue. После добавления ограничений на неизвестные Host и SNI этот запрос отклонялся. Приложение было живо, но не отвечало на запрос, который его не ждал. Проверка readiness работала с неправильным предположением: что внутреннее имя — эквивалент публичного. Оно не было.
Было: проверяли всё, кроме клиента
Раньше проверка готовности часто сводилась к запуску процесса, проверке порта, проверке health endpoint. Если всё проходило — считалось, что всё в порядке. Сейчас понятно: это не так. Клиент не обращается к порту, он обращается к домену. Он не проверяет, слушает ли процесс, он проверяет, видит ли страницу. В прошлом подходе система думала, что готовность — это техническая стабильность. Сейчас — что готовность — это способность ответить на реальный запрос клиента. Это фундаментальное изменение в понимании.
Кто в зоне риска — и как это узнать
Это касается любого, кто делает деплой, внедряет CI/CD, использует контейнеры. Если вы проверяете готовность через внутренний адрес, через служебное имя, без учёта Host или SNI — вы в зоне риска. Проверка может пройти, а сайт не работать. Как понять: запустите тест с тем же адресом, но с правильным Host. Если ответ разный — вы проверяете не то. Сайт может быть «здоров» в системе, но не виден клиенту.
Что делать — шаги в общем виде
Сначала убедитесь, что проверка готовности имитирует реальный запрос клиента. Проверяйте не только ответ, но и заголовки — Host, SNI. Используйте интеграционные тесты, не только метрики. Убедитесь, что внутренний запрос проходит с тем же Host, что и публичный. Проверяйте не только HTTP-статус, но и содержимое ответа. Убедитесь, что проверка не пропускает редиректы или неправильные сертификаты. И самое главное — не полагайтесь на то, что «всё работает», если вы не проверили, как клиент это воспринимает.
Что мы с этим делаем
Мы в Cetera работаем с проектами в разных отраслях — клиенты более чем в 30 отраслях. Каждый раз, когда мы проектируем интеграцию или проверку готовности, мы начинаем с того, как клиент попадает на сайт. Не с портов и процессов, а с запроса. Мы не проверяем, слушает ли сервер, мы проверяем, видит ли клиент страницу. Каналы меняются быстрее сайтов, и сайт, который не отвечает на запросы так, как их воспринимает клиент, теряет выручку — не из-за позиций, а из-за несоответствия. Если хотите понять, как это выглядит у вас, — давайте обсудим вашу задачу.
Это часть нашей работы — Внедрение. Установка готовых решений и программных продуктов. Или подготовка разработанного сайта к запуску. Внедрение
Автор: Святослав Семенов из Cetera Labs