Ручная настройка серверов – источник большинства аварий, которые мы разбираем на инцидентах. Кто-то правил конфиг по SSH в три часа ночи, забыл записать изменение, и через месяц новый узел собрали иначе. Воспроизвести окружение невозможно, откатиться некуда, а аудитор задаёт неудобные вопросы. Infrastructure as Code (IaC) убирает этот класс проблем: вы описываете состояние инфраструктуры текстовыми файлами, храните их в репозитории и применяете через инструмент развёртывания. Сервер становится производной от кода, а не наоборот.

Что меняется на практике

Декларативный подход означает, что вы фиксируете желаемый результат – «на хосте установлен nginx версии 1.6, открыт порт 443, выложен такой-то конфиг», – а инструмент сам приводит систему к этому состоянию. Puppet и Chef занимают эту нишу уже несколько лет, Ansible набирает популярность за счёт безагентной модели и работы поверх обычного SSH. Выбор зависит от парка машин и команды, но принцип общий: один источник правды в Git, а не разрозненные заметки в вики и голове админа.

Это даёт три эффекта сразу. Изменения проходят code review до того, как попадут в прод. История правок видна в git log – кто, когда и зачем тронул конфигурацию. Новый сервер поднимается из того же манифеста, что и десять предыдущих, поэтому «работает только на этой машине» перестаёт быть оправданием. Для госзаказчиков добавляется ещё и прозрачность: каждая правка инфраструктуры документирована и проверяема, что закрывает требования к управлению изменениями.

Связка с контейнерами

IaC и контейнеризация усиливают друг друга. Манифест Ansible поднимает хосты и Docker Engine, а описание самих сервисов уезжает в декларативные файлы. На прошлой неделе мы разбирали свежий Docker Compose – он как раз описывает многоконтейнерное приложение одним YAML-файлом, который тоже живёт в репозитории. Для оркестрации кластеров стоит присмотреться к проекту Kubernetes, который Google открыл этим летом: декларативная модель там доведена до уровня всего парка узлов.

Граница ответственности получается чистой. IaC отвечает за хост и платформу, контейнер – за приложение и его зависимости. Обновили базовый образ – пересобрали и выкатили без ручного вмешательства в систему. Это особенно важно для безопасности: когда в сентябре рванул Shellshock в bash, команды с описанной инфраструктурой накатили патч на весь парк одной командой и проверили результат за минуты. Те, кто ходил по серверам руками, искали уязвимые хосты сутками.

С чего начать

Не пытайтесь описать всё разом. Возьмите один типовой сервис, вынесите его конфигурацию в манифесты, заведите репозиторий и прогоните развёртывание на чистой машине. Когда сборка проходит повторяемо, подключайте следующий сервис. Параллельно настройте CI, который применяет изменения после ревью, а не вручную с ноутбука.

Мы внедряем IaC в банках, ритейле и ведомствах – от инвентаризации текущего хаоса до полностью автоматизированных конвейеров развёртывания. Перевести серверы под управление через репозиторий проще, когда инфраструктурой занимается отдельная команда, знающая ваш парк машин.

Сервер, который нельзя пересобрать из кода за полчаса, – это технический долг. IaC превращает инфраструктуру в актив, который читается, проверяется и воспроизводится. Чем раньше вы перестанете править прод руками, тем меньше инцидентов разберёте.