1.3. Red Hat Update Infrastructure のコンポーネント

RHUI インストールごとに RHUA がありますが、多くのクラウド環境では、リージョンまたはデータセンターごとに RHUI インストールがあります。たとえば、Amazon の EC2 クラウドは複数のリージョンで設定されています。すべてのリージョンでは、独自の RHUA ノードを持つ個別の RHUI が設定されています。

RHUA では、以下の作業を行うことができます。

RHUI は主に /etc/rhui/rhui-tools.conf と /etc/rhui-installer/answers.yaml の設定ファイルを使用します。

/etc/rhui/rhui-tools.conf 設定ファイルには、RHUA で使用される一般的なオプション (証明書のデフォルトのファイルの場所、Red Hat CDN 同期のデフォルト設定パラメーターなど) が含まれます。通常、このファイルを編集する必要はありません。

Red Hat Update Infrastructure Management Tool は、ユーザー入力の値に基づいて /etc/rhui-installer/answers.yaml 設定ファイルを生成します。これには、特定のリージョンで RHUA の実行を促進するすべての情報が含まれます。設定例には、パッケージをダウンロードするための RHUA の宛先と、RHUI インストールの CDS ノード (ホスト名) の一覧が含まれます。

RHUA は複数のサービスを使用して、配信を簡単にするためにコンテンツを同期し、整理し、配布します。

以下の考慮事項が該当します。

CDS ノードは、クライアントが更新したコンテンツ用に接続するリポジトリーを提供します。CDS は 1 つしかありません。RHUI はフェイルオーバー機能を備えたロードバランサーを提供するため、複数の CDS ノードを使用することが推奨されます。

エンドユーザーの RHEL システムへの CDS ホストコンテンツシステムの数は必要ありませんが、CDS はラウンドロビン形式の負荷分散方式 (A、B、C、A、B、C) で動作し、エンドユーザーシステムにコンテンツを提供します。CDS は HTTP を使用して、httpd-based yum リポジトリーを介してコンテンツをエンドユーザーシステムにホストします。

設定時に、パッケージが同期される CDS ディレクトリーを指定します。RHUA と同様に、唯一の要件は、CDS にディレクトリーをマウントすることです。必要なデバイスを割り当てる際の最適なアクションが判断されるのは、クラウドプロバイダー次第です。Red Hat Update Infrastructure Management Tool 設定 RPM は、パッケージディレクトリーと Apache 設定をリンクして、パッケージディレクトリーを提供します。

NFS が使用される場合、rhui-installer は RHUA で NFS 共有を設定し、コンテンツと NFS 共有をマウントする CDS のディレクトリーを保存できます。以下の rhui-manager オプションは、この設定を制御します。

これらのデフォルト値が使用される場合、RHUA の /export ディレクトリーと各 CDS の /var/lib/rhui/remote_share ディレクトリーは同じになります。たとえば、yum、docker、および ostree リポジトリーがすでに同期されている場合は、published サブディレクトリーの構造は以下のようになります。

[root@rhua ~]# ls /export/published/
docker  ostree  yum

[root@cds01 ~]# ls /var/lib/rhui/remote_share/published/
docker  ostree  yum

予想される使用法は、各 CDS がパッケージのコピーを保持することです。クラウドプロバイダーは、RHUA がパッケージを書き込んで各 CDS が読み取る共有ストレージ (Gluster Storage など) の形式を使用できます。

各 CDS で行われる唯一の標準以外のロジックは、エンタイトルメント証明書チェックです。このチェックにより、クライアントが yum リポジトリーまたは ostree リポジトリーに対して要求を行うのが、クラウドプロバイダーがこれらのリポジトリーにアクセスする権限を付与するようになります。このチェックでは、以下の条件を確認します。

CA の検証に失敗すると、クライアントには SSL エラーが表示されます。詳細は、/var/log/httpd/ にある CDS の Apache ログを参照してください。

[root@cds01 ~]# ls -1 /var/log/httpd/
access_log
cds.example.com_access_ssl.log
cds.example.com_error_ssl.log
crane_access_ssl.log
crane_error_ssl.log
default_error.log
error_log

複数の CDS が使用される場合は、負荷分散ソリューションを準備して、クライアント HTTPS 要求をすべてのサーバーに分散する必要があります。RHUI には HAProxy が同梱されていますが、インストール時に使用する負荷分散ソリューション (クラウドプロバイダーからのソリューションなど) を選択するのはユーザー次第です。HAProxy が使用されている場合は、挿入するノードの数を決定する必要もあります。詳細は、HAProxy の設定 を参照してください。

クライアントは CDS に直接移動するように設定されていません。リポジトリーファイルは、RHUI ロードバランサーである HAProxy を参照するように設定されます。HAProxy は特に高可用性環境に適した TCP/HTTP リバースプロキシーです。HAProxy は以下の作業を行います。

RHEL 7 では、ロードバランサー技術はベースオペレーティングシステムに含まれています。ロードバランサーは別のノードにインストールする必要があります。

正確な設定は、使用する特定のロードバランサーソフトウェアによって異なります。ロードバランサーの設定方法を理解するには、一般的な HAProxy 設定から取られる以下の設定を参照してください。

[root@rhui3proxy ~]# cat /etc/haproxy/haproxy.cfg
# This file managed by Puppet
global
  chroot  /var/lib/haproxy
  daemon
  group  haproxy
  log  10.13.153.2 local0
  maxconn  4000
  pidfile  /var/run/haproxy.pid
  stats  socket /var/lib/haproxy/stats
  user  haproxy

defaults
  log  global
  maxconn  8000
  option  redispatch
  retries  3
  stats  enable
  timeout  http-request 10s
  timeout  queue 1m
  timeout  connect 10s
  timeout  client 1m
  timeout  server 1m
  timeout  check 10s

listen crane00
  bind 10.13.153.2:5000
  balance roundrobin
  option tcplog
  option ssl-hello-chk
  server cds3-2.usersys.redhat.com cds3-2.usersys.redhat.com:5000 check
  server cds3-1.usersys.redhat.com cds3-1.usersys.redhat.com:5000 check

listen https00
  bind 10.13.153.2:443
  balance roundrobin
  option tcplog
  option ssl-hello-chk
  server cds3-2.usersys.redhat.com cds3-2.usersys.redhat.com:443 check
  server cds3-1.usersys.redhat.com cds3-1.usersys.redhat.com:443 check

グローバル、デフォルト、およびリッスンの設定の詳細は、Red Hat Enterprise Linux 7 ロードバランサーの管理 を参照してください。

クライアントが正常に接続できない場合は、/var/log/httpd/ の下にある CDS の httpd ログを確認して、要求が CDS に到達したことを確認することが重要であることに注意してください。リクエストが CDS に届かない場合は、DNS や一般的なネットワーク接続に問題がある可能性があります。

リポジトリーは、ソフトウェアパッケージ (RPM) のストレージの場所です。RHEL は、yum コマンドを使用して、RPM の検索、ダウンロード、インストール、および設定を行います。RPM には、アプリケーションの実行に必要なすべての依存関係が含まれます。RPM は、リポジトリーのソフトウェアの更新もダウンロードします。

RHEL 7 は、リソース管理用のコントロールグループ (cgroup)、プロセス分離用の名前空間、SELinux によるセキュリティーなどのコアな技術を使用して Linux コンテナーを実装します。これにより、セキュアなマルチテナントが可能になり、セキュリティーの悪用の可能性が低減します。Linux コンテナーは、セキュリティーを強化する一方で、迅速なアプリケーションデプロイメント、単純なテスト、メンテナーンス、およびトラブルシューティングを可能にします。Docker で RHEL 7 を使用すると、スタッフの効率を高め、サードパーティーのアプリケーションを迅速にデプロイし、よりアジャイルな開発環境を有効にし、リソースをより密接に管理できます。

RHEL 7 で Linux コンテナーを使用するには、2 つの一般的なシナリオがあります。ホストコンテナーをアプリケーションサンドボックスのツールとして使用するか、またはイメージベースのコンテナーの拡張機能を使用できます。イメージからコンテナーを起動すると、書き込み可能な階層がこのイメージの上部に追加されます。コンテナーをコミットするたびに (docker commit コマンドを使用)、変更を保存する新しいイメージ層が追加されます。

RHUI に関連するコンテンツは、RHUA ノードおよび CDS ノードで使用する Red Hat CDN からダウンロードしたソフトウェア (RPM など) です。RPM は、特定のアプリケーションおよびツールの実行に必要なファイルを提供します。クライアントには、rpm パッケージが提供する SSL コンテンツ証明書と鍵のセットによるアクセスが付与されます。これは、生成された yum リポジトリーファイルのセットも提供します。

詳細は、What Channels Can Be Delivered at Red Hat's Certified Cloud & Service Provider (CCSP) Partners? を参照してください。