Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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

director は Heat Orchestration Template (HOT) をオーバークラウドデプロイメントプランのテンプレート形式として使用します。HOT 形式のテンプレートは多くの場合に、YAML 形式で表現されます。テンプレートの目的は、リソースごとの設定や Heat が作成するリソースコレクションであるスタックを定義して作成することです。リソースとは、OpenStack のオブジェクトで、コンピュートリソース、ネットワーク設定、セキュリティーグループ、スケーリングルール、カスタムリソースが含まれる場合があります。

本章では、独自のテンプレートファイルを作成できるように HOT 構文を理解するための基本を説明します。

5.1. Heat テンプレートの基本学習

5.1.1. Heat テンプレートの理解

Heat テンプレートの構造には主に 3 つのセクションが含まれます。
parameters
prameters は Heat に渡される設定で、値を指定せずにパラメーターのデフォルト値やスタックをカスタマイズする方法を提供します。これらは、テンプレートの parameters セクションで定義されます。
resources
resources はスタックの一部として作成/設定する固有のオブジェクトです。OpenStack には全コンポーネントに対応するコアのリソースセットが含まれています。これらの設定は、テンプレートの resources セクションで定義されます。
output
output は、スタックの作成後に Heat から渡される値です。これらの値には、Heat API またはクライアントツールを使用してアクセスすることができます。これらは、テンプレートの output セクションで定義されます。

以下に、基本的な Heat テンプレートの例を示します。

heat_template_version: 2013-05-23

description: > A very basic Heat template.

parameters:
  key_name:
    type: string
    default: lars
    description: Name of an existing key pair to use for the instance
  flavor:
    type: string
    description: Instance type for the instance to be created
    default: m1.small
  image:
    type: string
    default: cirros
    description: ID or name of the image to use for the instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: My Cirros Instance
      image: { get_param: image }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }

output:
  instance_name:
    description: Get the instance's name
    value: { get_attr: [ my_instance, name ] }

このテンプレートは、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 セクションで定義されます。

以下に基本的な環境ファイルの例を示します。

resource_registry:
  OS::Nova::Server::MyServer: myserver.yaml

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

このファイルにより、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
注記

このテンプレートコレクションの 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 リソース種別を使用して、この設定スクリプトを送信します。

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

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

  1. OS::TripleO::NodeUserData は、コレクション内の他のテンプレートで使用する director ベースの Heat リソースで、全ノードに対して初回起動の設定を適用します。このリソースは、cloud-init で使用するデータを渡します。デフォルトの NodeUserData は、空の値 (firstboot/userdata_default.yaml) を指定する Heat テンプレートを参照します。この例では、firstboot.yaml の環境ファイルは、このデフォルトを独自の nameserver.yaml ファイルへの参照に置き換えます。
  2. nameserver_config は、初回起動で実行する Bash スクリプトを定義します。OS::Heat::SoftwareConfig リソースは、適用する設定としてこれを定義します。
  3. userdata は、OS::Heat::MultipartMime リソースを使用して、nameserver_config から複数のパートからなる MIME メッセージに設定を変換します。
  4. outputs では、output パラメーターの OS::stack_id が提供され、userdata から MIME メッセージを呼び出している Heat テンプレート/リソースに渡します。

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

#!/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 を追加するスクリプトを実行します。

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]}
重要

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

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

  1. OS::TripleO::NodeExtraConfig は、Heat テンプレートコレクション内の設定テンプレートで使用する director ベースの Heat リソースです。このリソースは、*-puppet.yaml を使用して各ノード種別に設定を渡します。デフォルトの NodeExtraConfig は、空の値 (puppet/extraconfig/pre_deploy/default.yaml) を指定する Heat テンプレートを参照します。この例では、pre_config.yaml の環境ファイルは、このデフォルトを独自の nameserver.yaml ファイルへの参照に置き換えます。
  2. 環境ファイルは、この環境の parameter_default の値として nameserver_ip を渡します。これは、ネームサーバーの IP アドレスを保存するパラメーターです。nameserver.yaml の Heat テンプレートは、parameters セクションで定義されているとおりに、このパラメーターを受け入れます。
  3. このテンプレートは、OS::Heat::SoftwareConfig を使用して設定リソースとして ExtraPreConfig を定義します。group: script プロパティーに注意してください。group は、使用するソフトウェア設定ツールを定義します。このソフトウェア設定ツールは Heat のフックセットで入手できます。この場合では、script フックは、SoftwareConfig リソースで config として定義される実行可能なスクリプトを実行します。
  4. このスクリプト自体は、/etc/resolve.conf にネームサーバーの IP アドレスを追加します。str_replace の属性に注意してください。これにより、templateセクションの変数を params セクションのパラメーターに置き換えることが可能となります。この場合は、NAMESERVER_IP をネームサーバーの IP アドレスに設定します。スクリプト内の同じ変数はこの IP アドレスに置き換えられ、その結果、スクリプトは以下のようになります。

    #!/bin/sh
    echo "nameserver 192.168.1.1" >> /etc/resolve.conf
  5. ExtraPreDeploymentsExtraPreConfig 設定をノードにデプロイします。以下の点に注意してください。

    • config 属性は、Heat がどの設定が適用されるかを理解できるように ExtraPreConfig リソースを参照します。
    • servers 属性は、overcloud-without-mergepy.yaml が渡すオーバークラウドのノードのマッピングを取得します。
    • actions 属性は、設定を適用するタイミングを定義します。この場合は、オーバークラウドが作成された時にのみ設定を適用します。実行可能なアクションは CREATEUPDATEDELETESUSPEND および RESUME です。

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

5.5. オーバークラウド設定後の設定のカスタマイズ

オーバークラウドの作成が完了してから、オーバークラウドの初回作成時または更新時に設定を追加する必要となる可能性があります。このような場合は、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']
重要

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

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

  1. OS::TripleO::NodeExtraConfigPost は、Heat テンプレートコレクション内の設定テンプレートで使用する director ベースの Heat リソースです。このリソースは、*-post.yaml を使用して各ノード種別に設定を渡します。デフォルトの NodeExtraConfigPost は、空の値 (extraconfig/post_deploy/default.yaml) を指定する Heat テンプレートを参照します。この例では、post_config.yaml の環境ファイルは、このデフォルトを独自の nameserver.yaml ファイルへの参照に置き換えます。
  2. 環境ファイルは、この環境の parameter_default の値として nameserver_ip を渡します。これは、ネームサーバーの IP アドレスを保存するパラメーターです。nameserver.yaml の Heat テンプレートは、parameters セクションで定義されているとおりに、このパラメーターを受け入れます。
  3. このテンプレートは、OS::Heat::SoftwareConfig を使用して設定リソースとして ExtraConfig を定義します。group: script プロパティーに注意してください。group は、使用するソフトウェア設定ツールを定義します。このソフトウェア設定ツールは Heat のフックセットで入手できます。この場合は、script フックは、SoftwareConfig リソースで config として定義される実行可能なスクリプトを実行します。
  4. このスクリプト自体は、/etc/resolve.conf にネームサーバーの IP アドレスを追加します。str_replace の属性に注意してください。これにより、templateセクションの変数を params セクションのパラメーターに置き換えることが可能となります。この場合は、NAMESERVER_IP をネームサーバーの IP アドレスに設定します。スクリプト内の同じ変数はこの IP アドレスに置き換えられ、その結果、スクリプトは以下のようになります。

    #!/bin/sh
    echo "nameserver 192.168.1.1" >> /etc/resolve.conf
  5. ExtraDeploymentsExtraConfig 設定をノードにデプロイします。以下の点に注意してください。

    • config 属性は、Heat がどの設定が適用されるかを理解できるように ExtraConfig リソースを参照します。
    • servers 属性は、overcloud-without-mergepy.yaml が渡すオーバークラウドのノードのマッピングを取得します。
    • actions 属性は、設定を適用するタイミングを定義します。この場合は、オーバークラウドが作成された時にのみ設定を適用します。実行可能なアクションは CREATEUPDATEDELETESUSPEND および RESUME です。

この例は、OS::Heat::SoftwareConfigOS::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'],
}

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 フックの例から SoftwareConfigSoftwareDeployments を使用するのに似ていますが、以下の点が異なります。

  1. puppet フックを実行するために group: puppet を設定します。
  2. config 属性は get_file 属性を使用して、追加の設定が含まれる Puppet マニフェストを参照します。
  3. 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

これにより、コンピュートノードの /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
重要

環境ファイルは、順序通りにスタックされます。これは、主要な 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 を参照してください。

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

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

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

    これにより、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 プラグインの一部としてドライバーをまず開発することを推奨します。

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

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

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 のディストリビューションの後にオーバークラウドのイメージに追加する。

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

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

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

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 など、異なるハードウェアおよびプロトコルをサポートするドライバーのコアセットを提供します。ベンダーは、認定済みのハードウェアのサポートを追加するためにドライバーを含めることができます。

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

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

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 と呼ばれるライブラリーが含まれます。

5.13. Shared File Systems (Manila)

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

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

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

Puppet モジュール:

Bugzilla コンポーネント:

  • openstack-manila
  • python-manilaclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

統合メモ:

  • アップストリームの manila リポジトリーでは manila/share/drivers/ にドライバーが含まれます。
  • puppet-manila リポジトリーでは manifests/backend ディレクトリーにドライバー設定が含まれます。
  • puppet-manila リポジトリーには、Cinder 設定ファイルに属性を追加するための manila_config と呼ばれるライブラリーが含まれます。