Ядро и провайдеры: кто здесь главный
Главное заблуждение новичка: думать, что Terraform "знает" про Yandex Cloud, AWS и сотню других облаков. Не знает. Бинарник terraform (или tofu) - это маленькое тупое ядро (core), которое умеет ровно три вещи: читать твой HCL-код, строить из него граф зависимостей и сравнивать желаемое состояние с фактическим. Всё. Ни одной строчки про конкретное облако в ядре нет.
Вся работа с реальным миром вынесена в провайдеры (providers) - это отдельные плагины. Когда ты пишешь в коде блок provider "yandex", при первом terraform init ядро скачивает плагин terraform-provider-yandex из реестра и кладёт рядом. Дальше ядро общается с плагином по локальному gRPC-протоколу, а плагин уже сам ходит в API Yandex Cloud по HTTPS и дёргает нужные ручки.
Зачем такая матрёшка? Чтобы команда Yandex могла выпускать обновления своего провайдера независимо от релизов самого Terraform. Появился новый тип диска или новая зона ru-central1-d - вышла новая версия провайдера, а ядро трогать не надо. Один и тот же бинарник ядра управляет и облаком, и DNS-провайдером, и даже базой PostgreSQL - просто плагины разные.
Жизненный цикл: от HCL до state
Разберём по шагам, что происходит, когда ты жмёшь plan, а потом apply. Это сердце terraform plan apply, и понимать его надо до автоматизма.
- Парсинг кода. Ядро читает все .tf файлы в папке (не один - все сразу), склеивает их в единую конфигурацию. Порядок файлов и блоков в них не важен, HCL декларативен.
- Граф зависимостей. Ядро строит направленный граф (DAG). Если диск ссылается на сеть, а виртуалка - на диск и сеть, ядро само понимает: сначала сеть, потом диск, потом ВМ. Ты нигде не пишешь "сделай это после того" - зависимости выводятся из ссылок между ресурсами. Независимые ресурсы создаются параллельно.
- Чтение state. Ядро открывает файл состояния (terraform state) - это JSON, где записано, что уже реально создано и с какими параметрами. На первом запуске он пустой.
- Refresh и сравнение. Через провайдер ядро спрашивает у облака: "а эта ВМ ещё жива, у неё всё ещё 2 ядра?". Полученное сравнивается с желаемым (твой код) и с записанным (state).
- План. Ядро выдаёт разницу (diff): что создать (+), что изменить (~), что удалить (-). Это и есть terraform plan - сухой отчёт "что я собираюсь сделать". Он ничего не меняет, его не страшно гонять хоть сто раз.
- Apply. При apply ядро идёт по графу и для каждого ресурса вызывает у провайдера нужную CRUD-операцию: Create, Read, Update или Delete. Провайдер переводит это в конкретные вызовы API облака. После успеха ядро записывает новые данные в state.
Маленький, но честный пример с реальными ресурсами провайдера yandex, чтобы было видно, откуда берутся зависимости в графе:
Код: Выделить всё
provider "yandex" {
token = var.yc_token
cloud_id = var.cloud_id
folder_id = var.folder_id
zone = "ru-central1-d"
}
resource "yandex_vpc_network" "net" {
name = "lesson-net"
}
resource "yandex_vpc_subnet" "subnet" {
name = "lesson-subnet"
zone = "ru-central1-d"
network_id = yandex_vpc_network.net.id
v4_cidr_blocks = ["10.5.0.0/24"]
}
resource "yandex_compute_instance" "vm" {
name = "lesson-vm"
platform_id = "standard-v3"
resources {
cores = 2
memory = 2
}
boot_disk {
initialize_params {
image_id = "fd80mrhj8fl2oe87o4e1"
}
}
network_interface {
subnet_id = yandex_vpc_subnet.subnet.id
nat = true
}
}
Что случилось в августе 2023 и кто такой OpenTofu
Теперь самое важное для 2026 года. До августа 2023 Terraform был полностью открытым (лицензия MPL 2.0) - бери, форкай, встраивай в свой продукт, никаких вопросов. В августе 2023 HashiCorp внезапно сменила лицензию на BSL 1.1 (Business Source License). Это так называемая лицензия terraform bsl: код видно, но коммерчески конкурировать с HashiCorp на нём запрещено. Для обычного юзера вроде бы ничего не поменялось, но для компаний, строивших платформы поверх Terraform (Spacelift, Env0, Scalr, Gruntwork), это был удар под дых.
Реакция сообщества была быстрой и злой. Уже осенью 2023 появился форк - OpenTofu. Его взяли под крыло Linux Foundation, а в 2025 проект приняли в CNCF (туда же, где живут Kubernetes и Prometheus). OpenTofu остался на старой свободной лицензии MPL 2.0. Бинарник называется tofu, команды те же: tofu init, tofu plan, tofu apply.
Чтобы два раза не вставать, по фактам на 2026 год:
- Лицензия. Terraform - BSL 1.1 (source-available, не open source). OpenTofu - MPL 2.0 (настоящий open source).
- Кто управляет. Terraform теперь под IBM: в феврале 2025 IBM закрыла сделку по покупке HashiCorp за 6.4 млрд долларов. OpenTofu - под Linux Foundation и CNCF, развивается силами сообщества.
- Совместимость. Полная. Тот же синтаксис HCL, тот же формат state, те же провайдеры (включая yandex - один и тот же бинарник плагина работает в обоих движках). Можно взять существующий проект и просто заменить terraform на tofu.
- Версии. Стабильный OpenTofu - ветка 1.12.x (1.12.1 на июнь 2026). Terraform держится около 1.10.
- Фичи. Тут форк уже заметно разошёлся. В OpenTofu раньше появились вещи, которых в открытом бинарнике Terraform нет: встроенное шифрование state, ранний расчёт переменных, for_each для провайдеров, флаг -exclude, поддержка OCI-реестров для модулей.
Типичные грабли
- Думать, что ядро знает про облако. Нет. Все ошибки вида "unsupported argument" - это про версию провайдера, а не про ядро. Обновляй провайдер, а не Terraform.
- Руками удалять или править state. Открыл terraform.tfstate, что-то поправил "по-быстрому" - и рассинхронизировал реальность с записями. Для правок есть команды terraform state, лезть в JSON руками не надо.
- Менять ресурсы в облаке мимо Terraform. Зашёл в консоль, добавил ВМ диск вручную - на следующем plan увидишь "drift", и apply попытается всё откатить к коду. Облако правим только через код.
- Путать plan и apply. plan безопасен и ничего не меняет, apply меняет. Привычка всегда смотреть план перед применением спасает от удаления прода одной командой.
- Ставить и terraform, и tofu вперемешку в команде. State совместим, но определись с одним движком на проект, чтобы не ловить разное поведение новых фич.
Руками, без зубрёжки:
- Возьми пример из урока, выполни terraform init (или tofu init) и посмотри, какой именно плагин provider скачался и какой у него номер версии.
- Запусти terraform plan и прочитай вывод: найди в нём знаки +, посчитай, сколько ресурсов будет создано и в каком порядке они идут.
- Открой получившийся terraform.tfstate после apply и найди там id своей сети - это та самая строка, на которую ссылалась подсеть.
- Замени в командах terraform на tofu (если поставил оба) и убедись, что тот же самый state читается без проблем.
- Из каких двух больших частей состоит Terraform и кто из них реально ходит в API облака?
- Что произойдёт, если удалить файл состояния, а потом запустить apply?
- Чем отличается terraform plan от terraform apply и почему plan можно гонять сколько угодно?
- Почему появился OpenTofu, под чьим управлением он находится и какая у него лицензия в отличие от Terraform?
Запомни три вещи. Первое: ядро Terraform тупое и про облака ничего не знает - всю грязную работу делают провайдеры-плагины, общаясь с API. Второе: цикл всегда один - HCL -> граф зависимостей -> план (diff) -> CRUD-вызовы через провайдер -> запись в state, и state тут источник правды, а не кэш. Третье: в 2026 терраформ-мир раздвоился после смены лицензии на BSL, и OpenTofu под Linux Foundation - это та же технология на свободной лицензии MPL 2.0, которую многие, особенно в РФ, выбирают по умолчанию. Всё, что ты учишь дальше, работает в обоих - просто держи в уме, что вместо terraform можно набирать tofu.
