Зачем описывать инфраструктуру кодом

Сервер, настроенный руками, — снежинка: второй такой же не собрать. Код решает это и ещё две проблемы.

Сервер-снежинка

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

Инфраструктура как код (IaC) — это когда состояние сервера описано в файлах, а к состоянию приводит инструмент. Три следствия:

  1. Воспроизводимость. Новый сервер = запустить код на чистой машине. Стенд для теста = тот же код.
  2. Ревью и история. Изменение инфраструктуры — это pull request: его видно, его можно обсудить и откатить. git log отвечает на «кто и когда это поменял».
  3. Документация, которая не врёт. Wiki устаревает в момент написания. Код, который реально применяется к серверам, устареть не может — он и есть текущее состояние.

Спектр инструментов

Уровень Инструмент Что описывает
Скрипты bash Последовательность команд
Конфигурация машин Ansible Состояние: пакеты, файлы, сервисы
Сами ресурсы Terraform Серверы, сети, базы у провайдера

Bash — это «как сделать», и повторный запуск обычно всё ломает. Ansible и Terraform описывают «что должно быть» — и приводят к этому из любого исходного состояния. Это свойство называется идемпотентностью: запуск один раз и десять раз дают одинаковый результат. Следующий урок — о том, как это выглядит на практике.

С чего начать

Не с покупки нового инструмента, а с честного вопроса: «если этот сервер исчезнет, из чего я соберу новый?» Всё, что в ответе звучит как «ну, я помню, что там…», — кандидат на перенос в код.