ブループリントをデプロイする

Last reviewed 2024-04-19 UTC

このセクションでは、ブループリントのデプロイに使用できるプロセス、その命名規則、ブループリントの推奨事項に代わる方法について説明します。

まとめ

このドキュメントで説明するアーキテクチャを実装するには、このセクションの手順を完了します。

ブループリントを新しい組織でデプロイする

ブループリントを新しい Google Cloud 組織にデプロイする手順は次のとおりです。

エンタープライズ基盤ブループリントを使用して、基盤インフラストラクチャを作成します。次の手順に沿って操作します。
1. 環境を分離するためのフォルダを含む組織構造を作成する。
2. 基本的な IAM 権限を構成して、デベロッパープラットフォーム管理者にアクセス権を付与する。
3. VPC ネットワークを作成する。
4. 基盤インフラストラクチャパイプラインをデプロイする。
エンタープライズ基盤ブループリントを使用しない場合は、エンタープライズ基盤ブループリントを使用せずにブループリントをデプロイするをご覧ください。
デベロッパープラットフォーム管理者は、基盤インフラストラクチャパイプラインを使用して、マルチテナントインフラストラクチャパイプライン、アプリケーションファクトリー、フリートスコープパイプラインを作成します。
デベロッパープラットフォーム管理者は、マルチテナントインフラストラクチャパイプラインを使用して、GKE クラスタと共有インフラストラクチャをデプロイします。
アプリケーションオペレーターは、アプリケーションファクトリーを使用して新しいアプリケーションをオンボーディングします。オペレーターがアプリケーションファクトリーリポジトリに 1 つ以上のエントリを追加し、アプリケーション固有のリソースの作成をトリガーします。
アプリケーションデベロッパーは、アプリケーション固有のインフラストラクチャ内でアプリケーション CI / CD パイプラインを使用して、アプリケーションをマルチテナントインフラストラクチャにデプロイします。

エンタープライズ基盤ブループリントを使用せずにブループリントをデプロイする

エンタープライズアプリケーションブループリントをエンタープライズ基盤ブループリントにデプロイしない場合は、次の手順に沿って操作します。

次のリソースを作成します。
- development、nonproduction、production フォルダを含む組織階層
- 各フォルダの共有 VPC ネットワーク
- GKE クラスタに必要な IP 範囲を考慮する IP アドレススキーム
- GKE クラスタの DNS メカニズム
- セキュリティポスチャーに沿ったファイアウォールポリシー
- プライベート IP アドレスを使用して Google Cloud APIs にアクセスするメカニズム
- オンプレミス環境との接続メカニズム
- セキュリティと監査のための一元的なロギング
- 脅威のモニタリングを行う Security Command Center
- セキュリティポスチャーに沿った組織のポリシー
- アプリケーションファクトリー、マルチテナントインフラストラクチャパイプライン、フリートスコープパイプラインのデプロイに使用できるパイプライン
リソースをデプロイしたら、新しい組織にブループリントをデプロイするの手順 2 に進みます。

ブループリントを既存の GKE Deployment に組み込む

このブループリントでは、まずデベロッパープラットフォームをデプロイし、次にアプリケーションをそのデベロッパープラットフォームにデプロイする必要があります。次の表は、Google Cloud でコンテナ化されたアプリケーションがすでに実行されている場合に、ブループリントを使用する方法を示しています。

既存の使用状況	移行戦略
すでに CI / CD パイプラインがある。	アプリケーションのビルドとデプロイに異なるプロダクトが使用されている場合でも、ブループリントのフリートアーキテクチャとクラスタアーキテクチャを使用できます。少なくとも、2 つのリージョンにイメージをミラーリングすることをおすすめします。
エンタープライズ基盤ブループリントと一致しない既存の組織構造がある。	より安全に順次デプロイを行うために、少なくとも 2 つの環境を用意することをおすすめします。環境を別々の共有 VPC やフォルダにデプロイする必要はありません。ただし、異なる環境に属するワークロードを同じクラスタにデプロイしないでください。
IaC を使用していない。	現在のアプリケーションデプロイプロセスで IaC を使用していない場合は、Google Cloud での Terraform の成熟度モデルで準備状況を評価できます。このブループリントと同様に構成され、マルチテナントパイプラインとテナントごとのパイプラインが分離されている別の Terraform プロジェクトに既存のリソースをインポートします。新しいクラスタを作成するには、Google Cloud 向け Terraform モジュールを使用します。
クラスタが同じ環境内の複数のプロジェクトに分散している。	複数のプロジェクトのクラスタをフリートにグループ化できます。同じフリート内で名前空間が一意の意味を持つことを確認します。フリートにクラスタを追加する前に、アプリケーションを一意の名前（たとえば `default` ではない）を使用した名前空間に移動するようチームに依頼してください。これにより、名前空間をスコープにグループ化できます。
クラスタが単一のリージョンに存在している。	ブループリントを採用するために、本番環境と非本番環境で複数のリージョンを使用する必要はありません。
環境にさまざまなセットが存在している。	ブループリントは、3 つ以上の環境をサポートするように変更できます。
クラスタの作成は、アプリケーションデベロッパーチームまたはアプリケーションオペレーターチームに委任される。	最も安全で一貫性のあるデベロッパープラットフォームを実現するために、クラスタの所有権をアプリケーションチームからデベロッパープラットフォームチームに移行できます。それができない場合でも、ブループリントのプラクティスの多くを採用できます。たとえば、異なるアプリケーションチームが所有するクラスタをフリートに追加できます。ただし、独立した所有権を持つクラスタを組み合わせる場合は、Workload Identity または Cloud Service Mesh を使用しないでください。誰がどのワークロード ID を表明できるかを十分に制御できないためです。代わりに、カスタム組織ポリシーを使用して、チームが GKE クラスタでこれらの機能を有効にしないようにしてください。クラスタがフリートにグループ化されている場合でも、ポリシーを監査、適用できます。カスタム組織ポリシーを使用すると、クラスタのプロジェクトが存在する環境フォルダに対応するフリート内にクラスタの作成を要求できます。フリートのデフォルト構成を使用すると、新しいクラスタでポリシー制御の使用を必須にできます。

デフォルトの推奨事項に代わる方法

このセクションでは、このガイドに含まれるデフォルトの推奨事項に代わる方法について説明します。

決定分野	代替策
すべてのアプリケーションは、同じ 5 つのクラスタセットで実行される。	このブループリントでは、5 つのクラスタのセットを使用します（本番環境に 2 つ、非本番環境に 2 つ、開発環境に 1 つ）。ブループリントを変更して、5 つのクラスタの追加セットを作成できます。アプリケーションを 5 つのクラスタのセットに割り当てます。アプリケーションのスコープまたはフリートの名前空間を他のセットのクラスタにバインドしないでください。次のようなアクティビティを完了するために、アプリケーションを異なるクラスタセットに分離することをおすすめします。特別な規制上の懸念事項（PCI-DSS など）を持ついくつかのアプリケーションをグループ化する。クラスタのアップグレード中に特別な処理が必要なアプリケーション（たとえば、永続ボリュームを使用するステートフルアプリケーションなど）を分離する。リスクの高いセキュリティプロファイルを使用してアプリケーションを分離する（たとえば、メモリ安全でない言語でユーザー提供のコンテンツを処理するなど）。 GPU、コスト感度、パフォーマンス感度を必要とするアプリケーションを分離する。ノード数の GKE クラスタの上限（15,000 ノード）に近づいている場合は、新しいクラスタセットを作成できる。 VPC Service Controls の境界内で実行する必要があるアプリケーションには、別の共有 VPC を使用する。たとえば、境界にクラスタセットを 1 つ、境界外にクラスタを 1 つ作成する。次のいずれかの状況が発生する可能性があるため、アプリケーションまたはテナントごとに新しいクラスタセットを作成しないでください。使用可能な最小インスタンスタイプであっても、最小クラスタサイズ（3 VM × 2 リージョン）が十分に活用されていないアプリケーション。さまざまなアプリケーションをビンパッキングすることによるコスト削減の可能性の損失。計画が各アプリケーションに対して個別に適用されたことによる、面倒で不確実な容量増加計画。容量の予測は、広範なアプリケーションに対して集計すると、より正確になります。新しいテナントまたはアプリケーション用の新しいクラスタの作成の遅延。これにより、プラットフォームに対するテナントの満足度が低下します。たとえば、組織によっては必要な IP アドレスの割り振りに時間がかかり、追加の承認が必要になることがあります。 VPC ネットワーク内の限定公開クラスタの上限に達する。
本番環境と非本番環境では、2 つのリージョンにクラスタがある。	複数のリージョンのエンドユーザーのレイテンシを低くするには、本番環境と非本番環境のワークロードを 2 つ以上のリージョンにデプロイできます（たとえば、本番環境用に 3 つのリージョン、非本番環境用に 3 つのリージョン、開発用に 1 つのリージョンなど）。このデプロイ戦略では、追加のリージョンでリソースを管理するコストとオーバーヘッドが増加します。
	すべてのアプリケーションの可用性要件が低い場合、本番環境と非本番環境のワークロードを 1 つのリージョン（1 つの本番環境、1 つの非本番環境、1 つの開発環境）にデプロイできます。この戦略は費用の削減には役立ちますが、デュアルリージョンアーキテクチャやマルチリージョンアーキテクチャと同じレベルの可用性は保護されません。
	アプリケーションの可用性要件が異なる場合は、アプリケーションごとに異なるクラスタセットを作成できます（たとえば、2 つの本番環境、2 つの非本番環境、1 つの開発環境を使用した `cluster-set-1`、1 つの本番環境、1 つの非本番環境、1 つの開発環境を使用した `cluster-set-2` など）。
ハブアンドスポークトポロジは、共有 VPC よりも要件に一致する。	ブループリントは、ハブアンドスポーク構成でデプロイできます。この構成では、各環境（開発環境、本番環境、非本番環境）が独自のスポークでホストされます。ハブアンドスポークトポロジでは、環境の分離が促進される可能性があります。詳細については、ハブアンドスポークネットワークトポロジをご覧ください。
アプリケーションごとに個別の Git リポジトリがあります。	複数のリポジトリではなく、すべてのソースコードに単一の Git リポジトリ（monorepo）を使用している組織もあります。monorepo を使用している場合は、ブループリントのアプリケーションファクトリーコンポーネントを変更すると、リポジトリをサポートできます。次の手順に沿って操作します。新しいアプリケーションごとに新しいリポジトリを作成するのではなく、既存のリポジトリにサブディレクトリを作成します。新しいリポジトリのオーナー権限をアプリケーションデベロッパーグループに付与する代わりに、既存のリポジトリに対する書き込み権限を付与し、新しいサブディレクトリに対する変更の審査者としてアプリケーションデベロッパーグループを指定します。`CODEOWNERS` 機能とブランチ保護を使用します。

次のステップ

エンタープライズ基盤ブループリントの詳細をご覧ください。
Google Cloud でのソフトウェアデリバリーの詳細については、次をご覧ください。
GKE でアプリケーションを実行する方法については、次をご覧ください。