デプロイ方法

Last reviewed 2023-12-20 UTC

エンタープライズ アプリケーションのブループリントは、一連の自動化されたシステムとパイプラインを介してデプロイされます。各パイプラインは、ブループリントの特定の要素をデプロイします。パイプラインは、ブループリントを構築するための制御可能で監査可能、そして再現可能なメカニズムを提供します。次の図は、さまざまなパイプライン、リポジトリ、ペルソナのやり取りを示したものです。

ブループリント パイプライン。

このブループリントでは、次のパイプラインを使用します。

  • 基盤インフラストラクチャ パイプライン(エンタープライズ基盤ブループリントの一部): アプリケーション ファクトリー、マルチテナント インフラストラクチャ パイプライン、フリート スコープ パイプラインをデプロイします。
  • マルチテナント インフラストラクチャ パイプライン: GKE クラスタと、エンタープライズ アプリケーションのブループリントが依存するその他のマネージド サービスをデプロイします。
  • フリート スコープ パイプライン: フリート スコープ、名前空間、RBAC ロールとバインディングを構成します。
  • アプリケーション ファクトリー: テンプレート化されたプロセスを介して新しいアプリケーション パイプラインをデプロイするメカニズムを提供します。
  • アプリケーションの CI / CD パイプライン: GKE クラスタにサービスをデプロイする CI / CD パイプラインを提供します。
  • Config Sync: Policy Controller の制約など、追加の Kubernetes 構成のデプロイと管理を行います。

リポジトリ、リポジトリ投稿者、リポジトリ変更承認者

ブループリント パイプラインは、Git リポジトリに対する変更によってトリガーされます。次の表に、ブループリント全体で使用されるリポジトリ、リポジトリに貢献するユーザー(投稿者)、リポジトリの変更を承認するユーザー(変更承認者)、リポジトリを使用するパイプライン、リポジトリの内容の説明を示します。

リポジトリ リポジトリ投稿者 リポジトリ変更承認者 パイプライン 説明

infra

デベロッパー プラットフォーム開発者

デベロッパー プラットフォーム管理者

基盤インフラストラクチャ パイプライン

マルチテナント インフラストラクチャ パイプライン、アプリケーション、フリート スコープ パイプラインをデプロイするコードを含むリポジトリ

eab-infra

デベロッパー プラットフォーム開発者

デベロッパー プラットフォーム管理者

マルチテナント インフラストラクチャ

デベロッパー プラットフォーム チームがインフラストラクチャを作成するときに使用する Terraform モジュール

fleet-scope

デベロッパー プラットフォーム開発者

デベロッパー プラットフォーム管理者

フリート スコープ

フリートのチームスコープとフリート内の名前空間を定義するリポジトリ

app-factory

デベロッパー プラットフォーム開発者

デベロッパー プラットフォーム管理者

アプリケーション ファクトリー

アプリケーション リポジトリを定義し、terraform-modules リポジトリ内のモジュールを参照するコード

app-template

アプリケーション デベロッパー

アプリケーション オペレーター

アプリケーション ファクトリー

リポジトリが最初に作成されたときに app-code リポジトリに配置されるベースコード

terraform-modules

デベロッパー プラットフォーム開発者

デベロッパー プラットフォーム管理者

アプリケーション ファクトリー

マルチテナント インフラストラクチャ

アプリケーションとインフラストラクチャを定義する Terraform モジュール

app-code

アプリケーション デベロッパー

アプリケーション オペレーター

アプリケーションの CI / CD

GKE クラスタにデプロイされるアプリケーション コード

config-policy

デベロッパー プラットフォーム開発者

デベロッパー プラットフォーム管理者

Config Sync

GKE クラスタが構成を管理するために使用するポリシー

自動化されたパイプラインは、セキュリティ、監査可能性、トレーサビリティ、反復性、制御性、コンプライアンスをデプロイ プロセスに組み込むのに役立ちます。権限の異なるシステムを使用し、異なる担当者を異なる運用グループに割り当てることで、責任を分離し、最小権限の原則に従います。

基盤インフラストラクチャ パイプライン

基盤インフラストラクチャ パイプラインは、エンタープライズ基盤ブループリントに記載されており、今後のリソースのデプロイのための汎用エントリ ポイントとして使用されます。次の表に、このパイプラインが作成するコンポーネントを示します。

コンポーネント 説明

マルチテナント インフラストラクチャ パイプライン

デベロッパー プラットフォームのすべてのテナントで使用される共有インフラストラクチャを作成します。

フリート スコープ パイプライン

名前空間と RBAC ロール バインディングを作成します。

アプリケーション ファクトリー

サービスのデプロイに使用されるアプリケーションの CI / CD パイプラインを作成します。

マルチテナント インフラストラクチャ パイプライン

マルチテナント インフラストラクチャ パイプラインは、フリート、GKE クラスタ、関連する共有リソースをデプロイします。次の図は、マルチテナント インフラストラクチャ パイプラインの各コンポーネントを示しています。

インフラストラクチャ パイプラインのコンポーネント。

次の表に、マルチテナント インフラストラクチャ パイプラインでビルドされるコンポーネントを示します。

コンポーネント 説明

GKE クラスタ

コンテナ化されたアプリケーションのサービスに対してホスティングを提供します。

Policy Controller

GKE クラスタとサービスを適切に構成するためのポリシーを提供します。

Config Sync

Policy Controller ポリシーをクラスタに適用し、一貫したポリシーの適用を維持します。

Cloud Key Management Service(Cloud KMS)

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 バインディングを構成します。次の表に、フリート スコープ パイプラインでビルドされるコンポーネントを示します。

コンポーネント 説明

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 構成の種類を示します。

コンポーネント 説明

Deployment

スケーリングされた一連の Pod(コンテナ)を定義します。

Service

クラスタ ネットワーク経由でデプロイメントに到達できるようにします。

VirtualService

サービスをサービス メッシュの一部にします。

DestinationRule

サービス メッシュ上のピアが仮想サービスに到達する方法を定義します。East-West トラフィックに対して地域によるロード バランシングを構成するためにブループリントで使用されます。

AuthorizationPolicy

サービス メッシュ内のワークロード間のアクセス制御を設定します。

Kubernetes サービス アカウント

Kubernetes Service が使用する ID を定義します。Workload Identity は、Google Cloud リソースへのアクセスに使用する Google Cloud サービス アカウントを定義します。

Gateway

外部の上り(内向き)トラフィックがサービスに到達できるようにします。ゲートウェイは、外部トラフィックを受信するデプロイメントでのみ必要です。

GCPBackendPolicy

外部トラフィックを受信するデプロイメント用に SSL、Google Cloud Armor、セッション アフィニティ、コネクション ドレインを構成します。GCPBackendPolicy は、外部トラフィックを受信するデプロイメントでのみ使用されます。

PodMonitoring

アプリケーションによってエクスポートされた Prometheus 指標のコレクションを構成します。

継続的インテグレーション

次の図は、継続的インテグレーションのプロセスを示しています。

継続的インテグレーション プロセスのブループリント。

プロセスは次のとおりです。

  1. デベロッパーがアプリケーション コードをアプリケーションのソース リポジトリに commit します。このオペレーションにより、Cloud Build がトリガーされ、インテグレーション パイプラインが開始されます。
  2. Cloud Build がコンテナ イメージを作成し、そのコンテナ イメージを Artifact Registry に push して、イメージ ダイジェストを作成します。
  3. Cloud Build がアプリケーションの自動テストを実行します。アプリケーションの言語に応じて、異なるテスト パッケージを実行できます。
  4. Cloud Build はコンテナ イメージに対して次のスキャンを実行します。
    1. Cloud Build は、コンテナ構造テスト フレームワークを使用してコンテナを分析します。このフレームワークでは、コマンドテスト、ファイルの存在テスト、ファイルの内容テスト、メタデータ テストが実行されます。
    2. Cloud Build は、脆弱性スキャンを使用して、Google Cloud が管理する脆弱性データベースに対するコンテナ イメージの脆弱性を特定します。
  5. スキャン結果が正常であれば、Cloud Build はパイプラインでのイメージの続行を承認します。
  6. Binary Authorization がイメージに署名します。Binary Authorization は Google Cloud 上のサービスであり、ポリシールールメモ証明書認証者署名者を使用して、コンテナベースのアプリケーションのソフトウェア サプライ チェーン セキュリティを提供します。コンテナのデプロイを許可する前に、デプロイ時に Binary Authorization ポリシー施行者がコンテナの出所を確認できるようにします。
  7. Cloud Build が Cloud Deploy にリリースを作成し、デプロイ プロセスを開始します。

ビルドのセキュリティ情報を表示するには、[セキュリティ分析情報] パネルに移動します。表示される分析情報は、Artifact Analysis を使用して検出された脆弱性や、SLSA ガイドラインで示されるビルドのセキュリティ保証レベルなどです。

アプリケーションをビルドする場合は、コンテナ構築のベスト プラクティスに沿って行う必要があります。

継続的デプロイ

次の図は、継続的デプロイのプロセスを示しています。

継続的デプロイ プロセスのブループリント。

プロセスは次のとおりです。

  1. ビルドプロセスの最後に、アプリケーションの CI / CD パイプラインは新しい Cloud Deploy リリースを作成し、新しくビルドされたコンテナ イメージを各環境に段階的にリリースします。
  2. Cloud Deploy が、デプロイ パイプラインの最初の環境(通常は開発環境)へのロールアウトを開始します。各デプロイ ステージは、手動承認を必要とするように構成されています。
  3. Cloud Deploy パイプラインは順次デプロイを使用して、環境内の各クラスタにイメージを順番にデプロイします。
  4. 各デプロイ ステージの終了時に、Cloud Deploy はデプロイされたコンテナの機能を検証します。この手順は、アプリケーションの Skaffold 構成内で構成できます。

新しいアプリケーションのデプロイ

次の図は、アプリケーション ファクトリーとアプリケーションの CI / CD パイプラインが連携して、新しいアプリケーションを作成およびデプロイする仕組みを示しています。

アプリケーションをデプロイするプロセス。

新しいアプリケーションを定義するプロセスは次のとおりです。

  1. アプリケーション オペレーターが、Cloud Build トリガーを実行してアプリケーション定義を生成することで、テナント内に新しいアプリケーションを定義します。
  2. トリガーにより、Terraform にアプリケーションの新しいエントリが追加され、アプリケーション ファクトリー リポジトリに変更が commit されます。
  3. commit された変更により、アプリケーション固有のリポジトリとプロジェクトの作成がトリガーされます。
  4. Cloud Build が次の処理を完了します。
    1. アプリケーションのソースコードと IaC をホストする 2 つの新しい Git リポジトリを作成します。
    2. ネットワーク ポリシー用の Kubernetes マニフェストと Workload Identity を構成管理リポジトリに push します。
    3. アプリケーションの CI / CD プロジェクトと Cloud Build IaC トリガーを作成します。
  5. アプリケーションの Cloud Build IaC トリガーが、アプリケーションの CI / CD パイプラインと Artifact Registry リポジトリをアプリケーションの CI / CD プロジェクトで作成します。
  6. Config Sync が、ネットワーク ポリシーと Workload Identity 構成をマルチテナント GKE クラスタにデプロイします。
  7. フリート スコープの作成パイプラインが、マルチテナント GKE クラスタ上のアプリケーション用にフリート スコープと Namespace を作成します。
  8. アプリケーションの CI / CD パイプラインが、GKE クラスタへの最初のアプリケーションのデプロイを実行します。
  9. 必要に応じて、アプリケーション チームが Cloud Build IaC トリガーを使用して、プロジェクトと追加のリソース(データベースやその他のマネージド サービスなど)を専用の単一テナント プロジェクト(環境ごとに 1 つ)にデプロイします。

GKE Enterprise の構成とポリシー管理

ブループリントでは、デベロッパー プラットフォームの管理者が Config Sync を使用して各環境にクラスタレベルの構成を作成します。Config Sync は Git リポジトリに接続します。Git リポジトリは、クラスタ構成の選択された状態に対する信頼できる情報源として機能します。Config Sync は、クラスタ内の構成の実際の状態を継続的にモニタリングし、手動による変更が発生した場合でも、選択された状態を遵守するために更新を適用して不一致を調整します。構成は、リポジトリのブランチ戦略を使用して、環境(開発環境、非本番環境、本番環境)に適用されます。

このブループリントでは、Config Sync が Policy Controller の制約を適用します。このような構成では、組織のデベロッパー プラットフォームの管理者が定義したセキュリティとコンプライアンスの管理が定義されます。このブループリントは、他のパイプラインを使用して他の構成を適用します。アプリケーションの CI / CD パイプラインはアプリケーション固有の構成を適用し、フリート スコープ パイプラインは Namespace と関連するロール バインディングを作成します。

次のステップ