Представь обычный вечер пятницы. Тимлид пишет в чат: "нужен ещё один сервер под стейджинг, как прод, только послабее". И ты идёшь в веб-консоль облака, кликаешь по кнопкам, выбираешь образ, диск, сеть, группу безопасности, копируешь ключи... и через сорок минут вроде бы готово. Только вот через месяц выясняется, что на этом сервере забыли открыть нужный порт, версия ядра другая, а файрвол настроен "почти как на проде". Почти. И вот это "почти" однажды роняет тебе релиз.
Так жили сисадмины долгие годы, и эпоха называлась гордо - "настройка руками". Каждый сервер был как ручная работа мастера: уникальный, неповторимый и абсолютно невоспроизводимый. Если машина умирала, восстановление превращалось в археологические раскопки по старым тикетам и памяти коллеги, который уже уволился. Знакомо? Если нет - повезло, читай дальше, чтобы и не познакомиться.
У этой ручной модели есть три классических беды, и у каждой есть имя.
Страх простоя. Любое изменение делается на живой системе вручную, а значит может что-то сломать. В итоге к серверам боятся прикасаться. "Работает - не трогай" - это не мудрость, это симптом того, что ты не контролируешь свою инфраструктуру.
Дрейф конфигурации (configuration drift). Это когда два сервера, которые должны быть одинаковыми, медленно расходятся. Тут кто-то подправил конфиг по-быстрому, там накатил пакет вручную, и через полгода у тебя зоопарк уникальных снежинок вместо стада одинаковых коров. А отлаживать баг, который воспроизводится только на одной машине из пяти - отдельный вид удовольствия.
Неповторяемость. Ты не можешь нажать кнопку и получить такую же среду ещё раз. Каждое развёртывание - это импровизация. А импровизация в инфраструктуре - это лотерея, где главный приз обычно ночной алёрт.
Восход DevOps и идея описать всё кодом
Движение DevOps выросло как раз из попытки склеить две враждующие планеты: разработчиков, которые хотят катить изменения каждый день, и эксплуатацию, которая хочет стабильности и поэтому ничего не хочет менять. Решение оказалось элегантным: а давайте относиться к инфраструктуре так же, как к коду. То есть описывать её текстом, хранить в git, ревьюить, тестировать и разворачивать автоматически.
Это и есть инфраструктура как код (infrastructure as code, сокращённо iac). Идея простая до неприличия: вместо того чтобы кликать в консоли или выполнять команды по памяти, ты пишешь файл-описание желаемого состояния. "Хочу две виртуалки вот с такими параметрами, одну сеть, один балансировщик". А специальный инструмент берёт это описание и приводит реальное облако к тому, что написано.
Ключевое слово здесь - декларативность. Ты описываешь не последовательность шагов ("создай диск, потом создай ВМ, потом подключи диск"), а конечную картину мира - что должно быть в итоге. А как туда прийти, инструмент разбирается сам. Это принципиально отличается от обычного скрипта на bash, который тупо выполняет команды сверху вниз и понятия не имеет, что половина из них уже была сделана вчера.
Что нам это даёт на практике:
- Повторяемость. Один и тот же код развернёт одинаковую среду хоть десять раз. Прод, стейдж, тест - близнецы, а не дальние родственники.
- Версионирование и ревью. Инфраструктура лежит в git. Видно, кто, когда и зачем поменял правило файрвола. Изменения проходят через pull request, и коллега может сказать "стоп, ты тут открываешь базу в интернет" до того, как это случится.
- Документация как код. Сам код и есть описание системы. Он не врёт и не устаревает, как вики-страница, которую последний раз трогали два года назад.
- Скорость и тестируемость. Новую среду поднимаешь командой за минуты. А ещё можно прогнать изменения в тестовом окружении и убедиться, что ничего не разъехалось, прежде чем катить в прод.
Инструментов для iac много, но Terraform стал фактическим стандартом для управления облачной инфраструктурой. Он от компании HashiCorp, работает с десятками провайдеров (Yandex Cloud, AWS, и так далее) через единый язык описания - HCL (HashiCorp Configuration Language). Один синтаксис, чтобы рулить хоть виртуалками, хоть DNS, хоть сетями.
Кстати, важная новость последних лет: после смены лицензии Terraform появился полностью открытый форк - opentofu. Он совместим по языку и подходам, так что почти всё, что ты выучишь про Terraform, применимо и к нему. В этом курсе мы говорим "terraform", но держи в голове, что opentofu - живая и популярная альтернатива.
Как Terraform думает. Он держит у себя файл состояния - terraform state. Это снимок того, что он уже создал в реальном мире. Когда ты меняешь код, Terraform сравнивает три вещи: что написано в коде, что записано в state и что есть на самом деле в облаке. Дальше он считает разницу и показывает план.
Рабочий цикл сводится к двум главным командам, которые ты будешь набирать тысячи раз: terraform plan и terraform apply. Сначала plan - "вот что я собираюсь сделать, посмотри". Потом apply - "ок, делай". Это и есть та самая магия terraform plan apply: ты всегда видишь будущее до того, как нажмёшь кнопку. Никаких сюрпризов.
Чтобы это не звучало как абстракция, вот как выглядит кусочек описания на HCL для Yandex Cloud. Не пугайся синтаксиса, разбирать его детально мы будем в следующих главах, сейчас просто прочувствуй идею:
Код: Выделить всё
# Подключаем провайдера Yandex Cloud
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
}
provider "yandex" {
zone = "ru-central1-a"
}
# Описываем сеть и подсеть
resource "yandex_vpc_network" "net" {
name = "demo-network"
}
resource "yandex_vpc_subnet" "subnet" {
name = "demo-subnet"
zone = "ru-central1-a"
network_id = yandex_vpc_network.net.id
v4_cidr_blocks = ["10.0.0.0/24"]
}
Теперь представь, что весь твой прод описан вот так. Захотел вторую такую же среду - скопировал, поменял пару имён, terraform apply. Минута, и готово. Сравни с сорока минутами кликанья из начала урока.
Типичные грабли новичка
- Лезть руками в облако в обход кода. Самый частый грех. Подправил что-то в веб-консоли "по-быстрому", а Terraform про это не знает. Возникает рассинхрон между state и реальностью, и при следующем apply он может попытаться откатить твою правку. Правило простое: если инфраструктурой управляет Terraform - меняй её только через Terraform.
- Путать декларативное с императивным. Не пытайся писать HCL как пошаговый скрипт. Ты описываешь желаемый итог, а не процесс. Это перестройка мышления, и поначалу мозг сопротивляется.
- Недооценивать state. Файл состояния - это сердце Terraform. Потеряешь его - и инструмент забудет, чем управлял. Хранить его как попало (например, локально на одном ноутбуке в команде из пяти человек) - прямая дорога к боли. Но это тема отдельной главы.
Ставить ничего не нужно, урок концептуальный. Прокрути мысленно:
- Вспомни любую систему, которую ты или твои коллеги настраивали руками. Где там притаился configuration drift? Какие шаги никто не записал?
- Возьми пример HCL выше и проговори словами, что он описывает. Найди строчку, где подсеть зависит от сети.
- Объясни сам себе разницу между plan и apply на бытовом примере. Подсказка: plan - это посмотреть смету ремонта, apply - вызвать бригаду.
- Что такое дрейф конфигурации и почему ручная настройка серверов его порождает?
- Чем декларативный подход (описываю результат) отличается от императивного (описываю шаги)? Почему iac выбирает первый?
- Зачем Terraform нужен файл terraform state и что он хранит?
- В чём разница между командами terraform plan и terraform apply?
Инфраструктура как код - это про то, чтобы перестать кликать мышкой и начать описывать своё облако текстом, который живёт в git. Это убивает три главные беды ручного админства: страх простоя, дрейф конфигурации и неповторяемость. Terraform - инструмент номер один в этом мире, работает декларативно, помнит сделанное в state и всегда показывает план перед применением. А opentofu - его открытый собрат, на котором всё это тоже работает. Дальше мы поставим Terraform и поднимем первую реальную виртуалку в Yandex Cloud.
