クラウドベースの自動登録
背景情報:
Red Hat は、パブリッククラウドの RHEL エクスペリエンスを向上させる 取り組みの一環として、フリート/アカウント全体を対象とした RHEL の接続方法を開発しました。
Red Hat は特にお客様のクラウドオンボーディングエクスペリエンスを全面的に見直すことを検討していました。これまでは、以前に購入したサブスクリプションを使用してパブリッククラウドで RHEL を使用するお客様には、次のことをお願いしていました。
- https://access.redhat.com/management/cloud にアクセスし、ワークロードをデプロイするクラウドプロバイダーを選択する。
- そのパブリッククラウド上で使用するエンタイトルメントの数を Red Hat に通知する。
- ワークロードのデプロイと廃止に応じて、この数を最新の状態に維持する。
これにより、お客様はゴールドイメージにアクセスできるようになり (該当する場合)、使用量を管理できるようになります (ゴールドイメージを使用した場合、RHEL の使用量に対する時間単位の料金ではなく、インフラストラクチャーのコストのみクラウドプロバイダーによって請求されます)。しかし、このワークフローにはいくつかの問題点がありました。
- エンタイトルメントの数を適切に最新の状態に保つことは困難です。また、この数は最終的にはお客様向けレポートで使用されませんでした。
- そのため、この数はゴールドイメージの有効化以外には、ほとんど役立ちませんでした (有効化は製品ラインごと、クラウドアカウントごとに 1 回だけ行う必要があります)。
- エンタイトルメント数を報告するようお客様に求めることは、当社が他の場所で提供しているサブスクリプションエクスペリエンスと矛盾します (システムへのサブスクリプション割り当てが不要である場合は、Simple Content Access を参照してください。その場合、お客様はアカウントレベルでサブスクリプションを割り当てる必要もありません)。
- このレポートの正確性は業務ワークフローにまったく影響を与えなかったため、このレポートの正確性は疑わしいものでした。当社はこの数に基づいてサポートを拒否したことも、コンテンツへのアクセスをブロックしたこともありません。
- このワークフローは、"サブスクリプション管理のためだけにお客様に業務負荷を与えない" というサブスクリプションエクスペリエンスの基本原則に反しています。
その一方で、対処すべき重要な問題があります。特に、パブリッククラウドにワークロードをデプロイしているお客様には、Red Hat ソフトウェアの使用状況を追跡し、予想を超えるデプロイを回避するための方法が必要です。"お客様自身でお調べください" と言うこともできますが、これは次の基本原則に反します。
"In all cases, avoid the temptation to fall back upon “this is the customer’s burden to report.”`.
そこで、より良い解決策をご用意しました。
Subscription Watch というレポートツールを使用することです。
パブリッククラウドでのコンテンツデリバリー
Red Hat は、パブリッククラウドで RHEL をご利用のお客様が、支払い方法に関係なく、すぐに確実にコンテンツにアクセスできるようにするべきだと考えています (we need yum to 'just work'™ を参照)。
この機能は Red Hat Update Infrastructure (RHUI) によって提供されます。
RHUI は、可用性の高いクラウド内更新を実現するために、当社がクラウドプロバイダーに提供している Pulp プロジェクトベースの製品です。通常、クラウドプロバイダーは RHUI インフラストラクチャーを実行してこのコンテンツを提供します。
RHUI へのアクセスは、クラウドイメージに組み込まれた特別な RPM を介して提供されます。この RPM には、yum リポジトリー定義と、当該クラウドの RHUI インフラストラクチャーへのアクセスを許可する証明書が含まれています。この RPM は、Red Hat アカウントをお持ちであるかどうかに関係なく、ワークロードを立ち上げると得られるものです。RHEL システムを立ち上げて、最も一般的な RHEL バージョンをインストールするだけなら、それがあれば十分です。
注記: 一部のゴールドイメージには、これまで RHUI へのアクセスが組み込まれていませんでした。Red Hat はゴールドイメージを改良し、RHUI へのアクセスを組み込みました。
このコンテンツデリバリーモデルは、このエクスペリエンスの他の部分の基盤を成すものです。そのため、これを標準化して一貫性を確保することは、サブスクリプションエクスペリエンスを簡略化するうえで重要なだけでなく、今後の設計上の決定をお客様にご理解いただくうえでも有益です。
クラウドインスタンスを Red Hat に接続するために、すべてのインスタンスに対して subscription-manager を実行するようお願いすることも考えられます。しかし、それをユーザーに要求するのは、"サブスクリプション管理のためだけにお客様に業務負荷を与えない" という前述の基本原則に反します。仮にそうした結果、矛盾していると非難を受けたとしても、受け入れるほかはないでしょう。
また、次の基本原則に従って、これを自動化する必要もあります。
"Work required for customers to support their subscriptions should be minimal and automated to the greatest possible extent. Subscription management is a distraction for customers and adds real, measurable overhead to the cost of Red Hat software. Manual workflows should be avoided"
以上が理論的な説明です。続いて実際の仕組みについて説明します。
自動登録
自動登録は次の 3 つの主な要素で構成されます。
- 自動登録プロセスの実行方法を把握している (およびそのように明示的に設定されている)、特定のバージョンの subscription-manager パッケージ
- Red Hat アカウントとクラウドプロバイダーアカウントのマッピングを維持する、Red Hat がホストするサービス
- ユーザーが自分の Red Hat アカウントを自分のクラウドプロバイダーアカウントに関連付けることを可能にするインターフェイス
ユーザーは "この Red Hat アカウントとこのクラウドプロバイダーアカウントの両方を所有している" ことを示し、"両方とも所有しているので、それらを 1 つに接続したい" と指示することができます。
では、自動登録の仕組みを最初から最後まで見ていきます。
まず、console.redhat.com に移動し、Sources を開きます。ここで、外部エンティティーを Red Hat アカウントにリンクします。プロバイダーとして Amazon Web Services (AWS) を選択します。Azure や Google の場合もワークフローは同様です。
次に、ソースに名前を付けます。
次に、アカウントの認証をどのように設定するかを選択します。2 つの異なるモデルがあります。
- Account Authorization - Red Hat に root 権限を与ます。Red Hat が必要な設定を行います。
- Manual Authorization - お客様が認証情報を設定し、Red Hat に提供します。
この例では、Manual Authorization を使用します。
次に、設定するアプリケーション (Cost Management と RHEL Management のどちらか) を選択する必要があります。ここで必要なのは、RHEL Management アプリケーションです。また、以下のものを すべて 追加します。
- Gold Images - このゴールドイメージにより、RHEL の時間単位の追加料金が発生することはありません。
- High precision subscription watch data - ユーザーが AWS で詳細な計測機能を設定できるようにします。Subscription Watch のドキュメントから抜粋: "現在、サブスクリプションサービスには、複数のクラウドプロバイダーの RHEL ベースのインスタンスを識別する機能があります。しかし、個々のインスタンスは (場合によっては 1 日に複数回 *) 起動および停止するため、そのアクティビティーを識別して追跡することはできません。パブリッククラウドのメータリングツールは、この機能を AWS インスタンスに提供します。これにより、サブスクリプションサービスによる個々のインスタンスの使用状況をより正確に監視できるようになります。"
- Autoregistration - ユーザーの Red Hat アカウント (サインインにより Red Hat に認識されているもの) とそのユーザーのクラウドプロバイダーアカウント (このワークフローで Red Hat に提供するもの) との間のマッピングを設定し、subscription-manager がチェックインしたときにユーザーのアカウントに登録できるようにします。
最後に、Amazon リソース名 (ARN) を入力します。他のクラウドの場合は ARN と同等の情報を入力します。この一意の認証トークンにより、ユーザーはアカウントを所有していることを証明できるようになり、さらに Red Hat がそのことを検証できるようになります。適切なマルチテナンシーを実現する必要があるため、これは重要です。
最後に、選択内容を確認してから確定します。
これを実行すると、以下のような結果になります。
- 前述のゴールドイメージにアクセスできるようになります。ゴールドイメージはすぐに Amazon アカウントに表示されます。
- クラウドメータリングが設定されます。これにより、API 経由でユーザーの Amazon アカウントにクエリーを実行し、Red Hat ワークロードを特定してカウントできるようになります。
- アカウントの Subscription Watch が有効になり、インスタンスの経時的な使用状況を表示できるようになります。
- Red Hat アカウントとクラウドプロバイダーアカウント間のマッピングが記録されます。このマッピングは、subscription-manager がシステムの登録を許可するために確認を取るときに使用されます。
これ以降、自動登録を設定したこのクラウドプロバイダーアカウント内のイメージからインスタンス化されるインスタンスが、すべて Red Hat に接続および登録されます。ユーザーによるこれ以上の操作は必要ありません。あとは、インスタンスを立ち上げて自由に使用し、Subscription Watch に表示される Red Hat 製品の使用状況を確認するだけです。
ワークロードを立ち上げて確認してみましょう。
クライアントレベルでの自動登録
AWS ソースを設定したら、コンソールでインスタンスを立ち上げます。ゴールドイメージを使用する場合、RHEL の時間単位の追加料金が適用されないように、"My AMIs" -> "Shared With Me" がオンになっていることを確認します。
自動登録は RHEL 8.3.1 で導入されたため、それより新しいイメージには自動登録が含まれています。RHEL9 ベースのイメージには、RHEL9 の一般提供時に自動登録が追加される予定です。RHEL7 ファミリーについては、この記事の執筆時点で、自動登録のバックポートを進めています。
今回は RHEL 8.5 インスタンスを立ち上げます。その前に、ここでの subscription-manager の役割を概説します。
Red Hat はこれまで subscription-manager を 'エンタイトルメントを割り当てるためのツール' であると認識してきました。確かに、その役割もあります。しかし、その機能の本質は、従来の 'サブスクリプションの割り当て' 用途にではなく、むしろシームレスなカスタマーエクスペリエンスに活用すべき一連の中核機能にあります。これらの中核機能について説明します。
subscription-manager の中核機能は、システムによる以下の操作を可能します。
- Red Hat でアイデンティティーを確立する。(システムを登録する、つまり一意に識別し、ホストと Red Hat の間にデータパイプラインを確立する)
- 情報を収集して送信する。
- ソケットやコアの数などのシステム情報
- "このシステムをどのように使用しているか" などのビジネス情報 (システムの目的)
- お客様の情報
- 次のどちらかの方法により、Satellite または CDN 経由で提供される保護されたコンテンツに対するシステムの認証を設定する。
- エンタイトルメントの割り当て
- Simple Content Access
- Satellite または CDN 経由で提供される保護されたコンテンツ (RPM や RPM-OStree コンテンツなど) をインストールできるように yum/dnf を設定する。
従来、これらの機能はすべて同時に使用されていましたが、一部の機能を使用するのが有効な場合もあります。自動登録はそのような使用例の 1 つです。ここでは、アイデンティティーの確立と情報の送信のために自動登録を使用し、Subscription Watch の使用状況レポートを強化できるようにします。また、このアイデンティティーの確立を再利用して Insights の導入を容易にします。ただし、'コンテンツの管理' には使用しません。(その必要はありません。確認したとおり、RHUI 経由で、インスタンスから最も一般的な RHEL バージョンにアクセスできるためです)。
システムが稼働したら、ログインして subscription-manager config を実行して設定を確認します。
[server]
hostname = [subscription.rhsm.redhat.com]
insecure = [0]
no_proxy = []
port = [443]
prefix = [/subscription]
proxy_hostname = []
proxy_password = []
proxy_port = []
proxy_scheme = [http]
proxy_user = []
server_timeout = [180]
ssl_verify_depth = [3]
[rhsm]
auto_enable_yum_plugins = [1]
baseurl = [https://cdn.redhat.com]
ca_cert_dir = [/etc/rhsm/ca/]
consumercertdir = [/etc/pki/consumer]
entitlementcertdir = [/etc/pki/entitlement]
full_refresh_on_yum = [0]
inotify = [1]
manage_repos = 0
package_profile_on_trans = [0]
pluginconfdir = [/etc/rhsm/pluginconf.d]
plugindir = [/usr/share/rhsm-plugins]
productcertdir = [/etc/pki/product]
repo_ca_cert = /etc/rhsm/ca/redhat-uep.pem
repomd_gpg_url = []
report_package_profile = [1]
[rhsmcertd]
auto_registration = 1
auto_registration_interval = [60]
autoattachinterval = [1440]
certcheckinterval = [240]
disable = [0]
splay = [1]
[logging]
default_log_level = [INFO]
[] - Default value in use
特に注目すべきは、現在 Red Hat のクラウドイメージのデフォルトとなっている次の 4 つの設定です。
- auto_registration = 1 - これは、subscription-manager に自動登録を試行するように指示する設定です。このデフォルト値は 0 です。この値はクラウドイメージの作成時に明示的に設定します。プロバイダーがゴールドイメージを作成するクラウド [Azure、GCP] の場合は、Microsoft や Google に同様の設定を行うよう指示します。
- auto_registration_interval = 60 - この設定では、自動登録が試行される間隔を定義します。自動登録は、この間隔で rhsmcertd サービスの呼び出しごとに 3 回試行されます。たとえば、この値を 60 に設定すると、システムは 60 分間隔で 3 回自動登録を試行します。自動登録が 3 回試行しても失敗した場合、rhsmcertd はサービスが再起動するまでそれ以上登録を試行しません。(注記: Red Hat のクラウドイメージでは、rhsmcertd がブート時に実行されるように設定されているため、インスタンスを再起動するとこのプロセスも再起動します)
- manage_repos = 0 - これは、/etc/yum.repos.d/redhat.repo にある CDN 提供コンテンツを管理しないように subscription-manager に指示する設定です (デフォルトは 1 です。RHSM に直接登録されているシステムや Satellite など、RHUI に接続されていないシステムの場合、そのリポジトリーは subscription-manager によって管理することをお勧めします)。Red Hat は、自動登録が有効な場合にはデフォルトで CDN コンテンツを有効にしないと決定したため、subscription-manager でコンテンツを管理しない設定になっています。RHUI と CDN の両方を使用するハイブリッドアプローチはあまり一般的ではありませんが、必要に応じて後でその設定を変更できます。なお、CDN ベースのリポジトリー (EPEL に必要な Optional/CRB リポジトリーなど) を有効にする場合は、この値を 1 に戻すと、リポジトリーを有効にできます。ただし、これを行うためにエンタイトルメントを割り当てる必要は一切ありません。これは、Simple Content Access が有効になっている場合に当てはまります。注記: 近い将来 (2022 年半ば) に、新しい Red Hat アカウントで SCA をデフォルトで有効にする予定です。
- splay = 1 - この設定は、登録中にランダムなオフセットを適用して、Thundering Herd を防ぎます。これにより負荷が分散され、ほぼ同時に起動した多数のシステムがすべて同時にチェックインすることがなくなります。
さらに、自動登録をサポートするために、rhsmcertd デーモンと subscription-manager yum プラグインが、Red Hat のクラウドイメージで有効になっています。
ログ (/var/log/rhsm/rhsmcertd.log) を細かく確認してみましょう。
tail /var/log/rhsm/rhsmcertd.log
Fri Apr 1 10:42:35 2022 [INFO] Starting rhsmcertd...
Fri Apr 1 10:42:35 2022 [INFO] Auto-registration interval: 60.0 minutes [3600 seconds]
Fri Apr 1 10:42:35 2022 [INFO] Auto-attach interval: 1440.0 minutes [86400 seconds]
Fri Apr 1 10:42:35 2022 [INFO] Cert check interval: 240.0 minutes [14400 seconds]
Fri Apr 1 10:42:35 2022 [INFO] Waiting 2.0 minutes plus 3287 splay seconds [3407 seconds total] before performing first auto-register
Fri Apr 1 10:42:35 2022 [INFO] Waiting 2.0 minutes plus 43071 splay seconds [43191 seconds total] before performing first auto-attach.
Fri Apr 1 10:42:35 2022 [INFO] Waiting 2.0 minutes plus 1723 splay seconds [1843 seconds total] before performing first cert check.
システムが稼働しており、3407 秒 (1 時間弱) 以内に自動登録を試行することがわかります。
Fri Apr 1 11:44:23 2022 [INFO] (Auto-registration) performed successfully.
subscription-manager は、クラウドプロバイダーによってデジタル署名されたインスタンスメタデータドキュメントのコピーを取得します。これには、自動登録にとって重要な、このインスタンスが存在するクラウドプロバイダーアカウントなど、インスタンスに関する多くの情報が含まれています。subscription-manager は、このコピーを信頼サービス (Red Hat アカウントのクラウドプロバイダーアカウントのマッピングを維持する当社のサービス) に提示して、登録をリクエストします。前の段階でソースを作成し、登録を明示的に許可したことを思い出してください。それでは、正しく登録されたかどうかを確認してみましょう。これは、subscription-manager アイデンティティーコマンドを使用して実行できます。
subscription-manager identity
system identity: ca03e0d1-7898-40bf-8cb7-b00faf2b2189
name: ip-172-30-0-68.ec2.internal
org name: 7843216
org ID: 7843216
実行した手順をまとめると、以下のようになります。
適切なバージョンの subscription-manager を使用して、自動登録を設定したイメージを立ち上げました。
指示したとおり、自動登録が試行されました。
ソースを設定したため、この登録は許可されます。
次のステップ
ホストを適切に登録したら、次のホスト機能を使用できます。
Insights を使用する
Insights-client --register を実行するだけで、システムを Insights に接続できます。rhc が利用可能な OS バージョンでは、rhc をインストールし、rhc connect を実行してください。どちらの場合も、認証用プロンプトは表示されず、そのまま接続します (特に、システムは subscription-manager に発行されたアイデンティティー証明書を再利用します)。
RHUI 経由では提供されない、サブスクリプションによって提供されるコンテンツを使用する
RHUI は Red Hat CDN で利用可能なコンテンツの一部を提供します。CDN リポジトリーを有効にする必要がある場合は、もちろん有効にできます。subscription-manager に "リポジトリー管理の仕事" をするように指示するだけです。これを行うには、/etc/rhsm/rhsm.conf を編集するか (推奨)、subscription-manager config --rhsm.manage_repos=1 を使用して編集してから (結果は同じだが、より簡潔な方法)、対応するコマンドを発行してリポジトリーを有効にします (例: subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms)。
RHEL の使用状況を確認する
Subscription Watch にアクセスします。RHEL の使用状況が表示されます。使用状況は、物理、仮想、およびシステムが実行されているパブリッククラウド別に分かれています。注記: Subscription Watch は 1 日に 1 回インベントリーを集計します。そのため、システムがサブスクリプションレポートに表示されるまでに最大 24 時間の遅延が発生する可能性があります。
よくある質問
Q: ユーザーがわざわざ手順を実行する必要がないように、Insights への登録を自動化できないでしょうか。そのような計画はありますか?
A: はい。これは以前からご要望いただいている機能であり、近い将来提供される予定です。
Q: 自動登録はどのクラウドでサポートされていますか?
A: この記事の執筆時点 (2022 年 4 月 1 日) では、AWS と Azure でサポートされています。Google は現在開発中で、2022 年半ばに完成する見込みです。
Q: 自動登録を使用したくない場合はどうすればよいですか?
A: クラウドソースを設定しないでください。
Q: 自動登録が完了するまでに約 1 時間かかるのはなぜですか?
A: 一貫性と負荷の間のバランスを取るためです。自動登録は、もともと 'レポートと分析のためのデータパイプラインを確立する' ために開発されたものです。コンテンツへのアクセスなどの 'クリティカルパス' として開発されたものではありません。RHUI により設定なしで確実に yum が機能するため、登録は非同期に処理できます。その仕組みが変わった場合は、そのモデルを修正いたします。
Q: 自動登録は素晴らしいと思います。クラウドプロバイダー (PAYG やマーケットプレイスなど) から購入したイメージで使用できますか?
A: はい。PAYG イメージとマーケットプレイスイメージは、自動登録を使用するように設定されており、今後も設定される予定です。
Q: subscription-manager でシステムを登録すると、サブスクリプションが消費されると認識しています。'二重請求' にならないでしょうか?
A: このご質問については、2 点に分けて回答します。まず、'システムの接続' と 'サブスクリプションの使用' を区別することが重要です。この 2 つは同義ではなくなりました。それを実現したのが、Simple Content Access です。一般的に、特にクラウドインスタンスを使用する場合は、SCA を導入することをお勧めしています。また、Insights クライアントを使用すると、どのシステムがマーケットプレイスからのものであるかがわかるほか、Subscription Watch でシステムを適切にカウントすることもできます。
Comments