OpenTofu 1.9 и полтора года форка: смотрим на экосистему без розовых очков

OpenTofu 1.9 вышел с двумя заметными вещами: стабильным шифрованием state и официальным расширением провайдерной экосистемы. Повод сесть и честно оценить, что происходит с проектом через полтора года после форка от HashiCorp.

Мы ведём несколько инфраструктурных проектов, где вопрос «Terraform или OpenTofu» стоит не абстрактно, а в контексте конкретных решений: что ставить новому клиенту, стоит ли мигрировать существующую кодовую базу, и не окажется ли OpenTofu через год в том же положении, что форкнутые проекты с энтузиазмом и без достаточного финансирования.

Что реально изменилось в 1.9

Шифрование state - это давно запрошенная фича, которую Terraform так и не добавил в open source версию. В OpenTofu она появилась в экспериментальном виде раньше, в 1.9 перешла в стабильный статус. Смысл прямой: state хранится в зашифрованном виде в backend (S3, GCS, AzureBlob), ключи управляются отдельно через KMS или статический passphrase. Для инфраструктуры с чувствительными данными в state - это реальная ценность, не маркетинг.

Из практики: state Terraform часто хранит то, что туда не должно было попасть - пароли баз, токены, содержимое секретов, переданных через sensitive переменные. Шифрование не решает вопрос «не кладите секреты в state», но снижает радиус поражения при компрометации backend.

Расширение провайдерной экосистемы в 1.9 - это скорее организационное, чем техническое изменение. OpenTofu Registry принял несколько провайдеров, которые раньше были доступны только через Terraform Registry. Команда OpenTofu также работает над совместимостью: большинство Terraform-провайдеров продолжают работать через source указание без изменений.

Где экосистема закрыта, где - нет

Честный ответ на вопрос «все ли провайдеры доступны» - почти все, но с нюансами.

Основные облачные провайдеры (AWS, Azure, GCP, Yandex Cloud, VK Cloud) работают без проблем. Провайдеры пишут под протокол, который OpenTofu и Terraform разделяют, и большинство из них не заинтересованы в разделении реестров.

Kubernetes, Helm, Vault, Consul - всё работает. Для стандартного DevOps-стека разницы нет.

Нишевые enterprise-провайдеры - здесь начинаются вопросы. Некоторые вендоры публикуют провайдеры только в Terraform Registry и явно указывают совместимость только с Terraform. Обычно это работает и в OpenTofu, но гарантий меньше, и при проблемах vendor support может отказать.

HashiCorp-продукты сами по себе - это отдельная тема. Vault, Consul, Nomad провайдеры технически работают в OpenTofu. Но с учётом того, что HashiCorp мигрировала на BSL-лицензию и у OpenTofu с ними сложные отношения, на длинном горизонте стоит держать этот вопрос в голове.

Отечественный стек - провайдеры Yandex Cloud, VK Cloud, Selectel - работают нормально. Это важно для наших задач: клиенты на российских облаках не теряют совместимость при переходе.

Где gap с Terraform всё ещё ощущается

OpenTofu держит совместимость с Terraform как приоритет, и в большинстве случаев это работает. Но есть несколько мест, где расхождение заметно.

Terraform Cloud / HCP Terraform - если клиент использует SaaS-платформу HashiCorp, это блокер. OpenTofu не интегрируется с HCP Terraform, и здесь нужна замена: самостоятельный state backend (S3 + DynamoDB для блокировок), Spacelift, Atlantis, или что-то ещё. Это не страшно, но это работа.

Sentinel и Policy as Code в Terraform Cloud - аналог в OpenTofu-экосистеме либо в разработке, либо решается сторонними инструментами (OPA, Conftest). Для крупных команд с mature policy workflow это может быть нетривиальная замена.

Скорость выхода фич - OpenTofu иногда запаздывает с реализацией изменений, которые появляются в Terraform. Не критично для стабильной инфраструктуры, но если кто-то активно следит за changelog Terraform в поисках новинок - в OpenTofu придётся подождать.

Стоит ли мигрировать новым клиентам прямо сейчас

Для новых проектов мы даём следующий ответ: OpenTofu - разумный выбор по умолчанию, если нет явной зависимости от Terraform Cloud или HCP-экосистемы.

Аргументы в пользу: лицензия MPL 2.0 без ограничений, шифрование state из коробки, стабильный темп разработки, реальное сообщество за проектом (Linux Foundation, несколько крупных компаний-спонсоров). За полтора года проект не умер и не замедлился - это уже кое-что говорит о жизнеспособности.

Аргументы против: если у клиента уже есть Terraform-кодовая база на несколько сотен модулей с привязкой к Terraform Cloud - миграция это работа, которую нужно планировать и которая не окупается мгновенно. Для таких случаев мы пока не рекомендуем мигрировать ради самой миграции.

Для существующих клиентов, которых мы сопровождаем в рамках managed-инфраструктуры: смотрим на конкретный стек. Если там нет HCP Terraform и нет экзотических провайдеров - миграция с Terraform на OpenTofu технически простая, командная строка совместима, синтаксис тот же, .tf-файлы не меняются. Основное - backend и state.

Что мы видим в целом

OpenTofu через полтора года - это рабочий инструмент, а не эксперимент. Шифрование state в 1.9 закрывает реальный пробел. Провайдерная экосистема достаточно полная для большинства задач.

Gap с Terraform есть, но он не в базовой функциональности - он в enterprise-обвязке: SaaS-платформа, политики, некоторые вендорские гарантии. Если этого нет в требованиях - разницы меньше, чем кажется из маркетинговых материалов обеих сторон.

Мы сами переходим на OpenTofu для новых проектов. Не из идеологии, а потому что лицензия предсказуемее и фича с шифрованием state закрывает реальный вопрос, который раньше решали обходными путями.