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

Подготовка инфраструктуры для развертывания приложения: этапы и стратегии

Подготовка инфраструктуры — это фундаментальная задача в DevOps-практиках, которая может происходить на разных этапах жизненного цикла разработки ПО. Традиционно она выполнялась вручную или с помощью скриптов перед началом разработки, но современные подходы смещают её в сторону непрерывной и автоматизированной подготовки на протяжении всего цикла. Вот ключевые этапы и подходы:

1. До начала разработки (классический подход "инфраструктура перед кодом")

• Описание: Команда операторов или DevOps создаёт стенды (development, staging, production) вручную или с помощью скриптов конфигурации (например, bash-скрипты) заранее. Приложение затем "устанавливается" на готовую инфраструктуру.
• Пример (устаревший метод): Ручное создание виртуальных машин в VMware и установка на них веб-сервера.
• Недостатки: Длительное время подготовки, дрейф конфигураций, риск "снежинок" (уникальных, невоспроизводимых конфигураций), трудности масштабирования.

2. На этапе CI/CD (современный подход "инфраструктура как код")

• Описание: Это основной современный этап. Инфраструктура описывается декларативно в виде кода (Terraform, AWS CDK, Pulumi) и подготавливается автоматически как часть пайплайна непрерывной интеграции и доставки (CI/CD).
• Этапы внутри CI/CD:

        *   **Сборка (Build):** Генерируются артефакты приложения (Docker-образы, JAR-файлы).
        *   **Подготовка инфраструктуры (Provisioning):** Запускается скрипт Terraform или CloudFormation, который создаёт или изменяет необходимые ресурсы (сети, ВМ, кластеры Kubernetes, базы данных).
        *   **Развертывание (Deployment):** На подготовленную инфраструктуру деплоится новое приложение.

• Пример пайплайна GitLab CI (упрощённый):

  stages:
    - build
    - provision
    - deploy
  
  build_image:
    stage: build
    script:
      - docker build -t myapp:$CI_COMMIT_SHA .
  
  provision_infra:
    stage: provision
    script:
      - cd terraform/
      - terraform init
      - terraform apply -auto-approve
    only:
      - main  # Запускаем apply только для продакшн-ветки
  
  deploy_app:
    stage: deploy
    script:
      - kubectl set image deployment/myapp app=myapp:$CI_COMMIT_SHA
  

• Преимущества: Воспроизводимость, версионирование, скорость, безопасность (креденшилы управляются пайплайном), возможность preview изменений (terraform plan).

3. По требованию / динамически (для тестирования и разработки)

• Описание: Для каждого Pull Request (PR) или задачи разработчика может автоматически разворачиваться временная среда с полным стеком инфраструктуры. После мержа PR или завершения работы среда автоматически уничтожается.
• Технологии: Terraform Workspaces, AWS CDK с изоляцией через Git-ветки, инструменты вроде Jenkins Job DSL или Spacelift.
• Цель: Обеспечить изолированное тестирование изменений в реалистичных условиях без влияния на общие среды (dev/staging).

4. Непрерывно и идемпотентно (философия "cattle, not pets")

• Описание: В парадигме иммутабельных (неизменяемых) инфраструктур (например, на базе Docker + Kubernetes) сама инфраструктура приложения (поды, сервисы, ingress) описывается в манифестах (YAML) и деплоится вместе с каждым релизом приложения. "Подготовка" здесь — это создание или обновление объектов внутри уже работающего кластера.
• Пример манифеста Kubernetes Deployment:

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: myapp
  spec:
    replicas: 3
    selector:
      matchLabels:
        app: myapp
    template:
      metadata:
        labels:
          app: myapp
      spec:
        containers:
        - name: app
          image: myapp:latest
          ports:
          - containerPort: 8080
  

• Важный нюанс: Базовый кластер Kubernetes (ноды, сетевые политики) может быть подготовлен заранее (этап 1 или 2), а рабочая нагрузка (workload) приложения — деплоиться постоянно.

Ключевые принципы современной подготовки инфраструктуры:

• Инфраструктура как код (IaC): Всё описывается в файлах, хранящихся в Git.
• Идемпотентность: Многократное выполнение скрипта приводит к одинаковому результату.
• Иммутабельность: Вместо изменения существующих серверов разворачиваются новые и старые уничтожаются.
• Автоматизация: Ни один этап не должен требовать ручного вмешательства.

Итог: В современном DevOps подготовка инфраструктуры — это не единовременное событие, а непрерывный, автоматизированный процесс, интегрированный в CI/CD-пайплайны. Основной этап подготовки (особенно для production) приходится на стадию provisioning в пайплайне, однако для сред разработки и тестирования она может запускаться динамически по триггеру (например, создание PR). Это позволяет достичь высокой скорости, надежности и согласованности между всеми средами.