Инфраструктура как код: Terraform и Ansible на практике

Админ ушёл в отпуск. Ночью упал сервер приложений. В чате начинается классика: «где конфиг nginx?», «на каком диске лежал docker-compose?», «а firewall мы же вроде руками правили в пятницу». К утру выясняется, что «боевой» стенд существует только в голове одного человека и в трёх недокументированных скриптах на его ноутбуке.

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

Инфраструктура как код (инфраструктура как код) — не модная аббревиатура для резюме. Инфраструктура как код позволяет быстро воссоздать серверы и настройки, что экономит время при восстановлении после сбоев..

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

Три типичных обвала «ручной» инфраструктуры

Первый сценарий — дискретность знаний. Один инженер знает, как поднять балансировщик и почему на тестовом контуре открыт порт, который в боевой контур закрыт. Он увольняется или заболевает — и команда неделю восстанавливает цепочку «как было». Бизнес в это время теряет релизы и доверие заказчиков.

Второй — дрейф конфигураций. Тестовый контур и боевой контур «почти одинаковые», пока не выясняется, что на проде стоит другая версия PostgreSQL, другой лимит соединений и другой набор переменных. Баг, который спокойно жил на тесте, на проде взрывается в пятницу вечером. Виноват не «случай», а отсутствие единого описания окружений.

Третий — аварийное масштабирование. Маркетинг запустил кампанию, трафик вырос втрое. Нужны ещё два инстанса приложения и реплика БД. Без инфраструктура как код это ручной марафон на полдня: создать ВМ, поставить пакеты, настроить сеть, проверить секреты, не забыть мониторинг. С описанной инфраструктурой тот же шаг — запуск известного пайплайна и проверка результата.

Где команды обычно ошибаются

Частая ошибка — считать инфраструктура как код «только Terraform». Terraform (или аналоги) хорошо описывает ресурсы: сети, ВМ, балансировщики, диски, группы безопасности. Но состояние внутри сервера — пакеты, сервисы, пользователи, шаблоны конфигов — это уже зона конфигурационного управления, где привычнее Ansible, cloud-init или образы. Если описать только «железо в облаке», а ОС по-прежнему настраивать руками, вы получите красивую оболочку и тот же хаос внутри.

Вторая ошибка — хранить секреты в репозитории «временно». Пароли БД в plain text, токены API в переменных без vault, ключи SSH в wiki. Это не «ускорение», а отложенный инцидент безопасности и требования регуляторов-проблема.

Третья — писать код инфраструктуры без владельца и без ревью. Любой может поменять firewall «на минутку», никто не смотрит diff, нет политики окружений. Через полгода инфраструктура как код превращается в свалку копипасты, которую боятся трогать сильнее, чем старые bash-скрипты.

Четвёртая — объявить «мы на инфраструктура как код», но оставлять критичные исключения вне репозитория: «этот балансировщик руками», «эту БД не трогаем кодом». Исключения быстро становятся правилом, и воспроизводимость снова исчезает.

Как выглядит рабочая схема Terraform + Ansible

Практичный порядок обычно такой. Сначала фиксируете целевую картину: какие окружения нужны (dev, тестовый контур, боевой контур), какие сервисы критичны, какие сети и доступы допустимы. Затем описываете базовую инфраструктуру декларативно: VPC или сети облака, подсети, security groups, инстансы, диски, DNS записи, роли доступа. Это слой, где Terraform (или аналог) создаёт и меняет ресурсы предсказуемо.

Параллельно готовите слой конфигурации. Ansible-плейбуки ставят runtime, агенты мониторинга, базовый усиление защиты, раскладывают конфиги приложений. Важно: playbooks должны быть идемпотентными — повторный прогон не должен ломать уже настроенный сервер и не должен требовать «сначала всё снести».

Дальше связываете оба слоя через единый процесс. Создание ресурса заканчивается не «ВМ появилась в консоли», а «ВМ создана, провижена, попала в inventory, прошла быстрая проверка-check». Без этой склейки Terraform и Ansible живут как два разных мира, и снова появляются ручные шаги.

Отдельно стоит договориться о состояниях. State Terraform — критичный артефакт: без него инструменты «не помнят», чем уже управляют. Его хранят централизованно, с блокировками и бэкапами. Inventory и переменные Ansible — тоже не на локальном диске одного человека, а в контролируемом месте с разделением секретов.

Что делать, если сейчас всё «на руках»

Не нужно переписывать весь зоопарк за спринт. Начните с одного контура, который больно восстанавливать: приложение + БД + балансировщик. Опишите его как код, прогоните создание на пустом стенде, сравните с боевым. Когда убедитесь, что стенд поднимается без шаманства — переносите изменения только через репозиторий.

Затем закройте «дыры знаний»: какие порты открыты и зачем, какие секреты где лежат, кто имеет право менять боевой контур. Это скучная работа, но без неё инфраструктура как код будет декорацией.

После этого подключите проверку перед применением: plan/проверка для инфраструктуры, dry-run или линтеры для плейбуков, обязательный проход через тестовый контур. Цель не в бюрократии, а в том, чтобы пятничный «быстрый фикс» firewall не стал понедельничным расследованием.

• выберите один критичный контур и опишите его целиком;
• разделите создание ресурсов и настройку ОС/сервисов;
• уберите секреты из репозитория в vault или секрет-хранилище облака;
• сделайте применение изменений через CI с ревью, а не с ноутбука админа;
• регулярно проверяйте, что из кода действительно поднимается рабочий стенд.

Что получает бизнес на выходе

Воспроизводимость сокращает время восстановления после сбоя: вместо дней на «вспомнить конфиг» — часы на прогон известного описания. Онбординг новых инженеров ускоряется: вместо экскурсии по чужим ssh-сессиям человек читает репозиторий и понимает карту. Аудиты и сертификации проще проходят, когда можно показать, как устроены доступы и изменения, а не рассказывать легенды.

Самое важное — предсказуемость релизов и масштабирования. Когда маркетинг или продукт просят «ещё мощности», это перестаёт быть героизмом ночной смены и становится управляемой операцией.

Если инфраструктура до сих пор держится на ручных кликах и памяти одного специалиста, имеет смысл выстроить подход через DevOps и CI/CD: описать контуры как код, связать Terraform и Ansible с пайплайнами и убрать зависимость от «единственного, кто знает, как поднять прод».

инфраструктура как код не делает инциденты невозможными. Он делает их управляемыми: вы знаете, что именно развернуто, можете повторить окружение и откатить изменение, а не искать следы в истории чата.