r3tam blog

Infrastructure as Code в 2026: Terraform, OpenTofu, Pulumi и платформенная инженерия

12 мин. чтения

Infrastructure as Code в 2026: Terraform, OpenTofu, Pulumi и платформенная инженерия

Рынок Infrastructure as Code (IaC) переживает самую значительную трансформацию за всю свою историю. Август 2023 года стал точкой бифуркации: HashiCorp перевёл Terraform с открытой лицензии MPL 2.0 на Business Source License (BSL), что спровоцировало появление форка OpenTofu под управлением Linux Foundation, а затем и поглощение HashiCorp корпорацией IBM за 6,4 миллиарда долларов в начале 2025-го. К середине 2026 года ландшафт стабилизировался, но стал принципиально иным.

Сегодня у инженерных команд есть три зрелых варианта: Terraform (теперь продукт IBM с исходным кодом, доступным по BSL), OpenTofu (community-форк под эгидой CNCF с лицензией MPL 2.0) и Pulumi (Apache 2.0, использующий языки общего назначения вместо HCL). Выбор между ними перестал быть чисто техническим — это стратегическое решение, влияющее на vendor-зависимость, культуру разработки и архитектуру платформенной инженерии.

В этой статье мы разберём ключевые различия между инструментами, рассмотрим best practices по управлению состоянием, проектированию модулей и тестированию, а также предложим фреймворк для принятия решения в зависимости от контекста вашей команды.

Состояние рынка IaC в 2026 году

Согласно опросам 2026 года, 89% организаций используют Infrastructure as Code как основной способ управления облачными ресурсами, а 68% работают с двумя и более облачными провайдерами. Рынок IaC, по оценкам Mordor Intelligence, вырастет с 1,96 миллиарда долларов в 2025 году до 6,4 миллиарда к 2031 году при среднегодовом росте 21,8%. Эти цифры подтверждают: IaC — не временный тренд, а фундамент современного управления инфраструктурой.

Terraform сохраняет наибольшую установленную базу — его используют тысячи предприятий, начавших внедрение IaC до лицензионного конфликта. Однако показатели планируемого внедрения говорят о другом: OpenTofu и Pulumi лидируют по темпам adoption среди новых проектов. Основной драйвер — стремление избежать vendor-локина и получить полностью открытую инфраструктурную платформу.

Terraform: наследие и настоящее

Terraform остаётся самым зрелым инструментом с экосистемой из более чем 3 000 провайдеров и огромным количеством готовых модулей. HashiCorp Configuration Language (HCL) — декларативный язык, который хорошо подходит для описания инфраструктуры, но требует изучения и имеет ограниченные возможности для реализации сложной логики.

После перехода на BSL и поглощения IBM Terraform продолжает активно развиваться. HCP Terraform (ранее Terraform Cloud) предлагает managed-решения с policy as code (Sentinel), аудитом и командной работой. В версии 1.14 появилась поддержка Stacks — модульных конфигураций для крупномасштабных развёртываний. Однако платная модель HCP Terraform изменилась: с 2026 года отменён бесплатный тариф, а ценообразование стало поресурсным, что вызывает беспокойство у средних команд. Для небольших проектов стоимость может оказаться неожиданно высокой — по некоторым оценкам, до 20 долларов за пользователя в месяц, не считая платы за ресурсы.

OpenTofu: community-форк под эгидой CNCF

OpenTofu был создан в августе 2023 года как форк последней MPL-версии Terraform (1.5.x). Проект управляется steering committee при Linux Foundation, а в апреле 2025 года был принят в CNCF Sandbox. Ключевое преимущество — полная открытость: лицензия MPL 2.0 не накладывает ограничений на коммерческое использование, включая право создавать конкурирующие продукты и сервисы.

OpenTofu сохраняет обратную совместимость с Terraform: конфигурации, модули и файлы состояний можно переносить между инструментами с минимальными усилиями. Однако с каждым релизом расхождения нарастают. В OpenTofu 1.8 появилась нативная поддержка шифрования state-файлов и провайдер-определяемые функции, которых нет в Terraform. OpenTofu 1.11 продолжает эту траекторию, добавляя улучшенную обработку переменных и расширенную валидацию. На момент середины 2026 года актуальная версия OpenTofu — 1.12.3 (июнь 2026).

Популярность проекта растёт: его поддерживают крупные игроки экосистемы — Gruntwork, Spacelift, env0, Scalr — и добавляют в свои платформы как второй движок наравне с Terraform. Сообщество насчитывает тысячи контрибьюторов, а публичный реестр модулей и провайдеров уже сопоставим по объёму с Terraform Registry.

Pulumi: инфраструктура как настоящий код

Pulumi занимает особую нишу: вместо DSL (HCL) он предлагает использовать TypeScript, Python, Go, C#, Java и YAML для описания инфраструктуры. Это принципиально иной подход: разработчики получают возможность применять циклы, условия, функции, классы, единый фреймворк тестирования и IDE-поддержку, к которой они привыкли при написании прикладного кода.

Pulumi поддерживает более 150 облачных провайдеров, имеет нативную интеграцию с Kubernetes (включая CRD и Helm), поддерживает политики как код (CrossGuard) и предоставляет Automation API для программного управления инфраструктурой без CLI. Версия 4.0, выпущенная в 2026 году, принесла улучшенную производительность и расширенную поддержку динамических провайдеров.

Pulumi Cloud — коммерческий managed-сервис для управления состоянием и совместной работы — имеет прозрачное ценообразование на основе количества пользователей, без привязки к числу ресурсов. Это часто оказывается дешевле HCP Terraform для проектов с большим количеством управляемых объектов.

Сравнительная таблица

| Характеристика | Terraform | OpenTofu | Pulumi |

|---|---|---|---|

| Лицензия | BSL 1.1 (ограничения) | MPL 2.0 (полностью open source) | Apache 2.0 |

| Язык описания | HCL | HCL (совместимый) | TypeScript, Python, Go, C#, Java, YAML |

| Управление состоянием | Локально, S3, GCS, Terraform Cloud | Локально, S3, GCS, любые Terraform-бэкенды | Локально, S3, GCS, Pulumi Cloud |

| Юнит-тесты | Terratest (Go) | Terratest (Go) | Нативные (pytest, Jest, Go test) |

| Экосистема провайдеров | Крупнейшая (3 000+) | Почти идентична Terraform | Растущая (1 200+) |

| Шифрование state | Через бэкенд | Нативное | Через бэкенд + встроенное |

| Policy as Code | Sentinel (Terraform Cloud) | OPA/Conftest | CrossGuard (OPA) |

| Cloud Native интеграция | Ограниченная | Ограниченная | Полная (K8s, CRD, Helm, GitOps) |

| Последняя стабильная версия | 1.14 (2026) | 1.12.3 (июнь 2026) | 4.0 (2026) |

Ключевые различия в архитектуре

Языки описания инфраструктуры

Это самое фундаментальное различие. Terraform и OpenTofu используют HCL — декларативный язык, в котором вы описываете желаемое состояние инфраструктуры, а инструмент вычисляет план изменений. HCL прост для понимания, но становится громоздким при реализации условной логики, циклов и композиции модулей.

Pulumi позволяет описывать инфраструктуру на языках общего назначения. Один и тот же разработчик может писать бизнес-логику и инфраструктурный код, используя единые паттерны, инструменты тестирования и CI/CD-пайплайны. Вот пример создания S3-бакета с тегированием на Pulumi с использованием Python:

import pulumi
import pulumi_aws as aws

environments = ['dev', 'staging', 'prod']
buckets = []

for env in environments:
    bucket = aws.s3.Bucket(f'app-data-{env}',
        acl='private',
        tags={
            'Environment': env,
            'ManagedBy': 'Pulumi',
            'CostCenter': 'platform'
        })
    buckets.append(bucket)
    pulumi.export(f'bucket_name_{env}', bucket.bucket)

Аналогичная конфигурация на HCL требует использования for_each и отдельных map-переменных:

variable "environments" {
  type = map(object({
    acl = string
  }))
  default = {
    dev     = { acl = "private" }
    staging = { acl = "private" }
    prod    = { acl = "private" }
  }
}

resource "aws_s3_bucket" "app_data" {
  for_each = var.environments
  bucket   = "app-data-${each.key}"
  acl      = each.value.acl
  tags = {
    Environment = each.key
    ManagedBy   = "Terraform"
  }
}

Разница становится ещё заметнее при реализации условной логики, где в Pulumi можно использовать обычный if, а в HCL приходится прибегать к count с тернарными операторами.

Производительность и скорость

Согласно независимым бенчмаркам 2026 года для развёртывания 500+ ресурсов в мультиоблачной среде:

| Метрика | Terraform | OpenTofu | Pulumi |

|---|---|---|---|

| Время выполнения (сек) | 125 | 132 | 89 |

| Управление ресурсами | 7.8/10 | 7.5/10 | 9.2/10 |

| Масштабируемость (ресурсов) | 450 | 440 | 520 |

Pulumi демонстрирует лучшее время выполнения благодаря использованию общего языка, что позволяет более эффективно выполнять параллельные операции. OpenTofu незначительно уступает Terraform, что объясняется дополнительными слоями абстракции для совместимости и безопасности.

Управление состоянием

State-файлы — самый критичный компонент любой IaC-системы. Они содержат идентификаторы ресурсов, выходные данные и, к сожалению, иногда секреты. Потеря или повреждение state-файла означает, что у вас работает инфраструктура без записи о том, как она была создана. Исследования показывают, что проблемы с состоянием ответственны примерно за 23% инцидентов в продакшене среди команд без надлежащего управления state.

Три недоговороспособных правила для state management:

  1. Никогда не используйте локальное состояние в окружениях, где работает больше одного человека. Remote backend с блокировкой (S3 + DynamoDB для AWS, GCS с object locking для GCP) — обязательное требование.
  2. Разделяйте окружения через директории, а не workspace. Практика environments/dev, environments/staging, environments/prod с отдельными state-файлами и наборами переменных делает каждый план явным и аудитируемым. Workspace-ы, напротив, создают иллюзию изоляции: один неверный workspace-name — и apply применяется к продакшену.
  3. Контролируйте доступ к state-файлам как к базе данных продакшена. Любой, кто может читать state-файл, получает доступ ко всем output-секретам, всем идентификаторам ресурсов и потенциально к plaintext-секретам. Используйте S3 Bucket Policies с per-role доступом и проводите аудит доступа ежеквартально.

Тестирование инфраструктурного кода

Возможность тестирования — ключевое преимущество Pulumi. Вы можете писать юнит-тесты, property-тесты и интеграционные тесты на тех же фреймворках, что и для прикладного кода (pytest, Jest, Go test). Terraform и OpenTofu не имеют встроенного фреймворка тестирования: для интеграционных тестов используется Terratest (на Go), для статического анализа — Checkov и tflint.

Пирамида тестирования для IaC выглядит так:

  • Статический анализ (Checkov, tflint) — проверка безопасности и синтаксиса, выполняется в pre-commit и CI за секунды. Checkov обнаруживает в среднем 14 проблем высокой серьёзности на 1 000 строк IaC-кода в командах, которые раньше не использовали сканирование.
  • Валидация плана (OPA/Conftest) — анализ diff-ов terraform plan на предмет неожиданных изменений. Можно написать Rego-правило, которое запрещает удаление определённых ресурсов или требует наличия encryption-флагов.
  • Интеграционные тесты (Terratest, Pulumi test) — реальное развёртывание в изолированном аккаунте с последующей валидацией и очисткой. Время выполнения — от 15 до 45 минут, но окупается снижением MTTR с 4,2 дней до 30 минут.

Платформенная инженерия и IaC

Инфраструктура как код — фундамент платформенной инженерии. Internal Developer Platform (IDP) невозможна без автоматизированного, повторяемого и проверяемого развёртывания инфраструктуры. В 2026 году 56% компаний среднего размера внедрили платформенную инженерию, а команды, использующие IDP, сообщают о сокращении времени онбординга разработчиков на 60% и уменьшении количества критических уязвимостей на 40%.

Выбор IaC-инструмента напрямую влияет на архитектуру платформы:

Terraform или OpenTofu + Terragrunt — классический стек для платформенных команд, предпочитающих декларативный подход. Модули публикуются в приватном реестре, а Terragrunt обеспечивает DRY-конфигурации для разных окружений. Такой подход хорошо масштабируется в организациях с централизованной платформенной командой и чётким разделением ответственности.

Pulumi + Automation API — более гибкий подход, позволяющий встраивать управление инфраструктурой непосредственно в код платформы. Automation API даёт возможность вызывать развёртывание из веб-приложения, чат-бота или CI/CD-пайплайна без необходимости в CLI. Для команд, строящих IDP с развитым self-service-слоем, это даёт принципиально иной уровень автоматизации.

GitOps и IaC

GitOps — естественное продолжение практик IaC. Принцип прост: желаемое состояние инфраструктуры хранится в Git-репозитории, а оператор в кластере Kubernetes (или CI-пайплайн) синхронизирует реальное состояние с объявленным. Этот подход особенно популярен в Kubernetes-экосистеме.

Flux и ArgoCD хорошо интегрируются с Pulumi благодаря нативной поддержке Kubernetes-провайдера и Automation API. Для Terraform и OpenTofu популярным решением является Atlantis — инструмент, который запускает plan и apply на основе Pull Request-ов.

Дрейф инфраструктуры

Дрейф — расхождение между объявленным в IaC состоянием и тем, что реально работает в облаке. Это одна из самых недооценённых проблем. Согласно исследованиям, 67% команд, использующих IaC, сталкиваются со значительным дрейфом. Основные причины — ручные изменения через консоль (кто-то «починил» security group в час ночи) и побочные эффекты автоскейлинга.

Решение — запускать terraform plan или tofu plan в read-only режиме каждые 4–6 часов и отправлять алерт при любом непустом diff. Это позволяет обнаружить ручные изменения в течение нескольких часов вместо недель, когда план неожиданно пытается уничтожить ресурс, от которого кто-то зависит.

Практические рекомендации по проектированию модулей

Средний Terraform-модуль разрастается до 2 400 строк, прежде чем команда решает его разделить. При таком размере terraform plan занимает 4–7 минут, а apply — 12–20 минут. Изменение одной security group rule заставляет план анализировать сотни несвязанных ресурсов.

Правильная архитектура модулей строится в два слоя:

  1. Resource modules — обёртка над одним типом ресурса провайдера с разумными значениями по умолчанию. Например, модуль rds-instance принимает размер БД и верцию движка, но не создаёт VPC, subnet group и parameter group — каждый из них отдельный модуль.
  2. Service modules — композиция resource modules в развёртываемую единицу. Модуль postgres-service вызывает rds-instance, subnet-group и security-group, экспортируя connection string и ARN секрета.

Практика показывает, что команды, ограничивающие размер модуля 500 строками, получают в 3 раза более быстрые циклы plan и apply и значительно меньший радиус взрыва при каждом изменении.

Как выбрать инструмент в 2026 году

Решение зависит от контекста. Вот типовые сценарии и рекомендации:

У вас большая существующая кодовая база на Terraform, и лицензия не вызывает беспокойства. Оставайтесь на Terraform. Стоимость миграции для крупной кодовой базы может достигать сотен человеко-часов, и эти ресурсы лучше направить на улучшение модулей, тестов и процессов.

У вас существующая база на Terraform, но вы обеспокоены vendor-локином. Мигрируйте на OpenTofu. Процесс для большинства команд сводится к замене бинарника и одной команде для переноса состояния. Однако окно возможностей сужается: чем дольше вы ждёте, тем сильнее расходятся feature-set-ы, и миграция станет нетривиальной.

Вы начинаете новый проект, и в команде сильные разработчики. Выбирайте Pulumi. Возможность писать инфраструктуру на знакомых языках, покрывать её тестами и переиспользовать код через стандартные механизмы (классы, функции, пакеты) окупается на проектах средней и высокой сложности. Pulumi также лучший выбор для deep Kubernetes-интеграции.

Вы начинаете новый проект, команда предпочитает декларативный подход. Выбирайте OpenTofu. Полностью открытая лицензия, активное развитие под эгидой CNCF и совместимость с экосистемой Terraform делают его лучшим выбором для greenfield-проектов, где не требуется сложная логика описания инфраструктуры.

Регулируемая отрасль с требованиями к открытому ПО. OpenTofu с лицензией MPL 2.0 — единственный вариант среди трёх, полностью свободный от ограничений BSL. Для финансового сектора, государственных учреждений и медицинских организаций это может быть решающим фактором.

Заключение

Infrastructure as Code в 2026 году — это зрелая, но динамично развивающаяся дисциплина. Terraform остаётся стандартом де-факто по установленной базе и объёму экосистемы. OpenTofu — наиболее безопасный выбор с точки зрения лицензионной чистоты и открытого управления. Pulumi — эволюционный шаг вперёд, превращающий управление инфраструктурой в программную инженерию.

Независимо от выбора инструмента, успех определяется инженерной дисциплиной: code review для каждого изменения, тесты на каждом уровне пирамиды, управление секретами с первого дня и автоматическое обнаружение дрейфа. Инструмент — это средство. Практика — то, что обеспечивает стабильность продакшена.

Рынок IaC продолжит расти, а инструменты — эволюционировать. Но фундаментальный принцип остаётся неизменным: инфраструктура должна быть описана как код, версионирована в Git и развёртываема автоматически. В 2026 году у нас есть все инструменты для этого — остаётся сделать правильный выбор под свою задачу.