На каком этапе CI/CD подготавливается инфраструктура для развертывания приложения

План подготовки инфраструктуры в CI/CD

Подготовка инфраструктуры для развертывания приложения — это критический процесс, который обычно происходит на ранних этапах CI/CD pipeline, но может быть реализован по разным стратегиям. Основные этапы и подходы:

1. Основные стратегии подготовки инфраструктуры

IaC (Infrastructure as Code) — это ключевая парадигма, где инфраструктура описывается в коде (например, Terraform, Ansible) и создается автоматически.

• Предварительная подготовка (Pre-provisioning):

    Инфраструктура создается заранее, до запуска pipeline. Это может быть сделано вручную или автоматически по отдельному schedule/trigger. Затем pipeline использует уже существующие ресурсы.

```yaml
# Пример stage в GitLab CI для предварительной подготовки
provision-infra:
  stage: .pre
  script:
    - terraform init
    - terraform apply -auto-approve
  only:
    - schedules  # Запускается только по расписанию, например, каждый день
```

• Динамическая подготовка (Dynamic Provisioning) в рамках pipeline:

    Инфраструктура создается непосредственно как часть pipeline, перед этапами деплоя. Это наиболее гибкий и чистый подход.

```yaml
# Пример pipeline (Jenkins / GitLab CI)
stages:
  - build
  - test
  - provision    # Этап подготовки инфраструктуры
  - deploy
  - cleanup
```

• Использование неизменяемой инфраструктуры (Immutable Infrastructure):

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

2. Типичное место в CI/CD Pipeline

В классическом pipeline подготовка инфраструктуры чаще всего происходит после этапов сборки (Build) и тестирования (Test), но непосредственно перед этапом развертывания (Deploy).

Build → Test → Provision Infrastructure → Deploy Application → Post-Deploy Tests → Cleanup (optional)

Логическое обоснование: мы хотим проверить, что наш код (приложение) работает корректно (успешно проходит тесты), прежде чем тратить ресурсы на создание инфраструктуры для его развертывания. Однако в некоторых моделях, особенно при использовании инфраструктуры как среды для тестирования, подготовка может происходить раньше.

3. Практическая реализация с использованием Terraform

Рассмотрим пример динамической подготовки в GitLab CI/CD:

# .gitlab-ci.yml
stages:
  - build
  - unit_test
  - provision_staging
  - deploy_to_staging
  - integration_test
  - provision_production  # Подготовка Prod инфраструктуры
  - deploy_to_production

provision_staging:
  stage: provision_staging
  image:
    name: hashicorp/terraform:latest
  script:
    - cd terraform/staging
    - terraform init
    - terraform plan -out=plan.tfplan
    - terraform apply plan.tfplan
  only:
    - main  # Запускаем только для основной ветки
  artifacts:
    reports:
      terraform: terraform/staging/plan.tfplan

deploy_to_staging:
  stage: deploy_to_staging
  script:
    - kubectl apply -f k8s/manifests  # Пример деплоя в подготовленный кластер Kubernetes
  environment: staging

4. Ключевые принципы и лучшие практики

• Отделение инфраструктуры приложения от инфраструктуры среды: Часто инфраструктура базовых сервисов (сети, кластер Kubernetes, базы данных) создается и управляется отдельно, а инфраструктура приложения (Namespace, Deployment, Service в K8s) создается в pipeline.
• Использование разных веток инфраструктуры для разных стадий: Инфраструктура для staging и production должна быть описана отдельно, но может использовать общие модули.
• Декларативный подход: Инфраструктура описывается в декларативных файлах (Terraform, CloudFormation), что позволяет четко понимать ее состояние.
• Версионирование инфраструктуры: Код инфраструктуры хранится в Git вместе с кодом приложения или в отдельном репозитории, что обеспечивает контроль изменений и возможность rollback.
• Проверки и политики: Перед применением используются terraform plan, проверки безопасности (например, с checkov), и утверждения (для production).

5. Связь с концепцией "Environment as a Service"

В современных DevOps практиках подготовка инфраструктуры все чаще становится самостоятельным сервисом, который может быть вызван по требованию (on-demand) для создания временной среды (например, для тестирования или разработки). Это может быть интегрировано в pipeline через API.

# Пример вызова сервиса подготовки среды через API в pipeline
curl -X POST https://env-service.company.com/api/environments \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"branch": "feature-x", "lifetime": "24h"}'

Заключение

Таким образом, подготовка инфраструктуры — это не фиксированный этап, а стратегический процесс, который может быть реализован в разных точках CI/CD pipeline. Основная тенденция — делать ее автоматизированной, декларативной и максимально близкой к этапу деплоя, обеспечивая свежесть, соответствие требованиям и эффективное использование ресурсов. В идеальном случае инфраструктура приложения создается и уничтожается в рамках каждого pipeline run, что соответствует принципам Immutable Infrastructure и Ephemeral Environments.