Хватит тянуть Terraform в OpenStack

Почему для создания IDP вам нужен Heat, а не «костыли» из внешних инструментов?

Многие DevOps-команды превратились в заложников привычки. «Мы знаем Terraform, мы используем Terraform везде» — этот подход стал стандартом дето-факто. Но когда речь заходит о построении полноценной Internal Developer Platform (IDP) внутри OpenStack, слепая приверженность TF становится тормозом, а не ускорителем. Почему? Давайте честно разберем, где Terraform проигрывает нативному OpenStack Heat.

1. Инфраструктура vs Сервис

Terraform — это великолепный менеджер ресурсов. Он создаст вам VM, сеть и диск. Но на этом его полномочия заканчиваются. Чтобы «оживить» сервер, вам приходится приклеивать Ansible, Bash-скрипты или надеяться на Cloud-init.

Heat — это оркестратор сервисов. Благодаря ресурсам SoftwareDeployment, он управляет жизненным циклом ПО «из коробки». Heat не просто бросает виртуалку на произвол судьбы, он дожидается сигнала от агента внутри ОС, подтверждающего, что приложение запущено и готово к работе.

2. IDP — это не GitOps для избранных

Суть IDP в том, чтобы разработчик мог нажать кнопку и получить готовую среду.

• В мире Terraform разработчику всё равно нужно понимать HCL, работать с репозиториями и ждать завершения CI/CD пайплайна. Это Infrastructure as Code, а не платформа.
• В мире Heat вы создаете каталог шаблонов (Service Catalog). Для разработчика это выглядит как простой UI или API запрос в нативном интерфейсе облака. Вся сложность инкапсулирована внутри OpenStack.

3. «State» как ахиллесова пята

Главная боль Terraform — файл состояния (.tfstate). Он живет отдельно от облака. Если кто-то изменил ресурс руками в консоли или через API, возникает «дрифт», который часто лечится долго и больно.

Heat хранит состояние прямо в базе данных OpenStack. Это «единый источник истины». Оркестратор всегда знает реальный статус стека, потому что он является частью самого облака, а не внешней надстройкой.

4. Автомасштабирование без костылей

Попробуйте реализовать нативное автомасштабирование в Terraform для OpenStack. Вам придется городить внешние системы мониторинга, которые будут дергать TF. Heat делает это нативно через связку с Aodh и Ceilometer. Облако само мониторит нагрузку и само расширяет стек. Это и есть настоящая облачная автономность.

5. Лицензионный вопрос и СПО

После смены лицензии HashiCorp на BSL, использование Terraform в коммерческих платформах стало юридическим минным полем. Зачем тащить в чистое Open Source облако (OpenStack) инструмент с сомнительным будущим (о OpenTofu речи в этом пункте не идет), когда есть мощный, родной и полностью свободный Heat?

Итог

Если ваша задача — просто нарезать виртуалки, Terraform сойдет. Но если вы строите Internal Developer Platform, которая должна скрывать сложность облака от разработчиков, обеспечивать глубокий провижининг ПО и жить в гармонии с OpenStack — смотрите в сторону Heat.

DevOps-инженерам пора перестать быть «инструментальными фанатиками» и начать быть архитекторами решений.