IAC в CircleCI: как автоматизировать инфраструктуру без лишних усилий

Введение

Infrastructure as Code (IAC) — подход, при котором вся инфраструктура описывается декларативными конфигурациями и управляется через систему контроля версий. На CI/CD‑платформе CircleCI IAC позволяет проверять код, автоматически разворачивать, тестировать и обновлять окружения. Это устраняет разрыв между разработкой и эксплуатацией, сокращает время вывода новых функций и повышает предсказуемость релизов.

1. Iac‑стек в CircleCI: поддерживаемые технологии

Технология	Тип iac	Как подключить в CircleCI	Пример использования
Terraform	Декларативный	setup_remote_docker → terraform init/apply в job	Автоматическое создание VPC, RDS и EKS‑кластера
Helm	Пакетный менеджер для k8s	helm upgrade --install в job после terraform apply	Деплой микросервисов в уже созданный кластер
Ansible	Пошаговый (imperative)	ansible-playbook в контейнере CircleCI	Настройка базовых параметров ОС, установка сертификатов
Pulumi (Go, TypeScript)	Программный	pulumi up в job, state в S3/Google Cloud	Инфраструктура как код на привычных языках

CircleCI поставляет официальные Docker‑образы с клиентами Terraform 1.6, Helm 3.12 и Pulumi 3.9. При необходимости можно собрать кастомный образ, добавив нужные плагины в Dockerfile.

1.1 Хранение state‑файлов

Для Terraform необходим бекенд. Наиболее надёжные варианты в CircleCI:

• AWS S3 + DynamoDB – консистентность при параллельных планах, поддержка блокировок.
• Google Cloud Storage + Cloud Firestore – аналогичный уровень надёжности.
• CircleCI contexts – передача переменных окружения (access keys) без их раскрытия в логах.

Пример конфигурации бекенда в main.tf:

terraform {
  backend "s3" {
    bucket         = "ci-terraform-state"
    key            = "prod/eu-west-1/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

1.2 Параллелизм и оркестрация

CircleCI позволяет запускать несколько jobs одновременно, каждый со своим resource_class. При работе с IAC важно:

• Не запускать одновременно два terraform apply на один workspace – использовать requires и type: approval для последовательного выполнения.
• Разделять планы: plan‑job генерирует файл plan.out, который передаётся в apply‑job через persist_to_workspace.

2. Пошаговый пример: от кода до кластера k8s

Сценарий: при пуше в ветку main CI разворачивает инфраструктуру в AWS и деплоит приложение в EKS.

2.1 .circleci/config.yml

version: 2.1
orbs:
  terraform: circleci/terraform@3.1
  helm: circleci/helm@2.1

executors:
  small:
    docker:
      - image: cimg/base:stable
    resource_class: medium

jobs:
  terraform-plan:
    executor: small
    steps:
      - checkout
      - terraform/install:
          version: "1.6.0"
      - run:
          name: Init & Plan
          command: |
            terraform init
            terraform plan -out=plan.out
      - persist_to_workspace:
          root: .
          paths:
            - plan.out

  terraform-apply:
    executor: small
    steps:
      - attach_workspace:
          at: .
      - run:
          name: Apply
          command: terraform apply -auto-approve plan.out

  helm-deploy:
    executor: small
    steps:
      - checkout
      - helm/install-helm:
          version: v3.12.0
      - run:
          name: Deploy to EKS
          command: |
            aws eks update-kubeconfig --region eu-west-1 --name prod-cluster
            helm upgrade --install webapp ./helm/webapp \
              --namespace prod --create-namespace \
              --set image.tag=${CIRCLE_SHA1}
      - store_artifacts:
          path: helm/release-notes.txt

workflows:
  version: 2
  deploy-prod:
    jobs:
      - terraform-plan
      - terraform-apply:
          requires:
            - terraform-plan
          context: aws-prod
      - helm-deploy:
          requires:
            - terraform-apply
          context: kube-prod

Ключевые моменты:

• persist_to_workspace передаёт plan.out без риска утечки секретов.
• context обеспечивает безопасный доступ к AWS‑ключам и kubeconfig.
• helm upgrade --install делает деплой идемпотентным.

2.2 Время выполнения

Шаг	Среднее время (сек)	Примечание
Checkout	8	Кешируются зависимости
Terraform init	12	При использовании S3‑бекенда
Terraform plan	45	План генерирует ~300 изменений
Terraform apply	180	2 мин 30 сек, полностью автоматизировано
Helm deploy	30	Параллельный пуш Docker‑образа в ECR (~15 сек)
Итого	≈ 5 мин	На продакшене, без ручных проверок

До внедрения IAC процесс занимал ~45 минут (ручные скрипты, согласования). Сокращение на ≈ 90 % ускорило выпуск новых функций.

3. Метрики и мониторинг iac‑pipeline

Без измерений невозможно понять, где теряется время и где появляются ошибки.

Метрика	Как собрать в CircleCI	Пороговое значение
Время terraform plan	circleci-agent step exit-status + скрипт	< 30 сек при < 200 ресурсах
Количество блокировок DynamoDB	CloudWatch DynamoDB/SuccessfulRequestLatency	< 5 мс
Частота откатов helm rollback	Helm‑plugin helm rollback --dry-run + артефакт	< 2 % релизов
Уровень drift (расхождение стейта)	terraform plan -detailed-exitcode в nightly‑job	0 (план без изменений)
Скорость загрузки Docker‑образов	docker pull в job + time	< 12 сек на образ 150 MB

Для алертинга настроена интеграция CircleCI Insights → Datadog; при превышении порогов webhook отправляется в Slack‑канал #ci-alerts.

3.1 Типичные подводные камни

Проблема	Причина	Как исправить
Флеш‑кеш Terraform	Отсутствие -lock=false в plan при параллельных job	Добавить terraform plan -lock=false только в read‑only job, а apply – с блокировкой
Helm‑release «stuck»	Короткий --timeout (по умолчанию 5 мин) при больших образах	Установить --timeout 10m и включить --wait
Переполнение S3‑bucket	Хранение всех plan‑файлов без очистки	Lifecycle rule: удалять файлы старше 30 дней
Утечка секретов	Вывод переменных через echo	Использовать circleci env и маскировать вывод (set +x)

4. Масштабирование iac в больших командах

При росте от 5 до 200 разработчиков IAC‑pipeline становится критической частью инфраструктуры.

4.1 Модульность конфигураций

• Terraform modules – отдельный репозиторий для VPC, EKS, RDS; подключение через source = "git::https://github.com/org/terraform-aws-vpc.git?ref=v1.2.0".
• Helm charts – values.yaml‑файлы per‑environment (dev, staging, prod). В CI меняем нужный файл через yq.

4.2 Права доступа

CircleCI contexts задают наборы переменных для разных окружений. В сочетании с IAM Roles for Service Accounts (IRSA) в EKS каждый пайплайн получает только необходимые права.

4.3 Review‑process

• Plan‑only PR – каждый Pull Request автоматически запускает terraform plan и публикует результат в комментарий PR (через orb github-comment).
• Manual approval – type: approval в workflow заставляет инженера подтвердить apply после ревью кода и плана.

4.4 Кеширование и ускорение

• Remote Docker layer caching – docker_layer_caching: true в resource_class: large сокращает сборку образов на ≈ 40 %.
• Terraform Cloud/Enterprise – хранит state в управляемом сервисе, избавляя от собственного S3/DynamoDB.

Заключение

Infrastructure as Code в CircleCI автоматизирует создание и обновление инфраструктуры, сокращает время вывода функций с десятков минут до пяти, обеспечивает контроль через метрики, блокировки и ревью, а также масштабируется благодаря модульным конфигурациям и контекстам доступа. Приоритетом должно стать внедрение описанной конфигурации, чтобы уменьшить количество человеческих ошибок и получить полную видимость над состоянием окружения.