Потратил тут довольно много времени на задачу по перетаскиванию когда-то созданной руками инфры под Terraform. Инфраструктура естественно уже в продакшене, на нее идёт трафик, так что метод “снести всё нафиг и построить новое светлое вечное” не подходил, пришлось менять колёса в автомобиле на ходу. Сильно на алгоритмах переноса останавливаться не буду, всё таки тут всё сильно зависит от конкретной инфры, просто опишу тулинг, который мне в этом помог.

terraform import

Про него рассказывать особо нечего, это часть terraform, которая позволяет “обнюхать” уже имеющийся ресурс и положить его в tfstate. Проблема в том, что этого мало, помимо стейта надо сгенерировать сам код, а руками перекладывать всё из выхлопа terraform plan весьма муторно.

terraformer

Утилита, которая умеет ходить в API AWS, Cloudflare и ряда других сервисов, собирать оттуда информацию об объектах инфраструктуры и генерировать terraform-код и terraform-стейт. По описанию звучит так, будто бы это серебрянная пуля, но на самом деле совсем нет.

Плюсы:

• Код действительно генерируется и он даже работает, в большинстве случаев если прогнать по этому коду terraform apply - всё будет ок;
• Удобно, когда надо оценить фронт работ и хотя бы просто понять, а насколько много инфраструктуры создано в том же AWS;
• Удобно, когда надо сделать “хоть как-то”, например если надо быстро отредачить кучу объектов, то может быть удобно “сдампить” их в terraform-код, отредактировать регуляркой и потом применить измененный код.

Минусы:

• Код низкого качества, куча дублированного кода, плохо с взаимосвязями ресурсов. Про модули я вообще молчу;
• Не всегда поддерживаются актуальные версии ресурсов, например в aws-провайдере для S3 есть тенденция к дроблению большого ресурса s3_bucket на кучу мелких про policy, про lifecycle и так далее. terraformer дампит всё по старинке в один большой ресурс.

Я обычно использовал его вместе с terraform import для кросс-верификации, чтобы убедиться что сгенерированный код совпадает с импортированным стейтом.

Небольшой гайд по использованию если что есть тут: https://blog.strangeman.info/devops/2023/01/30/terraformer-guide.html

Также есть утилита tfadd, которая умеет генерировать tf-код из стейта (то есть сначала импортируем стейт через terraform import, а потом генерируем из него код через tfadd), но я ей не пользовался.

k2tf и tfk8s

Обе утилиты делают одно и то же - конвертируют YAML-манифесты kubernetes в terraform-код. Стейт предлагается импортировать через terraform import.

tfk8s мне показалась менее удобной, так как генерирует только kubernetes_manifest ресурсы, что выглядит некрасиво. k2tf поумнее, она генерирует ресурсы типа kubernetes_deployment, kubernetes_service и так далее, что позволяет получить более качественный код.

Но у k2tf есть минус - последний коммит был в середине прошлого года, есть ощущение что её подзабросили и в какой-то момент она может перестать поддерживать актуальные версии провайдеров.

tfautomv

Утилита не столько для переноса уже созданной инфры под terraform, сколько для рефакторинга уже имеющегося кода, но сюда она тоже подойдет, так как рефачить всё то что мы надобавляли неизбежно придется.

Суть: вам потребовалось переименовать ресурс, или перенести его куда-то, или ещё что-то. Terraform естественно предложит вам снести старый ресурс и создать с нуля новый. Это может быть очень больно. Для облегчения страданий есть команда terraform state mv и специальные moved-блоки.

Но даже c moved это всё ещё больно. tfautomv эту боль убирает, генерируя эти блоки автоматически. Грубо говоря, он смотрит выхлоп terraform plan и, если видит идентичные ресурсы с разными именами на удаление и добавление, то кладет их в moved-блок. Утилита работает не идеально, особенно если рефакторинг включает в себя не только переименование, но всё равно сильно облегчает жизнь.