Ты пришёл изучать Terraform, а я зачем-то предлагаю поговорить про конкурентов. Звучит как трата времени. На деле наоборот: пока ты не понимаешь, в каком классе инструментов живёт Terraform и чем он от соседей отличается, ты будешь принимать его решения за капризы. "Почему нельзя просто зайти на сервер и пакет доставить?", "почему он каждый раз пересоздаёт виртуалку вместо того чтобы её поправить?", "куда он опять полез сверять состояние?". Все эти вопросы - не про баги, а про философию. Поймёшь философию - перестанешь воевать с инструментом.
Инфраструктура как код (она же IaC, infrastructure as code) - это не один подход, а целое семейство. Внутри него инструменты делятся по нескольким осям, и Terraform, Ansible, Pulumi и CloudFormation в этих осях стоят в разных точках. Разберём оси по очереди, а в конце честно скажу, когда брать стоит НЕ Terraform. Без фанатизма, обещаю.
Ось первая: декларативный против процедурного
Это главное деление. Процедурный подход - ты пишешь последовательность шагов: сделай это, потом то, потом проверь и сделай ещё вот это. Декларативный - ты описываешь желаемый результат, а как до него добраться, инструмент решает сам.
Сравни на пальцах. Тебе нужно три виртуалки.
Процедурный стиль (грубо, в духе скрипта):
Код: Выделить всё
создай vm-1
создай vm-2
создай vm-3
Декларативный стиль (Terraform):
Код: Выделить всё
resource "yandex_compute_instance" "web" {
count = 3
name = "web-${count.index}"
# ... остальные параметры
}
Где кто стоит:
- Terraform - декларативный до мозга костей.
- CloudFormation - тоже декларативный (это родной IaC для AWS, шаблоны в YAML/JSON).
- Pulumi - декларативный по сути, но ты описываешь желаемое состояние обычным языком программирования (Python, TypeScript, Go), а не спецсинтаксисом.
- Ansible - процедурный по натуре (плейбук - это последовательность задач), хотя за счёт идемпотентных модулей ведёт себя почти как декларативный. Почти.
Mutable (изменяемая) инфраструктура - сервер живёт долго, ты к нему подключаешься и дорабатываешь на месте: накатил обновление, поменял конфиг, доставил пакет. Машина та же, начинка эволюционирует. Классический пример - именно Ansible: подключился по SSH, привёл сервер в нужное состояние, ушёл.
Immutable (неизменяемая) инфраструктура - сервер не правят, его заменяют. Нужна новая версия - собираешь новый образ, поднимаешь новые машины из него, старые гасишь. Это любимый подход Terraform: многие ресурсы он не "редактирует на лету", а пересоздаёт, если поменялся ключевой параметр (например, образ диска или тип машины).
Зачем такая жестокость? У mutable есть болезнь под названием "дрейф конфигурации" (configuration drift). Сервера, которые правили руками годами, расходятся между собой: на одном забыли пакет, на другом кто-то поправил конфиг "временно" в три часа ночи. И вот у тебя зоопарк "снежинок" - каждый сервер уникален и неповторим, а значит, неотлаживаем. Immutable лечит это радикально: образ один, машины из него идентичны, перекатить версию - значит заменить, а не латать. Поломалось - не чинишь, а пересоздаёшь из заведомо рабочего описания.
Ось третья: DSL против обычного языка программирования
Terraform говорит на HCL (HashiCorp Configuration Language) - это предметно-ориентированный язык, DSL, заточенный ровно под описание инфраструктуры. Он намеренно простой: не язык программирования общего назначения, тут нет полноценных классов и сложной логики. Зато его читает даже тот, кто кодить не умеет, - почти как структурированный конфиг.
CloudFormation идёт ещё дальше в простоту: там вообще YAML/JSON, то есть формат данных, а не язык.
Pulumi - противоположный полюс: бери Python или TypeScript и описывай инфраструктуру кодом со всей мощью настоящего языка - циклы, функции, пакеты, тесты. Гибко, но и порог входа выше, и выстрелить себе в ногу проще: в полноценном языке соблазн нагородить абстракций велик.
Ansible использует YAML для плейбуков плюс шаблонизатор Jinja2 для подстановок - тоже своего рода декларативный конфиг с вкраплениями логики.
Почему Terraform выбрал именно HCL и immutable? Потому что цель была - сделать описание инфраструктуры читаемым, версионируемым в git и предсказуемым. Простой DSL легче читать в код-ревью, чем чужой Python со хитрыми абстракциями. А immutable-подход даёт ту самую предсказуемость: что в коде описано, то в облаке и стоит, без сюрпризов от ручных правок.
Ось четвёртая и далее: серверы, агенты, деньги, сообщество
Ведущий сервер (master). Некоторым инструментам нужен центральный сервер-дирижёр (исторически так было у Puppet, Chef). Terraform - masterless: это просто бинарник, запускаешь его на ноутбуке или в CI, никакого постоянного управляющего сервера не требуется. Ansible тоже masterless - гоняется с твоей машины.
Агенты. Agent-based значит, что на каждой управляемой машине крутится демон-агент. Terraform - agentless: он не лезет внутрь сервера, он общается с API облака (создать виртуалку, сеть, диск). Ansible тоже agentless в классике - заходит по SSH, агент на хосте не нужен. Это важное различие в зоне ответственности: Terraform управляет САМИМИ ресурсами облака (provisioning), а Ansible традиционно настраивает то, что ВНУТРИ уже поднятой машины (configuration management). Они не столько конкуренты, сколько часто работают в паре: Terraform поднял инфраструктуру, Ansible настроил софт на ней.
Деньги. Тонкий момент. Сам движок Terraform долго был открытым, но в 2023 году HashiCorp сменила лицензию на BSL - не классический open source. В ответ сообщество сделало форк OpenTofu - полностью открытую и совместимую альтернативу под эгидой Linux Foundation. На практике для тебя как для пользователя OpenTofu и Terraform пока почти неотличимы: тот же HCL, те же провайдеры, та же команда plan/apply. CloudFormation бесплатен, но это вечный билет в один вагон - только AWS. Pulumi - open source движок плюс платный SaaS для хранения состояния и командной работы. Ansible открыт, но энтерпрайз-обвязка (AAP) платная.
Сообщество и зрелость. Terraform - один из самых зрелых и распространённых IaC-инструментов, с огромным реестром провайдеров (включая Yandex Cloud, AWS, GCP, Azure и сотни других). CloudFormation зрелый, но живёт только в мире AWS. Ansible огромен в нише настройки серверов. Pulumi моложе и меньше, но быстро растёт и любим теми, кто хочет инфраструктуру "настоящим кодом".
Свожу всё в таблицу-шпаргалку (читать как: инструмент - подход - язык - ниша):
- Terraform / OpenTofu - декларативный, immutable, HCL (DSL), masterless, agentless. Ниша: provisioning облачных ресурсов, мультиоблако.
- Ansible - процедурный (но идемпотентный), YAML+Jinja2, masterless, agentless (SSH). Ниша: настройка ОС и софта внутри машин.
- Pulumi - декларативный, обычный язык (Python/TS/Go), masterless, agentless. Ниша: provisioning для тех, кто любит кодить.
- CloudFormation - декларативный, YAML/JSON, managed-сервис. Ниша: только AWS, зато нативно.
Чтобы декларативность не была абстракцией, вот минимальный осмысленный кусок на провайдере Yandex Cloud. Объявляем провайдера и одну виртуалку:
Код: Выделить всё
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
}
provider "yandex" {
zone = "ru-central1-a"
}
resource "yandex_compute_instance" "vm" {
name = "demo-vm"
resources {
cores = 2
memory = 2
}
boot_disk {
initialize_params {
image_id = "fd80mrhj8fl2oe87o4e1"
}
}
network_interface {
subnet_id = yandex_vpc_subnet.subnet.id
nat = true
}
}
resource "yandex_vpc_network" "net" {
name = "demo-net"
}
resource "yandex_vpc_subnet" "subnet" {
name = "demo-subnet"
zone = "ru-central1-a"
network_id = yandex_vpc_network.net.id
v4_cidr_blocks = ["10.5.0.0/24"]
}
Типичные грабли
- "Terraform vs Ansible - что выбрать?" Ложная дилемма. Они про разное. Terraform поднимает железо и сеть, Ansible настраивает софт внутри. Часто их используют вместе.
- Ждать от Terraform правок "на месте". Поменял тип диска - не удивляйся, что ресурс пересоздаётся. Это immutable-подход, а не баг. Всегда читай вывод plan перед apply.
- Путать движок и провайдера. Terraform сам по себе ничего про Yandex Cloud не знает - всю магию делает провайдер yandex-cloud/yandex. Один движок, разные провайдеры под разные облака.
- Думать, что CloudFormation "тоже мультиоблако". Нет. CloudFormation - это исключительно AWS. Хочешь Yandex Cloud или несколько облаков сразу - тебе к Terraform/OpenTofu или Pulumi.
- Бояться смены лицензии Terraform. Если душа не лежит к BSL - бери OpenTofu, он совместим. Учишь одно - умеешь оба.
Без фанатизма, как обещал.
- Тебе нужно только настроить уже существующие сервера (поставить пакеты, разложить конфиги) - бери Ansible, это его хлеб.
- Ты живёшь целиком в AWS, не планируешь уходить и хочешь максимально нативную интеграцию с экосистемой Amazon - CloudFormation (или CDK) может оказаться удобнее.
- Твоя команда - сильные разработчики, которым тесно в DSL, и хочется писать инфраструктуру настоящим кодом с тестами и абстракциями - присмотрись к Pulumi.
Мини-лаба
Руками, без запуска - просто чтобы уложилось в голове:
- Возьми три инструмента (Terraform, Ansible, Pulumi) и для каждого выпиши одним словом: декларативный или процедурный, immutable или mutable, DSL или обычный язык.
- Объясни своими словами товарищу (или коту), почему запустить процедурный скрипт дважды опасно, а terraform apply дважды - нет.
- Посмотри на HCL выше и найди строку, где одна виртуалка ссылается на подсеть. Это и есть точка, где Terraform строит граф зависимостей.
- В чём разница между декларативным и процедурным подходом, и к какому относится Terraform?
- Что такое immutable-инфраструктура и от какой болезни она лечит?
- Почему Terraform и Ansible чаще не конкуренты, а напарники?
- Что такое OpenTofu и зачем он появился?
Terraform - декларативный, immutable, masterless и agentless инструмент на DSL под названием HCL, который управляет ресурсами облака через провайдеров (для нас - Yandex Cloud). Ansible процедурный и про настройку внутренностей машин - он напарник, а не враг. CloudFormation декларативный, но заперт в AWS. Pulumi декларативный, но на обычном языке программирования. А OpenTofu - открытый форк Terraform, который ты получаешь бонусом, выучив сам Terraform. Дальше мы наконец перейдём от теории к делу и поднимем первую инфраструктуру руками.
