第5章 CLI ツールを使用した基本的なオーバークラウドの設定
本章では、CLI ツールを使用した OpenStack Platform 環境の基本的な設定手順を説明します。基本設定のオーバークラウドには、カスタムの機能は含まれていませんが、『オーバークラウドの高度なカスタマイズ』ガイドに記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズすることができます。
本章の例では、すべてのノードが電源管理に IPMI を使用したベアメタルシステムとなっています。電源管理の種別およびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。
ワークフロー
- ノード定義のテンプレートを作成して director で空のノードを登録します。
- 全ノードのハードウェアを検査します。
- ロールにノードをタグ付けします。
- 追加のノードプロパティーを定義します。
要件
- 「4章アンダークラウドのインストール」で作成した director ノード
- ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります (オーバークラウドロールに関する情報は「ノードのデプロイメントロールのプランニング」を参照してください)。これらのマシンは、各ノード種別の要件セットに従う必要があります。これらの要件については、「オーバークラウドの要件」を参照してください。これらのノードにはオペレーティングシステムは必要ありません。director が Red Hat Enterprise Linux 7 のイメージを各ノードにコピーします。
ネイティブ VLAN として設定したプロビジョニングネットワーク用のネットワーク接続 1 つ。全ノードは、このネイティブに接続して、「ネットワーク要件」で設定した要件に準拠する必要があります。この章の例では、以下の IP アドレスの割り当てで、プロビジョニングサブネットとして 192.168.24.0/24 を使用します。
表5.1 プロビジョニングネットワークの IP 割り当て
ノード名
IP アドレス
MAC アドレス
IPMI IP アドレス
director
192.168.24.1
aa:aa:aa:aa:aa:aa
不要
コントローラー
定義済みの DHCP
bb:bb:bb:bb:bb:bb
192.168.24.205
Compute
定義済みの DHCP
cc:cc:cc:cc:cc:cc
192.168.24.206
- その他のネットワーク種別はすべて、OpenStack サービスにプロビジョニングネットワークを使用しますが、ネットワークトラフィックの他のタイプに追加でネットワークを作成することができます。
5.1. オーバークラウドへのノードの登録
director では、手動で作成したノード定義のテンプレートが必要です。このファイル (instackenv.json) は、JSON 形式のファイルを使用して、ノードのハードウェアおよび電源管理の情報が含まれます。たとえば、2 つのノードを登録するテンプレートは、以下のようになります。
{
"nodes":[
{
"mac":[
"bb:bb:bb:bb:bb:bb"
],
"cpu":"4",
"memory":"6144",
"disk":"40",
"arch":"x86_64",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"p@55w0rd!",
"pm_addr":"192.168.24.205"
},
{
"mac":[
"cc:cc:cc:cc:cc:cc"
],
"cpu":"4",
"memory":"6144",
"disk":"40",
"arch":"x86_64",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"p@55w0rd!",
"pm_addr":"192.168.24.206"
}
]
}このテンプレートでは、以下の属性を使用します。
- pm_type
-
使用する電源管理ドライバー。この例では IPMI ドライバーを使用します (
pxe_ipmitool)。 - pm_user; pm_password
- IPMI のユーザー名およびパスワード
- pm_addr
- IPMI デバイスの IP アドレス
- mac
- (オプション) ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
- cpu
- (オプション) ノード上の CPU 数
- memory
- (オプション) メモリーサイズ (MB)
- disk
- (オプション) ハードディスクのサイズ (GB)
- arch
- (オプション) システムアーキテクチャー
電源管理の種別およびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。
テンプレートの作成後に、stack ユーザーのホームディレクトリー (/home/stack/instackenv.json) にファイルを保存して、以下のコマンドを使用して director にインポートします。
$ openstack overcloud node import ~/instackenv.json
このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。
ノードを登録して設定が完了した後に、CLI でこれらのノードの一覧を表示します。
$ openstack baremetal node list
5.2. ノードのハードウェアの検査
director は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントを起動します。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。
ポリシーファイルを作成して、イントロスペクションの直後にノードをプロファイルに自動でタグ付けすることも可能です。ポリシーファイルを作成してイントロスペクションプロセスに組み入れる方法に関する詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。または、「プロファイルへのノードのタグ付け」に記載の手順に従って、ノードをプロファイルに手動でタグ付けすることもできます。
以下のコマンドを実行して、各ノードのハードウェア属性を検証します。
$ openstack overcloud node introspect --all-manageable --provide
-
--all-manageableオプションは、管理状態のノードのみをイントロスペクションします。上記の例では、すべてのノードが対象です。 -
--provideオプションは、イントロスペクションの後に全ノードをactiveの状態にリセットします。
別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニタリングします。
$ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルの場合には、通常 15 分ほどかかります。
イントロスペクション完了後には、すべてのノードが active の状態に変わります。
ノードイントロスペクションの個別実行
active な状態のノードで個別にイントロスペクションを実行するには、ノードを管理モードに設定して、イントロスペクションを実行します。
$ openstack baremetal node manage [NODE UUID] $ openstack overcloud node introspect [NODE UUID] --provide
イントロスペクションが完了すると、ノードは active の状態に変わります。
初回のイントロスペクション後のノードイントロスペクションの実行
--provide オプションを指定したので、初回のイントロスペクションの後には、全ノードが active の状態に入るはずです。初回のイントロスペクション後に全ノードにイントロスペクションを実行するには、すべてのノードを manageable の状態にして、一括のイントロスペクションコマンドを実行します。
$ for node in $(openstack baremetal node list --fields uuid -f value) ; do openstack baremetal node manage $node ; done $ openstack overcloud node introspect --all-manageable --provide
イントロスペクション完了後には、すべてのノードが active の状態に変わります。
5.3. プロファイルへのノードのタグ付け
各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。このプロファイルタグにより、ノードがフレーバーに照合され、次にそのフレーバーがデプロイメントロールに割り当てられます。以下の例では、コントローラーノードのロール、フレーバー、プロファイル、ノード間の関係を示しています。
| タイプ | 説明 |
|---|---|
|
ロール |
|
|
フレーバー |
|
|
プロファイル |
|
|
ノード |
また、各ノードに |
アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー compute、control、swift-storage、ceph-storage、block-storage が作成され、大半の環境で変更なしに使用することができます。
多くのノードでは、プロファイルの自動タグ付けを使用します。詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。
特定のプロファイルにノードをタグ付けする場合には、各ノードの properties/capabilities パラメーターに profile オプションを追加します。たとえば、2 つのノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。
$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
profile:compute と profile:control オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。
これらのコマンドは、各ノードのブート方法を定義する boot_option:local パラメーターも設定します。お使いのハードウェアによっては、boot_mode パラメーターを uefi に追加して、ノードが BIOS モードの代わりに UEFI を使用してブートするようにする必要がある場合もあります。詳しい情報は、「UEFI ブートモード」を参照してください。
ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。
$ openstack overcloud profiles list
カスタムロールのプロファイル
カスタムロールを使用する場合には、これらの新規ロールに対応するために追加のフレーバーやプロファイルを作成する必要があるかもしれません。たとえば、Networker ロールの新規フレーバーを作成するには、以下のコマンドを実行します。
$ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker
この新規プロファイルにノードを割り当てます。
$ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d
5.4. ノードのルートディスクの定義
一部のノードは、複数のディスクを使用する場合があります。このため、 director はプロビジョニング中に、ルートディスクに使用するディスクを特定する必要があります。director がルートディスクを容易に特定できるようにするには、以下のようなプロパティーを使用することができます。
-
model(文字列): デバイスの ID -
vendor(文字列): デバイスのベンダー -
serial(文字列): ディスクのシリアル番号 -
wwn(文字列): 一意のストレージ ID -
hctl(文字列): SCSI のホスト:チャネル:ターゲット:Lun -
size(整数):デバイスのサイズ (GB)
以下の例では、root デバイスを特定するディスクのシリアル番号を使用して、オーバークラウドイメージをデプロイするドライブを指定します。
各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドは、ノードからのディスク情報を表示します。
$ 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 パラメーターを追加する必要があります。
$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0これにより、director がルートディスクとして使用する特定のディスクを識別しやすくなります。オーバークラウドの作成の開始時には、director はこのノードをプロビジョニングして、オーバークラウドのイメージをこのディスクに書き込みます。
各ノードの BIOS を設定して、選択したルートディスクからの起動が含まれるようにします。推奨のブート順は最初がネットワークブートで、次にルートディスクブートです。
name でルートディスクを設定しないでください。この値は、ノードブート時に変更される可能性があります。
5.5. オーバークラウドのカスタマイズ
アンダークラウドには、オーバークラウドの作成プランとして機能する Heat テンプレートセットが含まれます。『オーバークラウドの高度なカスタマイズ』ガイドを使用して、オーバークラウドの詳細機能をカスタマイズできます。
カスタマイズを使用しない場合には、継続して基本的なオーバークラウドをデプロイすることができます。詳しい情報は「CLI ツールを使用したオーバークラウドの作成」を参照してください。
基本的なオーバークラウドでは、ブロックストレージにローカルの LVM ストレージを使用しますが、この設定はサポートされません。ブロックストレージには、外部ストレージソリューションを使用することを推奨します。
5.6. CLI ツールを使用したオーバークラウドの作成
OpenStack 環境作成における最後の段階では、openstack overcloud deploy コマンドを実行して OpenStack 環境を作成します。このコマンドを実行する前には、キーのオプションやカスタムの環境ファイルの追加方法を十分に理解しておく必要があります。以下のセクションでは、openstack overcloud deploy コマンドと、それに関連するオプションについて説明します。
バックグラウンドプロセスとして openstack overcloud deploy を実行しないでください。バックグラウンドのプロセスとして開始された場合にはオーバークラウドの作成は途中で停止してしまう可能性があります。
オーバークラウドのパラメーター設定
以下の表では、openstack overcloud deploy コマンドを使用する際の追加パラメーターを一覧表示します。
表5.2 デプロイメントパラメーター
| パラメーター | 説明 |
|---|---|
|
|
デプロイする 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 サーバーの場合は、オーバークラウドは |
|
|
登録に使用するアクティベーションキー |
環境ファイルの parameter_defaults セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのパラメーターを対照しています。
表5.3 非推奨の 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 の今後のリリースで削除される予定です。
オプションの完全一覧については、以下のコマンドを実行します。
$ openstack help overcloud deploy
5.7. オーバークラウド作成時の環境ファイルの追加
オーバークラウドをカスタマイズするには、-e を指定して、環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができますが、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。
- 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
-
任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。 - 外部のロードバランシングの環境ファイル
- Ceph Storage、NFS、iSCSI などのストレージ環境ファイル
- Red Hat CDN または Satellite 登録用の環境ファイル
- その他のカスタム環境ファイル
-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。以下のコマンドは、追加するカスタム環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。
$ openstack overcloud deploy --templates \ -e ~/templates/node-info.yaml\ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e ~/templates/network-environment.yaml \ -e ~/templates/storage-environment.yaml \ --ntp-server pool.ntp.org \
このコマンドでは、以下の追加オプションも使用できます。
-
--templates:/usr/share/openstack-tripleo-heat-templatesの Heat テンプレートコレクションを使用してオーバークラウドを作成します。 -e ~/templates/node-info.yaml:-eオプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、各ロールに使用するノード数とフレーバーを定義するカスタムの環境ファイルです。以下に例を示します。parameter_defaults: OvercloudControlFlavor: control OvercloudComputeFlavor: compute OvercloudCephStorageFlavor: ceph-storage ControllerCount: 3 ComputeCount: 3 CephStorageCount: 3
-
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml:-eオプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、ネットワーク分離の設定を初期化する環境ファイルです。 -
-e ~/templates/network-environment.yaml:-eオプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。今回は、ネットワーク分離のカスタマイズが含まれるネットワーク環境ファイルです。 -
-e ~/templates/storage-environment.yaml:-eオプションは、オーバークラウドデプロイメントに別の環境ファイルを追加します。この場合は、ストレージの設定を初期化する環境ファイルです。 -
--ntp-server pool.ntp.org: 時刻の同期に NTP サーバーを使用します。これは、コントローラーノードクラスターの同期を保つ際に便利です。
director は、「8章オーバークラウド作成後のタスクの実行」に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。
オーバークラウド設定を後で変更する予定の場合には、以下の作業を行う必要があります。
- カスタムの環境ファイルおよび Heat テンプレートのパラメーターを変更します。
-
同じ環境ファイルを指定して
openstack overcloud deployコマンドを再度実行します。
オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。
環境ファイルディレクトリーの追加
--environment-directory オプションを使用して、環境ファイルを格納しているディレクトリー全体を追加することも可能です。デプロイメントコマンドにより、このディレクトリー内の環境ファイルは、最初に番号順、その後にアルファベット順で処理されます。この方法を使用する場合には、ファイル名に数字のプレフィックスを使用することを推奨します。以下に例を示します。
$ ls -1 ~/templates 00-node-info.yaml 10-network-isolation.yaml 20-network-environment.yaml 30-storage-environment.yaml 40-rhel-registration.yaml
以下のデプロイメントコマンドを実行してディレクトリーを追加します。
$ openstack overcloud deploy --templates --environment-directory ~/templates
回答ファイルの使用
回答ファイルは、テンプレートおよび環境ファイルの追加を簡素化する YAML ファイルです。回答ファイルでは、以下のパラメーターを使用します。
- テンプレート
-
使用するコア Heat テンプレートコレクション。これは、
--templatesのコマンドラインオプションの代わりとして機能します。 - 環境
-
追加する環境ファイルの一覧。これは、
--environment-file(-e) のコマンドラインオプションの代わりとして機能します。
たとえば、回答ファイルには以下の内容を含めることができます。
templates: /usr/share/openstack-tripleo-heat-templates/ environments: - ~/templates/00-node-info.yaml - ~/templates/10-network-isolation.yaml - ~/templates/20-network-environment.yaml - ~/templates/30-storage-environment.yaml - ~/templates/40-rhel-registration.yaml
以下のデプロイメントコマンドを実行して回答ファイルを追加します。
$ openstack overcloud deploy --answers-file ~/answers.yaml
5.8. オーバークラウドプランの管理
openstack overcloud deploy コマンドを使用する代わりに、director を使用してインポートしたプランを管理することもできます。
新規プランを作成するには、以下のコマンドを stack ユーザーとして実行します。
$ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud
このコマンドは、/usr/share/openstack-tripleo-heat-templates 内のコア Heat テンプレートコレクションからプランを作成します。director は、入力内容に基づいてプランに名前を指定します。この例では、my-overcloud という名前です。director は、この名前をオブジェクトストレージコンテナー、ワークフロー環境、オーバークラウドスタック名のラベルとして使用します。
以下のコマンドを使用して環境ファイルからパラメーターを追加します。
$ openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml
以下のコマンドを使用してプランをデプロイします。
$ openstack overcloud plan deploy my-overcloud
以下のコマンドを使用して既存のプランを削除します。
$ openstack overcloud plan delete my-overcloud
openstack overcloud deploy コマンドは基本的に、これらのコマンドをすべて使用して既存のプランの削除、環境ファイルを使用した新規プランのアップロード、プランのデプロイを行います。
5.9. オーバークラウドのテンプレートおよびプランの検証
オーバークラウドの作成またはスタックの更新を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。
レンダリングされたテンプレートの作成
オーバークラウドのコア Heat テンプレートは、Jinja2 形式となっています。テンプレートを検証するには、以下のコマンドを使用して Jinja 2 のフォーマットなしでバージョンをレンダリングします。
$ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation $ mkdir ~/overcloud-validation $ cd ~/overcloud-validation $ swift download overcloud-validation
その後の検証テストには ~/overcloud-validation のレンダリング済みテンプレートを使用します。
テンプレート構文の検証
以下のコマンドを使用して、テンプレート構文を検証します。
$ 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 オプションを追加して、ネストされたテンプレートからパラメーターを解決します。
このコマンドは、テンプレート内の構文エラーを特定します。テンプレートの構文の検証が正常に行われた場合には、出力には、作成されるオーバークラウドのテンプレートのプレビューが表示されます。
5.10. オーバークラウド作成の監視
オーバークラウドの作成プロセスが開始され、director によりノードがプロビジョニングされます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack ユーザーとして別のターミナルを開き、以下のコマンドを実行します。
$ source ~/stackrc $ openstack stack list --nested
openstack stack list --nested コマンドは、オーバークラウド作成の現在の段階を表示します。
5.11. オーバークラウドへのアクセス
director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成して、stack ユーザーのホームディレクトリーにこのファイル (overcloudrc) を保存します。このファイルを使用するには、以下のコマンドを実行します。
$ source ~/overcloudrc
これで、director のホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。director のホストとの対話に戻るには、以下のコマンドを実行します。
$ source ~/stackrc
オーバークラウドの各ノードには、heat-admin と呼ばれるユーザーが含まれます。stack ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。
$ nova list
次に、heat-admin ユーザーとノードの IP アドレスを使用して、ノードに接続します。
$ ssh heat-admin@192.168.24.23
5.12. オーバークラウド作成の完了
これで、コマンドラインツールを使用したオーバークラウドの作成が完了しました。作成後の機能については、「8章オーバークラウド作成後のタスクの実行」を参照してください。

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.