Azure Red Hat OpenShift のリソース編成に関する考慮事項 (省略可能)

リソース編成は、主にプラットフォーム基盤によって管理されます。 プラットフォーム基盤が Azure Red Hat OpenShift ランディング ゾーン アクセラレータに影響を与える可能性があるいくつかの経路を次に示します。

サブスクリプションとリソース グループの設計は、汎用的な Azure ランディング ゾーンの推奨事項で重要な考慮事項です。 これらは、Azure Red Hat OpenShift リソース編成の管理方法で基本的な役割を果たします。 サブスクリプションは、リソース ガバナンスと分離の管理境界です。 管理グループとサブスクリプションの編成で説明されているように、サブスクリプションと管理グループを使用して、境界内のリソースにポリシーを割り当てます。

たとえば、パブリック アプリケーションとプライベート アプリケーションがある場合、それらを別のサブスクリプションに分け、Corp と Online という適切な管理グループ、またはランディング ゾーンの下の他の管理グループに配置します。 Corp 管理グループ内に存在するサブスクリプションには、パブリック IP アドレスの作成を禁止するポリシーが設定されています。 Online 管理グループの下に存在するサブスクリプションは、インターネット接続とパブリック アクセスを直接許可します。 ARO 固有のポリシーなど、Azure ランディング ゾーン設計のさまざまなレベルで適用されるポリシーの詳細については、「Azure ランディング ゾーンのリファレンス実装に含まれるポリシー」を参照してください。

設計上の考慮事項

• コンテナー ホストを管理する人を決定します。

  • ホストが集中管理されている場合は、ランディング ゾーン インスタンスの数を減らすことができます。 開発者は、定義されたプロセスに従ってホストをデプロイし、ワークロード レベルの操作に共有ダッシュボードとアラートを使用する必要があります。

  • ワークロード チームがホストを管理している場合は、ホスト環境をセグメント化するために、より多くのランディング ゾーン インスタンスが必要になります。 ワークロード チームはデプロイを制御できます。

  • ホストがワークロード チームによって集中的に管理されているかどうかに関係なく、この考慮事項を、Web アプリケーション ファイアウォール、キー コンテナー、パイプライン ビルド エージェントなどの隣接する関連リソース (および潜在的にはジャンプ ボックス) に拡大します。

• クラスターのテナント モデルを選択します。

  • ワークロード チーム運用、シングル テナント: 1 つのワークロードをサポートする 1 つのクラスター ホストでは、ワークロード チームのセグメント化と制御のための専用のランディング ゾーンが必要になる可能性が高くなります。

  • テクノロジ プラットフォーム、マルチテナントのホスト: ホストが集中管理されているとき、運用効率は、共有ランディング ゾーンのサブスクリプションでの複数のホストと複数のワークロードの統合によってもたらされます。 統合により、1 つのクラスターまたはワークロードのサポート専用のランディング ゾーンとホストの数が削減されます。

    リージョン、事業単位、環境、重要性、その他の外部制約に基づいてワークロードを分離するためにセグメント化が必要な場合は、ランディング ゾーンのサブスクリプションの追加が必要になる場合があります。

    ヒント

    追加の管理グループを作成する前に、「要件を満たすように Azure ランディング ゾーンのアーキテクチャを調整する」を確認してください。

  • 集中運用、シングル テナント 好ましくないか規制されているにもかかわらず集中運用されているワークロードに対しては、ワークロードの専用ホストを持つのが一般的です。 それでも、サポートするランディング ゾーンを統合することで、運用の効率化を図ることができる場合があります。

• ポートフォリオ全体の要件をサポートするために必要な環境とホストの一般的なスケールと配置に基づいて、管理グループ階層を選択します。

  • 各ワークロード チームで非集中型の運用を実行するために、専用環境で多数の専用ホストをサポートするには、フラット構造を使用します。
  • 集中管理ホスト向けの管理グループと非集中型の運用向けの別個の管理グループを作成するには、セグメント化された構造を使用します。
  • 課金、ガバナンス、または運用要件を反映するように環境をさらにセグメント化するには、階層構造を使用します。

• 使用するコンテナー レジストリを決定します。

  • 統合された Red Hat OpenShift コンテナー プラットフォーム レジストリを使用します。 次の点を考慮します。
    • 組み込みのコンテナー レジストリを構成する必要があります。
    • エンタープライズ品質のコンテナー レジストリの場合は、Red Hat Quay レジストリを使用します。
  • Azure Container Registry を使用します。 次の点を考慮します。
    • Azure Container Registry のベスト プラクティスを実装します。
    • 検疫パターンを使用して、脆弱性スキャンされたイメージのみがレジストリに含まれるようにします。
  • サードパーティのコンテナー レジストリを使用します。

• Open Container Initiative (OCI) 成果物の配布に使用するコンテナー レジストリ トポロジを決定します。

  • ワークロードごとに 1 つのレジストリ。
  • クラスターごとに 1 つのレジストリ (レジストリ内に複数のワークロードを含む)。
  • ランディング ゾーン内のすべてのクラスターごとに 1 つのレジストリ (同じレジストリ内に複数のワークロードとクラスターを含む)。
  • 複数のランディング ゾーンにわたるすべてのクラスターごとに 1 つのレジストリ (同じレジストリ内に複数のワークロードとクラスターを含む)。

• Azure Policy のコンテナー レジストリ ポリシーのスコープを決定します。

  • ランディング ゾーン内のすべてのホストに定義されたレジストリを使用することを要求するポリシーをサブスクリプション レベルで設定します。
  • リソース グループ レベルでより詳細なポリシーを設定します。
  • 管理グループ レベルでより広範なポリシーを設定します。

設計の推奨事項

• Azure にデプロイされているすべてのコンテナー リソースに適用する名前付けおよびタグ付けの標準を定義します。 標準には少なくとも次を含める必要があります。
  • ワークロード名: 各クラスターがサポートするワークロード。
  • クラスター リソース: 前述の考慮事項からクラスター リソース配置のレベル上げ。
  • ホスト オペレーター: ホストの運用を担当するチーム。
• 組織のコンテナー レジストリ トポロジに基づいて特定の OCI 成果物レジストリを要求するポリシーを実装します。

次の手順

• Azure Red Hat OpenShift のセキュリティに関する推奨事項を確認します。