Ручная настройка серверов через SSH и веб-консоли – главный источник простоев и расхождений между средами. Тестовый стенд работает, прод падает, и никто не помнит, какой флаг кто-то поправил полгода назад. Инфраструктура как код решает это иначе: вся конфигурация хранится в Git, проходит ревью и разворачивается одной командой. Ниже – как мы применяем Terraform и Ansible на реальных проектах для бизнеса и госсектора.
Terraform: описываем что, Ansible – как
Эти инструменты решают разные задачи, и путать их не стоит. Terraform отвечает за provisioning – создаёт виртуальные машины, сети, балансировщики, диски. Он декларативен: вы описываете желаемое состояние, а Terraform вычисляет разницу с текущим и применяет только нужные изменения. terraform plan показывает, что произойдёт, до того как что-то сломается, – это снимает половину рисков.
Ansible настраивает уже созданные машины: ставит пакеты, разворачивает приложения, правит конфиги, перезапускает сервисы. Он работает по SSH без агентов на узлах, что важно для закрытых контуров, где лишний демон – это лишняя поверхность атаки. Плейбуки идемпотентны: повторный запуск не ломает то, что уже настроено.
На практике связка выглядит так: Terraform поднимает инфраструктуру в облаке или на on-prem гипервизоре, передаёт список хостов в инвентарь, Ansible доводит их до рабочего состояния. Весь пайплайн запускается из CI и не требует ручного входа на серверы.
Состояние, секреты и закрытые контуры
Главная операционная сложность Terraform – файл состояния (state). Он хранит соответствие между кодом и реальными ресурсами, и его нельзя держать в Git: там пароли и приватные данные. Мы выносим state в защищённое хранилище с блокировками, чтобы два инженера не применили изменения одновременно и не разрушили окружение.
Секреты не место в репозитории – это правило без исключений. После инцидентов с цепочками поставок ПО, разобранных в материале про атаку на Kaseya, доверие к тому, что попадает в сборку, должно быть нулевым по умолчанию. Ansible Vault шифрует чувствительные переменные, а ключи подаются из внешнего менеджера секретов на этапе запуска пайплайна.
Для госзаказчиков отдельная история – импортозамещение. IaC одинаково ложится и на зарубежные гипервизоры, и на отечественные платформы виртуализации, поэтому миграция между ними сводится к замене провайдера, а не к переписыванию всей обвязки. Тема преференций для российского софта, которую мы поднимали в разборе предустановки ПО, напрямую касается выбора целевой платформы под IaC.
Что это даёт на дистанции
Воспроизводимость – первый эффект. Новое окружение разворачивается за минуты и гарантированно совпадает с эталоном. Аварийное восстановление перестаёт быть подвигом: код в репозитории описывает всю систему целиком.
Второй эффект – аудит. Каждое изменение проходит через pull request, видно кто, что и зачем поправил. Для проверок и сертификации это готовая доказательная база.
Третий – скорость без потери контроля. Разработка приложений и подготовка инфраструктуры идут параллельно: пока команда собирает, например, кроссплатформенное мобильное приложение, стенды под него поднимаются по тому же коду, что и продакшен.
IaC – не разовый проект, а смена подхода к эксплуатации. Выстроить эту практику с нуля – от структуры репозитория и пайплайнов до передачи компетенций команде заказчика – проще, когда инфраструктура проектируется как единая система, а не собирается из разрозненных серверов.
