Infrastructure as Code: зачем описывать инфраструктуру кодом

Что такое Infrastructure as Code

Infrastructure as Code (IaC) — подход, при котором инфраструктуру не настраивают руками в панели провайдера или по SSH, а описывают в файлах. В этих файлах указано, какие нужны серверы, сети, базы данных, DNS-записи, права доступа. Специальный инструмент читает описание и приводит реальную инфраструктуру в соответствие с ним.

Главная идея: инфраструктура живёт по тем же правилам, что и код приложения — с историей изменений, ревью и автоматическими проверками.

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

Пример декларативного описания в Terraform:

resource "aws_s3_bucket" "assets" {
  bucket = "my-project-assets"
}

Вы не пишете «создай бакет» — вы пишете «бакет должен существовать». Если его нет, Terraform создаст его; если есть и совпадает с описанием, ничего не сделает.

Граница не абсолютная: Ansible тоже стремится к идемпотентности, а Pulumi описывает желаемое состояние на TypeScript или Python. Важно понимать, что именно вы получаете на выходе — описание состояния или последовательность команд.

Зачем хранить инфраструктуру в Git

• История изменений. Видно, кто, когда и зачем открыл порт или увеличил сервер.
• Ревью. Изменение инфраструктуры проходит через pull request, как любой код. Ошибку замечают до применения.
• Откат. Можно вернуться к предыдущей версии конфигурации.
• Документация. Файлы и есть актуальное описание системы — не нужно поддерживать отдельную схему, которая быстро устаревает.
• Автоматизация. CI/CD показывает план изменений и применяет его после одобрения. Такой подход часто называют GitOps.

Воспроизводимость: главная практическая выгода

Когда инфраструктура описана кодом, её можно развернуть заново одной командой:

• поднять staging, идентичный продакшену, и тестировать на нём, а не «на живую»;
• создать окружение для нового клиента или региона из того же шаблона;
• восстановиться после аварии быстрее, чем по памяти администратора;
• избавиться от дрейфа конфигурации — ситуации, когда серверы со временем начинают отличаться друг от друга из-за ручных правок.

Обзор основных инструментов

• Terraform / OpenTofu — создание облачной инфраструктуры у разных провайдеров: серверы, сети, базы, DNS. OpenTofu — открытый форк Terraform с совместимым синтаксисом.
• Pulumi — та же задача, но описание пишется на TypeScript, Python, Go и других языках.
• AWS CloudFormation, Azure Bicep — инструменты конкретного облака.
• Ansible — настройка уже созданных серверов: пакеты, конфиги, пользователи. Работает по SSH без агентов.
• Kubernetes-манифесты и Helm — описание приложений и их окружения внутри кластера.
• Docker / Dockerfile — описание окружения отдельного приложения.

Типичная связка: Terraform создаёт ресурсы, Ansible или образы настраивают их, Kubernetes запускает приложения.

Как начать

1. Опишите в коде один небольшой, но реальный кусок — например, DNS-записи или тестовый сервер.
2. Храните state (файл состояния Terraform) в удалённом хранилище с блокировкой, а не на ноутбуке.
3. Вынесите секреты из кода в менеджер секретов или переменные CI.
4. Запретите ручные изменения в панели для того, что уже описано кодом.
5. Добавьте в CI шаг plan для каждого pull request.

Частые ошибки

• Смешивать ручные правки и IaC — инструмент перезапишет изменения или упадёт на расхождениях.
• Хранить пароли и ключи в репозитории.
• Один огромный файл на всю инфраструктуру — разделяйте на модули и окружения.
• Применять без просмотра плана — особенно при удалении ресурсов.