При оновленні веб-застосунку на продакшені користувачі часто втрачають доступ або отримують помилки 503. Уявіть: викотили нову версію, а половина запитів впала з таймаутом — база не встигла переключитися. Стандартний підхід «зупинити → замінити → запустити» не підходить для сервісів з вимогами SLA 99.9%. Ми налаштовуємо Rolling Update — стратегію, що виключає простій при мінімальних витратах ресурсів. Наш досвід — 10+ років у DevOps, впровадження rolling update для fintech та e-commerce з мільйонною аудиторією.
Чому Rolling Update — найкращий вибір для zero-downtime деплою?
Rolling Update замінює інстанси поступово: спочатку оновлюється 1–2 pod, перевіряється їхнє здоров'я, потім наступні. На відміну від Blue-Green, не вимагає подвійних ресурсів, а в порівнянні з Recreate — не зупиняє всі поди одночасно. Це дає баланс між витратами та відмовостійкістю. Rolling Update у 2 рази швидший за Blue-Green за часом розгортання, а при правильній конфігурації downtime відсутній повністю.
| Параметр | Rolling Update | Blue-Green | Recreate |
|---|---|---|---|
| Додаткові ресурси | 0 | 2× | 0 |
| Downtime | Немає | Немає | Є |
| Час деплою | Середній | Швидкий | Швидкий |
| Складність налаштування | Середня | Висока | Низька |
| Ризик несумісності | Вищий | Нижчий | Нижчий |
Rolling Update дає найкраще співвідношення ціни та надійності для більшості продакшен-систем. Підтвердження — Rolling release у Wikipedia, де rolling update рекомендується як default-стратегія.
Як налаштувати Rolling Update у Kubernetes?
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 6
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 1
minReadySeconds: 30
selector:
matchLabels: { app: myapp }
template:
metadata:
labels: { app: myapp }
spec:
containers:
- name: myapp
image: registry.example.com/myapp:v1.1.0
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 3
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
terminationGracePeriodSeconds: 60
kubectl set image deployment/myapp myapp=registry.example.com/myapp:v1.2.0
kubectl rollout status deployment/myapp
kubectl rollout history deployment/myapp
kubectl rollout undo deployment/myapp
kubectl rollout undo deployment/myapp --to-revision=3
Що таке graceful shutdown і навіщо він потрібен?
Коректне завершення процесів — критичне для zero-downtime. При отриманні SIGTERM застосунок має завершити активні запити, закрити з'єднання та звільнити ресурси. Якщо застосунок не встигає завершитися за термінаційний період, Kubernetes примусово вбиває його, що призводить до втрати запитів.
// Node.js/Express — коректне завершення при SIGTERM
process.on('SIGTERM', async () => {
console.log('SIGTERM received, shutting down gracefully');
server.close(() => {
console.log('HTTP server closed');
});
await new Promise(resolve => setTimeout(resolve, 30_000));
await db.destroy();
process.exit(0);
});
Як перевірити готовність застосунку?
Readiness-проба має перевіряти залежні сервіси: БД, кеш, чергу. Приклад на Laravel:
// Laravel — health check routes
Route::get('/health/live', function () {
return response()->json(['status' => 'ok']);
});
Route::get('/health/ready', function () {
try {
DB::connection()->getPdo();
Cache::store()->get('health-check');
} catch (\Exception $e) {
return response()->json(['status' => 'not ready', 'error' => $e->getMessage()], 503);
}
return response()->json(['status' => 'ready']);
});
Як забезпечити сумісність бази даних при Rolling Update?
При співіснуванні двох версій схема БД має бути сумісною з обома. Жорстке правило — міграції запускаються до деплою нового коду і тільки backward-compatible. Заборонено одразу перейменовувати або видаляти колонки, змінювати типи даних без проміжних кроків.
Рекомендується триетапний деплой: спочатку додати нову колонку (nullable) або нову таблицю. Потім заповнити нові поля, переключити код на їх використання. І тільки в третій ітерації видалити старі колонки або таблиці. Такий підхід виключає помилки сумісності при одночасній роботі двох версій.
Типові проблеми при налаштуванні Rolling Update
Одна з частих помилок — занадто малий maxSurge або maxUnavailable, що затягує деплой. Наприклад, якщо maxSurge=1, а реплік 10, то оновлення займе 10 раундів. Правильно обирати ці параметри, виходячи із загальної кількості реплік та допустимої швидкості розгортання. Інша проблема — некоректні readiness-проби: вони мають перевіряти реальну готовність застосунку, а не просто повертати 200. Якщо проба не включає перевірку БД, новий pod може почати приймати трафік до того, як база ініціалізована, що призведе до помилок 500. Також часто забувають налаштувати terminationGracePeriodSeconds: якщо застосунок не встигає завершитися до примусового SIGKILL, активні запити втрачаються. Рекомендується встановлювати значення не менше 30 секунд.
Що входить у налаштування Rolling Update?
- Аналіз поточної інфраструктури та архітектури застосунку
- Конфігурація Kubernetes Deployment або Docker Swarm service
- Написання коректних readiness- та liveness-проб
- Доопрацювання graceful shutdown (SIGTERM, завершення запитів)
- Розробка стратегії backward-compatible міграцій
- Тестування на staging-оточенні з навантаженням
- Документація налаштувань та регламентів
- Навчання команди роботі з Rolling Update
Процес роботи
- Аналітика: вивчаємо поточний стек, інфраструктуру, процеси деплою
- Проектування: обираємо параметри Rolling Update, health checks
- Реалізація: налаштовуємо оркестратор, пишемо проби, graceful shutdown
- Тестування: перевіряємо на staging з навантажувальним тестуванням
- Деплой: котимо на production, моніторимо перші 24 години
Терміни реалізації
| Етап | Тривалість |
|---|---|
| Базове налаштування Rolling Update (Kubernetes + health checks) | 2–3 дні |
| Docker Swarm rolling update | 1–2 дні |
| Розробка backward-compatible міграцій | 1–2 дні |
| Повний цикл з навчанням | 3–5 днів |
Зв'яжіться з нами для консультації — оцінимо ваш проєкт за 2 дні. Замовте налаштування Rolling Update у професіоналів. Отримайте готове рішення з гарантією нульового downtime та повної сумісності.