App Hub の設定モデルを選択する

アプリ対応フォルダ(プレビュー)またはホスト プロジェクトを使用して、インフラストラクチャ リソースを App Hub アプリケーションに整理します。

アプリ対応フォルダ

推奨

アプリ対応フォルダは、インフラストラクチャ リソースを App Hub アプリケーションのサービスとワークロードとしてグループ化できる Google Cloud フォルダです。アプリ対応フォルダでは、フォルダ内のすべてのプロジェクトでアプリケーション管理がプロビジョニングされます。アプリ管理用フォルダでは、Application Design Center や Gemini Cloud Assist などの機能にもアクセスできます。アプリ対応フォルダに App Hub アプリケーションを設定する方法については、アプリ対応フォルダに App Hub を設定するをご覧ください。

ホスト プロジェクト

ホスト プロジェクトは、インフラストラクチャ リソースを App Hub アプリケーションのサービスとワークロードとしてグループ化できる Google Cloud プロジェクトです。詳細については、ホスト プロジェクト用に App Hub を設定するをご覧ください。

リソース階層の構造を計画する

App Hub アプリケーションを整理するための基盤は、選択した設定モデルに応じて、アプリ対応フォルダまたはホスト プロジェクトのいずれかになります。App Hub のデータモデルは、標準の Google Cloud リソース階層に基づいて構築されており、同じ階層ルールと継承ポリシーが維持されます。

Google Cloud リソース階層のメリットと App Hub のアプリケーション機能を効果的に組み合わせるには、想定されるアプリケーション境界を、設定モデルの基盤となるアプリ対応フォルダまたはホスト プロジェクトにマッピングします。App Hub のデータモデルは、標準の Google Cloud リソース階層のオーバーレイと考えることができます。

  • フォルダとプロジェクトは境界です。Resource Manager のフォルダとプロジェクトは、アプリ対応フォルダやホスト プロジェクトがアプリケーションの管理境界を定義するのと同じ方法で、ポリシーの継承と組織のリソースをグループ化します。
  • ロールと権限は継承されます: App Hub の IAM ロールと権限は、標準の IAM 継承ルールに従って、管理プロジェクト、アプリ対応フォルダ自体、またはホスト プロジェクトに付与されます。
  • メタデータが集中管理される: 管理プロジェクトまたはホスト プロジェクトでアプリケーション メタデータが集中管理され、リソース管理にアプリケーション対応レイヤが追加されます。

リソースの整理の詳細については、リソースの整理のコンセプトアプリ管理用のフォルダを構成するをご覧ください。

リソース階層に関する考慮事項

アプリケーションを管理する設定モデルを選択する際は、リソース階層について次の点を考慮することをおすすめします。

ホスト プロジェクトを使用している場合:

  • すべてのリソースは、App Hub アプリケーションに登録できるように、ホスト プロジェクトに手動で関連付ける特定のサービス プロジェクトに存在する必要があります。

アプリ対応フォルダを使用している場合:

  • サービスとワークロードは、フォルダの管理境界内の App Hub アプリケーションに登録できるように、アプリ対応フォルダまたはその子孫のプロジェクト内に存在する必要があります。
  • サービスとワークロードの自動検出は、特定のアプリ対応フォルダとその子孫のプロジェクトの境界内で動作します。
  • フォルダ構造を慎重に計画します。

    • 1 つのアプリ対応フォルダを使用して、そのフォルダ内の複数のプロジェクトにわたってアプリケーションを管理します。
    • アプリ対応のネストされたフォルダを作成して、アプリケーション管理をさまざまなチームやビジネス ユニットに委任し、アプリケーションをよりきめ細かく制御できるようにします。

フォルダ内のアプリケーションの管理で説明されているように、親フォルダ(F1 など)でアプリケーション管理を有効にすると、そのフォルダ内のアプリケーションは、そのフォルダ内のプロジェクト(P10P11 など)のリソースだけでなく、ネストされたフォルダ(F2 内の P20P21 など)内のプロジェクトのリソースも直接含めることができます。

フォルダレベルにまたがるプロジェクト P10 と P20 を含むアプリケーション。

ネストされたフォルダ F2 でアプリケーション管理のみを有効にすると、そのフォルダ内のアプリケーションは、P20P21 などのフォルダ内のプロジェクトのリソースのみを使用できます。親フォルダ F1 のリソース(P10P11 など)は、F2 のアプリでは使用できません。プロジェクトのリソースを親フォルダに含めるには、そのプロジェクトを F2 に移動する必要があります。

プロジェクト P10 と P20 を含むアプリケーション。ただし、P10 はフォルダ F2 に移動しています。

リソース構造のパターン

フォルダとプロジェクトの構造を慎重に計画するうえで、次の一般的なパターンをおすすめします。

  • 単一のアプリ対応フォルダ: 小規模な組織や初期導入で構成を開始し、単一の管理境界内でアプリケーション管理を統合します。
  • 環境ごとにアプリ対応フォルダ: 開発環境間の強力な分離を適用し、異なるポリシーを許可してリスクを軽減します。
  • 事業部門またはチームごとにアプリ対応フォルダを作成する: 管理を組織構造とチームの責任に合わせ、自律性を高めます。この方法を実装するには、複数の独立したアプリ対応フォルダを構造化します。
  • アプリ管理用フォルダのネスト構造を作成する: 階層制御を使用して、ビジネス ユニット、チーム、環境ごとに整理します。たとえば、ビジネス ユニットの最上位フォルダを作成し、各ユニット内に開発環境、ステージング環境、本番環境のネストされたフォルダを作成します。このパターンでは、リソース階層に関する考慮事項で説明されているアプリ対応フォルダ構造を利用します。
  • アプリケーションまたはアプリケーション グループごとに 1 つのホスト プロジェクト: 標準プロジェクトの既存のリソースを整理します。プロジェクトベースの関心の分離に慣れている組織や、この方法で管理されている既存のアプリケーションがある組織に適しています。

次のステップ