Зачем описывать инфраструктуру кодом
Сервер, настроенный руками, — снежинка: второй такой же не собрать. Код решает это и ещё две проблемы.
Сервер-снежинка
Сервер, который настраивали руками полгода, невозможно воспроизвести. Какие пакеты ставили, что правили в конфигах, какие «временные» костыли остались навсегда — не помнит никто. Пока он один и живой, это незаметно. Проблема проявляется в худший момент: сервер умер, нужен второй такой же, а «такой же» нигде не записан.
Инфраструктура как код (IaC) — это когда состояние сервера описано в файлах, а к состоянию приводит инструмент. Три следствия:
- Воспроизводимость. Новый сервер = запустить код на чистой машине. Стенд для теста = тот же код.
- Ревью и история. Изменение инфраструктуры — это pull request: его видно, его можно обсудить и откатить.
git logотвечает на «кто и когда это поменял». - Документация, которая не врёт. Wiki устаревает в момент написания. Код, который реально применяется к серверам, устареть не может — он и есть текущее состояние.
Спектр инструментов
| Уровень | Инструмент | Что описывает |
|---|---|---|
| Скрипты | bash | Последовательность команд |
| Конфигурация машин | Ansible | Состояние: пакеты, файлы, сервисы |
| Сами ресурсы | Terraform | Серверы, сети, базы у провайдера |
Bash — это «как сделать», и повторный запуск обычно всё ломает. Ansible и Terraform описывают «что должно быть» — и приводят к этому из любого исходного состояния. Это свойство называется идемпотентностью: запуск один раз и десять раз дают одинаковый результат. Следующий урок — о том, как это выглядит на практике.
С чего начать
Не с покупки нового инструмента, а с честного вопроса: «если этот сервер исчезнет, из чего я соберу новый?» Всё, что в ответе звучит как «ну, я помню, что там…», — кандидат на перенос в код.