以下の図は、Red Hat Satellite 6 のアーキテクチャー全体の俯瞰図を示しています。

図1.1 Red Hat Satellite 6 システムアーキテクチャー

このアーキテクチャーでは、コンテンツが 4 つのステージを通過します。

以下の図は、Satellite Server から Capsule へのコンテンツ配信の詳細を示しています。

図1.2 Red Hat Satellite 6 におけるコンテンツのライフサイクル

デフォルトでは、各組織は外部ソースのコンテンツのライブラリーを持ちます。コンテンツビューはインテリジェントなフィルタリングによって作成されるライブラリーのコンテンツのサブセットです。コンテンツビューはライフサイクル環境 (通常は「Dev (開発)」、「QA」および「Production (本番)」に公開し、プロモートできます。Capsule Server の作成時にその Capsule にコピーし、管理対象ホストで利用できるようにするライフサイクル環境を選択できます。

コンテンツビューを組み合わせて複合コンテンツビューを作成することができます。オペレーティングシステムで必要とするパッケージのリポジトリーやアプリケーションで必要とするパッケージのリポジトリーに別々のコンテンツビューを使用することには利点があります。1 つの利点として、1 つのリポジトリーにあるパッケージへのすべての更新には、関連するコンテンツビューの再公開のみが必要になります。その後は複合コンテンツビューを使用して公開済みのコンテンツビューを組み合わせることができるので、管理が容易になります。

どのコンテンツビューがどの Capsule Server にプロモートされるかは、Capsule の意図されている機能によって異なります。いずれの Capsule Server も、コンテンツまたは設定サービスなどで補完されるインフラストラクチャーサービスとして DNS、DHCP、および TFTP を実行できます。

ライブラリーの同期されたコンテンツを使用して新規バージョンのコンテンツビューを作成することで Capsule Server を更新できます。コンテンツビューの新規バージョンはライフサイクル環境でプロモートされます。さらにコンテンツビューのインプレース更新を作成することもできます。これは、ライブラリーからプロモートせずに現在のライフサイクル環境でコンテンツビューのマイナーバージョンを作成するという意味です。たとえば、「Production (本番)」のコンテンツビューにセキュリティーエラータを適用する必要がある場合、他のライフサイクルのプロモートせずにコンテンツビューを直接更新することができます。コンテンツ管理についての詳細は、Red Hat Satellite Content Management Guide を参照してください。

Red Hat Satellite 6 は、Satellite 6 として統合され、検証され、提供されるいくつかのオープンソースプロジェクトで構成されています。この情報については、Red Hat カスタマーポータル上で参照でき、定期的に更新されています。Satellite 6 Component Versions を参照してください。

Red Hat Satellite 6 は、以下のオープンソースプロジェクトで構成されています。

Red Hat Satellite およびそのアップストリームコンポーネントで使用される用語は広範囲に及びます。よく使われる用語の説明については、付録B 用語集 を参照してください。

各 Red Hat Satellite サブスクリプションには、Red Hat Enterprise Linux Server のサポートされたインスタンスが 1 つ含まれます。このインスタンスは Red Hat Satellite を実行する目的にのみ取り分けておく必要があります。Satellite に含まれるオペレーティングシステムを使用して環境内で他のデーモン、アプリケーション、またはサービスを実行することはサポート対象外となります。

Red Hat Satellite コンポーネントのサポートについては、以下で説明されています。

Red Hat は、Puppet モジュールを含む数多くの異なるスクリプトおよび他のフレームワークをサポートしています。これらのフレームワークのサポートは、アーティクルの How does Red Hat support scripting frameworks? に基づいて行われています。

Capsule Server は 2 つのセットの機能を提供します。まず、Satellite Server からのコンテンツをミラーリングできるように Capsule を設定できます。さらにホスト管理に必要なサービスを実行するために Capsule を使用することもできます。

以下はコンテンツに関連する機能になります。

以下はインフラストラクチャーおよびホスト管理サービスになります。

すべての Capsule 機能を1 度に有効にする必要はありません。Capsule Server は特定の限定された目的のために設定できます。一部の共通の設定には以下が含まれます。

Capsule を分離する目的は、リモートネットワークセグメントでファイアウォールポートを Capsule 自体に開くことだけで済むようにホストのネットワーク通信すべての単一エンドポイントを提供することにあります。以下の図は、ホストが分離した Capsule に接続されているシナリオで Satellite コンポーネントが対話する方法について示しています。

図2.1 分離した Capsule を含む Satellite トポロジー

以下の図は、ホストが Satellite Server に直接接続される場合に Satellite コンポーネントが対話する方法を示しています。外部 Capsule のベースシステムは Satellite のクライアントであるため、この図はホストを直接接続する場合でなくても関連性があることに留意してください。

図2.2 内部 Capsule を含む Satellite トポロジー

Red Hat Satellite インストールガイド の ポートとファイアウォールの要件 のセクションには、必要なポートを開くためにホストベースのファイアウォールを設定するための方法が詳述されています。ポートのマトリックス表も、ナレッジベースソリューション Red Hat Satellite 6.2 List of Network Ports で参照できます。

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

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

フラット構造

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

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

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

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

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

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

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

作業用の Satellite インフラストラクチャーに対する最初のステップとして、Red Hat Satellite インストールガイド に説明されているように Red Hat Satellite Server を専用 Red Hat Enterprise 7 Server にインストールします。本ガイドで説明している インストールの前提条件 および 大規模なデプロイメントについての考慮事項 について検討してください。

Red Hat Satellite 6 では、Satellite で設定される各組織の単一マニフェストが必要になります。Satellite 6 の組織機能を使用して、Red Hat Network アカウントでインフラストラクチャーの別々のユニットを管理する予定がある場合、必要に応じて 1 つのアカウントのサブスクリプションを組織ごとのマニフェストに割り当てます。

複数の Red Hat Network アカウントを持つ予定の場合や、Red Hat Network アカウントの保持者でもある別のエンティティーに属するシステムを管理する必要がある場合には、ユーザーと別のアカウント保持者は必要に応じてマニフェストにサブスクリプションを割り当てることができます。次に 1 つの Satellite Server で複数のマニフェストを使用して複数の組織を管理できます。

システムを管理する必要があるもののサブスクリプションへのアクセスがない場合、Smart Management サブスクリプションを使用します。これにより、ソフトウェアリポジトリーにサブスクライブするエンタイトルメントなしに複数のシステムを管理することができます。

以下の図は、複数のシステムを同じ Satellite 6 インストールで管理する必要のある、2 つの Red Hat Network アカウント保持者について示しています。このシナリオでは、Example Corporation 1 は 60 サブスクリプションの任意のサブセットを割り当てることができます。この例では、30 をマニフェストに割り当てています。これは別個の組織として Satellite にインポートできます。これにより、システム管理者は Satellite 6 を使用し、Example Corporation 2 の組織 (R&D、Operations、および Engineering) と完全に切り離して Example Corporation 1 のシステムを管理する機能できます。

サブスクリプションマニフェストの作成時:

サブスクリプションマニフェストは、インフラストラクチャーに変更があった場合やサブスクリプションを追加する場合に変更でき、Satellite Server にリロードできることに注意してください。マニフェストを削除することはできません。マニフェストを Red Hat カスタマーポータルや Satellite Web UI で削除する場合には、すべてのコンテンツホストの登録解除が行われます。

このセクションでは、Satellite 6 デプロイメントシナリオを指定するのに役立つ一般的な考慮事項について説明します。デプロイメントの最も一般的なシナリオについては、5章共通のデプロイメントシナリオ にその一覧が記載されています。以下はよくある質問です。

サブスクリプションマニフェストは Satellite Server からアクセスできる Red Hat リポジトリーを決定します。Red Hat リポジトリーを有効にすると、関連付けられた Satellite 製品が自動的に作成されます。カスタムソースからコンテンツを配信するには、製品およびリポジトリーを手動で作成する必要があります。Red Hat リポジトリーは、デフォルトでは GPG キーで署名されるため、カスタムリポジトリー用にも GPG キーを作成することが推奨されます。カスタムリポジトリーの設定は、それらが保持するコンテンツのタイプ (RPM パッケージ、Puppet モジュール、Docker イメージ、または OSTree スナップショット) によって異なります。

RPM パッケージのみを含む yum リポジトリーとして設定されるリポジトリーは、同期時間と保存スペースを節約するための新規ダウンロードポリシー設定を利用できます。この設定により、即時、オンデマンド、およびバックグラウンドから選択することができます。オンデマンド設定は、クライアントの要求時にのみパッケージをダウンロードすることでスペースと時間を節約します。バックグラウンド設定は、初期の同期後にダウンロードを完了することで時間を節約します。コンテンツソースのセットアップについての詳細な説明については、Red Hat Satellite Content Management Guide の Importing Red Hat Content セクションを参照してください。

Satellite Server 内のカスタムリポジトリーには、ほとんどの場合、外部ステージングサーバーからのコンテンツが設定されます。これらのサーバーは Satellite インフラストラクチャー外に置かれますが、カスタムコンテンツをより効果的に制御するために (Git などの) リビジョンコントロールシステムを使用することが推奨されます。

Satellite 6 は、コンテンツライフサイクルを詳細に管理するための各種機能を提供します。ライフサイクル環境 は、コンテンツライフサイクルのステージを表し、コンテンツビュー はコンテンツのフィルターされたコンテンツのセットであり、コンテンツの定義済みのサブセットとみなすことができます。コンテンツビューをライフサイクル環境に関連付けると、コンテンツを定義された方法でホストに対して利用可能にできます (プロセスの仮想化については、図1.2「Red Hat Satellite 6 におけるコンテンツのライフサイクル」 を参照)。コンテンツ管理プロセスの詳細の説明については、Red Hat 6 Content Management Guide を参照してください。以下のセクションでは、ライフサイクル環境と共にコンテンツビューをデプロイするための一般的なシナリオについて説明します。

ライブラリー と呼ばれるデフォルトのライフサイクル環境はすべての接続されたソースからコンテンツを収集します。ホストをライブラリーに直接関連付けることは、ホストに利用可能にする前のコンテンツのテストを実行できなくなるために推奨されていません。その代わりに、コンテンツのワークフローに適したライフサイクル環境パスを作成します。よくあるシナリオは以下のようになります。

以下はよくあるコンテンツビューのシナリオです。

最適なソリューションはホスト環境の性質によって異なります。多数のコンテンツビューを作成することは避けますが、コンテンツビューのサイズは関連する操作 (公開、プロモート) の速度に影響を与えることに注意してください。また、コンテンツビューのパッケージのサブセットを作成する際には、すべての依存関係も含まれていることを確認してください。キックスタートリポジトリーは、ホストのプロビジョニングにのみ使用されるのでコンテンツビューに追加できないことに注意してください。

Satellite 6 は、プロビジョニングテンプレート、Puppet を使用した設定管理、ホストロールの標準化されたプロビジョニングのためのホストグループを含む、ホストのプロビジョニングの自動化に役立つ複数の機能を提供します。プロビジョニングのワークフローについては、the Red Hat Satellite 6 Provisioning Guide の Understanding the Provisioning Workflow を参照してください。同じガイドには、各種のコンピュートリソースでのプロビジョニングの方法について記載されています。

ロールをユーザーに割り当てることにより、一連のパーミッションに基づく Satellite 6 コンポーネントへのアクセスを制御できます。ロールベースの認証は、ユーザーにとって不要なオブジェクトをユーザーから非表示にする方法として理解することができます。

組織内の複数の異なるロールを区別する基準は多岐に及びます。管理者ロールのほかにも、一般的に以下のタイプが見られます。

カスタムロールを定義する際に、以下の推奨事項を考慮してください。

ロールを定義し、これらをユーザーに割り当てる方法については、Red Hat Satellite サーバー管理ガイド の説明を参照してください。同ガイドには、外部の認証ソースについての情報が記載されています。

このセクションでは、特定のタスクを自動化したり、Satellite 6 のコアの使用を拡張したりするために使用できる選択された Satellite 機能の短い概要を示します。

統合 Capsule は、インストールプロセス時に Satellite Server でデフォルトで作成される仮想の Capsule Server です。これは、Satellite Server を、単一の地理的な場所の Satellite デプロイメント用の直接接続されたホストのプロビジョニングに使用できることを意味するため、1 つの物理サーバーのみが必要になります。分離した Capsule のベースシステムは Satellite Server で直接管理できますが、このレイアトを使用してリモート拠点にある他のホストを管理することは推奨されません。

Red Hat Satellite が単一の地理的な場所にデプロイされている場合でも、インフラストラクチャーに複数の分離したサブネットが必要になる場合があります。この分離は、たとえば DHCP および DNサービスが設定された複数の Capsule Server をデプロイすることによって実行できますが、単一の Capsule を使用して分離したサブネットを作成することが推奨されます。次にこの Capsule を使用して分離されたネットワークでホストおよびコンピュートリソースを管理し、それらが Capsule にアクセスすればプロビジョニング、設定、エラータ、およびその他の一般的な管理ができるようにします。サブネットの設定についての詳細は、Red Hat Satellite Host Configuration Guide を参照してください。

地理的な拠点ごとに 1 つ以上の Capsule Server を作成することが推奨されます。この方法により、ホストはローカルの Capsule Server からコンテンツを取得するので、帯域幅を節約できます。リモートリポジトリーからのコンテンツの同期は、各拠点の各ホストによってではなく Capsule によってのみ実行されます。さらに、このレイアウトにより、プロビジョニングインフラストラクチャーがより信頼性があり、設定しやすいものになります。このアプローチを示した図については、図1.1「Red Hat Satellite 6 システムアーキテクチャー」 を参照してください。

セキュリティーレベルの高い環境ではインターネットから切断された、閉じられたネットワークでホストを機能させることが必要になりますが、Red Hat Satellite は、システムに対して最新のセキュリティー更新、エラータ、パッケージおよびその他のコンテンツをプロビジョニングできます。この場合、Satellite Server にはインターネットへの直接のアクセスはありませんが、他のインフラストラクチャーコンポーネントのレイアウトは影響を受けません。切断された Satellite のインストールまたはアップグレードを実行する方法についての詳細は、Red Hat Satellite インストールガイド を参照してください。

切断された Satellite Server にコンテンツをインポートする方法として、2 つのオプションがあります。

コンテンツを切断された Satellite Server にインポートするための上記の方法を使用して、接続された Satellite の初期設定を加速することもできます。

外部 DNS、DHCP、または TFTP サービスを使用できるように Capsule Server (統合またはスタンドアロン) を設定できます。これらのサービスを提供するサーバーが環境内にすでに存在する場合は、それを Satellite デプロイメントに簡単に統合できます。外部サービスを使用できるように Capsule を設定する方法についての詳細は、Red Hat Satellite インストールガイド の外部サービスの設定 を参照してください。