エンタープライズ アプリケーションのブループリントは、一連の自動化されたシステムとパイプラインを介してデプロイされます。各パイプラインは、ブループリントの特定の要素をデプロイします。パイプラインは、ブループリントを構築するための制御可能で監査可能、そして再現可能なメカニズムを提供します。次の図は、さまざまなパイプライン、リポジトリ、ペルソナのやり取りを示したものです。
このブループリントでは、次のパイプラインを使用します。
- 基盤インフラストラクチャ パイプライン（エンタープライズ基盤ブループリントの一部）: アプリケーション ファクトリー、マルチテナント インフラストラクチャ パイプライン、フリート スコープ パイプラインをデプロイします。
- マルチテナント インフラストラクチャ パイプライン: GKE クラスタと、エンタープライズ アプリケーションのブループリントが依存するその他のマネージド サービスをデプロイします。
- フリート スコープ パイプライン: フリート スコープ、名前空間、RBAC ロールとバインディングを構成します。
- アプリケーション ファクトリー: テンプレート化されたプロセスを介して新しいアプリケーション パイプラインをデプロイするメカニズムを提供します。
- アプリケーションの CI / CD パイプライン: GKE クラスタにサービスをデプロイする CI / CD パイプラインを提供します。
- Config Sync: Policy Controller の制約など、追加の Kubernetes 構成のデプロイと管理を行います。
リポジトリ、リポジトリ投稿者、リポジトリ変更承認者
ブループリント パイプラインは、Git リポジトリに対する変更によってトリガーされます。次の表に、ブループリント全体で使用されるリポジトリ、リポジトリに貢献するユーザー（投稿者）、リポジトリの変更を承認するユーザー（変更承認者）、リポジトリを使用するパイプライン、リポジトリの内容の説明を示します。
| リポジトリ | リポジトリ投稿者 | リポジトリ変更承認者 | パイプライン | 説明 |
|---|---|---|---|---|
|
デベロッパー プラットフォーム開発者 |
デベロッパー プラットフォーム管理者 |
基盤インフラストラクチャ パイプライン |
マルチテナント インフラストラクチャ パイプライン、アプリケーション、フリート スコープ パイプラインをデプロイするコードを含むリポジトリ |
|
デベロッパー プラットフォーム開発者 |
デベロッパー プラットフォーム管理者 |
マルチテナント インフラストラクチャ |
デベロッパー プラットフォーム チームがインフラストラクチャを作成するときに使用する Terraform モジュール |
|
デベロッパー プラットフォーム開発者 |
デベロッパー プラットフォーム管理者 |
フリート スコープ |
フリートのチームスコープとフリート内の名前空間を定義するリポジトリ |
|
デベロッパー プラットフォーム開発者 |
デベロッパー プラットフォーム管理者 |
アプリケーション ファクトリー |
アプリケーション リポジトリを定義し、 |
|
アプリケーション デベロッパー |
アプリケーション オペレーター |
アプリケーション ファクトリー |
リポジトリが最初に作成されたときに |
|
デベロッパー プラットフォーム開発者 |
デベロッパー プラットフォーム管理者 |
アプリケーション ファクトリー マルチテナント インフラストラクチャ |
アプリケーションとインフラストラクチャを定義する Terraform モジュール |
|
アプリケーション デベロッパー |
アプリケーション オペレーター |
アプリケーションの CI / CD |
GKE クラスタにデプロイされるアプリケーション コード |
|
デベロッパー プラットフォーム開発者 |
デベロッパー プラットフォーム管理者 |
Config Sync |
GKE クラスタが構成を管理するために使用するポリシー |
自動化されたパイプラインは、セキュリティ、監査可能性、トレーサビリティ、反復性、制御性、コンプライアンスをデプロイ プロセスに組み込むのに役立ちます。権限の異なるシステムを使用し、異なる担当者を異なる運用グループに割り当てることで、責任を分離し、最小権限の原則に従います。
基盤インフラストラクチャ パイプライン
基盤インフラストラクチャ パイプラインは、エンタープライズ基盤ブループリントに記載されており、今後のリソースのデプロイのための汎用エントリ ポイントとして使用されます。次の表に、このパイプラインが作成するコンポーネントを示します。
| コンポーネント | 説明 |
|---|---|
デベロッパー プラットフォームのすべてのテナントで使用される共有インフラストラクチャを作成します。 |
|
名前空間と RBAC ロール バインディングを作成します。 |
|
サービスのデプロイに使用されるアプリケーションの CI / CD パイプラインを作成します。 |
マルチテナント インフラストラクチャ パイプライン
マルチテナント インフラストラクチャ パイプラインは、フリート、GKE クラスタ、関連する共有リソースをデプロイします。次の図は、マルチテナント インフラストラクチャ パイプラインの各コンポーネントを示しています。
次の表に、マルチテナント インフラストラクチャ パイプラインでビルドされるコンポーネントを示します。
| コンポーネント | 説明 |
|---|---|
GKE クラスタ |
コンテナ化されたアプリケーションのサービスに対してホスティングを提供します。 |
Policy Controller |
GKE クラスタとサービスを適切に構成するためのポリシーを提供します。 |
Config Sync |
Policy Controller ポリシーをクラスタに適用し、一貫したポリシーの適用を維持します。 |
GKE、AlloyDB for PostgreSQL、Secret Manager の顧客管理の暗号鍵（CMEK）に基づいて暗号鍵を作成します。 |
|
Secret Manager Secret |
JSON Web Tokens（JWT）によるユーザー認証に使用される RSA 鍵ペアの Secret ストアを提供します。 |
Google Cloud Armor セキュリティ ポリシー |
Google Cloud Armor ウェブ アプリケーション ファイアウォールで使用されるポリシーを提供します。 |
フリート スコープ パイプライン
フリート スコープ パイプラインは、フリートの GKE クラスタで Namespace と RBAC バインディングを構成します。次の表に、フリート スコープ パイプラインでビルドされるコンポーネントを示します。
| コンポーネント | 説明 |
|---|---|
物理クラスタ内の論理クラスタを定義します。 |
|
Kubernetes サービス アカウントがクラスタレベルまたは名前空間レベルで持つ認可を定義します。 |
アプリケーション ファクトリー
アプリケーション ファクトリーは、基盤インフラストラクチャ パイプラインによってデプロイされ、新しいアプリケーションごとにインフラストラクチャを作成するために使用されます。このインフラストラクチャには、アプリケーションの CI / CD パイプラインを保持する Google Cloud プロジェクトが含まれています。
エンジニアリング組織の規模が拡大したら、アプリケーション チームはアプリケーション ファクトリーを使用して新しいアプリケーションをオンボーディングできます。個別のアプリケーション CI / CD パイプラインを追加し、マルチテナント アーキテクチャ内で新しいアプリケーションをデプロイするためのインフラストラクチャをサポートすることで、スケーリングによる成長が可能になります。次の図は、アプリケーション ファクトリーを示したものです。
アプリケーション ファクトリーには次のコンポーネントがあります。
- アプリケーション ファクトリー リポジトリ: 宣言型のアプリケーション定義を格納する Git リポジトリ。
- アプリケーションを作成するパイプライン: Cloud Build に次の処理を要求するパイプライン。
- 宣言型のアプリケーション定義を作成し、アプリケーション カタログに保存する。
- 宣言型のアプリケーション定義を適用して、アプリケーション リソースを作成する。
- スターター アプリケーション テンプレート リポジトリ: シンプルなアプリケーション（Python、Golang、Java マイクロサービスなど）を作成するためのテンプレート。
- 共有モジュール: 標準的な方法で作成され、アプリケーションのオンボーディングやデプロイなど、複数の目的に使用される Terraform モジュール。
次の表に、アプリケーション ファクトリーが各アプリケーションに対して作成するコンポーネントを示します。
| コンポーネント | 説明 |
|---|---|
アプリケーションのソースコード リポジトリ |
特定のアプリケーションのビルドとデプロイに使用されるソースコードと関連する構成が含まれています。 |
アプリケーションの CI / CD パイプライン |
ソースコード リポジトリへの接続に使用され、アプリケーション サービスをデプロイするための CI / CD パイプラインを提供する Cloud Build ベースのパイプライン。 |
アプリケーションの CI / CD パイプライン
アプリケーションの CI / CD パイプラインを使用すると、コンテナベースのアプリケーションのビルドとデプロイを自動化できます。このパイプラインは、継続的インテグレーション（CI）と継続的デプロイ（CD）のステップで構成されます。このパイプライン アーキテクチャは、安全な CI / CD ブループリントに基づいています。
アプリケーションの CI / CD パイプラインでは、環境全体で不変のコンテナ イメージを使用します。不変のコンテナ イメージを使用すると、同じイメージがすべての環境にデプロイされ、コンテナの実行中に変更されることはありません。アプリケーション コードの更新やパッチの適用が必要な場合は、新しいイメージを作成して再デプロイします。不変のコンテナ イメージを使用するには、コンテナ構成を外部に置いて、ランタイム時に構成情報を読み取る必要があります。
プライベート ネットワーク パスを介して GKE クラスタにアクセスし、kubeconfig 認証を管理するために、アプリケーションの CI / CD パイプラインは Connect Gateway を介して GKE クラスタとやり取りします。このパイプラインは、CI / CD 環境用にプライベート プールも使用します。
各アプリケーションのソースコード リポジトリには、Kubernetes 構成が含まれています。これらの構成により、アプリケーションを GKE 上で Kubernetes Service として正常に実行できます。次の表に、アプリケーションの CI / CD パイプラインが適用される Kubernetes 構成の種類を示します。
| コンポーネント | 説明 |
|---|---|
スケーリングされた一連の Pod（コンテナ）を定義します。 |
|
クラスタ ネットワーク経由でデプロイメントに到達できるようにします。 |
|
サービスをサービス メッシュの一部にします。 |
|
サービス メッシュ上のピアが仮想サービスに到達する方法を定義します。East-West トラフィックに対して地域によるロード バランシングを構成するためにブループリントで使用されます。 |
|
サービス メッシュ内のワークロード間のアクセス制御を設定します。 |
|
Kubernetes Service が使用する ID を定義します。Workload Identity は、Google Cloud リソースへのアクセスに使用する Google Cloud サービス アカウントを定義します。 |
|
外部の上り（内向き）トラフィックがサービスに到達できるようにします。ゲートウェイは、外部トラフィックを受信するデプロイメントでのみ必要です。 |
|
外部トラフィックを受信するデプロイメント用に SSL、Google Cloud Armor、セッション アフィニティ、コネクション ドレインを構成します。GCPBackendPolicy は、外部トラフィックを受信するデプロイメントでのみ使用されます。 |
|
アプリケーションによってエクスポートされた Prometheus 指標のコレクションを構成します。 |
継続的インテグレーション
次の図は、継続的インテグレーションのプロセスを示しています。
プロセスは次のとおりです。
- デベロッパーがアプリケーション コードをアプリケーションのソース リポジトリに commit します。このオペレーションにより、Cloud Build がトリガーされ、インテグレーション パイプラインが開始されます。
- Cloud Build がコンテナ イメージを作成し、そのコンテナ イメージを Artifact Registry に push して、イメージ ダイジェストを作成します。
- Cloud Build がアプリケーションの自動テストを実行します。アプリケーションの言語に応じて、異なるテスト パッケージを実行できます。
- Cloud Build はコンテナ イメージに対して次のスキャンを実行します。
- スキャン結果が正常であれば、Cloud Build はパイプラインでのイメージの続行を承認します。
- Binary Authorization がイメージに署名します。Binary Authorization は Google Cloud 上のサービスであり、ポリシー、ルール、メモ、証明書、認証者、署名者を使用して、コンテナベースのアプリケーションのソフトウェア サプライ チェーン セキュリティを提供します。コンテナのデプロイを許可する前に、デプロイ時に Binary Authorization ポリシー施行者がコンテナの出所を確認できるようにします。
- Cloud Build が Cloud Deploy にリリースを作成し、デプロイ プロセスを開始します。
ビルドのセキュリティ情報を表示するには、[セキュリティ分析情報] パネルに移動します。表示される分析情報は、Artifact Analysis を使用して検出された脆弱性や、SLSA ガイドラインで示されるビルドのセキュリティ保証レベルなどです。
アプリケーションをビルドする場合は、コンテナ構築のベスト プラクティスに沿って行う必要があります。
継続的デプロイ
次の図は、継続的デプロイのプロセスを示しています。
プロセスは次のとおりです。
- ビルドプロセスの最後に、アプリケーションの CI / CD パイプラインは新しい Cloud Deploy リリースを作成し、新しくビルドされたコンテナ イメージを各環境に段階的にリリースします。
- Cloud Deploy が、デプロイ パイプラインの最初の環境（通常は開発環境）へのロールアウトを開始します。各デプロイ ステージは、手動承認を必要とするように構成されています。
- Cloud Deploy パイプラインは順次デプロイを使用して、環境内の各クラスタにイメージを順番にデプロイします。
- 各デプロイ ステージの終了時に、Cloud Deploy はデプロイされたコンテナの機能を検証します。この手順は、アプリケーションの Skaffold 構成内で構成できます。
新しいアプリケーションのデプロイ
次の図は、アプリケーション ファクトリーとアプリケーションの CI / CD パイプラインが連携して、新しいアプリケーションを作成およびデプロイする仕組みを示しています。
新しいアプリケーションを定義するプロセスは次のとおりです。
- アプリケーション オペレーターが、Cloud Build トリガーを実行してアプリケーション定義を生成することで、テナント内に新しいアプリケーションを定義します。
- トリガーにより、Terraform にアプリケーションの新しいエントリが追加され、アプリケーション ファクトリー リポジトリに変更が commit されます。
- commit された変更により、アプリケーション固有のリポジトリとプロジェクトの作成がトリガーされます。
- Cloud Build が次の処理を完了します。
- アプリケーションのソースコードと IaC をホストする 2 つの新しい Git リポジトリを作成します。
- ネットワーク ポリシー用の Kubernetes マニフェストと Workload Identity を構成管理リポジトリに push します。
- アプリケーションの CI / CD プロジェクトと Cloud Build IaC トリガーを作成します。
- アプリケーションの Cloud Build IaC トリガーが、アプリケーションの CI / CD パイプラインと Artifact Registry リポジトリをアプリケーションの CI / CD プロジェクトで作成します。
- Config Sync が、ネットワーク ポリシーと Workload Identity 構成をマルチテナント GKE クラスタにデプロイします。
- フリート スコープの作成パイプラインが、マルチテナント GKE クラスタ上のアプリケーション用にフリート スコープと Namespace を作成します。
- アプリケーションの CI / CD パイプラインが、GKE クラスタへの最初のアプリケーションのデプロイを実行します。
- 必要に応じて、アプリケーション チームが Cloud Build IaC トリガーを使用して、プロジェクトと追加のリソース（データベースやその他のマネージド サービスなど）を専用の単一テナント プロジェクト（環境ごとに 1 つ）にデプロイします。
GKE Enterprise の構成とポリシー管理
ブループリントでは、デベロッパー プラットフォームの管理者が Config Sync を使用して各環境にクラスタレベルの構成を作成します。Config Sync は Git リポジトリに接続します。Git リポジトリは、クラスタ構成の選択された状態に対する信頼できる情報源として機能します。Config Sync は、クラスタ内の構成の実際の状態を継続的にモニタリングし、手動による変更が発生した場合でも、選択された状態を遵守するために更新を適用して不一致を調整します。構成は、リポジトリのブランチ戦略を使用して、環境（開発環境、非本番環境、本番環境）に適用されます。
このブループリントでは、Config Sync が Policy Controller の制約を適用します。このような構成では、組織のデベロッパー プラットフォームの管理者が定義したセキュリティとコンプライアンスの管理が定義されます。このブループリントは、他のパイプラインを使用して他の構成を適用します。アプリケーションの CI / CD パイプラインはアプリケーション固有の構成を適用し、フリート スコープ パイプラインは Namespace と関連するロール バインディングを作成します。
次のステップ
- Cymbal Bank のアプリケーション アーキテクチャ（このシリーズの次のドキュメント）を確認する。