基盤のデプロイは、宣言型インフラストラクチャを使用して、一貫性のある制御可能な方法で行うことをおすすめします。このアプローチでは、許容可能なリソース構成に関するポリシー制御をパイプラインに適用することで、一貫したガバナンスを実現できます。このブループリントは GitOps フローを使用してデプロイされます。このとき、Terraform によって Infrastructure as Code（IaC）が定義され、バージョン管理とコードの承認のために Git リポジトリが使用され、デプロイ パイプラインの CI / CD 自動化には Cloud Build が使用されます。このコンセプトの概要については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するをご覧ください。
以降のセクションでは、デプロイ パイプラインを使用して組織内のリソースを管理する方法について説明します。
パイプライン レイヤ
環境内のさまざまなレイヤを管理するチームと技術スタックを分離するには、スタックの各レイヤを受け持つさまざまなパイプライン、およびさまざまなペルソナを使用するモデルをおすすめします。
次の図は、基盤パイプライン、インフラストラクチャ パイプライン、アプリケーション パイプラインを分離するための推奨モデルを示しています。
この図は、このモデルの各パイプライン レイヤを示しています。
- 基盤パイプラインは、プラットフォーム全体で使用される基盤リソースをデプロイします。複数のビジネス ユニットとワークロードによって使用される基盤リソースを、1 つの中央チームで管理することをおすすめします。
- インフラストラクチャ パイプラインは、VM インスタンスやデータベースなど、ワークロードで使用されるプロジェクトとインフラストラクチャをデプロイします。このブループリントでは、ビジネス ユニットごとに個別のインフラストラクチャ パイプラインが設定されますが、複数のチームで 1 つのインフラストラクチャ パイプラインを使用することもできます。
- アプリケーション パイプラインは、コンテナやイメージなど、各ワークロードのアーティファクトをデプロイします。複数のアプリケーション チームが、それぞれ個別のアプリケーション パイプラインを持つこともできます。
以降のセクションでは、各パイプライン レイヤの使用方法について説明します。
基盤パイプライン
基盤パイプラインは基盤リソースをデプロイします。また、ワークロードが使用するインフラストラクチャをデプロイするための、インフラストラクチャ パイプラインも構成します。
基盤パイプラインを作成するには、まず terraform-example-foundation を独自の Git リポジトリにクローニングまたはフォークします。0-bootstrap README ファイルの手順に沿って、ブートストラップ フォルダとリソースを構成します。
| ステージ | 説明 |
|---|---|
Google Cloud 組織をブートストラップします。このステップでは、後続ステージのブループリント コード用の CI / CD パイプラインも構成します。
|
0-bootstrap ステージで基盤パイプラインを作成すると、以下のステージで、基盤パイプライン上にリソースがデプロイされます。各ステージの README の手順を確認し、各ステージを順番に実装してください。
| ステージ | 説明 |
|---|---|
組織のポリシーを使用して、最上位の共有フォルダ、共有サービスのプロジェクト、組織レベルのロギング、ベースライン セキュリティを設定します。 |
|
作成した Google Cloud 組織内で開発環境、非本番環境、本番環境を設定します。 |
|
または |
選択したトポロジでの共有 VPC と、関連するネットワーク リソースを設定します。 |
インフラストラクチャ パイプライン
インフラストラクチャ パイプラインは、ワークロードで使用されるプロジェクトとインフラストラクチャ（VM インスタンスやデータベースなど）をデプロイします。基盤パイプラインにより、複数のインフラストラクチャ パイプラインがデプロイされます。基盤パイプラインとインフラストラクチャ パイプラインをこのように分離することで、プラットフォーム全体のリソースと、ワークロード固有のリソースとを分離できます。
次の図は、個別のチームが使用する複数のインフラストラクチャ パイプラインを、ブループリントで構成する方法を示したものです。
この図は、以下の主要なコンセプトを示しています。
- 各インフラストラクチャ パイプラインは、基盤リソースとは別にインフラストラクチャ リソースを管理するために使用されます。
- 各ビジネス ユニットには独自のインフラストラクチャ パイプラインがあり、
commonフォルダ内の専用プロジェクトでそれぞれ管理されます。 - 各インフラストラクチャ パイプラインには、そのビジネス ユニットに関連付けられたプロジェクトにのみリソースをデプロイできる権限を持つサービス アカウントがあります。この戦略では、基盤パイプラインに使用される特権サービス アカウントと、各インフラストラクチャ パイプラインで使用される特権サービス アカウントとの間に、職掌分散を確立できます。
複数のインフラストラクチャ パイプラインを使用するこのアプローチは、インフラストラクチャを個別に管理するスキルと意欲を持つ、複数の事業体が組織内に存在する場合におすすめします。特に、実施したいパイプライン検証ポリシーの種類などの要件が異なる場合には最適です。また、単一のチームが一貫した検証ポリシーを使用して、単一のインフラストラクチャ パイプラインを管理することもできます。
terraform-example-foundation では、ステージ 4 でインフラストラクチャ パイプラインを構成し、ステージ 5 では、そのパイプラインを使用してインフラストラクチャ リソースをデプロイする例を示します。
| ステージ | 説明 |
|---|---|
フォルダ構造、プロジェクト、インフラストラクチャ パイプラインを設定します。 |
|
|
インフラストラクチャ パイプラインを例として使用し、Compute Engine インスタンスでワークロード プロジェクトをデプロイします。 |
アプリケーション パイプライン
アプリケーション パイプラインは、アプリケーションのビジネス ロジックを実行するイメージや Kubernetes コンテナなど、個々のワークロード用のアプリケーション アーティファクトをデプロイする役割を担います。これらのアーティファクトは、インフラストラクチャ パイプラインによってデプロイされたインフラストラクチャ リソース上にデプロイされます。
エンタープライズ基盤のブループリントは、基盤パイプラインとインフラストラクチャ パイプラインを構成しますが、アプリケーション パイプラインはデプロイしません。アプリケーション パイプラインの例については、エンタープライズ アプリケーションのブループリントをご覧ください。
Cloud Build を使用したパイプラインの自動化
このブループリントは、Cloud Build を使用して CI / CD プロセスを自動化します。次の表は、terraform-example-foundation リポジトリによってデプロイされる基盤パイプラインとインフラストラクチャ パイプラインに組み込まれる管理機能を示したものです。他の CI / CD 自動化ツールを使用して独自のパイプラインを開発する場合も、同様の制御を適用することをおすすめします。
| 管理機能 | 説明 |
|---|---|
ビルド構成を分離して、デプロイ前にコードを検証する |
このブループリントは、パイプライン全体で 2 つの Cloud Build ビルド構成ファイルを使用します。ステージに関連付けられた各リポジトリには、これらのビルド構成ファイルに関連付けられた 2 つの Cloud Build トリガーがあります。コードがリポジトリ ブランチに push されると、ビルド構成ファイルがトリガーされ、まず |
Terraform ポリシー チェック | このブループリントには、Google Cloud CLI のポリシー検証によって適用される、一連の Open Policy Agent 制約が含まれます。これらの制約は、パイプラインによってデプロイできる、許容可能なリソース構成を定義します。最初のビルド構成のポリシーを遵守していないビルドの場合、2 番目のビルド構成ではリソースがデプロイされません。 ブループリントに適用されているポリシーは、GitHub の |
最小権限の原則 | 基盤パイプラインは、ステージごとに異なるサービス アカウントを持ちます。各アカウントには、そのステージで最小限の IAM ロールのみを付与する許可ポリシーが適用されています。各 Cloud Build トリガーは、そのステージの特定のサービス アカウントとして実行されます。異なるアカウントを使い分けることで、あるリポジトリを変更すると、別のリポジトリで管理されているリソースが影響を受ける可能性があるというリスクを軽減できます。各サービス アカウントに適用される特定の IAM ロールについては、ブートストラップ ステージの |
Cloud Build プライベート プール | このブループリントは、Cloud Build のプライベート プールを使用します。プライベート・プールを使用すると、公開リポジトリへのアクセス制限や、VPC Service Controls 境界内での Cloud Build の実行など、必要に応じて追加の管理機能を適用できます。 |
Cloud Build カスタム ビルダー | このブループリントは、独自のカスタム ビルダーを作成して Terraform を実行します。詳細については、 |
デプロイの承認 | 必要に応じて、Cloud Build に手動承認ステージを追加できます。この承認により、ビルドがトリガーされた後（ただし、ビルドの実行前）にチェック ポイントが追加され、特権ユーザーがビルドを手動で承認できるようになります。 |
ブランチ戦略
Git システムにコードを送信し、基盤パイプラインを通じてリソースをデプロイする場合は、永続ブランチ戦略をおすすめします。次の図は、永続ブランチ戦略を示したものです。
この図は、対応する Google Cloud 環境を反映する、Git の 3 つの永続ブランチ（開発環境、非本番環境、本番環境）を示しています。また、Google Cloud 環境にデプロイされたリソースに対応していない、エフェメラルな機能ブランチもいくつか存在します。
Git システムには、永続ブランチに統合されるすべてのコードに承認済みの pull リクエスト（PR）が含められるように、PR プロセスを適用することをおすすめします。
この永続ブランチ戦略でコードを開発する大まかな手順は次のとおりです。
- 新機能を開発する場合やバグの修正に取り組んでいる場合は、開発ブランチに基づいて新しいブランチを作成します。ブランチ名には、変更の種類、チケット番号などの識別子、人が読める形式の説明を含めた命名規則を使用します（例:
feature/123456-org-policies）。 - 機能ブランチの作業が完了したら、開発ブランチをターゲットとする PR を開きます。
- PR を送信すると、PR は基盤パイプラインをトリガーして
terraform planとterraform validateを実行し、変更をステージングして検証します。 - コードの変更を検証したら、機能またはバグの修正を開発ブランチに統合します。
- 統合プロセスにより、基盤パイプラインがトリガーされます。これにより
terraform applyが実行され、開発ブランチの最新の変更が開発環境にデプロイされます。 - ユースケースに関連する手動確認、機能テスト、またはエンドツーエンド テストを使用して、開発環境の変更を確認します。次に、非本番環境ブランチをターゲットとする PR を開いて、非本番環境への変更を昇格し、変更を統合します。
- リソースを本番環境にデプロイするには、ステップ 6 と同じプロセスを繰り返します。デプロイされたリソースを確認して検証し、本番環境ブランチへの PR を開いて統合します。
次のステップ
- オペレーションのベスト プラクティス（このシリーズの次のドキュメント）を確認する。