В этом уроке разберём, что такое OpenTofu в 2026 году, какие у него киллер-фичи, которых нет в Terraform, насколько больно (спойлер - почти не больно) мигрировать с одного на другое, и главный вопрос - terraform или opentofu, что выбрать в 2026, особенно если ты в РФ.
Почему форкнули и кто за этим стоит
Коротко по истории. Terraform до версии 1.5 включительно был под MPL 2.0 - нормальная OSI-одобренная открытая лицензия. С версии 1.6 HashiCorp перешла на BSL 1.1. BSL - это не open source в строгом смысле: исходники видны, но есть ограничение на коммерческое использование "в конкурентных целях". Это ударило по вендорам и по самому духу проекта.
Группа компаний и контрибьюторов сделала форк от последней открытой версии (Terraform 1.5.x), назвала его сначала OpenTF, потом OpenTofu, и передала под крыло Linux Foundation. Это ключевой момент: проектом теперь рулит не одна корпорация, а фонд с открытым управлением. Поддерживают его Spacelift, env0, Scalr, Harness и куча других - то есть ровно те, кому BSL мешал жить. Лицензия у OpenTofu - снова MPL 2.0, чистый open source.
Для нас, инженеров, важны два вывода. Первый - OpenTofu это не очередной форк-однодневка, за ним стоит фонд и индустрия. Второй - инфраструктура как код (IaC) перестала быть заложником одного вендора, и это здорово.
Уникальные фичи OpenTofu, которых нет в Terraform
Первые версии OpenTofu просто догоняли Terraform по фичам. Но в 2026 форк уже не догоняет, а кое в чём обгоняет. Вот что есть в OpenTofu и чего нет в открытом CLI Terraform.
1. Client-side state encryption (с версии 1.7). Шифрование terraform state из коробки. Раньше, если ты хранил state в S3 или Object Storage, в нём лежали все твои секреты практически открытым текстом - пароли БД, токены, ключи. Защита сводилась к "ну зашифруй бакет и молись". Теперь OpenTofu шифрует state на стороне клиента, ДО того как он уедет в хранилище. То есть бэкенд хранит шифротекст, который сам прочитать не может. Ключ можно завести через PBKDF2 от парольной фразы (самый простой вариант, без внешних сервисов) или через KMS - AWS KMS, GCP KMS, OpenBao. Для РФ актуально, что не обязательно тащить чужой KMS - хватит парольной фразы из переменной окружения.
2. Динамические провайдеры - for_each по провайдерам (с версии 1.9). Раньше, если тебе нужно было раскатать ресурсы в пять регионов или в десять аккаунтов, ты руками копипастил блоки provider с alias. Теперь можно перебирать конфигурации провайдера через for_each. Меньше копипасты - меньше багов.
3. Early variable / provider evaluation. OpenTofu умеет вычислять переменные на раннем этапе, поэтому ты можешь использовать var в местах, где Terraform ругается - например в backend-блоке или в version провайдера. Мелочь, а жизнь упрощает.
4. Provider-defined functions (провайдер-функции). Провайдер может приносить свои собственные функции, которые ты вызываешь прямо из HCL. Это расширяет язык за пределы встроенного набора функций.
5. Ephemeral values и .tofu-файлы. Эфемерные значения не попадают в state вообще (хороши для секретов на время прогона). А файлы с расширением .tofu позволяют держать переопределения только для OpenTofu - удобно, если конфиг должен работать и там и там, но с нюансами для форка.
Посмотрим на главную фичу в деле. Вот так включается шифрование state в OpenTofu:
Код: Выделить всё
terraform {
encryption {
key_provider "pbkdf2" "passphrase" {
passphrase = "menshe-20-simvolov-tochno-ne-prokatit"
}
method "aes_gcm" "default" {
keys = key_provider.pbkdf2.passphrase
}
state {
method = method.aes_gcm.default
enforced = true
}
plan {
method = method.aes_gcm.default
}
}
}
Совместимость, реестр и миграция terraform -> tofu
Поскольку OpenTofu форкнут от Terraform 1.5.x, язык HCL, протокол провайдеров, модель state и команды совместимы. Те же бинарники провайдеров работают в обоих движках. У OpenTofu есть свой публичный реестр провайдеров и модулей (registry.opentofu.org), где в 2026 уже тысячи провайдеров и десятки тысяч модулей - включая, разумеется, провайдер Yandex Cloud.
Самое приятное - миграция чаще всего бесшовная. В простом случае ты просто меняешь бинарь:
Код: Выделить всё
# было
terraform init
terraform plan
terraform apply
# стало - тот же конфиг, другой движок
tofu init
tofu plan
tofu apply
Код: Выделить всё
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
}
provider "yandex" {
zone = "ru-central1-a"
}
resource "yandex_vpc_network" "net" {
name = "tofu-demo-net"
}
resource "yandex_vpc_subnet" "subnet" {
name = "tofu-demo-subnet"
zone = "ru-central1-a"
network_id = yandex_vpc_network.net.id
v4_cidr_blocks = ["10.10.0.0/24"]
}
resource "yandex_compute_instance" "vm" {
name = "tofu-demo-vm"
platform_id = "standard-v3"
zone = "ru-central1-a"
resources {
cores = 2
memory = 2
}
boot_disk {
initialize_params {
image_id = "fd8..." # подставь актуальный id образа Ubuntu
}
}
network_interface {
subnet_id = yandex_vpc_subnet.subnet.id
nat = true
}
}
Типичные грабли
- Дорога в одну сторону по state. OpenTofu читает старые файлы состояния от Terraform 1.5.x и 1.6.x. Но как только ты сделал apply через OpenTofu 1.7+, в state может появиться метаинформация или шифрование, после которых обычный Terraform его уже не прочитает. Поэтому решай заранее: мигрируешь - так мигрируешь.
- Версии разошлись. Это уже не зеркала друг друга. На 2026 год Terraform ушёл в ветку 1.14.x, OpenTofu - в ветку 1.11-1.12.x, со своими отдельными фичами. Конфиг, который завязан на новые возможности одного движка, на другом не заведётся.
- Забыл про парольную фразу. Включил state encryption, потерял ключ - всё, state не расшифровать. Это не баг, это криптография. Храни ключ как самый ценный секрет.
- CI всё ещё зовёт terraform. После миграции не забудь поменять бинарь в пайплайнах, pre-commit хуках и Makefile. Иначе плейбук сделает вид, что мигрировал, а на деле катит старым движком.
Что повторить руками за полчаса:
- Поставь OpenTofu (через пакетный менеджер или скрипт установки) и проверь tofu version.
- Возьми любой свой простенький Terraform-проект на Yandet Cloud (или собери пример выше), сделай tofu init и tofu plan. Убедись, что план совпал с тем, что показывал Terraform.
- Добавь блок encryption с pbkdf2, прогони tofu apply и открой файл state глазами - убедись, что внутри шифротекст, а не твои секреты.
- Поломай нарочно: убери парольную фразу и попробуй tofu plan. Почувствуй, как это - потерять ключ от состояния.
- Почему вообще появился OpenTofu и под какой лицензией он сейчас живёт?
- Назови минимум три фичи, которые есть в OpenTofu, но которых нет в открытом CLI Terraform.
- В чём состоит главная "необратимость" при миграции state с Terraform на OpenTofu?
- Как технически включается шифрование state и какой самый простой провайдер ключа?
OpenTofu - это открытый форк Terraform под Linux Foundation и лицензией MPL 2.0, появившийся как ответ на переход HashiCorp к BSL. В 2026 году он уже не просто клон, а самостоятельный движок с фичами, которых в открытом Terraform нет: client-side state encryption из коробки, динамические провайдеры через for_each, early evaluation, провайдер-функции, эфемерные значения. Совместимость с HCL и провайдерами (включая Yandex Cloud) почти полная, миграция terraform -> tofu в типовом случае бесшовная, но переход по state - дорога в одну сторону. Если коротко отвечать на вопрос "terraform или opentofu что выбрать в 2026", особенно в РФ: для большинства команд OpenTofu - разумный выбор по умолчанию, потому что это честный open source, независимое управление и шифрование state без чужих облачных KMS. А раз и terraform plan, и tofu apply работают с одним и тем же кодом - попробовать форк ничего не стоит.
