第4章クラウドプロバイダー

CloudForms において、クラウドプロバイダーとは CloudForms アプライアンスに追加して、環境内のリソースの管理と対話を行うことが可能なクラウドコンピューティング環境のことです。本章では、CloudForms に追加可能な異種のクラウドプロバイダーとその管理方法について説明します。クラウドプロバイダーの多くは個別に、CloudForms に追加します。また Amazon EC2 および Azure クラウドプロバイダーは、CloudForms により自動的に検出されます。

Web インターフェースは、仮想サムネイルでクラウドプロバイダーを示します。各サムネイルは、デフォルトで 4 分割表示され、各プロバイダーの基本情報を確認することができます。

Cloudthumbnail

インスタンス数
管理システムソフトウェア
イメージ数
認証ステータス

表4.1 プロバイダー認証ステータス

アイコン	説明
	検証済み: 有効な認証情報が追加済みです。
	無効: 認証情報が無効です。
	不明: 認証ステータスが不明か、認証情報が入力されていません。

4.1. OpenStack プロバイダー

4.1.1. OpenStack プロバイダーの追加

Red Hat CloudForms はOpenStack admin テナントの運用をサポートしています。OpenStack プロバイダーの admin ユーザーは OpenStack admin テナントのデフォルト管理者なので、Red Hat CloudForms で OpenStack プロバイダーを作成する際にはこのユーザーを選択してくださ。admin の認証情報を使用する場合には、Red Hat CloudForms 内のユーザーは admin テナント内にプロビジョニングを行い、admin テナントに関連付けられたイメージ、ネットワーク、インスタンスを確認することができます。

OpenStack クラウドもしくはインフラストラクチャープロバイダーを追加する際には、テナントマッピング を Red Hat CloudForms で有効にして、そのプロバイダーから既存のテナントにマッピングするようにできます。つまり、Red Hat CloudForms が既存の各 OpenStack テナントに一致する新たなクラウドテナントを作成することになります。この新規作成のクラウドテナントと対応する OpenStack テナントは、同一のユーザーメンバーシップ、クォータ、アクセス/セキュリティールール、リソース割り当てを持つことになります。

プロバイダーのリフレッシュ中に、Red Hat CloudForms は OpenStack のテナントリストの変更もチェックします。Red Hat CloudForms は新しいテナントに一致する新規クラウドテナントを作成し、存在しなくなった OpenStack テナントに対応するクラウドテナントを削除します。Red Hat CloudForms は、OpenStack テナントになされた変更を対応するクラウドテナントにも複製します。

注記

Red Hat CloudForms でイベントのモニタリングに Telemetry サービスを使用するか、Advanced Message Queueing Protocol (AMQP) を使用するかを設定することができます。Telemetry を選択する場合には、最初に ceilometer サービスをオーバークラウド上でイベントを保管するように設定する必要があります。手順については、「オーバークラウドでイベントを保管するための設定」を参照してください。

詳しい情報は、Red Hat OpenStack Platform『アーキテクチャーガイド」の「OpenStack Telemetry (ceilometer)」のセクションを参照してください。

注記

自己署名の認証局 (CA) を使用してプロバイダーを認証するには、プロバイダーを追加する前に「自己署名の CA 証明書の使用」の手順に従い、CloudForms アプライアンスが証明書を信頼するように設定します。

コンピュート → クラウド → プロバイダーに移動します。
(構成) をクリックして (新規クラウドプロバイダーの追加) を選択します。
プロバイダーの名前を入力します。
タイプ のドロップダウンメニューから OpenStack を選択します。
一覧から適切な API バージョン を選択します。デフォルトは Keystone v2 です。
Keystone v3 を選択した場合には、Red Hat CloudForms が使用する必要のある Keystone V3 Domain ID を入力します。これは、後ほど Default タブで指定するユーザーアカウントのドメインです。プロバイダーでドメインが設定されていない場合には、default と入力します。
注記
Keystone API v3 を使用する場合には、ドメインは OpenStack 内のサービスエンティティーの管理の境界を決定するのに使用されます。ドメインにより、ドメイン固有の構成やセキュリティーオプションを設定するなどのさまざまな目的でユーザーをグループ化することができます。詳しい情報は、Red Hat OpenStack Platform 『アーキテクチャーガイド』の「OpenStack Identity (keystone)」のセクションを参照してください。
デフォルトでは、テナントマッピング は無効になっています。有効にするには、テナントマッピングの有効化 を Yes 設定します。
プロバイダー用に適切な ゾーン を選択します。デフォルトでは、ゾーンは default に設定されます。
注記
詳しい情報は、Red Hat OpenStack Platform『アーキテクチャーガイド』の「OpenStack Compute (nova)」のセクションでホストアグリゲートとアベイラビリティーゾーンの定義を参照してください。
デフォルト タブの エンドポイント のセクションで、OpenStack プロバイダーのホストと認証の詳細を設定します。
1. セキュリティープロトコル の方法を選択して、プロバイダーの認証方法を指定します。
  - 検証なしの SSL: SSL を使用してセキュアでない方法でプロバイダーを認証します。
  - SSL: 信頼済みの認証局を使用してセキュアにプロバイダーを認証します。プロバイダーに有効な SSL 証明書があり、信頼済みの認証局により署名されている場合にはこのオプションを選択します。このオプションでは、他の設定は必要ありません。これは、推奨の認証方法です。
  - 非 SSL: SSL なしの HTTP プロトコルのみでセキュアでない方法でプロバイダーに接続します。
2. または IPv4 または IPv6 アドレス に OpenStack Keystone サービスのパブリック IP または完全修飾ドメイン名を入力します。
  注記
  ここで必要なホスト名は、director によって生成される ~/overcloudrcファイル (Red Hat OpenStack Platform『director のインストールと使用方法』の「オーバークラウドへのアクセス」のセクションを参照)または Packstack によって生成される ~/keystonerc_admin ファイル (「OpenStack の評価: 単一ノードデプロイメント」を参照) の OS_AUTH_URL の値でもあります。
3. API ポート で、OpenStack Keystone サービスに使用するパブリックポートを設定します。デフォルトでは OpenStack はこのサービスにポート 5000 を使用します。
4. OpenStack プロバイダーとの認証に使用する適切な セキュリティープロトコル を選択します。
5. ユーザー名 のフィールドで、OpenStack 環境のユーザー名を入力します。
  重要
  Keystone v3 認証を使用する環境では、関連するドメインの admin ロールがユーザーに付与されている必要があります。
6. パスワード および パスワードの確認 フィールドで、ユーザーのパスワードを入力します。
7. 検証をクリックして、Red Hat CloudForms が OpenStack プロバイダーに接続できることを確認します。
次に、Red Hat CloudForms が OpenStack プロバイダーからイベントを受信する方法を設定します。エンドポイント セクションの イベント タブをクリックして設定を開始します。
- OpenStack プロバイダーの Telemetry サービスを使用するには、Ceilometer を選択します。使用する前には、プロバイダーをあらかじめ適切に設定しておく必要があります。詳しくは、「オーバークラウドでイベントを保管するための設定」を参照してください。
- 代わりに AMQP Messaging バスを使用する場合には、AMQP を選択します。その場合には、ホスト名 (または IPv4 または IPv6 アドレス) (エンドポイント の イベント タブ) に AMQP ホストのパブリック IP または修飾ドメイン名を入力します。
  - API ポート には、AMQP で使用するパブリックポートを設定します。デフォルトでは、OpenStack はこのホストにポート 5672 を使用します。
  - ユーザー名 のフィールドには、アクセス権限のある OpenStack ユーザー名を入力します (例: admin)。次に、対応するパスワードを パスワード と パスワードの確認 のフィールドに入力します。
  - 検証をクリックして認証情報を確認します。
クラウドプロバイダーを設定した後には、追加をクリックします。

注記

OpenStack 環境からインベントリーとメトリックを収集するために、Red Hat CloudForms アプライアンスは、OpenStack 環境の adminURL エンドポイントが非プライベートのネットワークにあることを要件とします。このため、OpenStack adminURL エンドポイントには 192.168.x.x 以外の IP アドレスを割り当てる必要があります。また、すべての Keystone エンドポイントがアクセス可能である必要があります。アクセスできない場合には、更新が失敗します。

4.1.1.1. オーバークラウドでイベントを保管するための設定

デフォルトでは、Telemetry サービスは、Red Hat OpenStack Platform 環境の他のサービスによって生成されたイベントは保管しません。以下の手順では、OpenStack クラウドプロバイダー上の Telemetry サービスがそれらのイベントを保管するようにする方法を説明します。これにより、イベントは、Red Hat OpenStack Platform 環境がクラウドプロバイダーに追加されると Red Hat CloudForms に表示されるようになります。

アンダークラウドホストにログインします。
ceilometer.yaml という名前の環境ファイルを作成し、以下の内容を追加します。
```
parameter_defaults:
  CeilometerStoreEvents: true
```
この環境ファイルを overcloud deploy コマンドで指定します。
```
# openstack overcloud deploy --templates -e ~/ceilometer.yaml
```

OpenStack クラウドプロバイダーがアンダークラウドでデプロイされたのではない場合には、手動で設定することができます。そのためには、以下のステップを実行します。

コントローラーノードにログインします。
/etc/ceilometer/ceilometer.conf を編集して以下のオプションを指定します。
```
store_events = True
```

/etc/heat/heat.conf を編集して以下のオプションを指定します。

notification_driver=glance.openstack.common.notifier.rpc_notifier
notification_topics=notifications

/etc/nova/nova.conf を編集して以下のオプションを指定します。
```
notification_driver=messaging
notification_topics=notifications
```

Compute サービスおよび Orchestration サービスを再起動します。

# systemctl restart openstack-heat-api.service \
  openstack-heat-api-cfn.service \
  openstack-heat-engine.service \
  openstack-heat-api-cloudwatch.service

# systemctl restart openstack-nova-compute.service

4.2. Azure プロバイダー

4.2.1. Azure プロバイダーの追加

Red Hat CloudForms は Microsoft Azure プロバイダーをサポートするようになりました。

重要

Red Hat CloudForms で Microsoft Azure を認証できるようにするには、前提条件となる一連のステップを Azure ポータルで実行する必要があります。「Create Active Directory application and service principal account using the Azure portal」を参照してください。このリンク先では、Azure Active Directory (AAD) の設定方法や、組織で開発するアプリケーションの作成、また Red Hat CloudForms のプロバイダーとして Azure インスタンスに接続できるようにするアプリケーションを追加するためのテナント ID、クライアント ID、クライアントキーの取得方法を説明しています。上記のリンクでは、アプリケーションをロールに割り当てる 際にステップ 3 では Contributor ロールを選択し、Reader ロールは選択しないように注意することが重要となります。また、これらのステップはすべて、Azure Resource Manager または Service Manager (Classic) モードを使用して実行可能な点にも注意してください。

Azure ポータルを使用してサービスプリンシパルアカウント (ディレクトリー内のアプリケーションのインスタンス) が作成されたら、Azure Active Directory (AAD) モジュール内で以下の 3 つの情報が利用可能になります。

テナント ID
クライアント ID
クライアントキー

これで、以下の手順に従って上記の項目を Red Hat CloudForms に実装し、Azure クラウドプロバイダーを追加することができるようになりました。

Azure クラウドプロバイダーを追加する手順:

注記

Azure クラウドプロバイダーを追加する際には、指定可能なリージョンの一覧からリージョンを 1 つ選択します。選択したリージョーンに対してプロバイダーが 1 つ作成されます。

コンピュート → クラウド → プロバイダーに移動します。
(構成) をクリックして (新規クラウドプロバイダーの追加) を選択します。
プロバイダーの名前を入力します。
タイプ の一覧から Azure を選択します。
リージョン の一覧からリージョンを 1 つ選択します。
テナント ID を入力します。
ゾーン を入力します。
認証情報 のセクションで、クライアント ID と クライアントキー を入力してから検証をクリックします。
追加をクリックします。

4.2.2. Azure プロバイダーの検出

Red Hat CloudForms は、全リージョンにわたる Microsoft Azure プロバイダーのセットを検出する機能を提供します。

コンピュート → クラウド → プロバイダーに移動します。
(構成) をクリックして (クラウドプロバイダーの検出) を選択します。
タイプの検出 の一覧から Azure を選択します。
認証情報のセクションで、Azure の クライアント ID、クライアントキー、Azure テナント ID、およびテナントの サブスクリプション ID を入力します。
開始をクリックします。

4.3. Amazon EC2 プロバイダー

4.3.1. Amazon EC2 プロバイダーの権限

Red Hat は、CloudForms に Amazon EC2 をクラウドプロバイダーとして追加する場合には、Amazon EC2 の パワーユーザー 用の Identity and Access Management (IAM) ポリシーを使用することを推奨します。このポリシーは、パワーユーザー グループ内のメンバーに、ユーザー管理以外の AWS サービスへの完全なアクセスを許可します。このため、CloudForms API ユーザーは全 API 機能にアクセスできますが、ユーザーの権限を変更することはできません。

自動化のスクリプトは直接 AWS SDK にアクセスして新しいアプリケーション機能を作成するので、API アクセスをさらに制限してしまうと、自動化機能が限定されてしまいます。

CloudForms API がアクセスする主要な AWS サービスには、以下が含まれます。

Elastic Compute Cloud (EC2)
CloudFormation
CloudWatch
Elastic Load Balancing
Simple Notification Service (SNS)
Simple Queue Service (SQS)

4.3.2. Amazon EC2 プロバイダーを追加します。

初回のインストールが完了し、Red Hat CloudForms 環境が作成された後に、以下の手順で Amazon EC2 クラウドプロバイダーを追加します。

コンピュート → クラウド → プロバイダーに移動します。
(構成) をクリックして (新規クラウドプロバイダーの追加) を選択します。
プロバイダーの名前を入力します。
タイプ の一覧から Amazon EC2 を選択します。
Amazon Region を選択します。
複数の ゾーン が利用可能な場合には、適切なゾーンを選択します。
Amazon AWS アカウントの セキュリティー認証情報 で アクセスキー を生成します。アクセスキー ID は ユーザー ID として機能し、シークレットアクセスキー は パスワード として機能します。
検証をクリックして認証情報を検証します。
追加をクリックします。

4.3.3. Amazon EC2 クラウドプロバイダーの検出

Red Hat CloudForms は、特定の Amazon EC2 アカウント情報のセットに関連付けられたクラウドプロバイダーを検出する機能を提供します。

コンピュート → クラウド → プロバイダーに移動します。
(構成) をクリックして (クラウドプロバイダーの検出) を選択します。
タイプの検出 の一覧から Amazon EC2 を選択します。
Amazon EC2 ユーザー ID と パスワード を入力します。パスワードの確認 フィールドにパスワードを再入力します。
開始をクリックします。

4.3.4. Amazon EC2 からのパブリック AMI の有効化

デフォルトでは、Amazon EC2 プロバイダーからのパブリック AMI は Red Hat CloudForms には表示されません。これらのイメージが表示されるようにするには、アプライアンスのメインの設定ファイルを編集する必要があります。

注記

パブリックイメージすべてを同期すると、追加のメモリーリソースが必要な場合があります。また、同期は、Amazon EC2 プロバイダーごとに同期が行われ、全メモリーリソースと同様の容量が必要となることを念頭においてください。

設定メニューから構成 → ゾーン → 詳細をクリックします。
ファイル 一覧から編集する設定ファイルを選択します。自動的に選択されていない場合には EVM Server Main Configuration を選択します。
get_public_images のパラメーターを設定します。
1. パブリックイメージが表示されるようにするには、get_public_images: true にパラメーターを設定します。
2. パブリックイメージが表示されないようにするには、get_public_images: false にパラメーターを設定します。
オプションで public_images_filters でフィルターのアレイを設定して、どのイメージを同期するかを絞り込みます。詳しい情報は、http://docs.aws.amazon.com/sdkforruby/api/Aws/EC2/Client.html#describe_images-instance_method を参照してください。

4.3.5. AWS Config の通知の有効化

Amazon の AWS Config は、Simple Notification Service (SNS) を使用して、リージョン内の変更をサブスクライバーに通知します。Red Hat CloudForms は AWS Config の差分の SNS サービスをサブスクライブして、その差分を Red Hat CloudForms のイベントに変換します。

AWS マネジメントコンソールで AWS Config サービスを有効化します。詳しい情報は、『AWS Config Developer Guide』を参照してください。
AWSConfig_topic という名前の新しい Amazon SNS トピックを作成します。Red Hat CloudForms はこのトピックに自動的に接続します。
(オプション) AWS マネジメントコンソールの差分作成の頻度を設定します。

Red Hat CloudForms ポリシーは、以下にリストする AWS イベントに対する割り当てることが可能です。アプライアンスは、AWS_EC2_Instance_UPDATE を除くこれらの全イベントでプロバイダーの更新を実行します。

イベント	ポリシー	更新
AWS_EC2_Instance_CREATE	src_vm vm_create	ems
AWS_EC2_Instance_UPDATE	該当なし	ems
AWS_EC2_Instance_running	src_vm vm_start	ems
AWS_EC2_Instance_stopped	src_vm vm_power_off	ems
AWS_EC2_Instance_shutting-down	src_vm vm_power_off	ems

4.4. Google Compute Engine プロバイダー

4.4.1. Google Compute Engine プロバイダーの追加

初回のインストールが完了し、Red Hat CloudForms 環境が作成された後に、以下の手順で Google Compute Engine プロバイダーを追加します。

前提条件

Google Compute Engine プロバイダーを Red Hat CloudForms に追加するための要件は以下のとおりです。

Google Cloud Platform アカウント
Google Compute Engine API が有効化された Google Compute Engine プロジェクト
対象のプロジェクトのサービスアカウント JSON キー
注記
対象のプロジェクト用のプライベート JSON キーは、 Google Cloud Platform の IAM と管理 → サービスアカウントで生成することができます。このキーは、プロバイダーに対して認証を行う際に使用されます。
詳しい情報は、https://cloud.google.com/storage/docs/authentication で Google Cloud Platform のドキュメントを参照してください。

Google Compute Engine プロバイダーを追加する手順

コンピュート → クラウド → プロバイダーに移動します。
(構成) をクリックして (新規クラウドプロバイダーの追加) を選択します。
プロバイダーの名前を入力します。
タイプ の一覧から Google Compute Engine を選択します。
一覧から 優先リージョン を選択します。
プロジェクト から Google Compute Engine のプロジェクト ID を入力します。
複数の ゾーン が利用可能な場合には、適切なゾーンを選択します。Red Hat は、 Google Compute Engine プロバイダー向けに新規ゾーンを作成することを推奨します。
対象のプロジェクトの サービスアカウント JSON キーの内容を サービスアカウント JSON フィールドにコピーします。
検証をクリックして認証情報を検証します。
追加をクリックします。

注記

NTP 同期が有効になっていて、機能していることを確認してください。クロックが同期していないと、以下のエラーが発生します。

Credential validation was not successful: Authorization failed. Server message: { "error" : "invalid_grant", "error_description" : "Invalid JWT: Token must be a short-lived token and in a reasonable timeframe" }

4.4.2. Google Compute Engine イベントの有効化

Google Compute Engine を Red Hat CloudForms のプロバイダーとして追加した後には、そのプロバイダーのイベントを有効化して、Red Hat CloudForms からシステムをモニタリングできるようにします。

イベントは、Google Stackdriver ロギングを Google Pub/Sub と組み合わせて使用して、プロジェクトごとに設定されます。Stackdriver ロギングは、Google のサービスおよびアプリケーションのログイベントをアグリゲートして公開するサービスです。Stackdriver はログイベントを Google Pub/Sub のメッセージングサービスに対してエクスポートします。本項では、Google Compute Engine プロジェクトのアクティビティーログのエントリーをエクスポートして、イベントが Red Hat CloudForms でキャプチャーされるようにする方法について説明します。

Google Compute Engine イベントをエクスポートするための前提条件

エクスポートするプロジェクトに対する所有者の権限があること。
Google Cloud Pub/Sub API が対象のプロジェクトに対して有効化されていること。API は以下の手順で有効化します。

Google Cloud Platform で、トップメニューバーから対象のプロジェクトを選択します。
をクリックして ツールとサービス メニューを表示します。API Manager をクリックして https://console.cloud.google.com/apis/library/ に進みます。
API Manager の概要タブの Google API 検索バーで Pub/Sub を検索し、結果から Google Cloud Pub/Sub API を選択します。有効にする のボタンをクリックします。
Google Cloud Pub/Sub API がすでに有効化されている場合には、有効にする のボタンは表示されず、代わりに Google Cloud Pub/Sub API が 有効な API の下に表示されます。

Stackdriver ロギングサービスには、対象のプロジェクトの Pub/Sub サービスに対してパブリッシュするための権限が付与されている必要があります。必要な権限を追加するには、以下の手順に従います。

Google Cloud Platform で、対象のプロジェクトを選択してからツールとサービス → IAM と管理 → IAM に移動して https://console.cloud.google.com/iam-admin/iam/ に進みます。
ログ設定書き込み の権限を対象のプロジェクトに割り当てます。
1. cloud-logs@system.gserviceaccount.com アカウントがすでに メンバー の下にリストされている場合には、役割の下に ログ設定書き込み が選択されていることを確認してください。
2. cloud-logs@system.gserviceaccount.com アカウントが メンバー の下にリストされていない場合には、以下のステップを実行します。
  1. 追加をクリックして権限を追加します。
  2. ダイアログボックスで、メンバー に cloud-logs@system.gserviceaccount.com を入力して Google API サービスアカウントを権限リストに追加します。
  3. 役割を選択 のドロップダウンメニューでログ → ログ設定書き込みの順に選択し、追加をクリックします。

4.4.2.1. Google Compute Engine でイベントをエクスポートするための設定

Google Compute Engine イベントをエクスポートするための前提条件のステップが完了したら、以下のステップに従って、Red Hat CloudForms にイベントをエクスポートするための Google Compute Engine プロジェクトを設定します。

Google Cloud Platform で、をクリックして ツールとサービス メニューを表示します。ログをクリックして https://console.cloud.google.com/logs/ に進みます。
トップメニューバーから対象のプロジェクトを選択します。
ログメニューから エクスポート を選択します。
サービスを選択 の一覧で、Compute Engine を選択します。
Export these sources で Add item をクリックし、一覧から compute.googleapis.com/activity_log を選択します。
Select export destinations で Publish to Cloud Pub/Sub topic ドロップダウンをクリックして、Add new topic… を選択します。
Create Cloud Pub/Sub Topic ダイアログで Name に manageiq-activity-log を入力します。Create をクリックします。
保存をクリックします。

Google Compute Engine インスタンスで変更が発生すると、Red Hat CloudForms は通知を受けて、それらの変更をイベントとして報告します。

注記

Google Compute Engine に関する更に詳しい情報は、Google Cloud Platform のドキュメントを参照してください。

Google Cloud Platform におけるクラウドログのエクスポート設定に関する情報は、https://cloud.google.com/logging/docs/export/configure_export を参照してください。
Google Cloud Pub/Sub API の運用とコストに関する情報は、https://cloud.google.com/pubsub/ を参照してください。

4.4.2.2. Red Hat CloudForms での Google Compute Engine イベントの表示

Red Hat CloudForms で以下の手順に従って Google Compute Engine プロジェクトのイベントを表示します。

コンピュート → クラウド → プロバイダーに移動して対象の Google Compute Engine プロジェクトを選択します。
プロバイダーの概要ページで監視 → タイムラインをクリックして、そのプロジェクトのイベントタイムラインを表示します。

4.5. クラウドプロバイダーの更新

クラウドプロバイダーを更新して、関連するその他のリソースを確認します。選択したクラウドプロバイダーの正しい認証情報があることを確認してから、更新を実行してください。

コンピュート → クラウド → プロバイダーに移動します。
クラウドプロバイダーのチェックボックスを選択して更新します。
(構成) をクリックして、 (リレーションシップと電源状態の更新) を選択します。
OK をクリックします。

4.6. クラウドプロバイダーのタグ付け

同時にまとめて分類するには、全クラウドプロバイダーにタグを適用します。

コンピュート → クラウド → プロバイダーに移動します。
タグ付けするクラウドプロバイダーのチェックボックスを選択します。
(ポリシー) をクリックして、 (タグの編集) を選択します。
最初の一覧から割り当てるカスタマータグを選択します。
2 番目のリストから割り当てる値を選択します。
保存をクリックします。

4.7. クラウドプロバイダーの削除

使用しなくなったクラウドプロバイダーを VMDB から削除する必要がある場合があります。

コンピュート → クラウド → プロバイダーに移動します。
削除するクラウドプロバイダーにチェックを付けます。
(構成) をクリックして、 (VMDB からのクラウドプロバイダーの削除) を選択します。
OK をクリックします。

4.8. クラウドプロバイダーの編集

プロバイダーの情報 (例: 名前、IP アドレス、ログイン認証情報) を編集します。

注記

タイプ の値は変更できません。

異なるクラウドプロバイダーを使用するには、新規作成します。

コンピュート → クラウド → プロバイダーに移動します。
編集するクラウドプロバイダーをクリックします。
(構成) をクリックして、 (選択したクラウドプロバイダーの編集) を選択します。
基本情報 を編集します。表示される項目は、プロバイダーの タイプ によって異なります。
認証情報 のセクションで ユーザー名 と パスワード を入力してから、パスワードの確認 で確認のためにパスワードを再入力します。
- Amazon EC2 を選択する場合には、Amazon AWS アカウントの セキュリティ認証情報 で アクセスキー を生成します。アクセスキー ID は ユーザー ID として機能し、シークレットアクセスキー は パスワード として機能します。
- OpenStack を選択する場合には、ログイン認証情報に Keystone のユーザー ID と パスワード を使用します。
OpenStack プロバイダーを編集する場合には、AMQP サブタブを使用して、OpenStack Nova コンポーネントの Advanced Message Queuing Protocol サービスに必要な認証情報を入力します。
検証をクリックして、検証が成功したことを知らせるメッセージが表示されるのを待ちます。
保存をクリックします。

4.9. クラウドプロバイダーのタイムラインの表示

クラウドプロバイダーに登録されているインスタンスのイベントのタイムラインを表示します。

コンピュート → クラウド → プロバイダーに移動します。
タイムラインを表示するクラウドプロバイダーをクリックします。
(監視) をクリックして、 (タイムライン) を選択します。
オプション から、表示する期間や表示するイベントタイプをカスタマイズします。
- 表示を使用して、通常の管理イベントとポリシーイベントを選択します。
- タイプ の一覧で毎時または毎日のデータポイントを選択します。
- 日付で、表示するタイムラインの日付を入力します。
- 毎日のタイムラインを表示するように選択した場合は、表示を使用して、何日分遡るかを設定します。最大の履歴は 31 日です。
- 3 つの イベントグループ リストでは、異なるイベントグループを選択して表示することができます。それぞれ独自の色が使用されます。
- レベル の一覧で概要のイベントか、イベントの詳細の一覧を選択します。

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.