第5章 オーケストレーション
director は Heat Orchestration Template (HOT) をオーバークラウドデプロイメントプランのテンプレート形式として使用します。HOT 形式のテンプレートは多くの場合に、YAML 形式で表現されます。テンプレートの目的は、リソースごとの設定や Heat が作成するリソースコレクションであるスタックを定義して作成することです。リソースとは、OpenStack のオブジェクトで、コンピュートリソース、ネットワーク設定、セキュリティーグループ、スケーリングルール、カスタムリソースが含まれる場合があります。
本章では、独自のテンプレートファイルを作成できるように HOT 構文を理解するための基本を説明します。
5.1. Heat テンプレートの基礎知識 リンクのコピーリンクがクリップボードにコピーされました!
5.1.1. Heat テンプレートの理解 リンクのコピーリンクがクリップボードにコピーされました!
Heat テンプレートの構造には主に 3 つのセクションが含まれます。
Heat テンプレートの構造には主に 3 つのセクションが含まれます。
- Parameters
-
Prameters は Heat に渡される設定のことで、値を指定せずにパラメーターのデフォルト値やスタックをカスタマイズする方法を提供します。これらは、テンプレートの
parametersセクションで定義されます。 - Resources
-
Resources とはスタックの一部として作成/設定する固有のオブジェクトのことです。OpenStack には全コンポーネントに対応するコアのリソースセットが含まれています。これらの設定は、テンプレートの
resourcesセクションで定義されます。 - Output
-
Output は、スタックの作成後に Heat から渡される値です。これらの値には、Heat API またはクライアントツールを使用してアクセスすることができます。これらは、テンプレートの
outputセクションで定義されます。
以下に、基本的な Heat テンプレートの例を示します。
このテンプレートは、type: OS::Nova::Server のリソース種別を使用して、特定のフレーバー、イメージ、キーを指定した my_instance と呼ばれるインスタンスを作成します。このスタックは、My Cirros Instance という instance_name の値を返します。
Heat テンプレートは、利用可能な関数や使用する構文のバージョンを定義する heat_template_version パラメーターも必要とします。詳しい情報は Heat の正式なドキュメント を参照してください。
5.1.2. 環境ファイルの理解 リンクのコピーリンクがクリップボードにコピーされました!
環境ファイルとは、Heat テンプレートをカスタマイズする特別な種類のテンプレートです。このファイルは、3 つの主要な部分で構成されます。
- Parameters
-
これらは、テンプレートのパラメーターに適用する共通設定で、環境ファイルの
parametersセクションで定義します。 - Parameter Defaults
-
これらのパラメーターは、テンプレートのパラメーターのデフォルト値を変更します。これらの設定は、環境ファイルの
parameter_defaultsセクションで定義します。 - Resource Registry
-
このセクションでは、カスタムのリソース名と、他の Heat テンプレートへのリンクを定義します。これは実質的に、コアリソースコレクションに存在しないカスタムのリソースを作成する方法を提供します。この設定は、環境ファイルの
resource_registryセクションで定義されます。
以下に基本的な環境ファイルの例を示します。
このファイルにより、OS::Nova::Server::MyServer と呼ばれる新しいリソース種別が作成されます。myserver.yaml ファイルは、このリソース種別を実装する Heat テンプレートファイルで、このファイルでの設定が元の設定よりも優先されます。
5.2. デフォルトの director テンプレートの取得 リンクのコピーリンクがクリップボードにコピーされました!
director は、オーバークラウドを作成する Heat テンプレートコレクションを使用します。このコレクションは、openstack-tripleo-heat-templatesリポジトリーの Github にある openstack グループから入手できます。このテンプレートコレクションのクローンを取得するには、以下のコマンドを実行します。
git clone https://github.com/openstack/tripleo-heat-templates.git
$ git clone https://github.com/openstack/tripleo-heat-templates.git
このテンプレートコレクションの Red Hat 固有のバージョンは、openstack-tripleo-heat-template パッケージから取得できます。このパッケージは、コレクションを /usr/share/openstack-tripleo-heat-templates にインストールします。
このテンプレートコレクションには、多数の Heat テンプレートおよび環境ファイルが含まれますが、注意すべき主要なファイルは以下の 3 つです。
overcloud-without-mergepy.yaml- これはオーバークラウド環境を作成するために使用する主要なテンプレートファイルです。
overcloud-resource-registry-puppet.yaml- これは、オーバークラウド環境の作成に使用する主要な環境ファイルで、オーバークラウドイメージ上に保存される Puppet モジュールの設定セットを提供します。director により各ノードにオーバークラウドのイメージが書き込まれると、Heat は環境ファイルに登録されているリソースを使用して各ノードに Puppet の設定を開始します。
overcloud-resource-registry.yaml- これは、オーバークラウド環境の作成に使用する標準の環境ファイルです。overcloud-resource-registry-puppet.yaml は、このファイルをベースにしており、お使いの環境をカスタム設定する際に使用します。
director は、最初の 2 つのファイルを使用して、オーバークラウドの作成を開始します。このコレクション内にある他のファイルはすべて overcloud-resource-registry-puppet.yaml ファイルと子関係にあるか、独自の環境ファイルに関連する追加の機能を提供して、デプロイメントに追加できるようにします。
environments-
オーバークラウドの作成に使用可能な Heat 環境ファイルが追加で含まれます。これらの環境ファイルは、作成された OpenStack 環境の追加の機能を有効にします。たとえば、ディレクトリーには Cinder NetApp のバックエンドストレージ (
cinder-netapp-config.yaml) を有効にする環境ファイルが含まれています。 extraconfig-
追加の機能を有効化するために使用するテンプレート。たとえば、director が提供する
extraconfig/pre_deploy/rhel-registrationは、ノードの Red Hat Enterprise Linux オペレーティングシステムを Red Hat コンテンツ配信ネットワークまたは Red Hat Satelite サーバーに登録できるようにします。 firstboot-
ノードを最初に作成する際に director が使用する
first_bootスクリプトを提供します。 network- 分離ネットワークおよびポートを作成しやすくする Heat テンプレートセット
puppet-
大部分は Puppet を使用した設定によって動作するテンプレート。前述した
overcloud-resource-registry-puppet.yaml環境ファイルは、このディレクトリーのファイルを使用して、各ノードに Puppet の設定が適用されるようにします。 validation-scripts- すべてのデプロイメント設定に有用な検証スクリプトが含まれます。
この章では、director がオーバークラウドの作成のオーケストレーションに使用するテンプレートの概要を説明しました。次の複数のセクションでは、オーバークラウドのデプロイメントに追加可能なカスタムのテンプレートや環境ファイルを作成する方法を説明します。
5.3. 初回起動での設定のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
director は、オーバークラウドの初期設定時に全ノードに設定を行うメカニズムを提供し、cloud-init でこの設定をアーカイブします。アーカイブした内容は、OS::TripleO::NodeUserData リソース種別を使用して呼び出すことが可能です。
以下の例は、全ノード上でカスタム IP アドレスを使用してネームサーバーを更新することを目的とします。まず基本的な Heat テンプレート (nameserver.yaml) を作成します。このテンプレートは、固有のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。OS::TripleO::MultipartMime リソース種別を使用して、この設定スクリプトを送信します。
次に、OS::TripleO::NodeUserData リソース種別として Heat テンプレートを登録する環境ファイル (firstboot.yaml) を作成します。
resource_registry: OS::TripleO::NodeUserData: nameserver.yaml
resource_registry:
OS::TripleO::NodeUserData: nameserver.yaml
これにより、以下の操作が実行されます。
-
OS::TripleO::NodeUserDataは、コレクション内の他のテンプレートで使用する director ベースの Heat リソースで、全ノードに対して初回起動の設定を適用します。このリソースは、cloud-initで使用するデータを渡します。デフォルトのNodeUserDataは、空の値 (firstboot/userdata_default.yaml) を指定する Heat テンプレートを参照します。この例では、firstboot.yamlの環境ファイルは、このデフォルトを独自のnameserver.yamlファイルへの参照に置き換えます。 -
nameserver_configは、初回起動で実行する Bash スクリプトを定義します。OS::Heat::SoftwareConfigリソースは、適用する設定としてこれを定義します。 -
userdataは、OS::Heat::MultipartMimeリソースを使用して、nameserver_configから複数のパートからなる MIME メッセージに設定を変換します。 -
outputsでは、output パラメーターのOS::stack_idが提供され、userdataから MIME メッセージを呼び出している Heat テンプレート/リソースに渡します。
これにより、各ノードは初回起動時に以下の Bash スクリプトを実行します。
#!/bin/bash echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/bash
echo "nameserver 192.168.1.1" >> /etc/resolve.conf
この例では、Heat テンプレートがあるリソースから別のリソースに設定を渡して変更する方法を示しています。また、新規の Heat リソース登録または既存のリソース変更を行う環境ファイルの使用方法も説明します。
5.4. オーバークラウドを構成する前の設定のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドは、OpenStackコンポーネントのコア設定に Puppet を使用します。director は、初回のブートが完了してコア設定が開始する前に、カスタム設定を提供するリソースのセットを用意します。これには、以下のリソースが含まれます。
- OS::TripleO::ControllerExtraConfigPre
- Puppet のコア設定前にコントローラーノードに適用される追加の設定
- OS::TripleO::ComputeExtraConfigPre
- Puppet のコア設定前にコンピュートノードに適用される追加の設定
- OS::TripleO::CephStorageExtraConfigPre
- Puppet のコア設定前に CephStorage ノードに適用される追加の設定
- OS::TripleO::NodeExtraConfig
- Puppet のコア設定前に全ノードに適用される追加の設定
以下の例では、まず基本的な Heat テンプレート (/home/stack/templates/nameserver.yaml) を作成します。このテンプレートは、変数のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。
servers パラメーターは、設定を適用するサーバー一覧で、親テンプレートにより提供されます。このパラメーターは、 すべての 事前設定テンプレートで必須です。
次に、OS::TripleO::NodeExtraConfig リソース種別として Heat テンプレートを登録する環境ファイル (/home/stack/templates/pre_config.yaml) を作成します。
resource_registry: OS::TripleO::NodeExtraConfig: nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::NodeExtraConfig: nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
これにより、以下の操作が実行されます。
-
OS::TripleO::NodeExtraConfigは、Heat テンプレートコレクション内の設定テンプレートで使用する director ベースの Heat リソースです。このリソースは、*-puppet.yamlを使用して各ノード種別に設定を渡します。デフォルトのNodeExtraConfigは、空の値 (puppet/extraconfig/pre_deploy/default.yaml) を指定する Heat テンプレートを参照します。この例では、pre_config.yamlの環境ファイルは、このデフォルトを独自のnameserver.yamlファイルへの参照に置き換えます。 -
環境ファイルは、この環境の
parameter_defaultの値としてnameserver_ipを渡します。これは、ネームサーバーの IP アドレスを保存するパラメーターです。nameserver.yamlの Heat テンプレートは、parametersセクションで定義されているとおりに、このパラメーターを受け入れます。 -
このテンプレートは、
OS::Heat::SoftwareConfigを使用して設定リソースとしてExtraPreConfigを定義します。group: scriptプロパティーに注意してください。groupは、使用するソフトウェア設定ツールを定義します。このソフトウェア設定ツールは Heat のフックセットで入手できます。この場合は、scriptフックは、SoftwareConfigリソースでconfigとして定義される実行可能なスクリプトを実行します。 このスクリプト自体は、
/etc/resolve.confにネームサーバーの IP アドレスを追加します。str_replaceの属性に注意してください。これにより、templateセクションの変数をparamsセクションのパラメーターに置き換えることが可能となります。この場合は、NAMESERVER_IP をネームサーバーの IP アドレスに設定します。スクリプト内の同じ変数はこの IP アドレスに置き換えられ、その結果、スクリプトは以下のようになります。#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow ExtraPreDeploymentsはExtraPreConfig設定をノードにデプロイします。以下の点に注意してください。-
config属性は、Heat がどの設定が適用されるかを理解できるようにExtraPreConfigリソースを参照します。 -
servers属性は、overcloud-without-mergepy.yamlが渡すオーバークラウドのノードのマッピングを取得します。 -
actions属性は、設定を適用するタイミングを定義します。この場合は、オーバークラウドが作成された時にのみ設定を適用します。実行可能なアクションはCREATE、UPDATE、DELETE、SUSPENDおよびRESUMEです。
-
この例は、コアの設定の前に OS::Heat::SoftwareConfig と OS::Heat::SoftwareDeployments で設定を定義してデプロイする Heat テンプレートの作成方法を示します。また、環境ファイルでパラメーターを定義して、設定でテンプレートを渡す方法も示します。
5.5. オーバークラウド設定後の設定のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドの作成が完了してから、オーバークラウドの初回作成時または更新時に設定を追加する必要となる可能性があります。このような場合は、OS::TripleO::NodeExtraConfigPost リソースを使用して、標準の OS::Heat::SoftwareConfig 種別を使用した設定を適用します。これにより、メインのオーバークラウド設定が完了してから、追加の設定が適用されます。
以下の例では、まず基本的な Heat テンプレート (nameserver.yaml) を作成します。このテンプレートは、変数のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。
servers パラメーターは、設定を適用するサーバー一覧で、親テンプレートにより提供されます (overcloud-without-mergepy.yaml)。このパラメーターは、 すべての OS::TripleO::NodeExtraConfigPost テンプレートで必須です。
次に、OS::TripleO::NodeExtraConfigPost リソース種別として Heat テンプレートを登録する環境ファイル (post_config.yaml) を作成します。
resource_registry: OS::TripleO::NodeExtraConfigPost: nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::NodeExtraConfigPost: nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
これにより、以下の操作が実行されます。
-
OS::TripleO::NodeExtraConfigPostは、Heat テンプレートコレクション内の設定テンプレートで使用する director ベースの Heat リソースです。このリソースは、*-post.yamlを使用して各ノード種別に設定を渡します。デフォルトのNodeExtraConfigPostは、空の値 (extraconfig/post_deploy/default.yaml) を指定する Heat テンプレートを参照します。この例では、post_config.yamlの環境ファイルは、このデフォルトを独自のnameserver.yamlファイルへの参照に置き換えます。 -
環境ファイルは、この環境の
parameter_defaultの値としてnameserver_ipを渡します。これは、ネームサーバーの IP アドレスを保存するパラメーターです。nameserver.yamlの Heat テンプレートは、parametersセクションで定義されているとおりに、このパラメーターを受け入れます。 -
このテンプレートは、
OS::Heat::SoftwareConfigを使用して設定リソースとしてExtraConfigを定義します。group: scriptプロパティーに注意してください。groupは、使用するソフトウェア設定ツールを定義します。このソフトウェア設定ツールは Heat のフックセットで入手できます。この場合は、scriptフックは、SoftwareConfigリソースでconfigとして定義される実行可能なスクリプトを実行します。 このスクリプト自体は、
/etc/resolve.confにネームサーバーの IP アドレスを追加します。str_replaceの属性に注意してください。これにより、templateセクションの変数をparamsセクションのパラメーターに置き換えることが可能となります。この場合は、NAMESERVER_IP をネームサーバーの IP アドレスに設定します。スクリプト内の同じ変数はこの IP アドレスに置き換えられ、その結果、スクリプトは以下のようになります。#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow ExtraDeploymentsはExtraConfig設定をノードにデプロイします。以下の点に注意してください。-
config属性は、Heat がどの設定が適用されるかを理解できるようにExtraConfigリソースを参照します。 -
servers属性は、overcloud-without-mergepy.yamlが渡すオーバークラウドのノードのマッピングを取得します。 -
actions属性は、設定を適用するタイミングを定義します。この場合は、オーバークラウドが作成された時にのみ設定を適用します。実行可能なアクションはCREATE、UPDATE、DELETE、SUSPENDおよびRESUMEです。
-
この例は、OS::Heat::SoftwareConfig と OS::Heat::SoftwareDeployments で設定を定義してデプロイする Heat テンプレートの作成方法を示します。また、環境ファイルでパラメーターを定義して、設定でテンプレートを渡す方法も示します。
5.6. カスタムの Puppet 設定のオーバークラウドへの適用 リンクのコピーリンクがクリップボードにコピーされました!
これまで、新規バックエンドの設定を OpenStack Puppet モジュールに追加する方法を説明しました。このセクションでは、director が新規設定を適用する方法を説明します。
Heat テンプレートは、OS::Heat::SoftwareConfig リソースで Puppet 設定を適用可能なフックを提供します。このプロセスは、Bash スクリプトを追加して実行した方法に似ていますが、group: script フックを使用するのではなく、group: puppet フックを使用します。
たとえば、公式の Cinder Puppet モジュールを使用して NFS Cinder バックエンドを有効化する Puppet マニフェスト (example-puppet-manifest.pp) があるとします。
cinder::backend::nfs { 'mynfsserver':
nfs_servers => ['192.168.1.200:/storage'],
}
cinder::backend::nfs { 'mynfsserver':
nfs_servers => ['192.168.1.200:/storage'],
}
Puppet の設定は、cinder::backend::nfs の定義型を使用して新規リソースを作成します。Heat を使用してこのリソースを適用するには、Puppet マニフェストを実行する基本的な Heat テンプレート (puppet-config.yaml) を作成します。
次に、OS::TripleO::NodeExtraConfigPost リソース種別として Heat テンプレートを登録する環境ファイル (puppet_config.yaml) を作成します。
resource_registry: OS::TripleO::NodeExtraConfigPost: puppet_config.yaml
resource_registry:
OS::TripleO::NodeExtraConfigPost: puppet_config.yaml
この例は前項の script フックの例から SoftwareConfig と SoftwareDeployments を使用するのに似ていますが、以下の点が異なります。
-
puppetフックを実行するためにgroup: puppetを設定します。 -
config属性はget_file属性を使用して、追加の設定が含まれる Puppet マニフェストを参照します。 options属性には、Puppet 設定固有のオプションが含まれます。-
enable_hieraオプションは、Puppet 設定で Hiera データを使用できるようにします。 -
enable_facterオプションは、facterコマンドからシステムファクトを使用する Puppet 設定を有効にします。
-
この例では、Puppet マニフェストをオーバークラウドのソフトウェア設定の一部として追加する方法を示します。これにより、オーバークラウドのイメージで既存の Puppet モジュールから特定の設定クラスを適用する方法ができ、特定のソフトウェアやハードウェアを使用するようにオーバークラウドをカスタマイズしやすくなります。
5.7. オーバークラウドでの Hiera データの変更 リンクのコピーリンクがクリップボードにコピーされました!
前述したように、Puppet は Hiera ツールを使用して特定の変数にノード固有の値を指定します。これらのキーと値は通常、/etc/puppet/hieradata にあるファイルに保存されます。オーバークラウドでは、このディレクトリーには、カスタムパラメーターを追加する際に使用する、追加の Hiera ファイルのセットが含まれます。
director の Heat テンプレートコレクションにあるパラメーターセットを使用してこの Hiera データを渡します。これらのパラメーターは以下のとおりです。
- ExtraConfig
- 全ノードに追加する設定
- NovaComputeExtraConfig
- コンピュートノードに追加する設定
- controllerExtraConfig
- コントローラーノードに追加する設定
- BlockStorageExtraConfig
- ブロックストレージノードに追加する設定
- ObjectStorageExtraConfig
- オブジェクトストレージノードに追加する設定
- CephStorageExtraConfig
- Ceph ストレージノードに追加する設定
デプロイ後の設定プロセスに設定を追加するには、parameter_defaults セクションにこれらのパラメーターが記載された環境ファイルを作成します。たとえば、コンピュートホストに確保するメモリーを 1024 MB に増やすには、以下のように設定します。
parameter_defaults:
NovaComputeExtraConfig:
nova::compute::reserved_host_memory: 1024
parameter_defaults:
NovaComputeExtraConfig:
nova::compute::reserved_host_memory: 1024
これにより、コンピュートノードの /etc/puppet/hieradata ディレクトリーにあるカスタムの Hiera ファイルに nova::compute::reserved_host_memory: 1024 が追加されます。
5.8. オーバークラウドのデプロイメントへの環境ファイルの追加 リンクのコピーリンクがクリップボードにコピーされました!
カスタム設定に関連する環境ファイルセットを開発した後に、オーバークラウドにこれらのファイルを追加します。これには、-e オプションの後に環境ファイルを指定して openstack overcloud deploy コマンドを実行します。カスタマイズに必要な回数だけ、-e オプションを指定することができます。
openstack overcloud deploy --templates -e network-configuration.yaml -e storage-configuration.yaml -e first-boot.yaml
$ openstack overcloud deploy --templates -e network-configuration.yaml -e storage-configuration.yaml -e first-boot.yaml
環境ファイルは、順序通りにスタックされます。これは、主要な Heat テンプレートコレクションとこれまでの全環境ファイル両方の上に後続のファイルがスタックされることを意味します。この方法により、リソースの定義の上書きが可能となります。たとえば、オーバークラウドのデプロイメントにある全環境ファイルは NodeExtraConfigPost リソースを定義し、その後に Heat は最後の環境ファイルで定義した NodeExtraConfigPost を使用します。そのため、環境ファイルの順序は重要です。環境ファイルを正しく処理してスタックできるように、環境ファイルは順序付けるようにしてください。
-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。director は、再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する場合があります。
[[Integration Points]] == Integration Points
本章では、director の統合における具体的な統合ポイントを考察し、固有の OpenStack コンポーネントと director またはオーバークラウドの統合とそのコンポーネントの関係について記載します。このセクションに記載する内容は、OpenStack のすべての統合についての包括的な説明ではありませんが、ハードウェアおよびソフトウェアを Red Hat OpenStack Platform に統合する作業を開始するには十分な情報となるはずです。
5.9. Bare Metal Provisioning (Ironic) リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Bare Metal Provisioning (Ironic) のコンポーネントは、director 内で使用され、ノードの電源状態を制御します。director はバックエンドドライバーのセットを使用して、固有のベアメタルの電源コントローラーとやりとりをします。これらのドライバーは、ハードウェアやベンダー固有の拡張や機能を有効化する際に重要です。最も一般的なドライバーは IPMI ドライバー (pxe_ipmitool) で、Intelligent Platform Management Interface (IPMI) をサポートするサーバーの電源状態を制御します。
Ironic との統合は、アップストリームの OpenStack コミュニティーから始まります。アップストリームで受け入れられた Ironic ドライバーは、コアの Red Hat OpenStack Platform 製品と director にデフォルトで自動的に含まれますが、認定要件によりサポートされない可能性があります。
機能が継続して確保されるように、ハードウェアドライバーは、常に統合テストを受ける必要があります。サードパーティー製のドライバーのテストおよび持続性に関する情報は、OpenStack コミュニティーページの Ironic Testing を参照してください。
アップストリームのリポジトリー:
アップストリームのブループリント:
- Launchpad: http://launchpad.net/ironic
Puppet モジュール:
Bugzilla コンポーネント:
- openstack-ironic
- python-ironicclient
- python-ironic-oscplugin
- openstack-ironic-discoverd
- openstack-puppet-modules
- openstack-tripleo-heat-templates
統合メモ:
-
アップストリームプロジェクトでは、
ironic/driversディレクトリーにドライバーが含まれます。 -
director は、JSON ファイルで定義されたノードをまとめて登録します。
os-cloud-configツール (https://github.com/openstack/os-cloud-config/) は、このファイルを解析して、ノード登録の詳細を判断して登録を実行します。これは、os-cloud-configツール、具体的にはnodes.pyファイルにはドライバーのサポートが必要です。 director は、Ironic を使用するように自動的に設定されます。つまり、Puppet 設定では、変更をほぼ加える必要はないということです。ただし、ドライバーに Ironic が含まれる場合には、お使いのドライバーを
/etc/ironic/ironic.confファイルに追加する必要があります。このファイルを編集してenabled_driversパラメーターを検索してください。以下に例を示します。enabled_drivers=pxe_ipmitool,pxe_ssh,pxe_drac
enabled_drivers=pxe_ipmitool,pxe_ssh,pxe_dracCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
driversディレクトリーからの指定のドライバーを Ironic が使用できるようになります。
5.10. Networking (Neutron) リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Networking (Neutron) は、クラウド環境でネットワークアーキテクチャーを作成する機能を提供します。このプロジェクトは、Software Defined Networking (SDN) ベンダーの統合ポイントを複数提供します。この統合ポイントは通常 プラグイン または エージェント のカテゴリーに分類されます。
プラグイン では、既存の Neutron の機能を拡張およびカスタマイズすることができます。ベンダーは、プラグインを記述して、Neutron と認定済みのソフトウェアやハードウェアの間で相互運用性を確保することができます。多くのベンダーは、独自のドライバーを統合するためのモジュラーバックエンドを提供する、Neutron の Modular Layer 2 (ml2) プラグインのドライバーを開発することを目的にする必要があります。
エージェント では、固有のネットワーク機能が提供されます。主な Neutron サーバー (およびプラグイン) は、Neutron エージェントと通信します。既存の例には、DHCP、Layer 3 のサポート、ブリッジサポートが含まれます。
プラグインおよびエージェントは、以下のいずれかが可能です。
- OpenStack Platform ソリューションの一部としてディストリビューションに含める。
- OpenStack Platform のディストリビューションの後にオーバークラウドのイメージに追加する。
認定済みのハードウェアおよびソフトウェアを統合する方法を判断できるように、既存のプラグインおよびエージェントの機能を分析することを推奨します。特に、ml2 プラグインの一部としてドライバーをまず開発することを推奨します。
アップストリームのリポジトリー:
アップストリームのブループリント:
- Launchpad: http://launchpad.net/neutron
Puppet モジュール:
Bugzilla コンポーネント:
- openstack-neutron
- python-neutronclient
- openstack-puppet-modules
- openstack-tripleo-heat-templates
統合メモ:
アップストリームの
neutronプロジェクトには、複数の統合ポイントが含まれます。-
プラグインは
neutron/plugins/にあります。 -
ml2 プラグインドライバーは
neutron/plugins/ml2/drivers/にあります。 -
エージェントは
neutron/agents/にあります。
-
プラグインは
-
OpenStack Liberty リリース以降、ベンダー固有の ml2 プラグインの多くが
networking-で始まる独自のリポジトリーに移動されました。たとえば、Cisco 固有のプラグインは https://github.com/openstack/networking-cisco にあります。 puppet-neutronリポジトリーには、これらの統合の設定用に別のディレクトリーも含まれます。-
プラグイン設定は
manifests/plugins/にあります。 -
ml2 プラグインのドライバー設定は
manifests/plugins/ml2/にあります。 -
エージェントの設定は
manifests/agents/にあります。
-
プラグイン設定は
-
puppet-neutronリポジトリーには、設定関数のライブラリーが別途多数含まれています。たとえば、neutron_plugin_ml2ライブラリーは、ml2 プラグインの設定ファイルに属性を追加する関数を追加します。
5.11. Block Storage (Cinder) リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Block Storage (Cinder) は、OpenStack がボリュームの作成に使用するブロックストレージデバイスと対話するための API を提供します。たとえば、Cinder はインスタンスの仮想ストレージデバイスや、異なるストレージハードウェアやプロトコルをサポートするドライバーのコアセットを提供します。コアのドライバーには、NFS、iSCSI、Red Hat Ceph Storage へのサポートを含むものもあります。ベンダーは、認定済みのハードウェアのサポートを追加するためにドライバーを含めることができます。
ベンダーの開発するドライバーおよび設定には、主に 2 つのオプションがあります。
- OpenStack Platform ソリューションの一部としてディストリビューションに含める。
- OpenStack Platform のディストリビューションの後にオーバークラウドのイメージに追加する。
認定済みのハードウェアおよびソフトウェアを統合する方法を判断できるように、既存のドライバーの機能を分析することを推奨します。
アップストリームのリポジトリー:
アップストリームのブループリント:
- Launchpad: http://launchpad.net/cinder
Puppet モジュール:
Bugzilla コンポーネント:
- openstack-cinder
- python-cinderclient
- openstack-puppet-modules
- openstack-tripleo-heat-templates
統合メモ:
-
アップストリームの
cinderリポジトリーではcinder/volume/drivers/にドライバーが含まれます。 puppet-cinderリポジトリーには、ドライバー設定の主要なディレクトリーが 2 つ含まれます。-
manifests/backendディレクトリーには、ドライバーの設定を行う定義型のセットが含まれます。 -
manifests/volumeディレクトリーには、デフォルトのブロックストレージデバイスを設定するクラスセットが含まれます。
-
-
puppet-cinderリポジトリーには、Cinder 設定ファイルに属性を追加するためのcinder_configと呼ばれるライブラリーが含まれます。
5.12. Image Storage (Glance) リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Image Storage (Cinder) は、イメージのストレージを提供するストレージ種別と対話するための API を提供します。Glance は、ファイルのサポート、OpenStack Object Storage (Swift)、OpenStack Block Storage (Cinder)、Red Hat Ceph Storage など、異なるハードウェアおよびプロトコルをサポートするドライバーのコアセットを提供します。ベンダーは、認定済みのハードウェアのサポートを追加するためにドライバーを含めることができます。
アップストリームのリポジトリー:
OpenStack:
GitHub:
アップストリームのブループリント:
- Launchpad: http://launchpad.net/glance
Puppet モジュール:
Bugzilla コンポーネント:
- openstack-glance
- python-glanceclient
- openstack-puppet-modules
- openstack-tripleo-heat-templates
統合メモ:
- Glance は、イメージストレージを管理する統合ポイントを含む Cinder を使用できるため、ベンダー固有のドライバーを追加する必要はありません。
-
アップストリームの
glance_storeリポジトリーではglance_store/_driversにドライバーが含まれます。 -
puppet-glanceリポジトリーではmanifests/backendディレクトリーにドライバー設定が含まれます。 -
puppet-glanceリポジトリーには、Cinder 設定ファイルに属性を追加するためのglance_api_configと呼ばれるライブラリーが含まれます。