Zero-Downtime Deployment (Безостановочное развертывание)

1. Обзор концепции и системная проблема

Примитивное обновление сервисов методом перезапуска процесса (systemctl restart app или docker restart container) приводит к технологическому простою (Downtime). В течение 5-30 секунд, пока новый процесс инициализирует среду выполнения, подключается к базам данных и компилирует JIT-код:

• Все текущие активные HTTP-запросы обрываются посередине передачи данных.
• Балансировщик нагрузки или обратный прокси возвращает пользователям ошибки 502 Bad Gateway или 504 Gateway Timeout.
• Пользовательские транзакции (оплата, сохранение состояния, генерация LLM) остаются в полураспавшемся состоянии.

Zero-Downtime Deployment (Безостановочное развертывание) устраняет простой через оркестрацию жизненного цикла процессов. Новая версия приложения запускается параллельно со старой. Трафик переключается исключительно после того, как новый инстанс успешно ответил на Health Check зонд, а старый инстанс корректно завершает все начатые операции в режиме Graceful Shutdown.

Фаза 1: Активная версия v1.0
[Клиенты] ---> [Reverse Proxy / Nginx] ---> [Container v1.0 (Active)]

Фаза 2: Запуск v1.1 и Healthcheck
[Клиенты] ---> [Reverse Proxy / Nginx] ---> [Container v1.0 (Active)]
                                             [Container v1.1 (Starting... /healthz: 200 OK)]

Фаза 3: Переключение трафика и Graceful Shutdown v1.0
[Клиенты] ---> [Reverse Proxy / Nginx] ---> [Container v1.1 (Active)]
                                       \---> [Container v1.0 (Finishing active requests... SIGTERM)]

Фаза 4: Завершение (v1.0 выключено)
[Клиенты] ---> [Reverse Proxy / Nginx] ---> [Container v1.1 (Active)]

2. Архитектурная таксономия и ментальная модель

Стратегии безостановочного обновления:

1. Blue/Green Deployment:
   • Полное дублирование инфраструктурного слоя.
   • Мгновенное атомарное переключение трафика на уровне Nginx, Traefik или DNS/ALB.
   • Высшая надежность, самый простой откат (Rollback), но требует двойного запаса оперативной памяти и ресурсов хоста.
2. Rolling Update (Постепенное скользящее обновление):
   • Контейнеры обновляются последовательно по одному или группами.
   • Поддерживается постоянная емкость кластера (например, минимум 3 рабочие реплики из 4).
   • Экономия ресурсов железа, стандарт по умолчанию в Kubernetes и Docker Swarm.
3. Canary Release (Канаречное развертывание):
   • Новая версия получает фиксированный микро-отсоток реального трафика (например, 2-5%) или пользователей определенной внутренней группы.
   • Отслеживаются системные метрики (Error Rate, Latency). Если аномалий не обнаружено, доля трафика постепенно повышается до 100%.

3. Технический пайплайн и внутренняя механика

Реализация Graceful Shutdown в Node.js / TypeScript

Процесс должен корректно перехватывать сигналы операционной системы SIGTERM и SIGINT:

import express from "express";
import http from "http";

const app = express();
let isShuttingDown = false;

// Healthcheck эндпоинт для оркестратора
app.get("/healthz", (req, res) => {
  if (isShuttingDown) {
    // Сигнал балансировщику не направлять сюда новые запросы
    return res.status(503).json({ status: "shutting_down" });
  }
  return res.status(200).json({ status: "healthy" });
});

const server = http.createServer(app);
server.listen(3000);

// Перехват сигнала завершения от Docker / systemd
process.on("SIGTERM", () => {
  console.log("SIGTERM received. Starting graceful shutdown...");
  isShuttingDown = true;

  // 1. Прекращаем прием новых HTTP-соединений
  server.close(async () => {
    console.log("Closed all remaining HTTP connections.");

    try {
      // 2. Закрываем пулы соединений с базами данных и Redis
      await dbPool.end();
      await redisClient.quit();
      console.log("Infrastructure connections closed. Exiting process.");
      process.exit(0);
    } catch (err) {
      console.error("Error during teardown:", err);
      process.exit(1);
    }
  });

  // 3. Запасной вариант (Fail-safe): принудительное завершение при зависании сокетов
  setTimeout(() => {
    console.error("Forced termination: active connections timed out.");
    process.exit(1);
  }, 20000); // 20 секунд лимита
});

Docker Compose Healthcheck конфигурация

Для обеспечения переключения трафика оркестратором конфигурируется параметр проверки здоровья:

services:
  api:
    image: my-company/api:v1.2.0
    restart: always
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/healthz"]
      interval: 5s
      timeout: 3s
      retries: 3
      start_period: 10s
    stop_grace_period: 30s # Время на выполнение Graceful Shutdown

4. Практические инженерные сценарии в продакшене

01. Развертывание через Coolify без прерывания трафика

Платформа Coolify использует встроенный обратный прокси Traefik. При нажатии Deploy она собирает новый Docker-образ, запускает новый контейнер на случайном порту, опрашивает его healthcheck эндпоинт и только после подтверждения работоспособности перенастраивает маршрутизацию Traefik на лету, после чего отправляет сигнал SIGTERM старой реплике.

02. Nginx Hot Configuration Reload (nginx -s reload)

При обновлении SSL-сертификатов или добавлении новых конфигураций upstream мастер-процесс Nginx запускает новый набор worker-процессов с новой конфигурацией. Старые воркеры перестают принимать новые соединения, завершают передачу активных файлов текущим клиентам и только после этого самоликвидируются без единого сброшенного пакета.

03. Развертывание миграций базы данных без блокировки таблиц в PostgreSQL

При добавлении индексов к большим таблицам (миллионы строк) стандартный CREATE INDEX блокирует таблицу на запись (EXCLUSIVE LOCK), что приводит к зависанию очереди запросов. Инженеры используют опцию CREATE INDEX CONCURRENTLY, которая строит индекс в фоне без блокировки параллельных операций чтения и записи.

5. Подводные камни, типовые ошибки и безопасность

1. Отсутствие stop_grace_period в Docker: По умолчанию Docker дает контейнеру лишь 10 секунд на обработку SIGTERM, после чего отправляет смертельный SIGKILL (немедленное убийство процесса). Если длительный запрос к LLM или платежный вебхук длится 12 секунд, операция обрывается с повреждением данных. Увеличивайте лимит до 30–60 секунд.
2. Несовместимость версий кода с базой данных: Попытка переименовать колонку таблицы (ALTER TABLE users RENAME COLUMN email TO contact_email) мгновенно ломает старую версию кода, которая продолжает работать во время деплоя параллельно. Всегда применяйте паттерн Expand-and-Contract в два отдельных релиза.
3. Ложноположительные Health Check эндпоинты: Если эндпоинт /healthz проверяет доступность всех внешних сторонних API (например, OpenAI или Twitter API) и они временно замедляются, оркестратор будет считать собственный сервис мертвым и уйдет в бесконечный цикл рестартов (CrashLoopBackOff / Healthcheck Storm), уничтожив работоспособную продакшен-систему. Зонд liveness должен проверять исключительно локальный процесс.