TerraformのCI/CDの整備

ツール導入前の課題

• 各プロジェクト担当者がローカルで Terraform を実行していた
  • コードの変更とインフラの変更が非同期で行われていた
  • 実行履歴を遡ってみることができなかった
  • 共通 module を変更すると、一つ一つのプロジェクトで terraform apply を実行する必要があった
• チームの人数とプロジェクトが増えてきた
  • tfstate ファイルの競合管理を行う必要が出てきた
  • プロジェクトが増えるにつれて、インフラ変更依頼も増えてきて、インフラの適用に明確な承認フローが必要になった

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

• GitHub 上のコードを Single Source of Truth (SSoT) として、AWS の構成を Infrastructure as Code (IaC)で管理できている
• GitHub 上の approve 状況に基づいて、インフラの適用が行われる
• 複数アカウントの AWS 構成を一つのレポジトリで管理できている

• tfaction
• Terraform Cloud
• PipeCD
• FluxCD

• 安全性
  • tfstate のロック機能を持つ
  • レビュアー が approve しないと terraform apply できない
  • プルリクエスト内で terraform apply のやり直しが可能である
• 可視性
  • terraform plan の実行履歴が見れる
  • tfstate のロック状態を見れる
• 独立性
  • レポジトリ内で複数の tfstate を管理できる(プロジェクト毎に tfstate を管理したい)
• コスト
  • プロジェクト数に比例しない
  • コントロールプレーンの運用の工数が少ない

• 上記の安全性/可視性/独立性を満たしている
  • 特に、merge 時に terraform apply が実行されるのではなく、PR の conversation 内で terraform apply で行うという点が Terraform の運用に適していた
• セルフホスト用の terraform module で簡単にセルフホストが可能である
• コストは多数のリソース量に依存せずに Atlantis サーバのみに抑えることができる

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

• 開発者のローカル環境で terraform の実行をする必要がなくなった
  • terraform の実行のための強い権限は Atlantis サーバのみとなり、セキュリティが向上した
• プルリクエスト上で plan/apply の結果を確認し、コードのレビューを行えるようになった
  • ローカルのplan結果を共有しながらレビューした従来の方法と比較して簡潔になった

• 複数のクロスアカウントへの対応
  • tfstate 管理用の S3 と Terraform 実行用の IAM Role の作成と共通化
• ブランチ保護ルールの決定
  • approved や mergeable のルールを設定してコマンドの誤実行を防いだ

GitHub Actions の設定も不要で、セルフホストするインフラの CD ツールとしては、比較的簡単に運用できると思います。また、コマンドが Terraform 互換なので導入の敷居が低い一方で、複雑なワークフローの実装には向いていません。

記事について

この記事は、導入を担当していただいたインターン生の森瀬健太郎君との共著で作成しました。