この記事は Nikkei Advent Calendar 2020 14日目の記事です。

弊社では、Infrastructure as Code(IaC)の思想に基づきTerraformを用いてインフラを構築・運用することが多く、そのCI/CDとしてTerraform Cloudを採用することでインフラ管理を行なうプロジェクトが増えてきました。

今回は、Terraform Cloudを導入するに至った背景と、1年ほど運用してきた中で感じた点について紹介したいと思います。

Terraform Cloudを導入した背景

Terraformを用いてインフラ管理を行うプロジェクトの場合、terraform applyをどの環境から実行するかを考えなければなりません。一番手軽な方法としては、開発者のローカル環境から実行することが挙げられますが、下記問題等が発生することからCI/CDで実行することが望ましいです。

• 複数の開発者がローカル環境から同時にTerraformコードを操作している場合、意図しないリソースの差分が発生する
• ローカル環境で変更・applyした内容をリモートにpushし忘れて最新のインフラ定義が不明確になる
• いつ誰がどのリソース変更を行なったのかを追いづらい

弊社では、Terraform Cloudを導入する前まではGitHub Actionsを用いることでCI/CDを行なっていました。上記課題を解決するのに加え、PRのコメントにterraform planの結果が自動的に挿入されてレビューが簡易化されるなど、運用もしやすい開発体制を整えることができました。

しかし、プロジェクトや環境が増えて同一リポジトリ内に実行単位であるtfstateが増えていくに連れ、CI/CDの要件が複雑化していくことになります。

• プロジェクト・環境ごとに異なるTerraformバージョンを指定したい
• あるプロジェクトのある環境のみデプロイ（apply）ブランチを変更したい
• PR時のplan結果だけでなく、デプロイブランチでもplan結果を確認して承認するフェーズを挟みたい

特に、Terraform v0.11=>v0.12の移行ではconfiguration languageがHCL=>HCL2に変更となったこともあり、プロジェクト・環境ごとに異なるTerraformバージョンを用いることを想定できていなかったCI/CDではアップグレードの調整に苦労しました。当時のコードベースの規模はまだ小さかったから良かったものの、モノリシックなTerraformリポジトリの規模が大きくなってくると、当時のCI/CDでは対応しきれない危機感がありました。

そこで、TerraformリポジトリのCI/CDの見直しを行った結果、SaaSであるTerraform Cloudを用いることで抱えていた課題の多くを解決できることがわかったため、CI/CDを自前で記述するのではなくTerraform Cloudを採用することにしました。

Terraform Cloudによる運用レベルの向上

Terraform Cloudは、GitHubなどのVCSプロバイダーと連携することで、イベントに応じてTerraform Cloud上の環境でterraformコマンドを実行してくれるCI/CDサービスです。

PRが作成されるとterraform planの結果を計算してくれるのに加え、PRがデプロイブランチにマージされたタイミングでterraform planをトリガーし、開発者はその結果を確認して承認ボタンを押下することで、terraform applyを実行する運用を実現することができます。

Workspaceという単位で設定を追加することができ、WorkspaceごとにTerraformのバージョンやリポジトリ内におけるterraformコマンドを発行するディレクトリを指定することが可能なため、モノリシックなリポジトリ構成の場合には特に効果を発揮します。

その他にも、運用時に嬉しい下記特徴を備えています。

• 実行履歴の記録
• tfstateの保管
• 承認プロセスを挟む
• 柔軟な権限管理
• PRのバリデーション
• slack通知の設定

tfstateには秘匿情報が格納されることがあるため、例えばtfstateをS3などに配置してしまうことで、予期せぬ情報の流出に繋がる可能性があります。Terraform Cloud上にtfstateを保管し、Workspaceごとの権限管理でアクセス可能なメンバーを絞ることで、秘匿情報の流出を未然に防ぐことができます。

Slack通知の設定は、Terraform CloudのGUIから通知を送りたいチャンネルのwebhook urlを指定するだけで完了します。手軽にSlack通知の設定を入れられることでSlack通知を行うプロジェクトが増え、開発の動きを把握しやすくなりました。

Terraform Cloudの利用状況とまとめ

現在、弊社では70のWorkspaceをTerraform Cloud上で運用していて、各プロジェクトの開発者にTerraform環境の提供を行なっています。

Terraform Cloudを導入したことで、導入前に抱えていたCI/CDの課題を解決することができ、独立したTerraformの開発環境を各プロジェクトの開発者に提供することを実現しました。

特に下記課題を早い段階で解決できたことは、導入した大きなメリットに感じています。

• プロジェクト・環境ごとに異なるTerraformバージョンを指定したい
• PR時のplan結果だけでなく、デプロイブランチでもplan結果を確認して承認するフェーズを挟みたい
• プロジェクトやインフラ担当者が増えるに従って管理の一元化がより急務となり、Terraform Cloudに集約することで解決できた

また、改めて感じたメリットとして、今月GAになったばかりのTerraform v0.14に既にアップグレードを済ませたプロジェクトが出てきたことも挙げられます。Terraformのバージョンに追随することはOSSの恩恵をより多く受けることにも繋がるので、その足回りの確保に貢献できるのは大きいと感じています。

最後に

本記事では、Terraform Cloudを用いたインフラ管理について簡単に紹介しました。

Terraform Cloudを用いた事例は少ないので、同じ様な課題感を持たれている方の導入の参考になれば幸いです。