Terraform или Pulumi: знакомый язык не отменяет цену миграции состояния

Если команда уверенно управляет действующей инфраструктурой через Terraform и HCL не мешает работе, сохранять этот процесс обычно разумнее. Pulumi стоит выбирать, когда привычный язык программирования и его средства тестирования дают команде конкретную пользу. При переходе придётся разобраться не только с кодом: новому инструменту нужны корректные привязки к уже существующим ресурсам.

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

Язык: когда гибкость оправданна

Terraform использует язык конфигурации HCL. Сравнение в документации Pulumi перечисляет Python, TypeScript, JavaScript, Go, .NET и Java среди языков Pulumi; HCL также поддерживается. Обычный язык позволяет применять знакомые библиотеки, средства разработки и тестовые среды. Это весомый довод, если команда уже поддерживает такой код и регулярно повторяет одни и те же схемы инфраструктуры.

У гибкости есть эксплуатационная цена. Функции и пакеты помогают собрать повторяющиеся ресурсы в понятные компоненты, но сложная программная логика может затруднить чтение будущих изменений. HCL задаёт более узкий способ описания конфигурации. Выбор зависит от того, кому предстоит разбирать изменения и дежурить при сбое: удобство автора программы не всегда равно удобству всей платформенной команды.

Состояние: что именно приходится переносить

Состояние связывает запись в конфигурации с реальным объектом. Документация Terraform о состоянии требует однозначного соответствия между экземпляром ресурса и удалённым объектом. Если убрать привязку вручную, дальнейшее соответствие должен обеспечить оператор. Перевод HCL в другой язык сохраняет описание ресурсов, но сам по себе не устанавливает их идентичность в состоянии Pulumi.

Terraform по умолчанию записывает состояние в локальный файл; для совместной работы применяют и удалённые хранилища. Pulumi по умолчанию использует Pulumi Cloud, при этом допускает самостоятельное хранение состояния. Для команды важны права доступа, резервное восстановление и блокировка одновременных изменений: ошибку в привязках или запись двух процессов в состояние не исправит выбор языка.

Особое внимание требуется секретам. Пометка значения как конфиденциального в выводе Terraform не заменяет защиту самого файла состояния и доступа к нему. При планировании перехода нужно проверить, где лежат оба состояния, кто может их читать и каким способом защищены чувствительные значения.

Тесты кода и предварительный просмотр решают разные задачи

В Pulumi можно проверять собственную логику средствами выбранного языка, подменяя обращения к движку при модульном тестировании. Такой тест помогает убедиться, что программа формирует ожидаемые параметры при заданных входных данных. Он не обращается к действующей инфраструктуре и не устанавливает, правильно ли новый стек распознал импортированный объект.

У Terraform тоже есть встроенные тесты: описание команды terraform test указывает, что тестовый сценарий может выполнять планирование или применение, а применение способно создать реальные ресурсы. Для миграции поэтому недостаточно результата тестового набора. Предварительный просмотр Pulumi на целевом состоянии должен отдельно показать, собирается ли движок менять уже работающие объекты. Неожиданное создание, удаление или замена — причина остановить перенос и сверить код, идентификаторы и состояние до применения.

Лицензия и хранилище — разные решения

Лицензию следует оценивать по сценарию использования организации. Сравнение Spacelift указывает Business Source License 1.1 для актуальных выпусков Terraform и Apache License 2.0 для открытой основы Pulumi; коммерческие облачные сервисы имеют отдельные условия. Это различие может влиять на выбор платформы, но само по себе не требует переносить действующие ресурсы.

Место хранения состояния также можно менять отдельно от языка конфигурации. Для команды, которую устраивают HCL и Terraform CLI, перенос состояния Terraform в другое поддерживаемое удалённое хранилище решает иную задачу, чем переход на движок Pulumi. В сравнении полезно заранее разделить стоимость лицензии и сервиса, контроль доступа к состоянию и трудоёмкость изменения инфраструктурного кода.

Четыре пути сосуществования

Руководство Pulumi по миграции позволяет сочетать четыре базовых пути: запуск существующих файлов HCL на движке Pulumi, преобразование HCL в программу на обычном языке, импорт действующих ресурсов и параллельную работу с чтением выходных значений состояния Terraform. Эти действия отвечают на разные вопросы, поэтому одно не заменяет остальные.

Запуск прежних файлов `.tf` избавляет от немедленного переписывания конфигурации, но Pulumi не использует файл состояния Terraform как собственное состояние на месте: существующие ресурсы нужно импортировать. При импорте из состояния в режиме HCL руководство предупреждает, что ресурсы внутри модулей пропускаются и требуют отдельной обработки. После преобразования кода в обычный язык состояние также импортируют отдельно; совпадение имён в двух программах ещё не гарантирует совпадения управляемых объектов.

Параллельная работа позволяет сохранить одну часть инфраструктуры под Terraform, а новые зависимые ресурсы описать в Pulumi. Pulumi может читать выходные значения состояния Terraform, например идентификатор сети, однако такое чтение не передаёт управление самой сетью. Отдельный вариант — хранить состояние Terraform в Pulumi Cloud и продолжать применять прежнюю конфигурацию через Terraform CLI. Так меняется сервис хранения и выполнения, а переход на программу Pulumi остаётся самостоятельным решением.

Контрольный список передачи ресурсов

Для действующей инфраструктуры безопаснее выделить участок с понятными зависимостями и заранее определить границу ответственности инструментов. Условный пример: сеть остаётся под Terraform, а новый сервис в Pulumi получает её идентификатор из выходного значения. Зависимость между ними не требует переносить сеть в новый стек.

1. Сохраните актуальный снимок состояния Terraform и проверьте возможность восстановления. На время передачи исключите параллельные применения и выясните, какие учётные записи имеют доступ к состоянию и облачным ресурсам.
2. Сопоставьте записи конфигурации с идентификаторами реальных объектов. Отметьте зависимости и ресурсы, замена которых приведёт к потере данных или перерыву в работе; заранее решите, какие из них остаются под Terraform.
3. Подготовьте описание выбранных ресурсов в Pulumi и импортируйте их в соответствующий стек. Учитывайте выбранный путь: для программы на обычном языке и для проекта, продолжающего использовать HCL, предусмотрены разные режимы чтения состояния Terraform.
4. Просмотрите предлагаемые Pulumi изменения по каждому импортированному ресурсу. Если вместо сохранения объекта показаны неожиданное создание, удаление или замена, исправьте описание либо привязку и повторите предварительный просмотр.
5. Перед возобновлением обычных применений уберите переданные объекты из области управления Terraform, не удаляя сами облачные объекты. Проверьте планы обоих инструментов: прежний не должен пытаться воссоздать переданный ресурс, а новый — заменить его без запланированной причины.

Переход оправдан, когда выигрыш от языка и способа разработки покрывает работу с состоянием, пересмотр автоматизации и проверку прав доступа. Если такой выгоды для существующих ресурсов пока нет, Terraform можно сохранить для них, а Pulumi использовать на новых участках с чёткой границей управления.

Читайте также:

• Работа на пенсии больше не отменяет индексацию: где искать высокий доход
• Как выбрать подходящий вам язык программирования
• 7 ключевых признаков «состояния потока»