При обновлении веб-приложения на продакшене пользователи часто теряют доступ или получают ошибки 503. Представьте: выкатили новую версию, а половина запросов упала с таймаутом — база не успела переключиться. Стандартный подход «остановить → заменить → запустить» не подходит для сервисов с требованиями SLA 99.9%. Мы настраиваем Rolling Update — стратегию, исключающую простой при минимальных затратах ресурсов. Наш опыт — 10+ лет в DevOps, внедрение rolling update для fintech и e-commerce с миллионной аудиторией.
Почему Rolling Update — лучший выбор для zero-downtime деплоя?
Rolling Update заменяет инстансы постепенно: сначала обновляется 1–2 пода, проверяется их здоровье, затем следующие. В отличие от 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. Если проба не включает проверку БД, новый под может начать принимать трафик до того, как база инициализирована, что приведёт к ошибкам 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 и полной совместимости.