Zero-Downtime Deployment (Безперервне розгортання)(Безперервне розгортання (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 master-процес 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 повинен перевіряти виключно локальний процес.