infrastructure as code

Infrastructure as Code (IaC, инфраструктура как код) — это практика управления и provisioning вычислительной инфраструктуры с помощью машиночитаемых конфигурационных файлов вместо ручных процессов или интерактивных инструментов. Серверы, сети, базы данных и облачные сервисы описываются в коде, который хранится в системе контроля версий и обрабатывается автоматически.

Почему IaC изменил DevOps

До IaC администраторы настраивали серверы вручную: через SSH, web-интерфейсы облачных консолей или скрипты на bash. Такой подход не масштабировался: конфигурация серверов «дрейфовала» со временем, окружения расходились между собой, а восстановление после аварии занимало часы или дни. Никто не помнил точно, что и зачем было изменено полгода назад.

IaC решает эти проблемы, применяя к инфраструктуре те же инженерные практики, что и к коду приложения: версионирование, code review, тестирование, автоматизацию.

Декларативный и императивный подходы

Декларативный IaC описывает желаемое конечное состояние: «у меня должно быть 3 сервера с такими характеристиками». Инструмент сам вычисляет, какие действия нужны для достижения этого состояния. Примеры: Terraform, AWS CloudFormation, Pulumi.

Императивный IaC описывает последовательность шагов: «создай сервер, установи пакет, запусти сервис». Примеры: Ansible (в значительной мере), Chef, скрипты bash/PowerShell.

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

Ключевые преимущества Infrastructure as Code

• Воспроизводимость: одна конфигурация разворачивает идентичные окружения — dev, staging, production. Проблема «у меня работало» исчезает.
• Версионность: история изменений инфраструктуры хранится в Git. Видно, кто, когда и зачем менял конфигурацию. Откат — это `git revert`.
• Автоматизация: новое окружение поднимается за минуты, не часы. Масштабирование автоматизировано.
• Согласованность: нет «ручных» изменений, которые расходятся с кодом. Код — единственный источник правды.
• Тестируемость: инфраструктуру можно тестировать инструментами вроде Terratest, Kitchen-Terraform, Checkov.

Основные инструменты IaC

Terraform

Самый популярный мультиоблачный IaC-инструмент. Декларативный HCL-синтаксис, тысячи провайдеров, зрелая экосистема модулей.

Pulumi

Позволяет описывать инфраструктуру на TypeScript, Python, Go, C#, Java. Привлекает разработчиков, избегающих нового DSL.

AWS CloudFormation / Azure Bicep / Google Deployment Manager

Нативные инструменты конкретных облаков. Глубоко интегрированы, но не переносимы между провайдерами.

Ansible

Преимущественно для configuration management, но используется и для provisioning. Agentless, работает через SSH.

Паттерны организации IaC

Модульность: инфраструктура разбивается на переиспользуемые модули — сеть, кластер, приложение, мониторинг. Каждый модуль версионируется отдельно.

Окружения через параметры: один и тот же код разворачивает dev и production, различаясь только переменными (размер инстансов, количество реплик, имена).

Разделение state: инфраструктура делится на независимые state-файлы с чёткими границами ответственности. Изменение в одном модуле не блокирует работу с другим.

IaC и безопасность

Политики безопасности тоже описываются как код — это называют Policy as Code. Инструменты: Open Policy Agent (OPA), Checkov, tfsec, Sentinel. Они сканируют IaC-конфигурации до применения и блокируют опасные паттерны: публичные S3-бакеты, открытые security groups, отключённое шифрование.

Drift и как с ним бороться

Configuration drift — расхождение между тем, что описано в коде, и тем, что реально работает в облаке. Возникает из-за ручных изменений через консоль. Для обнаружения drift используют terraform plan в режиме мониторинга, AWS Config, Drift Detection в CloudFormation. Решение — строгое правило: все изменения только через IaC, ручные правки через консоль запрещены.