Infrastructure as Code

Каждый раз, когда команда говорит «у нас IaC», мой первый вопрос звучит одинаково: правки мышкой в проде есть? Ответ «иногда, в срочных случаях» означает, что IaC нет, а есть его театр. Инфраструктура прода — облачные ресурсы, манифесты k8s, права, сетевые политики, ссылки на секреты — описана как версионируемый код в git и применяется декларативно через автоматический конвейер. PR, ревью, план, применение — и никакого «срочно правлю через консоль». Главная практика внутри L1 Configuration Management; соседи (GitOps, Policy as Code, Secrets Management) — в открытых вопросах.

Что должен уметь

Главный навык на уровне L5 — управление состоянием. Я регулярно вижу инциденты, которые начинаются с повреждённого файла состояния: два одновременных terraform apply без блокировки, состояние, случайно закоммиченное в git, потерянная настройка удалённого хранилища. Удалённое состояние с блокировкой — это не «удобно», это условие безопасной работы. Если состояние лежит в локальном файле, это не «пока работает», это таймер до инцидента.

Понимает разницу между декларативным и императивным подходом; читает чужой код на Terraform, Helm или Kustomize и понимает, какой ресурс из него получится.
Применяет изменения через конвейер (terraform plan → ревью → apply); состояние руками не редактирует, в консоль облака «по-быстрому» не ходит.

Пишет модуль или чарт под новый ресурс: переменные, выходные значения, README с примером, версионирование по semver.
Управляет удалённым состоянием: настройка хранилища (S3 с DynamoDB, GCS, Terraform Cloud), блокировки, разделение состояния по окружениям.
Использует Helm или Kustomize для манифестов k8s; понимает разницу — Helm это шаблон плюс значения, Kustomize это правки без шаблонов — и когда что уместнее.

Проектирует структуру репозитория: каталог на окружение против рабочих пространств, переиспользование через модули, секреты в Vault, Secrets Manager или Sealed Secrets, а в коде только ссылки.
Внедряет обнаружение дрейфа: регулярный terraform plan на основной ветке, алерты на изменения мимо конвейера. Правку мышкой в проде разбирает как операционный инцидент.
Реализует политики как код (OPA, Conftest, Sentinel) прямо в конвейере: требования безопасности проверяются автоматически, и PR с бакетом, открытым наружу, или ролью с правами на всё просто не проходит.

L6+

Выбирает стратегию на уровне организации: чем описывать, как раскладывать репозитории (один или много), какой поток применять (через CI или через GitOps), как связать всё это с каталогом сервисов.
Соразмеряет строгость проверок с последствиями изменения: права, сетевые политики, DNS и боевая база требуют явного ревью перед применением, рутинные правки уезжают автослиянием при зелёных проверках.

Материалы

Книги

Yevgeniy Brikman — Terraform: Up & Running, 3-е изд. (O’Reilly, 2022). Практическое руководство по Terraform для прода: модули, состояние, тестирование, связка с CI/CD.
Kief Morris — Infrastructure as Code: Dynamic Systems for the Cloud Age, 2-е изд. (O’Reilly, 2020). Принципы вне привязки к инструменту: декларативность, идемпотентность, версионирование, тестируемость. Ложится и на Terraform, и на Pulumi, и на Crossplane.

Статьи и фреймворки

Adam Wiggins — The Twelve-Factor App, фактор III «Config». Про то, что конфигурация живёт в окружении, а не в кодовой базе; с инфраструктурным кодом пересекается ровно там, где начинаются переменные окружения и секреты.

Инструменты

Terraform / OpenTofu — описание облака кодом на HCL, вне привязки к одному провайдеру. По моим наблюдениям, OpenTofu активно набирает обороты после смены лицензии HashiCorp в 2023 году: форк под крылом Linux Foundation с живым сообществом.
Pulumi — то же самое, но на обычных языках (TypeScript, Python, Go, C#, Java); альтернатива HCL для команд, у которых инженерная культура уже есть.
Helm — менеджер пакетов для Kubernetes; чарт — это шаблон плюс значения. Стандарт для того, что распространяется наружу.
Kustomize — настройка без шаблонов, правками поверх базы; встроен в kubectl apply -k. Альтернатива Helm для тех, кто шаблоны не любит.
Crossplane — расширение Kubernetes, которое управляет ресурсами за пределами кластера через его же API: один пульт и для приложений, и для инфраструктуры.
Политики как код — OPA и Conftest, Sentinel от HashiCorp; проверка требований безопасности в конвейере до применения.
Хранилища состояния — Terraform Cloud, Spacelift, Atlantis (open-source автоматизация вокруг pull request); дают централизованное состояние без ручной возни с настройками хранилища.

Best practices

Правка мышкой в проде не бывает «один разочек». Это всегда система. «Быстро поправлю в консоли облака, потом запишу в код» — фраза, после которой через месяц никто не помнит, что именно менялось, дрейф растёт, а следующий terraform apply бодро «чинит» сделанное руками и роняет сервис. Поэтому у меня такая правка — операционный инцидент с постмортемом, а не срочный фикс.

План идёт перед применением всегда. Читает его не только автор PR. План показывает точную разницу: что создастся, что обновится на месте, что пересоздастся, а что будет уничтожено. Применение без прочитанного плана — гадание с правами root в проде. Разница между «мы посмотрели разницу» и «мы посмотрели, что CI зелёный» — это разница между изменением и лотереей.

Состояние — удалённое и с блокировкой, локального не бывает в принципе. Два одновременных применения дают повреждённый файл, потерянные из учёта ресурсы и несколько часов ручного восстановления в самый неудачный момент. Хранилище вроде S3 с DynamoDB, GCS со штатной блокировкой или Terraform Cloud закрывает сразу две дыры: саму блокировку и общую видимость того, кто именно сейчас катит изменение. Локальный файл этого не даёт никогда.

Одно окружение — одно состояние, без сцепок между ними. Когда dev, staging и прод живут в общем файле, случайный эксперимент в dev делает план в проде ненулевым, и рано или поздно кто-нибудь нажмёт применение не глядя. Разделение по окружениям физически ограничивает то, что может пострадать. Дисциплина простая, но её постоянно откладывают до «вырастем — разделим», а к тому моменту разделение стоит в разы дороже.

Секретов в коде нет ни в открытом, ни в зашифрованном виде. Vault, AWS Secrets Manager, GCP Secret Manager, Sealed Secrets для k8s — в коде остаются только ссылки. Зашифрованный секрет в git — это «расшифруется, когда утечёт ключ». А ключ утечёт не в удобный день, и в этот момент разбираться придётся уже не с одним секретом, а со всей историей коммитов, где он лежал. Шифрование репозитория на диске работает как страховка, а не как защита, и от утечки самого секрета оно не спасает.

Инфраструктурный код тестируется до прода, а не проверяется им. «Тест-стенд у нас прод» стоит дорого ровно один раз. На первой ошибке в правах или сетевой политике. Модульные проверки (terraform test, terratest, kuttl для k8s), интеграционные прогоны в staging, план в PR и проверка политик в конвейере вместе занимают минуты. Стоимость непроверенной звёздочки в правах доступа измеряется инцидентом.

Граница у практики есть, и проходит она по частоте изменений и по правам. Если инфраструктура меняется дважды в год и состоит из трёх виртуалок, конвейер с планом, политиками и отдельным хранилищем состояния окупаться не будет: там честнее скрипт и запись в вики. Не работает подход и там, где у команды нет прав применять изменения самостоятельно, а всё уходит заявкой в соседний отдел: код в репозитории есть, а порядок применения остаётся ручным, и весь смысл теряется по дороге.

Связанные листья

GitOps — там контроллер сам подтягивает изменения, здесь их применяет конвейер. Соседняя практика внутри того же L1 Configuration Management.
Service Ownership — владелец сервиса владеет и его инфраструктурным кодом; каталог связывает сервис с местом, где этот код лежит.
Progressive Delivery — изменения инфраструктуры сами просятся выкатываться постепенно, особенно если это выкатки в k8s, сетевые политики или права.
Runbooks — runbook’и на типичные инциденты с инфраструктурным кодом (повреждённое состояние, дрейф, ручной откат) — обязательный набор.
Programming Languages — Pulumi на обычных языках превращает инфраструктурный код в обычную разработку со всеми её практиками.
Networking — сетевые политики, ingress, настройки балансировщиков — частая часть инфраструктурного кода.
Cloud Providers — облачные ресурсы (сети, права, управляемые сервисы) — главная цель описания кодом; граница ответственности провайдера определяет, что вообще можно описать.
Containerization & Orchestration — кластер k8s разворачивается тем же кодом; манифесты приложений — следующий декларативный слой того же подхода.

Открытые вопросы

Policy as Code (TBD) — OPA, Conftest, Sentinel: самостоятельная практика на стыке Configuration Management и Information Security.
Secrets Management (TBD) — Vault, Secrets Manager, Sealed Secrets: отдельная подтема на стыке с безопасностью.
Инфраструктурный код для нескольких облаков — когда мультиоблако вообще оправдано и чем оплачивается уход от привязки к одному поставщику.

Отдельно висит выбор между Terraform и OpenTofu для команды, которая стартует сейчас. У меня нет уверенного ответа. OpenTofu обещает путь, который ведёт сообщество, но консенсуса по долгосрочной стратегии я пока не вижу, а команды вокруг делятся примерно поровну: одни выжидают, другие уже переехали.