Infrastructure as Code: идея

Как раньше поднимали серверы

Классический способ завести сервер — зайти по SSH и руками поставить пакеты, накидать конфигов, открыть порты. Работает ровно до того момента, пока серверов не стало пять, а потом десять. Тогда вылезают проблемы:

• никто не помнит, что именно настроено на каждой машине,
• новый сервер собирают «по памяти», и он чуть отличается от соседнего,
• человек, который всё настраивал, ушёл, и знание ушло с ним.

Infrastructure as Code (IaC) убирает ручную настройку. Вместо того чтобы кликать и набирать команды, ты описываешь нужную инфраструктуру текстом, кладёшь его в git, а инструмент приводит реальность к этому описанию.

Декларативно, а не пошагово

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

# пример декларативного описания (Terraform)
resource "yandex_compute_instance" "web" {
  name   = "web-01"
  cores  = 2
  memory = 4
}

Это тот же подход, что в Kubernetes-манифестах: описываешь, что должно быть, контроллер приводит кластер к этому. Запусти описание дважды, и результат будет одинаковый, потому что инструмент создаёт только то, чего ещё нет. Это свойство называется идемпотентностью.

Что это даёт

• Воспроизводимость. Из одного описания собирается одинаковый сервер хоть десять раз. Dev, staging, prod собираются из общего кода.
• Версионирование. Инфраструктура лежит в git: видно, кто и когда что поменял, можно откатиться на прошлое состояние.
• Ревью. Изменение инфраструктуры приходит как Merge Request, его смотрят коллеги до применения, как обычный код.
• Документация. Описание и есть документация. Чтобы узнать, как устроен прод, читаешь файлы, а не расспрашиваешь людей.

Дрейф конфигурации

Главный враг IaC — дрейф (drift). Это когда кто-то залез на сервер руками и поменял что-то в обход кода. Теперь реальность разошлась с описанием в git, и описание врёт.

Поэтому в зрелых командах действует правило: руками в прод не лезем, все изменения только через код. Инструменты IaC умеют показать разницу между «что в коде» и «что в реальности» (terraform plan), чтобы дрейф было видно до применения.

Где это в DevOps-стеке

IaC — это слой описания. Конкретные инструменты делят зоны:

• Terraform / OpenTofu — провижининг ресурсов у облаков (сети, виртуалки, базы, балансировщики).
• Ansible — настройка уже существующих машин (пакеты, конфиги, сервисы).
• Kubernetes-манифесты — описание того, что крутится внутри кластера.

Все они декларативны и живут в git. Дальше CI применяет их автоматически, как обычный пайплайн.

Что важно запомнить

IaC описывает инфраструктуру текстом в git и приводит реальность к этому описанию. Подход декларативный: задаёшь желаемое состояние, инструмент сам решает, как его достичь.

Это даёт воспроизводимость, версионирование, ревью через MR и живую документацию. Главный риск — дрейф, когда реальность правят в обход кода.

Terraform провижинит облачные ресурсы, Ansible настраивает машины, Kubernetes описывает нагрузку внутри кластера.

В следующем уроке разберём первый ресурс в Terraform на практике.