Как мы внедрили zero-downtime деплой с Nginx и Docker

GigaDevOps

Получить консультацию

Блог
→
Статья

Как мы внедрили zero-downtime деплой с Nginx и Docker: кейс DevOps-команды

6 минут

2 февраля 2026

Содержание

• Контекст: что мы вообще деплоим
• Зачем вообще нужен zero-downtime
• Что мы решили использовать
• Архитектура
• CI/CD pipeline
• Подводные камни
• Что получилось
• Советы
• Что дальше

Бесплатная консультация

Сообщество DevOps

Всё началось с одного сообщения: «А почему сайт лежал ночью почти минуту?». На проде выкатили микрофикс — фронт сдох, Nginx поймал 502, мониторинг заорал. Да, всего минута. Но у нас финтех, SLA, и CTO уже закатывал рукава. Так я занялся zero-downtime деплоем.

Контекст: что мы вообще деплоим

Немного про приложение. Это микросервис, отвечающий за расчёт кредитных скорингов в нашей финтех-платформе. Он получает заявку, парсит данные клиента (доходы, возраст, кредитную историю), запускает ML-модель и возвращает скоринговый балл в формате JSON.

Всё на Node.js (NestJS + TypeORM), база — PostgreSQL. Приложение довольно чувствительное к отклонениям: если не ответит за 2 секунды — фронт отваливает, клиент видит ошибку.

Именно на нём были ночные 502. Даже 10 секунд простоя — это десятки потерянных заявок и потенциальный минус к доверию.

Зачем вообще нужен zero-downtime

Если ты когда-либо деплоил вживую, знаешь, как это выглядит:

Дёргаем docker-compose pull && up -d;
Старый контейнер гаснет, пока новый скачивается;
За это время — пустота, ошибки, 502.

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

минимальный даунтайм (идеально — ноль);
rollback в случае фейла;
деплой без дергания балансировщика вручную.

Что мы решили использовать

Мы работаем в Docker. У нас есть docker-compose
и CI (GitHub Actions). Решили не прыгать в Kubernetes — всё-таки это не кластер.

Итого:

Docker + docker-compose;
Nginx как реверс-прокси;
два backend-сервиса (актуальный и обновляемый);
GitHub Actions — CI/CD pipeline.

Паттерн — классический Blue/Green deployment:

Всегда есть 2 версии сервиса: blue (текущая) и green (готовится). Как только green проверен — трафик уходит на него, а blue умирает.

Архитектура

Упрощённо:

Конфиг Nginx (упрощён):

upstream backend {
    server app_blue:3000;
    server app_green:3000 backup;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

Чтобы переключиться: меняем приоритет в upstream, пересобираем Nginx, он переключает трафик.

CI/CD pipeline

GitHub Actions делает всё:

Билдит docker-образ;
Тегирует как green;
Деплоит app_green;
Прогоняет health-check;
Меняет конфиг Nginx (переключает на green);
Рестартит Nginx;
Убивает app_blue.

Пример deploy.yml:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Build & push image
        run: |
          docker build -t myapp:green .
          docker tag myapp:green registry/app:green
          docker push registry/app:green

      - name: Deploy green
        run: ssh user@host 'docker-compose -f green.yml up -d'

      - name: Health-check
        run: curl -f http://host/healthz || exit 1

      - name: Switch Nginx
        run: ssh user@host 'cp nginx_green.conf nginx.conf && docker restart nginx'

      - name: Remove blue
        run: ssh user@host 'docker-compose -f blue.yml down'

Подводные камни

1. Медленный healthcheck
curl /healthz может сработать, а сервис ещё не прогрет. Решили:

добавить sleep 10;
проверять ответ на бизнес-метрику (не просто 200, а status: ok).

2. Nginx не сразу переключает
После docker restart Nginx может держать кеш. Помогло:

proxy_cache_bypass
в конфиг;
resolver прописать явно, если имена контейнеров меняются.

3. Сбои при одновременном деплое
CI мог запускаться параллельно. Добавили concurrency в GitHub Actions:

concurrency:
  group: deploy
  cancel-in-progress: true

Что получилось

Теперь при каждом пуше в main:

поднимается green;
проверяется /healthz;
Nginx переключается;
blue удаляется.

Деплой занимает 30–45 секунд. Ни одного 502 за 2 недели.

Cоветы

Делай health-check настоящим: не просто 200, а с логикой.
Всегда держи старый backend до конца.
Автоматизируй rollback (в проде всё ломается).
Не забудь про concurrency в CI.

Telegram-бот с плюшками

Если вы готовитесь к переходу в DevOps — этот бот станет вашей отправной точкой.
Здесь не общие рекомендации из блогов, а выжимка из реального опыта: вопросы с реальных собеседований, шаблоны ответов, разборы типичных ошибок и то, что действительно спрашивают в компаниях.
Бот регулярно пополняется новыми материалами — от подборок актуальных вакансий и инсайтов от специалистов до ссылок на полезные курсы и ресурсы.
А также комьюнити, которое помогает ускорить рост: опытные инженеры, живые обсуждения и поддержка на каждом этапе перехода в DevOps.
Бесплатно и без спама.

Запустить бот

Что дальше

Следующий шаг — Canary: будем прокидывать 10% трафика на новую версию и следить за ошибками.
А пока — zero-downtime работает. Даже ночью, даже на проде.

Хочешь попробовать деплой или поработать с Nginx в боевых условиях — заходи на GigaDevOps Platform. Там можно развернуть контейнер, отловить баг и сделать rollout — прямо в браузере.

Истории успеха

Семен

27 лет

Устроился на 250 тыс. ₽

Все супер, спустя 3 месяца вышел на работу почти без начального уровня знаний. После обучения также есть поддержка, чтобы освоиться на рабочем месте. На обучении обсуждаются все основные моменты профессии, но чтобы быть опытным специалистом в своем деле, надо помимо обучения также читать и выполнять задания дополнительно, тогда все будет супер.

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

Илья

23 года

Устроился на 220 тыс. ₽

Максим

33 года

Устроился на 215 тыс. ₽

До GigaDevOps я только начинал разбираться в теме и не представлял, как перейти в DevOps самостоятельно. С менторами получилось выстроить понятный путь: от базовых вещей вроде Linux и сетей до Docker, Kubernetes, Terraform и облаков.
Что получилось по итогам: