第4章 ホストのグループ化の概念
Capsule Server の物理トポロジーとは別に、Red Hat Satellite はホストのグループ化に複数の論理ユニットを提供します。これらのグループのメンバーであるホストは、グループ設定を継承します。たとえば、プロビジョニング環境を定義する単純なパラメーターは、以下のレベルで適用できます。
Global > Organization > Location > Domain > Host group > Host
以下は Red Hat Satellite の主な論理グループです。
- 組織: ホストの高位の論理グループです。組織により、コンテンツと設定が明確に区別されます。各組織には個別の Red Hat Subscription Manifest が必要であり、Satellite Server の個別の仮想インスタンスと考えることができます。低位のホストグループが適用可能な場合には組織を使用しないようにしてください。
- ロケーション: 物理的なロケーションに一致するホストのグループ分けです。ロケーションは、ネットワークインフラストラクチャーのマッピングに使用して、間違ったホストの配置または設定を防ぐことができます。たとえば、サブネット、ドメイン、またはコンピュートリソースを直接 Capsule Server に割り当てることはできず、ロケーションにのみ割り当てられます。
- ホストグループ: 割り当て済みの Puppet クラス、コンテンツビュー、またはオペレーティングシステムを含むホストの定義を主に提供する媒体です。設定の大半は、ホストを直接定義するのではなく、ホストグループレベルで設定することが推奨されます。新規ホストの設定は、適切なホストグループへの追加が主な作業になります。ホストグループはネスト化できるため、要件に最も適した設定を作成できます (「ホストグループの構造」 を参照)。
- ホストコレクション: サブスクリプションおよびコンテンツの管理目的で Satellite Server に登録されたホストは コンテンツホスト と呼ばれます。コンテンツホストはホストコレクションに分類できるため、パッケージ管理やエラータインストールなどの一括処理が可能になります。
ロケーションおよびホストグループは入れ子にすることができます。組織とホストコレクションはフラットです。
4.1. ホストグループの構造
ホストグループをネスト化して相互のパラメーターを継承できるということは、特定のワークフローに適するホストグループの階層を定義できるということになります。ホストグループの構造を入念に計画すれば、ホスト設定の保守が容易になります。本セクションでは、ホストグループを体系化するための 4 つのアプローチを説明します。
図4.1 ホストグループ構造の例
フラット構造
フラット構造の利点は、継承が行われないため、あまり複雑にはならないことです。ホストのタイプが限られているデプロイメントでは、このシナリオが最善のオプションになります。ただし、継承が行われないため、ホストグループの設定が重複するリスクがあります。
ライフサイクル環境ベースの構造
この階層では、最初のホストグループレベルはライフサイクル環境に固有のパラメーターに使用します。2 番目のレベルにはオペレーティングシステム関連の定義が含まれ、3 番目のレベルにはアプリケーション固有の設定が含まれます。この構造は、ライフサイクル環境ごとに責任が分けられているシナリオで役に立ちます (たとえば、ライフサイクルのDevelopment (開発)、QA (品質保証)、Production (実稼働)の各ステージごとに所有者がそれぞれ設定されている場合)。
アプリケーションベースの構造
この階層は、特定のアプリケーションに対するホストのロールに基づいています。たとえば、これにより、バックエンドおよびフロントエンドのサーバーグループに対するネットワーク設定の定義が可能になります。ホストの一部の特徴を、Puppet ベースの、複雑な設定の管理に対応した形で分類できます。ただし、コンテンツビューはこの階層の最下位レベルのホストグループにのみ割り当てることができます。
ロケーションベースの構造
この階層では、ロケーションの区分がホストグループ構造に連動します。ロケーション (Capsule Server) トポロジーが他の多くの属性を決定するシナリオでは、このアプローチが最善のオプションになります。しかし、この構造はロケーション間でのパラメーターの共有を複雑にします。そのため、アプリケーションが多数ある複雑な環境では、設定を変更するたびに、変更が必要になるホストグループの数が大幅に増加します。
