Как происходит deploy билда в окружении

# Процесс деплоя билда в окружении: от артефакта до продакшена

Общая концепция и компоненты процесса

Деплой (развертывание) билда — это комплексный процесс доставки собранного артефакта (приложения, сервиса, обновления) в целевое окружение (environment), его настройки, запуска и верификации. Это ключевой этап CI/CD-пайплайна, требующий максимальной автоматизации, идемпотентности и контроля.

Основные компоненты:

• Артефакт (билд): Результат сборки — Docker-образ, JAR/WAR-файл, набор JS/бинарных файлов.
• Окружение: Изолированный набор инфраструктурных ресурсов (dev, staging/UAT, pre-prod, prod).
• Инфраструктура: Может быть "традиционной" (виртуальные машины, bare-metal) или "современной" (оркестраторы, бессерверные платформы).
• Паблишер/Deployer: Инструмент, выполняющий развертывание (kubectl, Ansible, Terraform, Capistrano, встроенный в CI/CD-систему).

Типовой процесс деплоя (на примере модели с Docker и Kubernetes)

Представим пайплайн для микросервиса, упакованного в Docker.

1. Подготовка артефакта и целевого окружения

• CI-стадия завершается успешной сборкой, прогоном юнит-тестов и созданием Docker-образа с уникальным тегом (часто SHA коммита).
• Образ пушится в реестр (Docker Hub, GitLab Registry, ECR, GCR, Harbor).

# Пример Dockerfile для Node.js приложения
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY src/ ./src/
# Сборка приложения...

FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app ./
USER node
EXPOSE 3000
CMD ["node", "src/server.js"]

# Сборка и публикация образа в CI (упрощенный пример)
docker build -t my-registry.com/my-app:${CI_COMMIT_SHA} .
docker push my-registry.com/my-app:${CI_COMMIT_SHA}

• CD-стадия активируется (вручную или автоматически), получает артефакт и подготавливает окружение: проверяет доступность кластера/серверов, наличие нужных конфигураций (ConfigMaps, Secrets), сетевых политик.

2. Стратегия развертывания

Выбор стратегии критически важен для минимизации простоя и рисков.

• Recreate (с пересозданием): Останов всех старых подов -> развертывание новых. Просто, но есть даунтайм.
• Rolling Update (постепенное обновление): Постепенная замена подов старых версий на новые. Нет даунтайма, поддерживается две версии одновременно. Стандарт для Kubernetes.
• Blue-Green (сине-зеленое): Два идентичных окружения ("blue" — текущая версия, "green" — новая). После развертывания и тестов в "green", трафик переключается. Мгновенный откат, но требует двойных ресурсов.
• Canary (канареечное): Новая версия развертывается для небольшого % трафика/пользователей. После успешного мониторинга доля постепенно увеличивается до 100%. Лучший контроль рисков.

В Kubernetes Rolling Update настраивается в Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Сколько лишних подов можно создать поверх replicas
      maxUnavailable: 0  # Сколько подов может быть недоступно во время обновления
  template:
    spec:
      containers:
      - name: app
        image: my-registry.com/my-app:abc123  # Тег обновляется при деплое
        readinessProbe: # Важно для корректного Rolling Update
          httpGet:
            path: /health
            port: 3000

3. Применение конфигурации и релиз

Инструмент деплоя (например, kubectl, helm, kustomize) применяет манифест, ссылающийся на новый образ.

# Пример обновления образа в Deployment
kubectl set image deployment/my-app app=my-registry.com/my-app:${NEW_SHA} -n production

# Или с использованием Helm (более управляемый способ)
helm upgrade --install my-app ./charts/my-app \
  --set image.tag=${NEW_SHA} \
  --set environment=prod \
  --atomic # Важно: автоматический откат при неудаче

В этот момент оркестратор начинает процесс замены подов согласно выбранной стратегии.

4. Верификация и пост-деплойные проверки

Успешное обновление пода не гарантирует работоспособность приложения. Обязательные этапы:

• Readiness/Liveness Probes: Kubernetes автоматически проверяет здоровье подов.
• Интеграционные/сквозные тесты (Post-Deployment Tests): Запускаются автоматически против нового окружения.
• Мониторинг и алертинг: Проверка метрик (задержка, количество ошибок, RPS) в Grafana/Prometheus, логов (ELK). Отклонение от базовой линии может триггерить автоматический откат.
• Smoke-тесты: Быстрая проверка ключевой функциональности.
• Согласование с бизнес-показателями (для продвинутых пайплайнов): Использование Feature Flags и систем типа Flagger для канареечных развертываний на основе бизнес-метрик.

5. Процедура отката (Rollback)

Четкий и быстрый откат — страховка от сбоев. Механизм зависит от инструмента:

• Kubernetes: kubectl rollout undo deployment/my-app
• Helm: helm rollback my-app 1 (к предыдущему релизу)
• Blue-Green: Мгновенное переключение трафика обратно на "blue".

Ключевые принципы успешного деплоя

• Идемпотентность: Повторный запуск деплоя в неизмененном состоянии не должен ничего менять.
• Воспроизводимость: Деплой в любое окружение должен производиться одинаковым способом из одного источника истины (инфраструктура как код, GitOps).
• Неизменяемость (Immutable Infrastructure): Вместо изменения конфигурации на "живых" серверах, разворачиваются абсолютно новые инстансы из образа.
• Малая площадь изменений (Small Batch Sizes): Деплой небольших частей снижает сложность и упрощает отладку.
• Комплексный мониторинг (Observability): Без логов, трейсов и метрик деплой вслепую опасен.

Современные парадигмы: GitOps

В модели GitOps (например, с ArgoCD или Flux) процесс деплоя инвертируется. Не CI-система "заталкивает" изменения в кластер, а оператор в кластере постоянно сравнивает желаемое состояние, описанное в Git-репозитории (манифесты, Helm-чарты), с реальным состоянием кластера и автоматически приводит их в соответствие. Деплой сводится к мержу кода в нужную ветку Git, что повышает безопасность, прозрачность и согласованность.

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