きっかけ

去年、入社し手間もない頃に職場のCloud FormationをTerraformに移行するという長期的な方針を立てました。最初は軽い気持ちで決めたのですが、かなり莫大なCloud Formationスタックを地道に移行していくのは途中で心が折れそうでした。ですが、継続的にTerraform周りの改善が進んだため、現在では単なる移行作業ではなく、それなりに意義のある良い取り組みになっていると考えています。

取り組み

Cloud FormationからTerraformへの移行手順のブラッシュアップ

当初はterraformerやcf2tfを利用しようと考えました。どのツールも魅力的だったのですが、利用しないことにしました。
網羅するAWSサービスが足りておらず、どのみち移行作業が発生したためです。

まずは手順を整備しました。
Cloud FormationのPhysicalResourceIdとTerraformのimport時の第二引数が同じであるケースが多いことがわかりました。もちろんそうでないケースもありますが、徐々に知見を積むことで効率化できると考えました。
以下で取得できるCloud Formationの情報と照らし合わせて、Terraformで記述する予定の内容を入力すれば自動でimportコマンドが生成されるスプレッドシートを作りました。

$ aws cloudformation describe-stack-resources --stack-name ${STACKNAME} | jq -r ".StackResources[] | [.StackName, .ResourceType,.LogicalResourceId,.PhysicalResourceId] |@csv"  > ${STACKNAME}.csv

Terraformの入力項目は、モジュール名(module.hoge)、リソースタイプ（aws_iam_role etc..）、リソース名です。
若干効率化できたと思います。うまくいかなかった点としては、TerraformはS3など、Cloud Formationよりも細かくリソースが別れており、この方法ではうまくいきませんでした。

現状は目視確認や手動入力が多いので、スクリプトを書いてさらに効率化できると良いと考えてます。

Terragruntの導入

移行を実施する中でstateが肥大化してCI/CDが遅くなってしまう課題がありました。そこでterragruntを用いてstateをCloud Formationスタックごとに分ける方針にしました。
バックエンドのS3バケットは共通化しつつ、stateを細かく分離できるため移行作業に安心して取り組むことができます。

もう少し落ち着いたら細かく分離しすぎたstateの共通化を検討しようと思います。
流石にstate多すぎな気がしているのと、TerraformやProviderのバージョン管理が多くなってしまい運用負荷が高いと感じます。

その他

ツールの導入

セキュリティスキャンを行うtfsecや、コードからコストを見積もるinfracostの導入をチームで検討・実施しました。改めて現状を見直す機会になりました。

Lambdaの整備

Lambdaを実装した人によって異なっていることが多くありました。そのため同じ管理手法に統一しました。
Lambdaのリソースに関してはTerraformで管理し、関数は同じ命名規則に沿ったリポジトリ名を配置することで管理コストを下げています。CI/CDが実装されていなかったり、さまざまなリポジトリに散らばっていたため実施してよかったです。

おわりに

空いた時間を見つけて、楽しんで実施しています。詳しい内容はこれから発信していこうと思います！

2022年に行ったTerraform周りの施策まとめ