株式会社ROXXのTerraform Cloud 導入レビュー

ツール導入前の課題

Terraform Cloud利用以前はGitHub ActionsでTerraformを運用していました。

1. CI/CDの作り込み・メンテナンスコスト

次のようなワークフローをGitHub Actionsで自作していました。

• PRを作成したら自動でterraform planを実行して、結果をコメントとして投稿する
• PRをマージすると自動でterraform applyを実行する

これを運用していて課題に感じていたのは次の点です。

• PRの差分と関係ある部分だけterraform planしてほしい（全て実行すると時間がかかる）
• terraform planの結果がただのテキストで見づらい
• terraform apply の結果がGitHub Actionsのログを見に行かないとわからない
• GitHub Actionsの調整とデバッグに時間がかかる

2. AWS認証情報や権限の管理

以前はAWSに接続するための認証情報は各自で管理していました。

• 自分のPCからterraform planする場合は自分の認証情報(aws sso login等)
• GitHub Actionsで実行する場合はOIDC認証

課題は以下の点です。

• 別環境で実行したい場合は認証情報を毎回切り替える必要がある
• どの環境で作業しているのかわかりにくい
• terraform_remote_state で別環境の情報を取得している箇所が非常に扱いにくい
  • 環境毎に認証が異なるため、state backendへの接続情報を変える必要がある
  • しかも自PCとGitHub Actionsで認証方法が異なるためそこにも対応する必要がある

3. workspaceを跨いだstateの参照

terraform_remote_state の扱いにくさが原因となり以下の問題も出てきました。

• terraform_remote_state を使いたくないので、workspaceが分割されずにどんどん大きくなっていく
• terraform plan に時間がかかるようになる

4. Variables の管理

環境毎に設定値を切り替えるためにtfvarsファイルやlocalsブロックで定義しterraform.workspaceの値に基づいて切り替えるという方式を利用していました。
課題は以下の点でした。

• 開発環境で実験的に変えたい値なども毎回PRを出す必要があり、作業効率が悪かった
• コミットされてしまうため、機密情報は実質的に利用できなかった

5. terraformの運用環境自体の管理

terraformを実行できるようにするためのAWSリソース(tfstateのS3バケット、IAM等)はterraform管理外であり、手動で作成していました。
そのため、作業内容が不透明でレビューしにくく属人的になっていました。

どのような状態を目指していたか

当時はインフラ担当が２名だったため、なかなか改善のための工数を取れずにいました。

また、システム構成の改善やデプロイの効率化等のプロダクト運営に直結する、よりクリティカルな部分に時間を使いたいという思いもありました。

• Terraform Cloud
• 自前実装を継続して改善する
• Atlantis

• Terraformの開発元であるHashiCorp運営しているクラウドサービスであること。
• 無料プランで運用に関わる大半の機能を利用することができ、導入後の改善イメージが明確につかめた点。
• 導入のステップが簡単だったこと。

改善したかった課題はどれくらい解決されたか

CI/CDの作り込み・メンテナンスコスト

GitHub Appとして設定するだけで簡単にCI/CDに組み込むことができました。

• PRの差分と関係ある部分だけterraform planしてほしい。（全て実行すると時間がかかる）
  • →特定のパスの変更、ブランチ、タグの時だけ実行するように設定できます。
• terraform planの結果がただのテキストで見づらい。
  • →見やすく整形された状態で見れるようになりました。
  • →URLを共有するだけで他の人に見てもらえるのでレビューしやすくなりました。
• terraform apply の結果がGitHub Actionsのログを見に行かないとわからない。
  • →履歴がTerraform Cloud上に残っているのとSlack通知ができるので追いやすくなりました。
• GitHub Actionsの調整とデバッグに時間がかかる
  • →GitHub Appに変わったのでGitHub Actionsでの作り込みは一切不要になりました。

AWS認証情報や権限の管理

Terraform CloudもGitHub Actionsと同じくAWSのOIDC認証に対応しています。 また、Terraform Cloudを使ってterraform planやterraform applyする場合は実行者の認証情報ではなくTerraform Cloud上に設定した認証情報が利用されます。

• 別環境で実行したい場合は認証情報を毎回切り替える必要がある。
  • →Terraform Cloudに一度ログインしておけば、workspace毎に適切な認証情報を使ってくれます。切り替え不要になりました。
• どの環境で作業しているのかわかりにくい。
  • →Terraform Cloudの設定でCI以外でのterraform applyを禁止することができるため、間違える事故は起きなくなりました。
• terraform_remote_state で別環境の情報を取得している箇所が非常に扱いにくい。
  • →tfe_outputsという別の方法で別環境の情報を取得できるようになりました。
  • →認証情報を意識する必要がなく非常に扱いやすくなりました。

workspaceを跨いだstateの参照

• terraform_remote_state を使いたくないので、workspaceが分割されずにどんどん大きくなっていく。
  • →tfe_outputs を活用してworkspaceの分割を進めることができました。
• terraform plan に時間がかかるようになる。
  • →workspaceの分割が進んだことで高速化されました。

Variables の管理

Terraform CloudにはVariables管理機能があり、Terraform Cloudの画面上でVariablesの設定や編集ができます。

• 開発環境で実験的に変えたい値なども毎回PRを出す必要があり、作業効率が悪かった。
  • →画面上で変更できるようになったため、値変更のためのPRは不要になった。
  • →tfvarsファイルやlocalsとの併用も可能。
• コミットされてしまうため、機密情報は実質的に利用できなかった。
  • →sensitiveかどうかも設定できるため、機密情報も管理できるようになりました。

terraformの運用環境自体の管理

tfe providerを利用すると、Terraform Cloudの環境自体をterraformで管理することができます。

コードで管理できるようになったため、workspaceの新規作成作業等を自動化することができました

機能性は十分なので、Terraform Cloudに払う金額が自前実装する工数・時間に見合っているかがポイントです。
小規模チームの場合はかなりメリットが大きいのではないかと思います。