パートナーのソリューションの統合

director を使用して有意義な統合作業を完了させるには、複数の前提条件を満たす必要があります。これらの要件は、技術的な統合に限定されず、さまざまなレベルのパートナーソリューションの文書化も含まれます。これは、統合全体について完全な知識を共有して、Red Hat のエンジニアリングチーム、パートナーのマネージャー、サポート要員が効率的に作業をサポートできるようにすることが目的です。

最初の要件は、Red Hat OpenStack Platform ソリューションの認定に関連します。パートナーのソリューションを Red Hat OpenStack Platform director を使用して統合するには、まず Red Hat OpenStack Platform で認定される必要があります。

本セクションでは、Red Hat OpenStack Platform director のコアコンポーネントをいくつか考察して、それらのコンポーネントがオーバークラウドの作成にどのように貢献するのかを説明します。

2.1.1. Ironic

Ironic は、セルフサービスのプロビジョニングを使用してエンドユーザーに専用のベアメタルホストを提供します。director は、Ironic を使用してオーバークラウドのベアメタルハードウェアのライフサイクルを管理します。Ironic には、ベアメタルノードを定義するネイティブの API があります。director で OpenStack 環境をプロビジョニングする管理者は、特定のドライバーを使用して、Ironic にノードを登録する必要があります。ハードウェアの多くで Intelligent Platform Management Interface (IPMI) 電源管理機能がサポートされているため、IPMI が主要なサポートドライバーとなっています。しかし、Ironic には HP iLO または Dell DRAC などのベンダー固有のドライバーも含まれています。Ironic は、ノードの電源管理を制御し、イントロスペクションメカニズムを使用して、ハードウェアの情報や ファクト を収集します。director は、イントロスペクションプロセスから取得した情報を使用して、コントローラーノード、コンピュートノード、ストレージノードなど、さまざまな OpenStack 環境のロールとノードを照合します。たとえば、ディスクが 10 個あるノードが検出された場合は、ストレージノードとしてプロビジョニングされる可能性が高いです。

director でのハードウェアサポートを希望するパートナーは、Ironic のドライバーに対応している必要があります。

2.1.2. Heat

Heat は、アプリケーションスタックのオーケストレーションエンジンとして機能します。これにより、組織では、クラウドにデプロイする前に特定のアプリケーションの要素を定義することができます。このプロセスでは、複数のインフラストラクチャーリソース (例: インスタンス、ネットワーク、ストレージボリューム、Elastic IP アドレスなど) や設定用のパラメーターセットなどが含まれるスタックテンプレートを作成します。Heat は、指定の依存関係チェーンに基づいてこれらのリソースを作成して、リソースの可用性を監視し、必要に応じてスケーリングします。これらのテンプレートにより、アプリケーションスタックは移植可能となり、常に同じ結果が得られるようになります。

director は、ネイティブの OpenStack Heat API を使用して、オーバークラウドのデプロイに関連するリソースのプロビジョニングおよび管理を行います。これには、1 ノードロールあたりのプロビジョニングするノードの数、各ノードに設定するソフトウェアコンポーネント、それらのコンポーネントとノードの種別を director が設定する順序の定義などの詳細情報が含まれます。また director は、デプロイメントのトラブルシューティングやデプロイメント後の変更を容易に行うためにも Heat を使用します。

以下の例は、コントローラーノードのパラメーターを定義する Heat テンプレートのスニペットです。

NeutronExternalNetworkBridge:
    description: Name of bridge used for external network traffic.
    type: string
    default: 'br-ex'
NeutronBridgeMappings:
    description: >
      The OVS logical->physical bridge mappings to use. See the Neutron
      documentation for details. Defaults to mapping br-ex - the external
      bridge on hosts - to a physical name 'datacentre' which can be used
      to create provider networks (and we use this for the default floating
      network) - if changing this either use different post-install network
      scripts or be sure to keep 'datacentre' as a mapping network name.
    type: string
    default: "datacentre:br-ex"

Heat は、director に含まれるテンプレートで Ironic を呼び出してノードの電源を入れるなど、オーバークラウドの作成を簡素化します。標準の Heat ツールを使用して作成中のオーバークラウドのリソース (およびステータス) を表示することができます。たとえば、Heat ツールを使用して、入れ子状のアプリケーションスタックとしてオーバークラウドを表示することができます。

Heat には、実稼働向けの OpenStack クラウドを宣言および作成するための幅広く強力な構文があります。ただし、事前にパートナーのソリューションとの統合に関する知識とスキルが必要です。パートナーのテクノロジーを統合するユースケースにはすべて、Heat のテンプレートが必要です。

director では、オーバークラウドのノードをプロビジョニングする際に、複数のディスクイメージが必要です。詳細を以下に示します。

rhosp-director-images および rhosp-director-images-ipa パッケージからこれらのイメージを取得します。

$ sudo dnf install rhosp-director-images rhosp-director-images-ipa

stack ユーザーのホーム (/home/stack/images) の images ディレクトリーにアーカイブを展開します。

$ cd ~/images
$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.0.tar; do tar -xvf $i; done

場合によっては、最初の ramdisk を変更する必要がある可能性があります。たとえば、イントロスペクションまたはプロビジョニングプロセス中にノードを起動する際には、特定のドライバーを利用できるようにする必要がある場合があります。以下の手順では、最初の ramdisk を変更する方法を記載しています。オーバークラウドにおいては、これには以下のいずれかが含まれます。

以下の手順では、例として ironic-python-agent.initramfs ramdisk に追加の RPM パッケージを追加します。

root ユーザーとしてログインして、ramdisk の一時ディレクトリーを作成します。

# mkdir ~/ipa-tmp
# cd ~/ipa-tmp

skipcpio と「cpio」コマンドを使用して、一時ディレクトリーに ramdisk を展開します。

# /usr/lib/dracut/skipcpio ~/images/ironic-python-agent.initramfs | zcat | cpio -ivd | pax -r

展開したコンテンツに RPM パッケージをインストールします。

# rpm2cpio ~/RPMs/python-proliantutils-2.1.7-1.el7ost.noarch.rpm | pax -r

新しい ramdisk を再作成します。

# find . 2>/dev/null | cpio --quiet -c -o | gzip -8  > /home/stack/images/ironic-python-agent.initramfs
# chown stack: /home/stack/images/ironic-python-agent.initramfs

ramdisk に新しいパッケージが存在することを確認します。

# lsinitrd /home/stack/images/ironic-python-agent.initramfs | grep proliant

libguestfs-tools パッケージには virt-customize ツールが含まれます。rhel-8-for-x86_64-appstream-eus-rpms リポジトリーから libguestfs-tools をインストールします。

$ sudo dnf install libguestfs-tools

$ sudo systemctl disable --now iscsid.socket

overcloud-full.qcow2 イメージの内容を確認する前に、このイメージを使用する仮想マシンを作成する必要があります。

overcloud-full.qcow2 イメージを使用する仮想マシンインスタンスを作成するには、guestmount コマンドを入力します。

$ mkdir ~/overcloud-full
$ guestmount -a overcloud-full.qcow2 -i --ro ~/overcloud-full

QCOW2 イメージの内容は、~/overcloud-full で確認できます。

または、virt-manager を使用して、以下の起動オプションで仮想マシンを作成できます。

イメージで root ユーザーのパスワードを設定します。

$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --root-password password:test
[  0.0] Examining the guest ...
[ 18.0] Setting a random seed
[ 18.0] Setting passwords
[ 19.0] Finishing off

これにより、管理者レベルのアクセス権限でコンソールを使用してノードにアクセスできるようになります。

イメージを一時的に登録して、カスタマイズに適切な Red Hat のリポジトリーを有効にします。

$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager register --username=[username] --password=[password]'
[  0.0] Examining the guest ...
[ 10.0] Setting a random seed
[ 10.0] Running: subscription-manager register --username=[username] --password=[password]
[ 24.0] Finishing off

[username] および [password] は、お客様の Red Hat アカウントの情報に置き換えます。これで、イメージに対して以下のコマンドが実行されます。

subscription-manager register --username=[username] --password=[password]

このコマンドでは、Red Hat のコンテンツ配信ネットワークにオーバークラウドのイメージを登録します。

アカウントのサブスクリプションからプール ID の一覧を検索します。

$ sudo subscription-manager list

サブスクリプションプール ID を選択して、その ID をイメージにアタッチします。

$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager attach --pool [subscription-pool]'
[  0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Running: subscription-manager attach --pool [subscription-pool]
[ 52.0] Finishing off

[subscription-pool] は選択したサブスクリプションプール ID に必ず置き換えてください。これで、イメージに対して以下のコマンドが実行されます。

subscription-manager attach --pool [subscription-pool]

このコマンドではイメージにプールが追加され、以下のコマンドで Red Hat リポジトリーを有効化できるようになります。

$ subscription-manager repos --enable=[repo-id]

サードパーティー製のソフトウェアをイメージに追加するには、追加のリポジトリーが必要です。たとえば、以下は、OpenDaylight リポジトリーの内容を使用する設定が含まれたリポジトリーファイルの例です。

$ cat opendaylight.repo

[opendaylight]
name=OpenDaylight Repository
baseurl=https://nexus.opendaylight.org/content/repositories/opendaylight-yum-epel-8-x86_64/
gpgcheck=0

リポジトリーファイルをイメージにコピーします。

$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --upload opendaylight.repo:/etc/yum.repos.d/
[  0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Copying: opendaylight.repo to /etc/yum.repos.d/
[ 13.0] Finishing off

--copy-in オプションは、リポジトリーファイルをオーバークラウドイメージの /etc/yum.repos.d/ にコピーします。

重要: Red Hat は、認定を受けていないベンダーからのソフトウェアに対するサポートは提供していません。インストールするソフトウェアがサポートされていることを、Red Hat のサポート担当者に確認してください。

virt-customize コマンドを使用して、イメージにパッケージをインストールします。

$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --install opendaylight
[  0.0] Examining the guest ...
[ 11.0] Setting a random seed
[ 11.0] Installing packages: opendaylight
[ 91.0] Finishing off

--install オプションを指定すると、インストールするパッケージを指定することができます。

必要なパッケージをインストールしてイメージをカスタマイズした後に、サブスクリプションを削除して、イメージの登録を解除します。

$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager remove --all'
[  0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Running: subscription-manager remove --all
[ 18.0] Finishing off

これで、イメージからサブスクリプションプールがすべて削除されます。

イメージの登録を解除します。これは、オーバークラウドのデプロイメントプロセスでイメージをノードにデプロイして、各ノードを個別に登録するためです。

$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager unregister'
[  0.0] Examining the guest ...
[ 11.0] Setting a random seed
[ 11.0] Running: subscription-manager unregister
[ 17.0] Finishing off

イメージのマシン ID をリセットします。これにより、このイメージを使用するマシンが重複するマシン ID を使用するのを防ぎます。

$ virt-sysprep --operation machine-id -a overcloud-full.qcow2

イメージを変更した後には、director にアップロードします。stackrc ファイルを読み込み、コマンドラインから director にアクセスできるようにしてください。

$ source stackrc
$ openstack overcloud image upload --image-path /home/stack/images/

これにより、bm-deploy-kernel、bm-deploy-ramdisk、overcloud-full、overcloud-full-initrd、overcloud-full-vmlinuz のイメージが director にアップロードされます。これらは、デプロイメントとオーバークラウド用のイメージです。スクリプトにより、director の PXE サーバー上にイントロスペクションイメージもインストールされます。以下のコマンドを使用して CLI にイメージ一覧を表示します。

$ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

この一覧には、イントロスペクションの PXE イメージ (agent.*) は表示されません。director は、これらのファイルを /httpboot にコピーします。

[stack@host1 ~]$ ls /httpboot -l
total 151636
-rw-r--r--. 1 ironic ironic       269 Sep 19 02:43 boot.ipxe
-rw-r--r--. 1 root   root         252 Sep 10 15:35 inspector.ipxe
-rwxr-xr-x. 1 root   root     5027584 Sep 10 16:32 agent.kernel
-rw-r--r--. 1 root   root   150230861 Sep 10 16:32 agent.ramdisk
drwxr-xr-x. 2 ironic ironic      4096 Sep 19 02:45 pxelinux.cfg

次のセクションでは、Puppet の構文および Puppet のモジュールの構造を理解するのに役立つ基本事項を説明します。

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
}

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
}

Listen <%= @httpd_port %>
NameVirtualHost *:<%= @httpd_port %>
<VirtualHost *:<%= @httpd_port %>>
  DocumentRoot /var/www/myserver/
  ServerName *:<%= @fqdn %>>
  <Directory "/var/www/myserver/">
    Options All Indexes FollowSymLinks
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
  file {'/etc/httpd/conf.d/myserver.conf':
  notify => Service["httpd"],
    ensure => file,
    require => Package["httpd"],
    content => template("mymodule/myserver.conf.erb"),
  }
  file { "/var/www/myserver":
    ensure => "directory",
  }
}

Red Hat OpenStack Platform は、Github の openstack グループから取得する正式な OpenStack Puppet モジュールを使用します。https://github.com/openstack に移動して、フィルターセクションで puppet を検索します。すべての Puppet モジュールには、puppet- の接頭辞が使用されます。

この例では、以下のコマンドを使用してクローンを作成し、正式な OpenStack Block Storage (cinder) を検証します。

$ git clone https://github.com/openstack/puppet-cinder.git

これにより、Cinder の Puppet モジュールのクローンを作成します。

OpenStack モジュールでは、主にコアサービスを設定します。モジュールの多くには、backends、agents または plugins として知られる追加のサービスを設定するための追加のマニフェストが含まれます。たとえば、cinder モジュールには backends と呼ばれるディレクトリーがあり、この中には NFS、iSCSI、Red Hat Ceph Storage などの異なるストレージデバイス用の設定オプションが含まれます。

たとえば、manifests/backends/nfs.pp ファイルには以下の設定が含まれます。

define cinder::backend::nfs (
  $volume_backend_name  = $name,
  $nfs_servers          = [],
  $nfs_mount_options    = undef,
  $nfs_disk_util        = undef,
  $nfs_sparsed_volumes  = undef,
  $nfs_mount_point_base = undef,
  $nfs_shares_config    = '/etc/cinder/shares.conf',
  $nfs_used_ratio       = '0.95',
  $nfs_oversub_ratio    = '1.0',
  $extra_options        = {},
) {

  file {$nfs_shares_config:
    content => join($nfs_servers, "\n"),
    require => Package['cinder'],
    notify  => Service['cinder-volume']
  }

  cinder_config {
    "${name}/volume_backend_name":  value => $volume_backend_name;
    "${name}/volume_driver":        value =>
      'cinder.volume.drivers.nfs.NfsDriver';
    "${name}/nfs_shares_config":    value => $nfs_shares_config;
    "${name}/nfs_mount_options":    value => $nfs_mount_options;
    "${name}/nfs_disk_util":        value => $nfs_disk_util;
    "${name}/nfs_sparsed_volumes":  value => $nfs_sparsed_volumes;
    "${name}/nfs_mount_point_base": value => $nfs_mount_point_base;
    "${name}/nfs_used_ratio":       value => $nfs_used_ratio;
    "${name}/nfs_oversub_ratio":    value => $nfs_oversub_ratio;
  }

  create_resources('cinder_config', $extra_options)

}

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

これにより、ハードウェアの OpenStack ドライバーを設定するマニフェストを追加することの重要性が分かります。マニフェストは、director がハードウェアに適した設定オプションを追加する簡単な方法を提供します。マニフェストは、director がハードウェアをオーバークラウドで使用できるように設定する際の主要な統合ポイントの役割を果たします。

Puppet には、Hiera と呼ばれるツールが含まれています。このツールはノード固有の設定を提供するキーと値のシステムとして機能します。これらのキーと値は通常、/etc/puppet/hieradata に配置されるファイルに保管されています。/etc/puppet/hiera.yaml ファイルは、Puppet が hieradata ディレクトリーのファイルを読み込む順序を定義します。

オーバークラウドを設定する際には、Puppet はこのデータを使用して特定の Puppet クラスのデフォルト値を上書きします。たとえば、puppet-cinderにある cinder::backend::nfs の NFS のマウントオプションはデフォルトでは未定義になっています。

  $nfs_mount_options    = undef,

ただし、cinder::backend::nfs の定義する型を呼び出す独自のマニフェストを作成して、このオプションを Hiera データに置き換えることができます。

  cinder::backend::nfs { $cinder_nfs_backend:
    nfs_mount_options   => hiera('cinder_nfs_mount_options'),
  }

これは、nfs_mount_options パラメーターが cinder_nfs_mount_options キーから取得した Hiera データの値を使用することを意味します。

cinder_nfs_mount_options: rsize=8192,wsize=8192

または、NFS 設定の全評価に適用されるように Hiera データを使用して cinder::backend::nfs::nfs_mount_options パラメーターを直接上書きすることができます。以下に例を示します。

cinder::backend::nfs::nfs_mount_options: rsize=8192,wsize=8192

上記の Heira データは cinder::backend::nfs の各評価上にあるこのパラメーターを上書きします。

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

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

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

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

director は、オーバークラウドの初回作成時に全ノードに対して設定を行います。そのために、director は OS::TripleO::NodeUserData リソース種別を使用して呼び出すことのできる cloud-init を使用します。

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

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

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/resolv.conf

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

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

resource_registry:
  OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml

初回起動の設定を追加するには、最初にオーバークラウドを作成する際に、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/firstboot.yaml \
    ...

-e を使用して、オーバークラウドスタックに環境ファイルを適用します。

これにより、ノード作成後の初回起動時に設定がすべてのノードに追加されます。これ以降は (たとえば、オーバークラウドスタックの更新時)、これらのテンプレートを追加してもこれらのスクリプトは実行されません。

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

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

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

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

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

以下の例では、ノードの resolv.conf に変数のネームサーバーを書き込むスクリプトを実行するために、まず基本的な Heat テンプレート (/home/stack/templates/nameserver.yaml) を作成します。

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

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

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

  CustomExtraDeploymentPre:
    type: OS::Heat::SoftwareDeployment
    properties:
      server: {get_param: server}
      config: {get_resource: CustomExtraConfigPre}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

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

上記の例では、resources セクションには以下のパラメーターが含まれます。

Heat テンプレートをロールベースのリソース種別として登録する環境ファイル (/home/stack/templates/pre_config.yaml) を作成します。たとえば、コントローラーノードだけに適用するには、ControllerExtraConfigPre フックを使用します。

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

この設定を適用するには、オーバークラウドの作成時または更新時に、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/pre_config.yaml \
    ...

これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定前にすべてのコントローラーノードに設定が適用されます。

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

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

オーバークラウドは、OpenStack コンポーネントのコア設定に Puppet を使用します。director にはフックが用意されており、初回起動が完了してコア設定が開始する前に、すべてのノード種別が設定されます。

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

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  server:
    type: string
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

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

  CustomExtraDeploymentPre:
    type: OS::Heat::SoftwareDeployment
    properties:
      server: {get_param: server}
      config: {get_resource: CustomExtraConfigPre}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

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

上記の例では、resources セクションには以下のパラメーターが含まれます。

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

resource_registry:
  OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

この設定を適用するには、オーバークラウドの作成時または更新時に、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/pre_config.yaml \
    ...

これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定前にすべてのノードに設定が適用されます。

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

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

オーバークラウドの初回作成時または更新時において、オーバークラウドの作成が完了してからすべてのロールに設定の追加が必要となる可能性があります。このような場合には、以下の設定後フックを使用します。

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

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  servers:
    type: json
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string
  EndpointMap:
    default: {}
    type: json

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

  CustomExtraDeployments:
    type: OS::Heat::SoftwareDeploymentGroup
    properties:
      servers:  {get_param: servers}
      config: {get_resource: CustomExtraConfig}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

上記の例では、resources セクションには以下のパラメーターが含まれます。

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

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

この設定を適用するには、オーバークラウドの作成時または更新時に、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/post_config.yaml \
    ...

これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定後にすべてのノードに設定が適用されます。

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

この例は、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 モジュールから特定の設定クラスを適用する方法ができ、特定のソフトウェアやハードウェアを使用するようにオーバークラウドをカスタマイズしやすくなります。

Heat テンプレートコレクションには、特定のノード種別に追加の設定を渡すためのパラメーターセットが含まれています。これらのパラメーターでは、ノードの Puppet 設定用 hieradata として設定を保存します。これらのパラメーターは以下のとおりです。

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

parameter_defaults:
  ComputeExtraConfig:
    nova::compute::reserved_host_memory: 1024
    nova::compute::vnc_keymap: ja

openstack overcloud deploy を実行する際に、この環境ファイルを指定します。

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

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

コア Heat テンプレートコレクションには、コンポーザブルサービスのテンプレートセットが 2 つ含まれています。

各テンプレートには目的を特定する記述が含まれています。たとえば、deployment/time/ntp-baremetal-puppet.yaml サービステンプレートには以下のような記述が含まれます。

description: >
  NTP service deployment using puppet, this YAML file
  creates the interface between the HOT template
  and the puppet manifest that actually installs
  and configure NTP.

これらのサービステンプレートは、Red Hat OpenStack Platform デプロイメント固有のリソースとして登録されます。これは、overcloud-resource-registry-puppet.j2.yaml ファイルで定義されている一意な Heat リソース名前空間を使用して、各リソースを呼び出すことができることを意味します。サービスはすべて、リソース種別に OS::TripleO::Services 名前空間を使用します。

一部のリソースは、直接コンポーザブルサービスのベーステンプレートを使用します。以下に例を示します。

resource_registry:
  ...
  OS::TripleO::Services::Ntp: deployment/time/ntp-baremetal-puppet.yaml
  ...

ただし、コアサービスにはコンテナーが必要なので、コンテナー化されたサービステンプレートを使用します。たとえば、コンテナー化された keystone サービスでは、以下のリソースを使用します。

resource_registry:
  ...
  OS::TripleO::Services::Keystone: deployment/keystone/keystone-container-puppet.yaml
  ...

通常、これらのコンテナー化されたテンプレートは、依存関係を追加するために他のテンプレートを参照します。たとえば、deployment/keystone/keystone-container-puppet.yaml テンプレートは、ContainersCommon リソースにベーステンプレートの出力を保管します。

resources:
  ContainersCommon:
    type: ../containers-common.yaml

これにより、コンテナー化されたテンプレートは、containers-common.yaml テンプレートからの機能やデータを取り込むことができます。

overcloud.j2.yaml Heat テンプレートには、roles_data.yaml ファイル内の各カスタムロールのサービス一覧を定義するための Jinja2-based コードのセクションが含まれています。

{{role.name}}Services:
  description: A list of service resources (configured in the Heat
               resource_registry) which represent nested stacks
               for each service that should get installed on the {{role.name}} role.
  type: comma_delimited_list
  default: {{role.ServicesDefault|default([])}}

デフォルトのロールの場合は、これにより次のサービス一覧パラメーターが作成されます: ControllerServices、ComputeServices、BlockStorageServices、ObjectStorageServices、CephStorageServices

roles_data.yaml ファイル内の各カスタムロールのデフォルトのサービスを定義します。たとえば、デフォルトの Controller ロールには、以下の内容が含まれます。

- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Core
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
...

これらのサービスは、次に ControllerServices パラメーターのデフォルト一覧として定義されます。

本項では、ユーザー定義のコンポーザブルサービスの作成方法を考察し、その日のメッセージ (motd: message of the day) サービスの実装に重点を置いて説明します。以下の例では、設定フックを使用するか、「 3章オーバークラウドイメージ 」の手順に従ってオーバークラウドイメージを編集して、そのイメージにカスタムの motd Puppet モジュールが読み込まれていることを前提とします。

独自のサービスを作成する場合には、そのサービスの Heat テンプレートで定義すべき特定の項目があります。

以下は、motd サービス用の Heat テンプレート (service.yaml) の一例です。

heat_template_version: 2016-04-08

description: >
  Message of the day service configured with Puppet

parameters:
  ServiceNetMap:
    default: {}
    type: json
  DefaultPasswords:
    default: {}
    type: json
  EndpointMap:
    default: {}
    type: json
  MotdMessage: 1
    default: |
      Welcome to my Red Hat OpenStack Platform environment!

    type: string
    description: The message to include in the motd

outputs:
  role_data:
    description: Motd role using composable services.
    value:
      service_name: motd
      config_settings: 2
        motd::content: {get_param: MotdMessage}
      step_config: | 3
        if hiera('step') >= 2 {
          include ::motd
        }

この例では、オーバークラウドのコントローラーノードでのみカスタムの motd サービスを設定することを目的としています。そのためには、カスタムの環境ファイルとカスタムのロールデータファイルをデプロイメントに追加する必要があります。

まず最初に、OS::TripleO::Services 名前空間内の登録済み Heat リソースとして新規サービスを環境ファイル (env-motd.yaml) に追加します。この例では、motd サービスのリソース名は OS::TripleO::Services::Motd です。

resource_registry:
  OS::TripleO::Services::Motd: /home/stack/templates/motd.yaml

parameter_defaults:
  MotdMessage: |
    You have successfully accessed my Red Hat OpenStack Platform environment!

このカスタム環境ファイルには、デフォルトの MotdMessage を上書きする新しいメッセージも含まれている点に注意してください。

デプロイメントに motd サービスが追加されました。ただし、この新規サービスを必要とする各ロールは、カスタムの roles_data.yaml ファイルにある ServicesDefault リストを更新する必要があります。以下の例では、コントローラーノードのみでこのサービスを設定します。

デフォルトの roles_data.yaml ファイルのコピーを作成します。

$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/custom_roles_data.yaml

このファイルを編集して、Controller ロールにスクロールし、ServicesDefault リストにサービスを追加します。

- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephExternal
...
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::Motd           # Add the service to the end

オーバークラウドの作成時には、編集した環境ファイルと custom_roles_data.yaml ファイルを他の環境ファイルおよびデプロイメントオプションとともに追加します。

$ openstack overcloud deploy --templates -e /home/stack/templates/env-motd.yaml -r ~/custom_roles_data.yaml [OTHER OPTIONS]

このコマンドにより、デプロイメントにカスタムの motd サービスが追加され、コントローラーノードのみでサービスが設定されます。

1 つのプロジェクトが 1 つのパートナーイメージに対応します。イメージが複数ある場合には、複数のプロジェクトを作成する必要があります。

この段階で、Red Hat はプロジェクトを評価しその認定を確認します。アップストリームコードに関してプラグインが ツリー内 か ツリー外 かを記載して、connect@redhat.com にメールを送信してください。

Red Hat がプラグインのステータスを確認したら、Certification Checklist に進みます。

認定済みコンテナーは、パッケージング、配布、およびメンテナンスに関する Red Hat の基準を満たす必要があります。認定済みコンテナーでは、イメージを最新の状態に維持し、コンテナー対応プラットフォーム (Red Hat OpenStack Platform を含む) に対して最高の信頼性とサポート性を提供することを、パートナーがコミットすると解釈されます。

チェックリストには、以下の項目が含まれます。

チェックリストの最後の項目は Configure Automated Build Service です。このサービスを設定するためには、プロジェクトに Red Hat の認定基準に適合する Dockerfile が含まれていなければなりません。

イメージビルドプロセスの一環として、ビルドサービスはビルドイメージをスキャンし、Red Hat の基準に適合していることを確認します。プロジェクトに含める Dockerfile のガイドラインを以下に示します。

スキャンに必要な情報を、以下の Dockerfile の例に示します。

FROM registry.redhat.io/rhosp-rhel8/openstack-cinder-volume
MAINTAINER VenderX Systems Engineering <maintainer@vendorX.com>

###Required Labels
LABEL name="rhosp-rhel8/openstack-cinder-volume-vendorx-plugin" \
      maintainer="maintainer@vendorX.com" \
      vendor="VendorX" \
      version="3.7" \
      release="1" \
      summary="Red Hat OpenStack Platform 16.0 cinder-volume VendorX PluginY" \
      description="Red Hat OpenStack Platform 16.0 cinder-volume VendorX PluginY"


USER root

###Adding package
###repo exmple
COPY vendorX.repo /etc/yum.repos.d/vendorX.repo

###adding package with curl
RUN curl -L -o /verdorX-plugin.rpm http://vendorX.com/vendorX-plugin.rpm

###adding local package
COPY verdorX-plugin.rpm /

# Enable a repo to install a package
RUN dnf clean all
RUN yum-config-manager --enable openstack-16-for-rhel-8-x86_64-rpms
RUN dnf install -y vendorX-plugin
RUN yum-config-manager --disable openstack-16-for-rhel-8-x86_64-rpms

# Add required license as text file in Liceses directory (GPL, MIT, APACHE, Partner End User Agreement, etc)
RUN mkdir /licenses
COPY licensing.txt /licenses

USER cinder

以下の手順では、コンテナーイメージの名前空間やレジストリーなどのプロジェクト詳細を設定します。

以下の手順で、パートナープラグインのコンテナーイメージをビルドする方法を説明します。

Scan Details のページには、失敗した項目を含めスキャン結果が表示されます。イメージのスキャンにより FAILED のステータスが報告される場合には、以下の手順を使用して、これらのエラーを修正する方法を確認してください。

コンテナーイメージがスキャンに合格したら、コンテナーイメージを公開することができます。

コンテナーイメージを公開したら、プラグインの認定に関する詳細情報を得るために認定関連ドキュメントを確認してください。認定関連ドキュメントへのリンクは、「パートナーソリューションの統合に関する要件」を参照してください。

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 はインスタンスの仮想ストレージデバイスを提供します。Cinder は、異なるストレージハードウェアやプロトコルをサポートするドライバーのコアセットを提供します。たとえば、コアのドライバーには、NFS、iSCSI、Red Hat Ceph Storage へのサポートを含むものもあります。ベンダーは、追加の認定済みのハードウェアをサポートするためにドライバーを含めることができます。

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

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

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

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

Puppet モジュール:

Bugzilla コンポーネント:

統合メモ:

OpenStack Image Storage (glance) は、イメージのストレージを提供するためにストレージ種別と対話する 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 コンポーネント:

統合メモ:

OpenStack Platform では OpenShift-on-OpenStack のデプロイメントをサポートする方針です。OpenShift とパートナーソリューションの統合は本書の範囲から外れますが、「Red Hat OpenShift partners」のページで詳細な情報を確認することができます。