概要、概念、デプロイメントに関する考慮事項

Red Hat Satellite のコンテンツフローには、外部ソースからホストへのコンテンツの管理と配布が含まれます。

Satellite のコンテンツは、外部コンテンツソース から Satellite Server に流れます。Capsule Server は、Satellite Server のコンテンツを ホスト にミラーリングします。

コンテンツビューは、ホストがアクセスできるコンテンツの意図的にキュレーションされたサブセットです。コンテンツビューを作成することで、特定の環境または Capsule Server で使用されるソフトウェアバージョンを定義できます。

各コンテンツビューは、各環境にわたってリポジトリーのセットを作成します。これらのリポジトリーは、Satellite Server によって保存および管理されます。たとえば、次の方法でコンテンツビューを作成できます。

Red Hat Satellite を使用すると、さまざまなコンテンツタイプをインポートして管理できます。

たとえば、Satellite は次のコンテンツタイプをサポートしています。

Satellite の Simple Content Access (SCA) により、ソフトウェアエンタイトルメントの管理が簡素化されます。SCA を使用すると、有効なサブスクリプションをサブスクリプション割り当てまたはマニフェストに追加し、Satellite 内で更新できます。したがって、SCA を有効にすると、ホストにサブスクリプションを個別にアタッチする必要がなくなります。

Red Hat Satellite を使用すると、複数の方法を使用してホストをプロビジョニングできます。

Satellite Server は、コンテンツのライフサイクルを計画および管理する Satellite デプロイメントの中心となるコンポーネントです。

一般的な Satellite デプロイメントには、次の操作を実行する 1 つの Satellite Server が含まれます。

Satellite Server は、コンテンツ配信、ホストのプロビジョニング、Capsule Server への通信を移譲します。Satellite Server 自体にも Capsule が含まれています。

Satellite Server には、きめ細かい認証システムも含まれています。Satellite ユーザーに、担当するインフラストラクチャーの部分のみにアクセスするための権限を付与できます。

Satellite Server では、コンテンツ、ホスト、および設定を整理するために、複数の 組織 と ロケーション を定義できます。

Capsule Server を使用すると、Satellite デプロイメントの範囲とスケーラビリティーを拡張できます。Capsule Server は、Red Hat Satellite デプロイメントで次の機能を提供します。

コンテンツビューを使用すると、Capsule Server でホストが利用できるコンテンツの正確なサブセットを指定できます。詳細は、1章Red Hat Satellite によるコンテンツとパッチの管理 を参照してください。

ホストは、Red Hat Satellite が管理する Linux クライアントを指します。ホストは物理サーバーでも仮想サーバーでもかまいません。

仮想ホストは、Amazon EC2、Google Compute Engine、KVM、libvirt、Microsoft Azure、OpenStack、Red Hat Virtualization、Rackspace Cloud Services、VMware vSphere など、Red Hat Satellite でサポートされている任意のプラットフォームにデプロイできます。

Satellite を使用すると、監視、プロビジョニング、リモート実行、設定管理、ソフトウェア管理、サブスクリプション管理など、大規模なホスト管理が可能になります。

Satellite は、次のような相互に統合された複数のオープンソースプロジェクトで構成されています。

Capsule Server はローカルホスト管理サービスを提供し、Satellite Server からのコンテンツをミラーリングできます。

Satellite Server からのコンテンツをミラーリングするために、Capsule は次の機能を提供します。

Capsule を使用して、インフラストラクチャーとホスト管理用の次のサービスを実行できます。

Capsule で一部の機能のみを有効にすることで、Capsule Server を特定の限定された目的のために設定できます。一般的な設定は次のとおりです。

Satellite Server と Capsule Server に登録されたホスト間の通信は、その Capsule Server を介してルーティングされます。Capsule Server はホストに Satellite サービスも提供します。

Capsule Server が管理するサービスの多くは、専用のネットワークポートを使用します。ただし、Capsule Server は、ホストから Satellite Server へのすべての通信が単一のソース IP アドレスを使用するようにし、ファイアウォールの管理を簡素化します。

図4.1 ホストが Capsule に接続した際に Satellite コンポーネントが相互作用する方法

図4.2 ホストが Satellite Server に直接接続する際に Satellite コンポーネントが相互作用する方法

Satellite Web UI を使用して、ブラウザーから Satellite インフラストラクチャーを管理および監視できます。たとえば、Satellite Web UI では次のナビゲーション機能を使用できます。

Hammer を使用して CLI コマンドで Satellite Server を設定および管理できます。

Hammer を使用すると、次のような利点があります。

Hammer コマンドを発行するには、ユーザーが Satellite Server にアクセスできる必要があります。

バックグラウンドで、各 Hammer コマンドは最初に API へのバインドを確立し、要求を送信します。この動作は、大量の Hammer コマンドを順に実行する場合に、パフォーマンスに影響を与える可能性があります。対照的に、API コマンドを使用するスクリプトは Satellite API と直接通信し、バインドを 1 回だけ確立します。

Satellite Server が提供する Representational State Transfer (REST) API を使用して、HTTP 経由で Satellite API にアクセスするカスタムスクリプトや外部アプリケーションを作成できます。REST API を使用して、企業の IT システムやサードパーティーのアプリケーションと統合し、自動メンテナンスやエラーチェックタスクを実行して、スクリプトを使用して反復タスクを自動化します。

REST API を使用すると、次のような利点があります。

API コマンドに基づくスクリプトは Satellite API と直接通信するため、redhat.satellite 内のモジュールに依存する Hammer コマンドや Ansible Playbook に基づくスクリプトよりも高速になります。

リモート実行を使用すると、シェルスクリプトまたは Ansible タスクと Playbook を使用して、Capsule からホスト上でジョブをリモート実行できます。

Satellite でリモート実行を使用すると、次の利点が得られます。

リモート実行の通信は Capsule Server を介して行われます。そのため、Satellite Server はターゲットホストに直接アクセスする必要がなく、多数のホストを管理するように拡張できます。

リモート実行を使用するには、ジョブテンプレートを定義する必要があります。ジョブテンプレートは、リモートホストに適用するコマンドです。ジョブテンプレートは複数回実行できます。

Satellite は、ERB 構文ジョブテンプレートを使用します。詳細は、ホストの管理 の テンプレート作成リファレンス を参照してください。

Satellite にはデフォルトでシェルスクリプトと Ansible のジョブテンプレートがいくつか含まれています。詳細は、ホストの管理 の ジョブテンプレートのセットアップ を参照してください。

Satellite Ansible コレクションは、Satellite API と対話する Ansible モジュールのセットです。Satellite Ansible コレクションを使用すると、Satellite のさまざまな側面を管理および自動化できます。

インストールに必要なすべての情報を含むキックスタートファイルを作成することにより、Satellite Server または Capsule Server のインストールプロセスを自動化できます。

Red Hat Satellite Kickstart スクリプトを実行すると、スクリプトは次のアクションを実行します。

すべての Red Hat Satellite コンポーネントの使用は、以下に説明するように、Red Hat Satellite のコンテキスト内でのみサポートされます。

Satellite でホストを登録および管理するには、次の Red Hat Enterprise Linux のメジャーバージョンとハードウェアアーキテクチャーの組み合わせを使用できます。この組み合わせには、Red Hat Satellite Client 6 リポジトリーも利用できます。

Satellite を使用したホストのプロビジョニングには、次の Red Hat Enterprise Linux のメジャーバージョンとハードウェアアーキテクチャーの組み合わせを使用できます。

Satellite による設定管理には、次の Red Hat Enterprise Linux のメジャーバージョンとハードウェアアーキテクチャーの組み合わせを使用できます。

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

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

地理的な拠点ごとに 1 つ以上の Capsule Server を作成することが推奨されます。これにより、ホストはローカルの Capsule Server からコンテンツを取得するため、帯域幅を節約できます。リモートリポジトリーとのコンテンツの同期は、各拠点の各ホストではなく、Capsule によってのみ実行されます。さらに、このレイアウトにより、プロビジョニングインフラストラクチャーの信頼性があがり、設定が容易になります。

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

切断された Satellite Server にコンテンツをインポートする方法は 2 つあります。

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

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

作業用の Satellite インフラストラクチャーに対する最初のステップとして、Satellite Server のインスタンスを専用の Red Hat Enterprise Linux 8 Server にインストールします。

Red Hat Satellite では、Satellite に設定した各組織に対して、マニフェストが 1 つ必要になります。Satellite の組織機能を使用して、1 つの Red Hat Network アカウントで、インフラストラクチャーを分けて管理する予定がある場合は、必要に応じて 1 つのアカウントが所有するサブスクリプションを、各組織のマニフェストに割り当てます。

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

システムの管理が必要であるにもかかわらず、RPM のサブスクリプションにアクセスできない場合は、Red Hat Enterprise Linux Satellite アドオンを使用する必要があります。詳細は、Satellite アドオン を参照してください。

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

図8.1 複数のマニフェストを含む Satellite Server

Red Hat Subscription Manifest を作成する場合:

Red Hat Satellite では、未来の日付が指定されたサブスクリプションをマニフェストで使用することができます。これにより、既存のサブスクリプションの有効期限の前に、未来の日付が指定されたサブスクリプションがマニフェストに追加され、継続的にリポジトリーへアクセスすることができます。

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

Satellite のインストール時に、satellite-installer コマンドで Satellite のインストール先の同じサーバーにデータベースを作成します。要件によっては、外部データベースに移行することで、Satellite の作業メモリーが増え、データベースの操作要求への対応時間が短縮される可能性があります。また、外部データベースに移行することで、負荷を分散し、パフォーマンスチューニングの容量を増やすことができます。

以下のシナリオで Satellite のデプロイメントを使用する予定の場合は、外部データベースの使用をご検討ください。

外部データベースの使用に関する詳細は、オンラインネットワーク環境での Satellite Server のインストール の Satellite での外部データベースの使用 を参照してください。

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

Red Hat Subscription Manifest は、Satellite Server からアクセスできる Red Hat リポジトリーを決定します。Red Hat リポジトリーを有効にすると、関連付けられた Satellite 製品が自動的に作成されます。カスタムソースからコンテンツを配信するには、製品およびリポジトリーを手動で作成する必要があります。Red Hat リポジトリーは、デフォルトでは GPG キーで署名されるため、カスタムリポジトリー用にも GPG キーを作成することが推奨されます。

RPM パッケージのみを含む Yum リポジトリーは、同期時間とストレージ容量を削減する オンデマンド ダウンロードポリシーをサポートします。オンデマンド ダウンロードポリシーは、ホストから要求された場合にのみパッケージをダウンロードすることで、スペースと時間を節約します。コンテンツソースのセットアップに関する詳細な手順については、コンテンツの管理 の コンテンツのインポート を参照してください。

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

Satellite には、コンテンツライフサイクルを詳細に管理する各種機能が含まれています。ライフサイクル環境 は、コンテンツライフサイクルのステージを表し、コンテンツビュー は、フィルター機能があるコンテンツセットであり、コンテンツの定義済みのサブセットとみなすことができます。コンテンツビューをライフサイクル環境に関連付けることにより、定義された方法でホストがコンテンツを利用できるようにします。

コンテンツ管理プロセスの詳細な概要は、コンテンツの管理 の カスタムコンテンツのインポート を参照してください。以下のセクションでは、ライフサイクル環境と共にコンテンツビューをデプロイする一般的なシナリオを説明します。

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

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

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

コンテンツデプロイメントは、コンテンツホスト上のエラータとパッケージを管理します。Satellite は、MQTT/HTTPS (プルベース) または SSH (プッシュベース) 経由で、リモート実行を実行するように設定できます。リモート実行は Satellite Server でデフォルトで有効になっていますが、Capsule Server およびコンテンツホストでは無効になっています。これは手動で有効にする必要があります。

Satellite には、プロビジョニングテンプレート、Puppet を使用した設定管理、ホストロールを標準化してプロビジョニングするホストグループなど、ホストプロビジョニングの自動化を容易にする機能が複数含まれています。プロビジョニングワークフローに関する詳細は、ホストのプロビジョニング の プロビジョニングワークフロー を参照してください。このガイドには、各種のコンピュートリソースでのプロビジョニング方法が記載されています。

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

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

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

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

このセクションでは、特定のタスクを自動化したり、Satellite のコアの使用率を拡張したりするために使用できる Satellite 機能の一部を簡単に概説します。

組織は、所有者、目的、コンテンツ、セキュリティーレベルなどの区分に基づいて Red Hat Satellite リソースを論理グループに分割します。Red Hat Satellite では複数の組織を作成して管理し、サブスクリプションを分けて各組織に割り当てることができます。これにより、1 つの管理システムで複数の個別の組織のコンテンツを管理できるようになります。

ロケーションは、地理的なロケーションに基づいて組織を論理グループに分割します。各ロケーションは、1 つのアカウントで作成および使用されますが、1 つのアカウントで管理できるロケーションと組織の数は複数になります。

アプリケーションライフサイクルは、アプリケーションライフサイクルの各ステージを表す ライフサイクル環境 に分割されます。ライフサイクル環境はリンクされて 環境パス を形成します。コンテンツは、必要に応じて環境パスの次のライフサイクル環境にプロモートできます。たとえば、アプリケーションのあるバージョンの開発が終了したら、そのバージョンをテスト環境にプロモートし、次のバージョンの開発を開始できます。

図9.2 4 つの環境を含む環境パス

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

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

フラット構造

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

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

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

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

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

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

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

PXE (preboot execution environment) は、ネットワーク上でシステムを起動することができます。PXE は、ローカルハードディスクまたは CD-ROM を使用する代わりに、DHCP を使用してネットワークに関する一般情報をホストに提供し、TFTP サーバーを検出し、ブートイメージをダウンロードします。PXE サーバー設定の詳細は、Red Hat ナレッジベースのソリューション How to set-up/configure a PXE Server を参照してください。

HTTP ブートを使用して、HTTP を使用するネットワーク経由でシステムをブートできます。