第7章 デプロイメントに関する考慮事項

本セクションでは、Red Hat Satellite 6 デプロイメントの計画時に検討される一般的なトピックの概要と推奨事項を説明し、より具体的なドキュメントを紹介します。たとえば、お客様のシナリオ例 (Satellite 6.1 に特化) に基づいた実装は、Red Hat ナレッジベースソリューションの 「10 Steps to Build an SOE: How Red Hat Satellite 6 Supports Setting up a Standard Operating Environment」 を参照してください。

7.1. Satellite Server の設定

作業用の Satellite インフラストラクチャーに対する最初のステップとして、『インストールガイド』に従って Red Hat Satellite Server のインスタンスを専用 Red Hat Enterprise Linux 7 サーバーにインストールします。ここで説明されている「インストールのための環境準備」および「大規模デプロイメントに関する考慮事項」について検討してください。

Satellite サブスクリプションマニフェストの Satellite Server への追加

サブスクリプションマニフェストは、サブスクリプション情報が含まれる暗号化されたファイルのセットです。Satellite Server はこの情報を使用して CDN にアクセスし、関連付けられたサブスクリプションで利用可能なリポジトリーを検索できます。サブスクリプションマニフェストを作成し、インポートする方法は、『コンテンツ管理ガイド』「サブスクリプションの管理」を参照してください。

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

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

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

以下の図は、複数のシステムを同じ 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

Satellite Server with Multiple Manifests 441823 0317 ECE

サブスクリプションマニフェストの作成時に、以下が行われます。

  • 切断された Satellite Server または自己登録 Satellite Server を計画する場合は、Satellite Server のサブスクリプションをマニフェストに追加します。これは、ベースシステムで Red Hat Subscription Manager ユーティリティーを使用してサブスクライブしている、接続済みの Satellite Server には不要です。
  • 作成する必要があるすべての Capsule Server にサブスクリプションを追加します。
  • Satellite で管理する必要がある全 Red Hat 製品にサブスクリプションを追加します。
  • サブスクリプションの有効期限が切れる日に注意し、有効期限が切れる前に更新するように計画します。
  • 1 つの組織につきマニフェストを 1 つ作成します。マニフェストは複数使用することができ、複数の Red Hat サブスクリプションからマニフェストを選択することもできます。

Red Hat Satellite 6.3 には、マニフェストに将来の日付が指定されたサブスクリプションを使用する機能が追加されました。これにより、既存のサブスクリプションの有効期限の前に、将来の日付が指定されたサブスクリプションがマニフェストに追加されても、リポジトリーへのアクセスが妨げられることはありません。

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

7.2. ロケーションおよびトポロジー

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

  • 必要な Capsule Server の数は?: 組織が機能する地理的な場所の数が Capsule Server の数であると考えることができます。Capsule を各ロケーションに割り当てることで、Satellite Server の負荷が軽減されると同時に、冗長性が強化され、帯域幅の使用量が減少します。Satellite Server 自体も Capsule として機能できます (これにはデフォルトで統合 Capsule が含まれます)。これは 1 つのロケーションのデプロイメントで使用でき、Capsule Server のベースシステムをプロビジョニングするのに使用できます。統合 Capsule を使用してリモートロケーションのホストと通信することは、ネットワークの使用が最適化されない可能性があるため推奨されません。
  • Capsule Server が提供するサービスは?: Capsule の数を設定したら、各 Capsule で有効にするサービスを決定します。コンテンツおよび設定管理機能のスタック全体が利用可能な場合でも、一部のインフラストラクチャーサービス (DNS、DHCP、TFTP) は Satellite 管理者の管理対象外である場合があります。その場合は、Capsule を外部サービスと統合する必要があります(「Capsule と外部サービス」 を参照)。
  • Satellite Server をインターネットから切断している必要があるか?: 切断された Satellite は一般的なデプロイメントシナリオで使用されます (「インターネットから切断された Satellite」 を参照)。切断された Satellite で Red Hat コンテンツの更新が頻繁に必要な場合には、Satellite 間の同期を図るための追加の Satellite インスタンスについて計画してください。
  • ホストに必要なコンピュートリソースは?: ベアメタルホストのプロビジョニングのほかに、Satellite 6 でサポートされる各種のコンピュートリソースを使用できます。コンピュートリソースが異なる場合のプロビジョニングの詳細は、『プロビジョニングガイド 』を参照してください。

7.3. コンテンツソース

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

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

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

7.4. コンテンツのライフサイクル

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

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

  • 単一ライフサイクル環境: ライブラリーのコンテンツは、本番ステージに直接プロモートされます。このアプローチでは、複雑さの面で制限がありますが、ホストで利用可能にする前に、ライブラリー内でコンテンツをテストできます。

    A single life cycle environment

  • 単一ライフサイクル環境パス: オペレーティングシステムとアプリケーションコンテンツは共に同じパスでプロモートされます。そのパスは複数のステージ (たとえば、Development (開発)QA (品質保証)Production (本番)) で構成されており、詳細なテストを可能にしますが、これには追加の作業が必要です。

    A single life cycle environment path

  • アプリケーション固有のライフサイクル環境パス: 各アプリケーションには異なるパスがあるため、アプリケーション別のリリースサイクルが可能になります。特定のコンピュートリソースをアプリケーションライフサイクルのステージに関連付けて、テストを容易にすることができます。しかしながら、このシナリオではメンテナンスが複雑になります。

    Application specific life cycle environment paths

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

  • オールインワンコンテンツビュー: 大半のホストに必要なすべてのコンテンツが含まれるコンテンツビューです。コンテンツビューの数を減らすことは、リソース (時間、保存スペース) に制限のあるデプロイメントや、ホストタイプが同一のデプロイメントの場合に利点があります。ただし、このシナリオでは、時間ベースのスナップショットやインテリジェントなフィルタリングなどのコンテンツビューの各種機能が制限されます。コンテンツソースを変更すると、一部のホストに影響を及ぼします。
  • ホスト固有のコンテンツビュー: 各ホストタイプの専用コンテンツビューです。このアプローチは、ホストタイプの数が少ない (最高 30) デプロイメントで役立ちます。ただし、この場合はホストタイプ間のコンテンツの共有や、ホストタイプ以外の基準に基づく分離 (オペレーティングシステムとアプリケーション間など) を防ぎます。重要な更新があった場合は、すべてのコンテンツビューを更新する必要があり、これによりメンテナンスの作業が増加します。
  • ホスト固有の複合コンテンツビュー: 各ホストタイプ専用のコンテンツビューの組み合わせです。このアプローチにより、ホスト固有のコンテンツと共有コンテンツの分離が可能になります。たとえば、Puppet 設定の専用のコンテンツビューを設定することができます。このコンテンツビューを複数のホストタイプの複合コンテンツビューに組み込むと、他のホストコンテンツよりも高い頻度で Puppet 設定を更新できます。
  • コンポーネントベースのコンテンツビュー: 特定のアプリケーションの専用コンテンツビューです。たとえば、データベースコンテンツビューはいくつかの複合コンテンツビューに組み込むことができます。このアプローチにより標準化のレベルが上がりますが、コンテンツビューの数が増えることにもなります。

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

7.5. コンテンツのデプロイメント

コンテンツのデプロイメントは、コンテンツホストにおけるエラータおよびパッケージの管理です。Satellite でコンテンツをデプロイする方法は 2 つあります。1 つ目は、デフォルトの方法である Goferd サービスエージェント です。2 つ目は、Satellite 6.2.11 以降で利用可能な置換で、リモート実行 を介した管理となります。

  • Goferd サービスエージェント: このサービスは Satellite サーバーとやり取りし、パッケージのインストール、更新、レポート作成時の主なタスクとなり、Katello-agent RPM パッケージのインストールに成功すると、コンテンツホストで自動的に起動します。
  • リモート実行: SSH トランスポートを介したリモート実行では、パッケージのインストール、更新、または削除、そして設定管理エージェントのブートストラップと、Puppet 実行のトリガーが可能になります。Satellite Server サーバでは、リモート実行がデフォルトで有効ですが、Capsule Server とコンテンツホストのデフォルトでは無効になっているため、手動で有効にする必要があります。
  • コンテンツのデプロイメント方法を検討する: リモート実行を使用すると、Goferd サービスを無効にして、コンテンツホストのメモリーと CPU 負荷を減らすことができます。ただし、リモート実行を全コンテンツホストで手動で設定しないと、Goferd を置き換えることができません。この設定プロセスは、デプロイしたコンテンツホストの数が多いシステムでは大掛かりとなります。詳細は『ホストの管理』「Goferd を使用せずにホスト管理の設定」を参照してください。

7.6. プロビジョニング

Satellite 6 は、プロビジョニングテンプレート、Puppet を使用した設定管理、ホストロールの標準化されたプロビジョニングのためのホストグループなど、ホストのプロビジョニングの自動化に役立つ機能を提供します。プロビジョニングのワークフローの詳細は『プロビジョニングガイド 』「プロビジョニングワークフローの概要」を参照してください。このガイドには、各種のコンピュートリソースでのプロビジョニング方法が記載されています。

7.7. ロールベースの認証

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

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

  • アプリケーションまたはインフラストラクチャーの一部に関連するロール: たとえば、オペレーティングシステムとなる Red Hat Enterprise Linux の所有者と、アプリケーションサーバーおよびデータベースサーバーの所有者を比較できます。
  • ソフトウェアライフサイクルの特定のステージに関連するロール: たとえば、開発、テスト、および本番のフェーズで区分されたロールで、各フェーズに 1 人以上の所有者が設定されるケース。
  • 特定のタスクに関連するロール: セキュリティーマネージャー、ライセンスマネージャー、または Access Insights 管理者など。

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

  • 予想されるタスクおよび責任を定義する: 所定のロールからアクセスできる Satellite インフラストラクチャーのサブセットと、このサブセットで許可されるアクションを定義します。ロールの責任について、また他のロールとの違いについて検討します。
  • 事前に定義されたロールを使用する (可能な場合): Satellite 6 は、単独またはロールの組み合わせの一部として使用できる数多くのサンプルロールを提供します。既存のロールをコピーおよび編集して、カスタムロールの作成を開始すると良いでしょう。
  • 影響を受けるすべてのエンティティーを考慮に入れる: たとえば、コンテンツビューのプロモートにより、特定のライフサイクル環境およびコンテンツビューの組み合わせに対する新規の Puppet 環境が自動的に作成されます。そのため、あるロールがコンテンツビューをプロモートすることが予想される場合に、Puppet 環境を作成し、編集するパーミッションも必要になります。
  • 関連分野を考慮に入れる: ロールの責任範囲が限定されている場合でも、関連する分野は広範囲に及ぶ場合があります。そのため、ロールに読み取り専用アクセスを付与する際に、ロールの責任範囲に影響を与える Satellite インフラストラクチャー部分のみに限定できます。これにより、ユーザーは今後の変更の可能性に関する情報を早期に取得することができます。
  • パーミッションを段階的に追加する: カスタムロールが予定通りに機能することを確認するためにテストします。問題が生じた場合には、限定されたパーミッションセットでこれを開始し、パーミッションを段階的に追加して継続的にテストするのが効果的な方法です。

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

7.8. 追加のタスク

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

  • 既存ホストのインポート: Satellite 6 で管理していなかった既存のホストがある場合は、そのホストを Satellite Server にインポートできます。通常、この手順には Red Hat Satellite 5 からの移行で 1 つのステップが必要になります。詳細は『移行ガイド』を参照してください。 移行プロセスの概要については、Red Hat ナレッジベースソリューション「Red Hat Satellite 5 から Satellite 6 への移行」を参照してください。
  • ベアメタルホストの検出: Satellite 6 検出プラグインは、プロビジョニングネットワーク上にある不明なホストのベアメタルを自動的に検出できます。これらの新規ホストは、シリアル ID、ネットワークインターフェース、メモリー、ディスク情報など、Facter が収集するクライアントアップロードシステムのファクトに基づいて、Satellite Server および Puppet エージェントに自己登録します。登録後は、それらの検出されたホストのプロビジョニングを初期化できます。詳細は『ホストの管理』「Satellite でのベアメタルホストの検出」を参照してください。
  • バックアップ管理: Satellite Server のバックアップおよび障害回復の手順を参照してください (『Red Hat Satellite の管理』「Satellite Server および Capsule Server のバックアップと復元」を参照)。リモート実行を利用すると、管理対象ホストで繰り返されるバックアップタスクを設定することもできます。リモート実行の詳細は『ホストの管理』「ホストでのリモートジョブの実行」を参照してください。
  • セキュリティー管理: Satellite 6 は、セキュリティー管理を様々な方法でサポートします。たとえば、更新およびエラータ管理、システム検証のための OpenSCA 統合、更新およびセキュリティーコンプライアンスのレポート作成、詳細なロールベースの認証が挙げられます。エラータ管理および OpenSCAP 概念の詳細は『ホストの管理』を参照してください。
  • インシデント管理: Satellite 6 は、レポート作成やメール通知など、全システムの一元化された概要を提供することで、インシデント管理プロセスをサポートします。最近の変更を示すイベント履歴をはじめ、各ホストの詳細情報は、Satellite Server からアクセスできます。また、Satellite 6 は Red Hat Insights と統合されています。
  • Hammer および API を使用したスクリプト: Satellite 6 は、大半の Web UI の手順と同等の CLI を提供する Hammer というコマンドラインツールを提供します。さらに、Satellite API へのアクセスを使用して、選択したプログラミング言語で自動化スクリプトを作成できます。詳細は『Hammer CLI ガイド』 および 『API ガイド』を参照してください。