リソース編成は、主にプラットフォーム基盤によって管理されます。 プラットフォーム基盤が 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 Container Platform レジストリを使用します。 次の要因を考慮してください。
- 組み込みのコンテナー レジストリを構成する必要があります。
- エンタープライズ品質のコンテナー レジストリの場合は、 Red Hat Quay レジストリを使用します。
-
Azure Container Registry を使用します。 次の要因を考慮してください。
- Azure Container Registry のベスト プラクティスを実装します。
- 検疫パターンを使用して、レジストリに脆弱性スキャンされたイメージのみが含まれていることを確認します。
- サードパーティのコンテナー レジストリを使用します。
- 統合された Red Hat OpenShift Container Platform レジストリを使用します。 次の要因を考慮してください。
Open Container Initiative (OCI) 成果物の配布に使用するコンテナー レジストリ トポロジを決定します。
- ワークロードごとに 1 つのレジストリ。
- クラスターごとに 1 つのレジストリ。レジストリには複数のワークロードがあります。
- 同じレジストリに複数のワークロードとクラスターがある、ランディング ゾーン内のすべてのクラスターに対して 1 つのレジストリ。
- 同じレジストリ内に複数のワークロードとクラスターがある、複数のランディング ゾーンにまたがるすべてのクラスターに対して 1 つのレジストリ。
Azure Policy でコンテナー レジストリ ポリシーのスコープを決定します。
- 定義済みのレジストリを使用するようにランディング ゾーン内のすべてのホストに要求するように、サブスクリプション レベルでポリシーを設定します。
- リソース グループ レベルで、より詳細なポリシーを設定します。
- 管理グループ レベルで、より広範なポリシーを設定します。
設計に関する推奨事項
- Azure にデプロイされたすべてのコンテナー リソースに適用する 名前付けとタグ付けの標準 を定義します。 少なくとも、標準には次のものが含まれている必要があります。
- ワークロード名: 各クラスターがサポートするワークロードまたはワークロード。
- クラスター リソース: 上記の考慮事項からのクラスター リソースの配置の昇格。
- ホストオペレーター: ホスト操作を担当するチーム。
- 組織のコンテナー レジストリ トポロジに基づく特定の OCI 成果物レジストリを要求するポリシーを実装します。