Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第6章 CLI ツールを使用した基本的なオーバークラウドの設定
本章では、CLI ツールを使用した OpenStack Platform 環境の基本的な設定手順を説明します。基本設定のオーバークラウドには、カスタムの機能は含まれていませんが、『オーバークラウドの高度なカスタマイズ』に記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズすることができます。
6.1. オーバークラウドへのノードの登録
director では、手動で作成したノード定義のテンプレートが必要です。このファイルは JSON または YAML 形式を使用し、ノードのハードウェアおよび電源管理の情報が含まれます。
手順
ノードの一覧が含まれるテンプレートを作成します。JSON 形式のテンプレートの例を以下に示します。
{ "nodes":[ { "mac":[ "bb:bb:bb:bb:bb:bb" ], "name":"node01", "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.168.24.205" }, { "mac":[ "cc:cc:cc:cc:cc:cc" ], "name":"node02", "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.168.24.206" } ] }
また、YAML 形式の類似ノードテンプレートの例を以下に示します。
nodes: - mac: - "bb:bb:bb:bb:bb:bb" name: "node01" cpu: 4 memory: 6144 disk: 40 arch: "x86_64" pm_type: "ipmi" pm_user: "admin" pm_password: "p@55w0rd!" pm_addr: "192.168.24.205" - mac: - cc:cc:cc:cc:cc:cc name: "node02" cpu: 4 memory: 6144 disk: 40 arch: "x86_64" pm_type: "ipmi" pm_user: "admin" pm_password: "p@55w0rd!" pm_addr: "192.168.24.206"
このテンプレートでは、以下の属性を使用します。
- name
- ノードの論理名
- pm_type
使用する電源管理ドライバー。この例で使用しているのは IPMI ドライバー (
ipmi
) で、電源管理の推奨ドライバーです。注記IPMI が推奨されるサポート対象電源管理ドライバーです。これ以外のサポート対象電源管理ドライバーおよびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。
- pm_user; pm_password
- IPMI のユーザー名およびパスワード
- pm_addr
- IPMI デバイスの IP アドレス
- mac
- (オプション) ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
- cpu
- (オプション) ノード上の CPU 数
- memory
- (オプション) メモリーサイズ (MB)
- disk
- (オプション) ハードディスクのサイズ (GB)
- arch
(オプション) システムアーキテクチャー
重要マルチアーキテクチャークラウドをビルドする場合には、
x86_64
アーキテクチャーを使用するノードとppc64le
アーキテクチャーを使用するノードを区別するためにarch
キーが必須です。
テンプレートの作成後に、
stack
ユーザーのホームディレクトリーにファイルを保存して (/home/stack/nodes.json
)、以下のコマンドを使用して director にインポートします。$ source ~/stackrc (undercloud) $ openstack overcloud node import ~/nodes.json
このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。
ノードを登録して設定が完了した後に、CLI でこれらのノードの一覧を表示します。
(undercloud) $ openstack baremetal node list
6.2. ノードのハードウェアの検査
director は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントを起動します。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。
手順
以下のコマンドを実行して、各ノードのハードウェア属性を検証します。
(undercloud) $ openstack overcloud node introspect --all-manageable --provide
-
--all-manageable
オプションは、管理状態のノードのみをイントロスペクションします。上記の例では、すべてのノードが対象です。 -
--provide
オプションは、イントロスペクション後に全ノードをavailable
の状態にします。
-
別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニタリングします。
(undercloud) $ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
重要このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルの場合には、通常 15 分ほどかかります。
-
イントロスペクション完了後には、すべてのノードが
available
の状態に変わります。
6.3. プロファイルへのノードのタグ付け
各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。このプロファイルタグにより、ノードがフレーバーに照合され、次にそのフレーバーがデプロイメントロールに割り当てられます。以下の例では、コントローラーノードのロール、フレーバー、プロファイル、ノード間の関係を示しています。
タイプ | 説明 |
---|---|
ロール |
|
フレーバー |
|
プロファイル |
|
ノード |
また、各ノードに |
アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー compute
、control
、swift-storage
、ceph-storage
、block-storage
が作成され、大半の環境で変更なしに使用することができます。
手順
特定のプロファイルにノードをタグ付けする場合には、各ノードの
properties/capabilities
パラメーターにprofile
オプションを追加します。たとえば、2 つのノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
profile:compute
とprofile:control
オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。これらのコマンドにより、各ノードの起動方法を定義する
boot_option:local
パラメーターも設定されます。ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。
(undercloud) $ openstack overcloud profiles list
6.4. UEFI ブートモードの設定
デフォルトのブートモードは、レガシー BIOS モードです。新しいシステムでは、レガシー BIOS モードの代わりに UEFI ブートモードが必要な可能性があります。以下の手順を使用して、UEFI モードに変更します。
手順
undercloud.conf
ファイルで以下のパラメーターを設定します。ipxe_enabled = True inspection_enable_uefi = True
このファイルを保存して、アンダークラウドのインストールを実行します。
$ openstack undercloud install
インストールスクリプトが完了するまで待ちます。
登録済みの各ノードのブートモードを
uefi
に設定します。たとえば、capabilities
プロパティーにboot_mode
パラメーターを追加する場合や既存のパラメーターを置き換える場合には、以下のコマンドを実行します。$ NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
注記profile
およびboot_option
のケイパビリティーが保持されていることを確認してください。+
$ openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilities
各フレーバーのブートモードを
uefi
に設定します。$ openstack flavor set --property capabilities:boot_mode='uefi' control
6.5. ノードのルートディスクの定義
一部のノードでは、複数のディスクが使用される場合があります。このため、director はプロビジョニング中ルートディスクとして使用するディスクを特定する必要があります。プロビジョニングプロセス中、director は QCOW2 overcloud-full
イメージをルートディスクに書き込みます。
director がルートディスクを容易に特定できるようにするには、以下のようなプロパティーを使用することができます。
-
model
(文字列): デバイスの ID -
vendor
(文字列): デバイスのベンダー -
serial
(文字列): ディスクのシリアル番号 -
hctl
(文字列): SCSI のホスト:チャネル:ターゲット:Lun -
size
(整数):デバイスのサイズ (GB) -
wwn
(文字列): ストレージの一意識別子 -
wwn_with_extension
(文字列): ベンダー拡張が末尾に付いたストレージの一意識別子 -
wwn_vendor_extension
(文字列): ベンダーのストレージの一意識別子 -
rotational
(ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false。 -
name
(文字列): デバイス名 (例: /dev/sdb1)
name
は、永続デバイス名が付いたデバイスのみに使用します。name
で他のデバイスのルートディスクを設定しないでください。この値は、ノードのブート時に変更される可能性があります。
シリアル番号を使用してルートデバイスを指定する方法を、以下の例で説明します。
手順
各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドは、ノードからのディスク情報を表示します。
(undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
たとえば、1 つのノードのデータで 3 つのディスクが表示される場合があります。
[ { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sda", "wwn_vendor_extension": "0x1ea4dcc412a9632b", "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b", "model": "PERC H330 Mini", "wwn": "0x61866da04f380700", "serial": "61866da04f3807001ea4dcc412a9632b" } { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sdb", "wwn_vendor_extension": "0x1ea4e13c12e36ad6", "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6", "model": "PERC H330 Mini", "wwn": "0x61866da04f380d00", "serial": "61866da04f380d001ea4e13c12e36ad6" } { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sdc", "wwn_vendor_extension": "0x1ea4e31e121cfb45", "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45", "model": "PERC H330 Mini", "wwn": "0x61866da04f37fc00", "serial": "61866da04f37fc001ea4e31e121cfb45" } ]
以下の例では、ルートデバイスをシリアル番号が
61866da04f380d001ea4e13c12e36ad6
の disk 2 に設定する方法を説明します。そのためには、ノード定義のroot_device
パラメーターを変更する必要があります。(undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
注記各ノードの BIOS を設定して、選択したルートディスクからの起動が含まれるようにします。推奨のブート順は最初がネットワークブートで、次にルートディスクブートです。
6.6. アーキテクチャーに固有なロールの作成
マルチアーキテクチャークラウドをビルドする場合には、roles_data.yaml
にアーキテクチャー固有のロールを追加する必要があります。以下に示す例では、デフォルトのロールに加えて ComputePPC64LE
ロールを追加しています。『オーバークラウドの高度なカスタマイズ』の「roles_data ファイルの作成」セクションには、ロールについての情報が記載されています。
openstack overcloud roles generate \ --roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \ Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage
6.7. 環境ファイル
アンダークラウドには、オーバークラウドの作成プランとして機能するさまざまな Heat テンプレートが含まれます。YAML フォーマットの環境ファイルを使って、オーバークラウドの特性をカスタマイズすることができます。このファイルで、コア Heat テンプレートコレクションのパラメーターおよびリソースを上書きします。必要に応じていくつでも環境ファイルを追加することができますが、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。
- 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
- コンテナー化された OpenStack サービスのコンテナーイメージの場所。
-
任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml
) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。 - 外部のロードバランシングの環境ファイル。
- Ceph Storage、NFS、iSCSI などのストレージ環境ファイル。
- Red Hat CDN または Satellite 登録用の環境ファイル。
- その他のカスタム環境ファイル。
カスタム環境ファイルは、別のディレクトリーで管理することを推奨します (たとえば、templates
ディレクトリー)。
『オーバークラウドの高度なカスタマイズ』を使用して、オーバークラウドの詳細機能をカスタマイズできます。
基本的なオーバークラウドでは、ブロックストレージにローカルの LVM ストレージを使用しますが、この設定はサポートされません。ブロックストレージには、外部ストレージソリューション (Red Hat Ceph Storage 等) を使用することを推奨します。
これ以降の数セクションで、オーバークラウドに必要な環境ファイルを作成する方法について説明します。
6.8. ノード数とフレーバーを定義する環境ファイルの作成
デフォルトでは、director は baremetal
フレーバーを使用して 1 つのコントローラーノードとコンピュートノードを持つオーバークラウドをデプロイします。ただし、この設定は概念検証のためのデプロイメントにしか適しません。異なるノード数およびフレーバーを指定して、デフォルトの設定をオーバーライドすることができます。小規模な実稼働環境では、コントローラーノードとコンピュートノードを少なくとも 3 つにし、適切なリソース仕様でノードが作成されるように特定のフレーバーを割り当てる必要があります。以下の手順では、ノード数およびフレーバー割り当てを定義する環境ファイル node-info.yaml
の作成方法を説明します。
手順
/home/stack/templates/
ディレクトリーにnode-info.yaml
ファイルを作成します。(undercloud) $ touch /home/stack/templates/node-info.yaml
ファイルを編集し、必要なノード数およびフレーバーを設定します。以下の例では、3 つのコントローラーノード、コンピュートノード、および Ceph Storage ノードをデプロイします。
parameter_defaults: OvercloudControllerFlavor: control OvercloudComputeFlavor: compute ControllerCount: 3 ComputeCount: 3
6.9. アンダークラウド CA を信頼するための環境ファイルの作成
アンダークラウドで TLS が使用され CA が一般に信頼できない場合には、以下の手順に従う必要があります。アンダークラウドでは、SSL エンドポイント暗号化のために自己の認証局 (CA) が運用されます。デプロイメントの他の要素からアンダークラウドのエンドポイントにアクセスできるようにするには、アンダークラウドの CA を信頼するようにオーバークラウドノードを設定します。
この手法が機能するためには、オーバークラウドノードにアンダークラウドの公開エンドポイントへのネットワークルートが必要です。スパイン/リーフ型ネットワークに依存するデプロイメントでは、この設定を適用する必要があります。
アンダークラウドで使用することのできるカスタム証明書には、2 つのタイプがあります。
-
ユーザーの提供する証明書: 自己の証明書を提供している場合がこれに該当します。自己の CA からの証明書、または自己署名の証明書がその例です。この証明書は
undercloud_service_certificate
オプションを使用して渡されます。この場合、自己署名の証明書または CA のどちらかを信頼する必要があります (デプロイメントによります)。 -
自動生成される証明書:
certmonger
により自己のローカル CA を使用して証明書を生成する場合がこれに該当します。このプロセスは、generate_service_certificate
オプションを使用して有効にします。この場合、CA 証明書 (/etc/pki/ca-trust/source/anchors/cm-local-ca.pem
) およびアンダークラウドの HAProxy インスタンスが使用するサーバー証明書が用いられます。この証明書を OpenStack に提示するには、CA 証明書をinject-trust-anchor-hiera.yaml
ファイルに追加する必要があります。
手順
以下の例では、/home/stack/ca.crt.pem
に保存された自己署名の証明書が使われています。自動生成される証明書を使用する場合には、代わりに /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
を使用してください。
証明書ファイルを開き、証明書部分だけをコピーします。鍵を含めないでください。
$ vi /home/stack/ca.crt.pem
必要となる証明書部分の例を、以下に示します。
-----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----
以下に示す内容で
/home/stack/inject-trust-anchor-hiera.yaml
という名称の新たな YAML ファイルを作成し、PEM ファイルからコピーした証明書を追加します。parameter_defaults: CAMap: ... undercloud-ca: content: | -----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----
注記証明書の文字列は、PEM の形式に従う必要があります。
オーバークラウドのデプロイメント時に CA 証明書がそれぞれのオーバークラウドノードにコピーされ、アンダークラウドの SSL エンドポイントが提示する暗号化を信頼するようになります。環境ファイル追加の詳細は、「オーバークラウドデプロイメントへの環境ファイルの追加」を参照してください。
6.10. デプロイメントコマンド
OpenStack 環境作成における最後の段階では、openstack overcloud deploy
コマンドを実行して OpenStack 環境を作成します。このコマンドを実行する前に、キーオプションやカスタムの環境ファイルの追加方法を十分に理解しておく必要があります。
バックグラウンドプロセスとして openstack overcloud deploy
を実行しないでください。バックグラウンドのプロセスとして開始された場合にはオーバークラウドの作成は途中で停止してしまう可能性があります。
6.11. デプロイメントコマンドのオプション
以下の表では、openstack overcloud deploy
コマンドを使用する際の追加パラメーターを一覧表示します。
表6.1 デプロイメントコマンドのオプション
パラメーター | 説明 |
---|---|
|
デプロイする Heat テンプレートが格納されているディレクトリー。空欄にした場合には、コマンドはデフォルトのテンプレートの場所である |
|
作成または更新するスタックの名前 |
|
デプロイメントのタイムアウト (分単位) |
|
ハイパーバイザーに使用する仮想化タイプ |
|
時刻の同期に使用する Network Time Protocol (NTP) サーバー。コンマ区切りリストで複数の NTP サーバーを指定することも可能です (例: |
|
環境変数 no_proxy のカスタム値を定義します。これにより、プロキシー通信から特定のホスト名は除外されます。 |
|
オーバークラウドノードにアクセスする SSH ユーザーを定義します。通常、SSH アクセスは |
|
オーバークラウドデプロイメントに渡す追加の環境ファイル。複数回指定することが可能です。 |
|
デプロイメントに追加する環境ファイルが格納されているディレクトリー。このコマンドは、これらの環境ファイルを最初に番号順、その後にアルファベット順で処理します。 |
|
オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的でないエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。 |
|
オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかのクリティカルではない警告が発生した場合に終了します。 |
|
オーバークラウドに対する検証チェックを実行しますが、オーバークラウドを実際には作成しません。 |
|
オーバークラウドのデプロイ後の設定を省略します。 |
|
オーバークラウドのデプロイ後の設定を強制的に行います。 |
|
|
|
引数とパラメーターが記載された YAML ファイルへのパス |
|
カスタマーポータルまたは Satellite 6 にオーバークラウドノードを登録します。 |
|
オーバークラウドノードに使用する登録方法。Red Hat Satellite 6 または Red Hat Satellite 5 は |
|
登録に使用する組織 |
|
すでに登録済みでもシステムを登録します。 |
|
オーバークラウドノードを登録する Satellite サーバーのベース URL。このパラメーターには、HTTPS URL ではなく、Satellite の HTTP URL を使用します。たとえば、https://satellite.example.com ではなく http://satellite.example.com を使用します。オーバークラウドの作成プロセスではこの URL を使用して、どのサーバーが Red Hat Satellite 5 または Red Hat Satellite 6 サーバーであるかを判断します。Red Hat Satellite 6 サーバーの場合は、オーバークラウドは |
|
登録に使用するアクティベーションキー |
オプションの完全一覧については、以下のコマンドを実行します。
(undercloud) $ openstack help overcloud deploy
環境ファイルの parameter_defaults
セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのパラメーターを対照しています。
表6.2 非推奨の CLI パラメーターと Heat テンプレートのパラメーターの対照表
パラメーター | 説明 | Heat テンプレートのパラメーター |
---|---|---|
|
スケールアウトするコントローラーノード数 |
|
|
スケールアウトするコンピュートノード数 |
|
|
スケールアウトする Ceph Storage ノードの数 |
|
|
スケールアウトする Cinder ノード数 |
|
|
スケールアウトする Swift ノード数 |
|
|
コントローラーノードに使用するフレーバー |
|
|
コンピュートノードに使用するフレーバー |
|
|
Ceph Storage ノードに使用するフレーバー |
|
|
Cinder ノードに使用するフレーバー |
|
|
Swift Storage ノードに使用するフレーバー |
|
|
フラットなネットワークが neutron プラグインで設定されるように定義します。外部ネットワークを作成ができるようにデフォルトは「datacentre」に設定されています。 |
|
|
各ハイパーバイザーで作成する Open vSwitch ブリッジ。デフォルト値は「br-ex」で、通常この値は変更する必要はないはずです。 |
|
|
使用する論理ブリッジから物理ブリッジへのマッピング。ホスト (br-ex) の外部ブリッジを物理名 (datacentre) にマッピングするようにデフォルト設定されています。これは、デフォルトの Floating ネットワークに使用されます。 |
|
|
ネットワークノード向けにインターフェースを br-ex にブリッジするインターフェースを定義します。 |
|
|
Neutron のテナントネットワーク種別 |
|
|
neutron テナントネットワークのトンネリング種別。複数の値を指定するには、コンマ区切りの文字列を使用します。 |
|
|
テナントネットワークを割り当てに使用できる GRE トンネリングの ID 範囲 |
|
|
テナントネットワークを割り当てに使用できる VXLAN VNI の ID 範囲 |
|
|
サポートされる Neutron ML2 および Open vSwitch VLAN マッピングの範囲。デフォルトでは、物理ネットワーク「datacentre」上の VLAN を許可するように設定されています。 |
|
|
neutron テナントネットワークのメカニズムドライバー。デフォルトでは、「openvswitch」に設定されており、複数の値を指定するにはコンマ区切りの文字列を使用します。 |
|
|
VLAN で区切られたネットワークまたは neutron でのフラットネットワークを使用するためにトンネリングを無効化します。 |
パラメーターのマッピングなし |
|
オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的なエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。 |
パラメーターのマッピングなし |
これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで削除される予定です。
6.12. オーバークラウドデプロイメントへの環境ファイルの追加
オーバークラウドをカスタマイズするには、-e
を指定して、環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができますが、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。
- 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
- コンテナー化された OpenStack サービスのコンテナーイメージの場所。
-
任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml
) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。 - 外部のロードバランシングの環境ファイル。
- Ceph Storage、NFS、iSCSI などのストレージ環境ファイル。
- Red Hat CDN または Satellite 登録用の環境ファイル。
- その他のカスタム環境ファイル。
-e
オプションを使用してオーバークラウドに追加した環境ファイルは、すべてオーバークラウドのスタック定義の一部となります。
以下のコマンドは、本シナリオの初期に定義した環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。
(undercloud) $ openstack overcloud deploy --templates \ -e /home/stack/templates/node-info.yaml\ -e /home/stack/templates/overcloud_images.yaml \ -e /home/stack/inject-trust-anchor-hiera.yaml -r /home/stack/templates/roles_data.yaml \
上記のコマンドでは、以下の追加オプションも使用できます。
- --templates
-
/usr/share/openstack-tripleo-heat-templates
の Heat テンプレートコレクションをベースとして使用し、オーバークラウドを作成します。 - -e /home/stack/templates/node-info.yaml
- 各ロールに使用するノード数とフレーバーを定義する環境ファイルを追加します。
- -e /home/stack/templates/overcloud_images.yaml
- コンテナーイメージソースを含む環境ファイルを追加します。
- -e /home/stack/inject-trust-anchor-hiera.yaml
- アンダークラウドにカスタム証明書をインストールする環境ファイルを追加します。
- -r /home/stack/templates/roles_data.yaml
- (オプション) カスタムロールを使用する、またはマルチアーキテクチャークラウドを有効にする場合に生成されるロールデータ。詳しくは、「アーキテクチャーに固有なロールの作成」を参照してください。
director は、「9章オーバークラウド作成後のタスクの実行」に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。
オーバークラウド設定を後で変更する予定の場合には、以下の作業を行う必要があります。
- カスタムの環境ファイルおよび Heat テンプレートのパラメーターを変更します。
-
同じ環境ファイルを指定して
openstack overcloud deploy
コマンドを再度実行します。
オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。
6.13. デプロイメント操作を行う前のオーバークラウド設定の検証
オーバークラウドのデプロイメント操作を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。
手順
オーバークラウドのコア Heat テンプレートは、Jinja2 形式となっています。テンプレートを検証するには、以下のコマンドを使用して Jinja 2 のフォーマットなしでバージョンをレンダリングします。
$ cd /usr/share/openstack-tripleo-heat-templates $ ./tools/process-templates.py -o ~/overcloud-validation
以下のコマンドを使用して、テンプレート構文を検証します。
(undercloud) $ openstack orchestration template validate --show-nested \ --template ~/overcloud-validation/overcloud.yaml -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml \ -e [ENVIRONMENT FILE] \ -e [ENVIRONMENT FILE]
検証には、
overcloud-resource-registry-puppet.yaml
の環境ファイルにオーバークラウド固有のリソースを含める必要があります。環境ファイルをさらに追加するには、このコマンドに-e
オプションを使用してください。また、--show-nested
オプションを追加して、ネストされたテンプレートからパラメーターを解決します。- 検証コマンドにより、テンプレート内の構文エラーが特定されます。テンプレートの構文の検証が正常に行われた場合には、出力には、作成されるオーバークラウドのテンプレートのプレビューが表示されます。
6.14. オーバークラウドデプロイメントの出力
オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された Ansible のプレイの概要が director により提示されます。
PLAY RECAP ************************************************************* overcloud-compute-0 : ok=160 changed=67 unreachable=0 failed=0 overcloud-controller-0 : ok=210 changed=93 unreachable=0 failed=0 undercloud : ok=10 changed=7 unreachable=0 failed=0 Tuesday 15 October 2018 18:30:57 +1000 (0:00:00.107) 1:06:37.514 ****** ========================================================================
director により、オーバークラウドへのアクセス情報も提供されます。
Ansible passed. Overcloud configuration completed. Overcloud Endpoint: http://192.168.24.113:5000 Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard Overcloud rc file: /home/stack/overcloudrc Overcloud Deployed
6.15. オーバークラウドへのアクセス
director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成して、stack
ユーザーのホームディレクトリーにこのファイル (overcloudrc
) を保存します。このファイルを使用するには、以下のコマンドを実行します。
(undercloud) $ source ~/overcloudrc
これで、director のホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。
(overcloud) $
director のホストとの対話に戻るには、以下のコマンドを実行します。
(overcloud) $ source ~/stackrc (undercloud) $
オーバークラウドの各ノードには、heat-admin
と呼ばれるユーザーが含まれます。stack
ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。
(undercloud) $ openstack server list
次に、heat-admin
ユーザーとノードの IP アドレスを使用して、ノードに接続します。
(undercloud) $ ssh heat-admin@192.168.24.23
6.16. 次のステップ
これで、コマンドラインツールを使用したオーバークラウドの作成が完了しました。作成後の機能については、「9章オーバークラウド作成後のタスクの実行」を参照してください。