Аннотация. Инфраструктура как код (IaC) — это способ описывать сервера, сети и сервисы в файлах, а не руками на машине. Ниже — принципы, где это применимо, обзор ключевых инструментов и чеклист, как внедрять без боли.
ℹ️ Небольшое примечание. По плану сегодня должна была выйти статья про ansible. Я перенёс её на следующий выпуск, чтобы сначала коротко объяснить, что такое IaC и зачем он нам. Практика — сразу после этого текста.
Зачем IaC и какую боль он лечит 💊
Ручные правки — это «память администратора». Сегодня получилось, завтра — забыли ключ, послезавтра коллега сделал «чуть по-другому», и два сервера уже разные. IaC делает настройки повторяемыми и проверяемыми: мы сохраняем всё в репозитории, запускаем по команде и всегда можем откатиться.
Вы выигрываете:
- скорость (минуты вместо часов);
- надёжность (идемпотентность и тесты);
- прозрачность (история изменений, code review);
- безопасность (секреты под контролем).
Принципы IaC (коротко) ⚙️
- Определяем результат, а не команды.
Мы описываем итоговое состояние системы, а не список действий.
Пример: «пакет nginx установлен, сервис включён и запущен» — вместо «apt install nginx; systemctl start nginx». - Идемпотентность.
Повторный запуск ничего лишнего не меняет, если всё уже настроено правильно.
Пример: запустили плейбук второй раз — он сообщил «ok», без перезаписей и простоя. - Версионирование.
Всё хранится в Git: видно, кто/что/когда поменял и можно откатить. - Воспроизводимость.
Один и тот же код даёт одинаковый результат на dev/stage/prod.
Пример: роль «users» создаёт одинаковые учётки везде, различаются только переменные. - Секреты отдельно и безопасно.
Пароли/ключи — в хранилище (Vault/SOPS), а не в плейбуках.
Пример: db_password лежит в зашифрованном файле, а в коде — только ссылка на переменную. - Проверяемость перед применением.
Автоматические проверки помогают ловить ошибки заранее.
Что используем:
Проверка стиля и типичных ошибок (инструменты вроде ansible-lint);
Пробный запуск (--check, «dry-run») — покажет, что изменится;
Смотрим различия (--diff) для файлов;
Code review — второй взгляд коллеги перед выкатом в прод. - Читаемость и модульность.
Дробим на небольшие, понятные части, каждая решает одну задачу.
Пример: отдельные роли os_base (пакеты/настройки ОС), nginx (веб-сервер), users (пользователи) вместо одного огромного плейбука «на всё». Такие куски легче читать, тестировать и переиспользовать.
Важно: IaC — это не «только Ansible» или «только Terraform». Это подход. Инструменты выбираем под задачу.
Инструменты: кто за что отвечает 🧰
- Конфигурации и софт: Ansible, Salt, Chef. (Файлы, пакеты, сервисы, шаблоны.)
- Поднимаем окружение файлами: Terraform, Pulumi, CloudFormation — всё, что обычно «кликают» в облаке (ВМ, сети, балансеры), описываем в коде.
- Контейнеры и оркестрация: Docker, Compose, Kubernetes (+ Helm, Kustomize).
- Имиджи и образы: Packer, Docker build.
- Секреты: Ansible Vault, HashiCorp Vault, SOPS/age, KMS.
- Политики/проверки: Open Policy Agent (OPA), Conftest, Checkov, ansible-lint.
- Тесты: Molecule (для Ansible), Terratest (для Terraform), «dry-run»/--check.
Не нужно всё сразу. Для старта достаточно связки: Git + Ansible (конфиги, пакеты, сервисы) и Vault/SOPS для секретов. Потом докрутите Terraform/Helm, если придёте к облакам/кубам.
Где чаще всего болит (и что с этим сделать) 🩹
- Секреты в гите. Используйте ansible-vault или SOPS, заведите правило «секреты только шифрованные».
- «Один огромный плейбук на всё». Разбивайте на роли, выносите повторяющиеся куски.
- Нет dry-run. Привычка --check --diff экономит часы отладки.
- Снежинки-серверы. Любая «ручная правка» → фиксим кодом, коммитим, прогоняем везде одинаково.
- Смешивание окружений. Отдельные инвентари/vars для dev/stage/prod, общие роли — разные переменные.
Почему это работает (коротко и честно) 🧠
IaC переносит «знание о системе» из головы инженера в исходники, которые:
- можно ревьюить, тестировать и прогонять в CI;
- легко повторять на новых окружениях;
- откатывать и аудировать по истории;
- сочетать с политиками безопасности (ленты, чекапы, утверждения).
Результат — меньше случайностей, больше предсказуемости. Команда тратит время не на «починить руками», а на улучшение самих процессов.
Чеклист «с чего начать» 📝
- Определите цели: что автоматизируем первым (конфиги/пакеты/сервисы).
- Договоритесь о структуре репозитория и нейминге.
- Выберите хранилище секретов (Vault/SOPS) и правило «без открытых ключей».
- Введите обязательные проверки: линтер, dry-run, review перед продом.
- Запланируйте «миграцию без боли»: новые изменения — только через код; старые «ручные» — постепенно переводим в IaC.
Дальше — еще немого теории. В отдельных статьях начнём с того, что такое Ansible, как его установить, а далее ansible.cfg, hosts.yml и первый ansible all -m ping.