Деплой без простоя на сервере: типичные ошибки
Перезапустить приложение — не то же самое, что выкатить обновление без простоя: пользователи могут получить 502, потерять сессию или записать данные в несовместимую схему. Разбираем ошибки деплоя за Nginx и способы снизить риск.
Без простоя — это не просто быстрый перезапуск
Если обновление приложения на сервере на несколько секунд прекращает принимать запросы, пользователи увидят ошибку или зависшую загрузку. Для сайта за Nginx с приложением под управлением systemd риск часто появляется в одном из трёх мест: процесс перезапускают до готовности новой версии, старый экземпляр останавливают раньше времени или обновление кода ломает совместимость с базой данных.
Ни один способ не гарантирует нулевой простой сам по себе. Ниже — практические варианты для типовой схемы «Nginx → приложение»: они применимы к разным языкам и фреймворкам, но точные команды запуска и проверки здоровья зависят от вашего стека. Для определённости речь о Linux-сервере, Nginx и приложении, которым управляет systemd; конкретные версии Nginx и приложения нужно сверить с установленными у вас.
Главная ошибка — считать, что новый процесс уже готов принимать трафик, потому что команда запуска завершилась без ошибки.
Выберите способ выкладки до того, как чинить простой
Разные схемы меняют разные части системы. Перезапуск одного процесса проще, но оставляет короткое окно недоступности. Два экземпляра позволяют переключать трафик, однако требуют свободных ресурсов и совместимой базы данных.
| Подход | Что происходит | Цена и ограничения |
|---|---|---|
| Перезапуск процесса | Остановить старое приложение и запустить новое | Прост в настройке, но между остановкой и готовностью возможен отказ запросов |
| Последовательный перезапуск нескольких экземпляров | Обновлять экземпляры по очереди, сохраняя часть работающих | Нужны балансировщик, несколько экземпляров и проверка готовности; один сервер может не выдержать двойную нагрузку |
| Blue-green | Запустить новую версию отдельно, проверить её и переключить Nginx | Переключение удобно откатить, но нужны ресурсы на две версии и совместимость с общими данными |
Термин проверка готовности1 означает проверку, что экземпляр не просто запущен, а может обслужить запрос: например, приложение загрузило конфигурацию и установило соединение с необходимыми зависимостями. Проверка должна быть безопасной и не менять данные.
Ошибки, из-за которых выкладка всё равно роняет сайт
1. Nginx переключают до готовности нового экземпляра
Файл конфигурации может быть синтаксически корректным, а приложение за новым upstream — ещё запускаться. Nginx отправляет туда запросы и получает отказ соединения или 502. Проверяйте новый экземпляр напрямую, до изменения маршрута: он должен успешно отвечать на заранее выбранный health-check. Только после этого переключайте трафик.
Если вы меняете конфигурацию Nginx, сначала проверьте её штатной проверкой синтаксиса, затем применяйте изменение. Не заменяйте проверку конфигурации надеждой на то, что сервер «сам разберётся». Способ применения зависит от unit-файла и конфигурации вашей системы; сверяйтесь с документацией Nginx и настройками установленного сервиса.
2. Старый процесс завершается вместе с запросами
Приложение может получить сигнал остановки и сразу закрыть соединения, хотя запросы ещё выполняются. Клиент увидит обрыв, а операция записи иногда успеет завершиться на сервере, но не дойдёт до подтверждения. Пользователь нажмёт кнопку повторно — и получит дубликат.
Уточните, поддерживает ли ваш сервер приложений корректное завершение: прекращение приёма новых запросов, ожидание активных запросов и ограничение времени ожидания. Названия параметров и сигналов у разных серверов отличаются, поэтому не переносите настройки из чужой инструкции без проверки версии. Для операций, которые нельзя повторять без последствий, продумайте идемпотентность отдельно от деплоя.
3. Миграция базы ломает откат
Выкладка приложения и изменение схемы БД — связанные, но не одинаковые шаги. Если новая версия удаляет колонку, пока старый процесс ещё работает, тот может начать падать. А если миграция необратимо меняет или удаляет данные, возврат старого кода не восстановит прежнее состояние.
Безопаснее разделить несовместимые изменения на этапы: сначала добавить новое поле так, чтобы его понимали старый и новый код; затем выпустить версию, которая работает с новой схемой; удалять старое поле — только после прекращения использования старой версии и проверки данных. Конкретная последовательность зависит от СУБД, ORM и миграционного инструмента.
4. Релиз очищает файлы, которыми ещё пользуются
Если деплой заменяет содержимое рабочей директории на месте, старый процесс может потерять шаблон, файл или библиотеку во время обработки запроса. Если релиз хранится в отдельной директории, а текущая версия переключается ссылкой, старый процесс всё равно может обращаться к файлам уже после переключения. Не удаляйте предыдущую версию сразу: дождитесь, пока старые процессы завершатся, и проверьте, что фоновые задачи тоже не используют её файлы.
5. Фоновые задачи обновляются вместе с веб-процессом
После выкладки веб-сервер уже запустил новый код, а очередь задач ещё выполняет задания старого формата. Новые задания могут содержать поля, которые старый обработчик не знает, и наоборот. Согласуйте порядок обновления приложения, обработчиков очереди и формата сообщений. На время перехода сохраняйте обратную совместимость форматов или приостанавливайте выдачу несовместимых задач.
Когда какой вариант выбирать
- Один процесс и редкие обновления: начните с перезапуска и честно считайте короткий разрыв частью текущего уровня сервиса. Проверьте, что пользователи и мониторинг его замечают.
- Нужен переход без переключения на неготовое приложение: запустите второй экземпляр, проверьте его отдельно и только затем направьте на него трафик через Nginx.
- Нужен быстрый возврат к предыдущей версии: используйте blue-green, но заранее проверьте совместимость схемы БД и внешних интеграций. Переключение трафика не откатывает уже выполненные записи.
Если на сервере не хватает памяти или CPU, одновременный запуск двух версий может ухудшить ситуацию: обе будут конкурировать за ресурсы. Перед выбором измерьте потребление при пике нагрузки и убедитесь, что запас позволяет держать старую и новую версии вместе.
Что проверить перед следующим релизом
- Определите, какой ответ означает готовность приложения, и проверьте его у нового экземпляра до переключения.
- Запишите порядок действий для веб-процессов, обработчиков очереди и миграций БД.
- Проверьте, как приложение завершает активные запросы и сколько времени ему дают на остановку.
- Убедитесь, что предыдущий релиз и способ возврата к нему доступны, а схема данных допускает работу старого кода.
- После выкладки наблюдайте за ошибками 5xx, временем ответа, перезапусками процесса и очередью задач. Сравнивайте показатели с обычным уровнем, а не с выдуманным универсальным порогом.
Следующий шаг — провести тестовую выкладку на стенде с тем же способом запуска и похожей схемой Nginx. Замерьте, сколько занимает запуск, сколько живёт старый процесс после переключения и какие ошибки появляются в логах. Инвалидация кеша и миграции конкретной СУБД — отдельные темы; здесь разобраны ошибки переключения приложения и связанных процессов.
1 Health-check — проверка состояния сервиса. Важно отличать проверку «процесс отвечает» от проверки «экземпляр готов принимать пользовательский трафик».
Проверка рекламы на риски: Что в макете вызовет вопросы ФАС: превосходные степени, сравнения, обещания результата, маркировка.
Спросить за 40 ₽Источники: Nginx: контролируемое применение конфигурации, systemd.service — документация systemd
Частые вопросы
Можно ли гарантировать полный ноль ошибок при деплое?
Обязательно ли запускать две копии приложения?
Что делать, если после выкладки появились 502?
Можно ли просто откатить код, если миграция уже прошла?
Нужно ли перезапускать обработчики очереди отдельно?
Если переключение прошло, можно сразу удалить предыдущую версию?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.