第4章 ホスト分類の概念

Red Hat Satellite は、Capsule Server の物理的なトポロジーのほかにも、ホストを分類するためのいくつかの論理ユニットを提供します。ホストは各グループのメンバーになり、そのグループ設定を継承します。たとえば、プロビジョニング環境を定義する単純なパラメーターは以下のレベルで適用できます (パラメーターの使用については『Puppet ガイド』の「パラメーター」を参照してください)。 

Global > Organization > Location > Domain > Host group > Host

以下は Red Hat Satellite の主な論理グループです。

  • 組織: ホストの高位の論理グループです。組織により、コンテンツと設定が明確に区別されます。各組織には個別のサブスクリプションマニフェストが必要であり、それぞれを個別の Satellite Server 仮想インスタンスと見なすことができます。低位のホストグループが適用可能な場合には組織を使用しないようにしてください。
  • ロケーション: 物理的な場所に対応するホストのグループ分けです。ロケーションは、ネットワークインフラストラクチャーのマッピングに使用して、間違ったホストの配置または設定を防ぐことができます。たとえば、サブネット、ドメイン、またはコンピュートリソースを直接 Capsule Server に割り当てることはできず、ロケーションにのみ割り当てられます。
  • ホストグループ: 割り当て済みの Puppet クラス、コンテンツビュー、またはオペレーティングシステムを含むホストの定義を主に提供する媒体です。ホストグループのパラメーターの完全一覧は『Puppet ガイド』の「パラメーター」を参照してください。設定の大半は、ホストを直接定義するのではなく、ホストグループレベルで設定することが推奨されます。そのため、「新規ホストを設定すること」は、そのホストを適切なホストグループに追加することと考えることができます。ホストグループはネスト化できるため、要件に最も適した構造を作成できます (「ホストグループの構造」を参照)。
  • ホストコレクション: サブスクリプションおよびコンテンツの管理目的で Satellite Server に登録されたホストは コンテンツホスト と呼ばれます。コンテンツホストはホストコレクションを使用して分類できるため、パッケージ管理やエラータインストールなどの一括処理が可能になります。

ロケーションおよびホストグループにはネストを使用できます。組織およびホストコレクションはフラット (非階層) です。

4.1. ホストグループの構造

ホストグループをネスト化して相互のパラメーターを継承できるということは、特定のワークフローに適するホストグループの階層を定義できるということになります。ホストグループの構造を入念に計画すれば、ホスト設定の保守が容易になります。本セクションでは、ホストグループを体系化するための 4 つのアプローチを説明します。

図4.1 ホストグループ構造の例

Host Group Structuring Examples

フラット構造

フラット構造の利点は、継承が行われないため、あまり複雑にはならないことです。ホストのタイプが限られているデプロイメントでは、このシナリオが最善のオプションになります。ただし、継承が行われないため、ホストグループの設定が重複するリスクがあります。

ライフサイクル環境ベースの構造

この階層では、最初のホストグループレベルはライフサイクル環境に固有のパラメーターに使用します。2 番目のレベルにはオペレーティングシステム関連の定義が含まれ、3 番目のレベルにはアプリケーション固有の設定が含まれます。この構造は、ライフサイクル環境ごとに責任が分けられているシナリオで役に立ちます (たとえば、「ライフサイクルのDevelopment (開発)」、「QA (品質保証)」、「Production (本番)」の各ステージごとに所有者がそれぞれ設定されている場合)。

アプリケーションベースの構造

この階層は、特定のアプリケーションに対するホストのロールに基づいています。たとえば、これにより、バックエンドおよびフロントエンドのサーバーグループに対するネットワーク設定の定義が可能になります。ホストの一部の特徴を、Puppet ベースの、複雑な設定の管理に対応した形で分類できます。ただし、コンテンツビューはこの階層の最下位レベルのホストグループにのみ割り当てることができます。

ロケーションベースの構造

この階層では、ロケーションの区分がホストグループ構造に連動します。ロケーション (Capsule Server) トポロジーが他の多くの属性を決定するシナリオでは、このアプローチが最善のオプションになります。しかし、この構造はロケーション間でのパラメーターの共有を複雑にします。そのため、アプリケーションが多数ある複雑な環境では、設定を変更するたびに、変更が必要になるホストグループの数が大幅に増加します。