第5章 オーケストレーション

director は、オーバークラウドを作成する Heat テンプレートコレクションを使用します。このコレクションは、openstack-tripleo-heat-templatesリポジトリーの Github にある openstack グループから入手できます。このテンプレートコレクションのクローンを取得するには、以下のコマンドを実行します。

$ git clone https://github.com/openstack/tripleo-heat-templates.git

このテンプレートコレクションには、多数の Heat テンプレートおよび環境ファイルが含まれますが、注意すべき主要なファイルは以下の 3 つです。

director は、最初の 2 つのファイルを使用して、オーバークラウドの作成を開始します。このコレクション内にある他のファイルはすべて overcloud-resource-registry-puppet.yaml ファイルと子関係にあるか、独自の環境ファイルに関連する追加の機能を提供して、デプロイメントに追加できるようにします。

この章では、director がオーバークラウドの作成のオーケストレーションに使用するテンプレートの概要を説明しました。次の複数のセクションでは、オーバークラウドのデプロイメントに追加可能なカスタムのテンプレートや環境ファイルを作成する方法を説明します。

director は、オーバークラウドの初期設定時に全ノードに設定を行うメカニズムを提供し、cloud-init でこの設定をアーカイブします。アーカイブした内容は、OS::TripleO::NodeUserData リソース種別を使用して呼び出すことが可能です。

以下の例は、全ノード上でカスタム IP アドレスを使用してネームサーバーを更新することを目的とします。まず基本的な Heat テンプレート (nameserver.yaml) を作成します。このテンプレートは、固有のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。OS::TripleO::MultipartMime リソース種別を使用して、この設定スクリプトを送信します。

heat_template_version: 2014-10-16

resources:
  userdata:
    type: OS::Heat::MultipartMime
    properties:
      parts:
      - config: {get_resource: nameserver_config}

  nameserver_config:
    type: OS::Heat::SoftwareConfig
    properties:
      config: |
        #!/bin/bash
        echo "nameserver 192.168.1.1" >> /etc/resolve.conf

outputs:
  OS::stack_id:
    value: {get_resource: userdata}

次に、OS::TripleO::NodeUserData リソース種別として Heat テンプレートを登録する環境ファイル (firstboot.yaml) を作成します。

resource_registry:
  OS::TripleO::NodeUserData: nameserver.yaml

これにより、以下の操作が実行されます。

これにより、各ノードは初回起動時に以下の Bash スクリプトを実行します。

#!/bin/bash
echo "nameserver 192.168.1.1" >> /etc/resolve.conf

この例では、Heat テンプレートがあるリソースから別のリソースに設定を渡して変更する方法を示しています。また、新規の Heat リソース登録または既存のリソース変更を行う環境ファイルの使用方法も説明します。

オーバークラウドは、OpenStackコンポーネントのコア設定に Puppet を使用します。director は、初回のブートが完了してコア設定が開始する前に、カスタム設定を提供するリソースのセットを用意します。これには、以下のリソースが含まれます。

以下の例では、まず基本的な Heat テンプレート (/home/stack/templates/nameserver.yaml) を作成します。このテンプレートは、変数のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。

heat_template_version: 2014-10-16

parameters:
  server:
    type: json
  nameserver_ip:
    type: string

resources:
  ExtraPreConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolve.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}
  ExtraPreDeployment:
    type: OS::Heat::SoftwareDeployment
      properties:
        config: {get_resource: ExtraPreConfig}
        server: {get_param: server}
        actions: ['CREATE']

outputs:
  deploy_stdout:
    description: Deployment reference, used to trigger post-deploy on changes
    value: {get_attr: [ExtraPreDeployment, deploy_stdout]}

次に、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

これにより、以下の操作が実行されます。

この例は、コアの設定の前に OS::Heat::SoftwareConfig と OS::Heat::SoftwareDeployments で設定を定義してデプロイする Heat テンプレートの作成方法を示します。また、環境ファイルでパラメーターを定義して、設定でテンプレートを渡す方法も示します。

オーバークラウドの作成が完了してから、オーバークラウドの初回作成時または更新時に設定を追加する必要となる可能性があります。このような場合は、OS::TripleO::NodeExtraConfigPost リソースを使用して、標準の OS::Heat::SoftwareConfig 種別を使用した設定を適用します。これにより、メインのオーバークラウド設定が完了してから、追加の設定が適用されます。

以下の例では、まず基本的な Heat テンプレート (nameserver.yaml) を作成します。このテンプレートは、変数のネームサーバーが指定された各ノードの resolv.conf を追加するスクリプトを実行します。

heat_template_version: 2014-10-16

parameters:
  servers:
    type: json

  nameserver_ip:
    type: string

resources:

  ExtraConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolve.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  ExtraDeployments:
    type: OS::Heat::SoftwareDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ExtraConfig}
      actions: ['CREATE']

次に、OS::TripleO::NodeExtraConfigPost リソース種別として Heat テンプレートを登録する環境ファイル (post_config.yaml) を作成します。

resource_registry:
  OS::TripleO::NodeExtraConfigPost: nameserver.yaml
parameter_defaults:
  nameserver_ip: 192.168.1.1

これにより、以下の操作が実行されます。

この例は、OS::Heat::SoftwareConfig と OS::Heat::SoftwareDeployments で設定を定義してデプロイする Heat テンプレートの作成方法を示します。また、環境ファイルでパラメーターを定義して、設定でテンプレートを渡す方法も示します。

これまで、新規バックエンドの設定を 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'],
}

Puppet の設定は、cinder::backend::nfs の定義型を使用して新規リソースを作成します。Heat を使用してこのリソースを適用するには、Puppet マニフェストを実行する基本的な Heat テンプレート (puppet-config.yaml) を作成します。

heat_template_version: 2014-10-16

parameters:
  servers:
    type: json

resources:
  ExtraPuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: puppet
      config:
        get_file: example-puppet-manifest.pp
      options:
        enable_hiera: True
        enable_facter: False

  ExtraPuppetDeployment:
    type: OS::Heat::SoftwareDeployments
    properties:
      config: {get_resource: ExtraPuppetConfig}
      servers: {get_param: servers}
      actions: ['CREATE','UPDATE']

次に、OS::TripleO::NodeExtraConfigPost リソース種別として Heat テンプレートを登録する環境ファイル (puppet_config.yaml) を作成します。

resource_registry:
  OS::TripleO::NodeExtraConfigPost: puppet_config.yaml

この例は前項の script フックの例から SoftwareConfig と SoftwareDeployments を使用するのに似ていますが、以下の点が異なります。

この例では、Puppet マニフェストをオーバークラウドのソフトウェア設定の一部として追加する方法を示します。これにより、オーバークラウドのイメージで既存の Puppet モジュールから特定の設定クラスを適用する方法ができ、特定のソフトウェアやハードウェアを使用するようにオーバークラウドをカスタマイズしやすくなります。

前述したように、Puppet は Hiera ツールを使用して特定の変数にノード固有の値を指定します。これらのキーと値は通常、/etc/puppet/hieradata にあるファイルに保存されます。オーバークラウドでは、このディレクトリーには、カスタムパラメーターを追加する際に使用する、追加の Hiera ファイルのセットが含まれます。

director の Heat テンプレートコレクションにあるパラメーターセットを使用してこの Hiera データを渡します。これらのパラメーターは以下のとおりです。

デプロイ後の設定プロセスに設定を追加するには、parameter_defaults セクションにこれらのパラメーターが記載された環境ファイルを作成します。たとえば、コンピュートホストに確保するメモリーを 1024 MB に増やすには、以下のように設定します。

parameter_defaults:
  NovaComputeExtraConfig:
    nova::compute::reserved_host_memory: 1024

これにより、コンピュートノードの /etc/puppet/hieradata ディレクトリーにあるカスタムの Hiera ファイルに nova::compute::reserved_host_memory: 1024 が追加されます。

カスタム設定に関連する環境ファイルセットを開発した後に、オーバークラウドにこれらのファイルを追加します。これには、-e オプションの後に環境ファイルを指定して openstack overcloud deploy コマンドを実行します。カスタマイズに必要な回数だけ、-e オプションを指定することができます。

$ openstack overcloud deploy --templates -e network-configuration.yaml -e storage-configuration.yaml -e first-boot.yaml

[[Integration Points]] == Integration Points

本章では、director の統合における具体的な統合ポイントを考察し、固有の OpenStack コンポーネントと director またはオーバークラウドの統合とそのコンポーネントの関係について記載します。このセクションに記載する内容は、OpenStack のすべての統合についての包括的な説明ではありませんが、ハードウェアおよびソフトウェアを Red Hat OpenStack Platform に統合する作業を開始するには十分な情報となるはずです。

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 を参照してください。

アップストリームのリポジトリー:

アップストリームのブループリント:

Puppet モジュール:

Bugzilla コンポーネント:

統合メモ:

OpenStack Networking (Neutron) は、クラウド環境でネットワークアーキテクチャーを作成する機能を提供します。このプロジェクトは、Software Defined Networking (SDN) ベンダーの統合ポイントを複数提供します。この統合ポイントは通常 プラグイン または エージェント のカテゴリーに分類されます。

プラグイン では、既存の Neutron の機能を拡張およびカスタマイズすることができます。ベンダーは、プラグインを記述して、Neutron と認定済みのソフトウェアやハードウェアの間で相互運用性を確保することができます。多くのベンダーは、独自のドライバーを統合するためのモジュラーバックエンドを提供する、Neutron の Modular Layer 2 (ml2) プラグインのドライバーを開発することを目的にする必要があります。

エージェント では、固有のネットワーク機能が提供されます。主な Neutron サーバー (およびプラグイン) は、Neutron エージェントと通信します。既存の例には、DHCP、Layer 3 のサポート、ブリッジサポートが含まれます。

プラグインおよびエージェントは、以下のいずれかが可能です。

認定済みのハードウェアおよびソフトウェアを統合する方法を判断できるように、既存のプラグインおよびエージェントの機能を分析することを推奨します。特に、ml2 プラグインの一部としてドライバーをまず開発することを推奨します。

アップストリームのリポジトリー:

アップストリームのブループリント:

Puppet モジュール:

Bugzilla コンポーネント:

統合メモ:

OpenStack Block Storage (Cinder) は、OpenStack がボリュームの作成に使用するブロックストレージデバイスと対話するための API を提供します。たとえば、Cinder はインスタンスの仮想ストレージデバイスや、異なるストレージハードウェアやプロトコルをサポートするドライバーのコアセットを提供します。コアのドライバーには、NFS、iSCSI、Red Hat Ceph Storage へのサポートを含むものもあります。ベンダーは、認定済みのハードウェアのサポートを追加するためにドライバーを含めることができます。

ベンダーの開発するドライバーおよび設定には、主に 2 つのオプションがあります。

認定済みのハードウェアおよびソフトウェアを統合する方法を判断できるように、既存のドライバーの機能を分析することを推奨します。

アップストリームのリポジトリー:

アップストリームのブループリント:

Puppet モジュール:

Bugzilla コンポーネント:

統合メモ:

OpenStack Image Storage (Cinder) は、イメージのストレージを提供するストレージ種別と対話するための API を提供します。Glance は、ファイルのサポート、OpenStack Object Storage (Swift)、OpenStack Block Storage (Cinder)、Red Hat Ceph Storage など、異なるハードウェアおよびプロトコルをサポートするドライバーのコアセットを提供します。ベンダーは、認定済みのハードウェアのサポートを追加するためにドライバーを含めることができます。

アップストリームのリポジトリー:

アップストリームのブループリント:

Puppet モジュール:

Bugzilla コンポーネント:

統合メモ:

OpenStack Shared File System Service (Manila) は、共有および分散型のファイルシステムサービス向けの API を提供します。ベンダーは、認定済みのハードウェアのサポートを追加するためにドライバーを含めることができます。

アップストリームのリポジトリー:

アップストリームのブループリント:

Puppet モジュール:

Bugzilla コンポーネント:

統合メモ: