Cloud Build で Terraform デプロイのスケーリングとコンプライアンスを実現

※この投稿は米国時間 2021 年 12 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

Terraform は再利用可能なクラウド自動化ソリューションの構築に携わるプラットフォーム デベロッパーの間で人気のある、オープンソースの Infrastructure as Code ツールです。Terraform Provider for Google Cloud Platform は Anthos on GKE をはじめとする Google Cloud の最新機能を次々にサポートし続けています。また、Google Cloud 側でも Cloud Foundation Toolkit や Terraform Validator といった Terraform インテグレーションを拡張し続けています。

多くのチームは実際に Google Cloud で Terraform をどのように使用しているのでしょうか。最もシンプルなアプローチは、ターミナルから直接 terraform init、plan、apply を実行する方法ですが、本番環境のデプロイを自動化する場合にはおすすめできません。初めに、セキュリティとコンプライアンスを確保しながらチーム コラボレーションを進められるように Terraform の状態を保存する方法を決定する必要があります。次に、スケーリングと信頼性の問題があります。最もシンプルなクラウド デプロイメントの場合でも、Terraform は Terraform プロバイダが使用するエンドポイントに対して何千回もの Create / Read / Update / Delete API 呼び出しを行う場合があります。その結果、一部のプロバイダで割り当ての問題が発生したり、その他の理由で再試行を余儀なくされることがあります。今年実現した Terraform Private Catalog インテグレーションは、Google Cloud Console のシンプルさを活かしながら、特定の Terraform ソリューションをデプロイする際のベスト プラクティスを確立したいと考えているプラットフォーム管理者にとってうってつけの機能です。

Private Catalog 以外に、Google Cloud 上で Terraform を使用する方法としては、Cloud Build と Cloud Storage が推奨されてきました。この方法ではリモート バックエンドを使用するため、競合状態を回避し、再利用可能なモジュールを異なる構成間で簡単に共有できます。Cloud Build では、リポジトリに変更がプッシュされたときに Terraform の構成を自動的に plan して apply するように GitOps の CI / CD パイプラインを構成できます。

これらは Terraform、Cloud Build、GitOps を使用して Infrastructure as Code を管理することにより得られるメリットとしてすでに幅広く定着しています。また、特に企業のお客様にとっては、まだあまり知られていない Cloud Build のメリットがあります。Cloud Build の同時実行機能と VPC-SC のサポート、Cloud Storage のバージョニング、セキュリティとコンプライアンスなどです。これらのメリットをさらに掘り下げてみましょう。

Cloud Build のスケーリング機能を使用すると、異なるリージョン間で複数の Terraform デプロイをグローバルかつ同時に処理できます。デフォルトでは、Cloud Build は 30 個の同時ビルドをサポートし、実行中のビルドが完了するとキューにある残りのビルドが処理されます。ですが、それだけでは不十分な場合もあります。複数のゾーンへの並行デプロイを行うお客様や、インフラストラクチャのプロビジョニングを複数のテナントから委託されているお客様の多くは、与えられたデプロイ期間内にすべてのデプロイを完了するために、さらに多くのデプロイを同時に実行する必要があります。Cloud Build のプライベート プール機能を使用すると、最大 100 個の同時ビルドが可能になり、リクエストに応じてさらに調整することができます。以下は、プライベート プールを作成し、ビルドの送信時にプライベート プールを使用する例です。

Cloud Build でプライベート プールを作成し、80 以上の Terraform デプロイを同時に送信する詳細な手順は、こちらで確認できます。

Cloud Build を使用すると大規模な Terraform プロビジョニング サービスを独自に構築する必要がなくなり、開始されたビルド インスタンスごとに結果の確認と診断を行えます。

Cloud Build とプライベート プールを組み合わせて使用すると、VPC Service Controls などの推奨されるセキュリティ機能が有効になります。これにより、安全な境界を設定してデータの流出を防ぎ、特定のプライベート プールのみを使用するように制限を適用することが可能になります。その結果、境界の内側に専用の踏み台インスタンスを構成する必要がなくなり、全体的なセキュリティ対策が強化されます。

Cloud Storage を使用する目的は、リモート ストレージだけではありません。バージョニング、セキュリティ、コンプライアンスなども Cloud Storage を使用する理由として挙げることができます。バージョニングを有効にすると、状態ファイルの破損を防ぎ、以前のバージョンを表示できます。バージョニングを有効にするには、次のように gsutil コマンドを使用します。

バージョニングに加え、顧客指定の暗号鍵を使用すると、Terraform の状態ファイルを暗号化できます。生成した暗号鍵は、以下のようにバックエンド オブジェクトの encryption_key パラメータで指定できます。

暗号化された状態でも、boto の構成ファイルに encryption_key オプションを追加すれば、状態ファイルの内容を見ることができます。

最後に、Cloud Storage は FedRAMP High の要件を満たす Google Cloud サービスの一つであるため、Google Cloud 上で FedRAMP 要件を独自に満たすことが求められている組織にとっては特に重要です（詳しくは、コンプライアンス リソース センターをご覧ください）。

まとめると、Terraform デプロイに Cloud Build と Cloud Storage を使用すれば、使い慣れた gcloud と Google Cloud Console インターフェースを通じ、シンプルな構成で、高いスケーラビリティ、セキュリティ、コンプライアンスを実現できます。詳細なガイダンスは、こちらのサンプルをご覧ください。