Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

Red Hat OpenStack Platform 8

OpenStack Platform 環境における認定済みのサードパーティーソフトウェアおよびハードウェアの統合

OpenStack Documentation Team

概要

本書は、認定済みのサードパーティー製コンポーネントを Red Hat OpenStack Platform 環境に統合する際の指針を提供します。これには、オーバークラウドのイメージへのこれらのコンポーネントの追加や、director を使用したデプロイメントの設定作成が含まれます。

第1章 はじめに
リンクのコピー

本書は、Red Hat OpenStack Platform のパートナーが OpenStack Platform 環境のインストールやデプロイメントライフサイクルの管理に使用するツールとして、Red Hat OpenStack Platform director を使用してソリューションを統合する作業を支援するために執筆されました。director を使用した統合により、パートナーの技術をシームレスに導入することが可能となります。リソースの最適化、デプロイメント所要時間の短縮、ライフサイクル管理コストの削減など、幅広いメリットが得られます。

今後、OpenStack Platform director を使用した統合は、既存のエンタープライズ管理システムおよびプロセスとの充実した統合を提供するための強固な対策の 1 つとなります。director の機能は将来、Red Hat の製品ポートフォリオ内の CloudForms などのツールによって統合/使用されるようになり、サービスデプロイメント管理のより多くのプロセスをグラフィカルユーザーインターフェイスで実行できるようになる見通しです。

1.1. パートナー統合の概要
リンクのコピー

このガイドは、director がオーバークラウドの一部として設定する方法で、パートナーがソフトウェアとハードウェアソリューションを統合するのに役立つことを目的としています。これは、特定の統合タスクを実行する方法を示す複数のセクションに分割されたワークフローに従います。

  • アーキテクチャー: director がオーバークラウドの作成および設定を行うのに使用するテクノロジーの一部を調査します。
  • オーバークラウド イメージ：director は、ノード種別のベースとしてオーバークラウドの各ノードにベースイメージを書き込みます。本セクションでは、ドライバーまたはソフトウェアを含めることができるように、デプロイ前にこれらのイメージを変更する方法を説明します。これは、アップストリームで対応する前にドライバーと設定をテストする際に便利です。
  • 設定: director はオーバークラウド上で各サービスを設定します（主に Puppet モジュールを使用します）。本項では、Puppet モジュールの仕組みおよびオーバークラウドの設定方法を説明します。
  • Orchestration - director は、一連の Heat テンプレートを使用してオーバークラウドを作成および設定します。これには、オーバークラウドの設定動作を変更するカスタム環境ファイルおよび Heat テンプレートも含まれます。このセクションでは、オーバークラウドのカスタム設定を有効にするためのこのようなテンプレートの作成に焦点を当てます。これには、前の章の Puppet 設定も含まれます。
  • Integration Points: director がデプロイするイメージには、設定に必要な OpenStack コンポーネントおよび Puppet モジュールのセットが含まれます。このセクションでは、コンポーネントドライバーおよび Puppet モジュールを提供するためのアップストリームプロジェクトの一部について説明します。これにより、Red Hat がテストして、将来の Red Hat OpenStack Platform ディストリビューションに追加できるようになります。
  • 例 - 本章は、以前の章の知識のカリング化で、実際の認定ベンダーが現在ディレクターを使用してそのプロジェクトをオーバークラウドにどのように統合するかを説明します。これには、いくつかの実用的なネットワークとストレージの例が含まれています。本セクションは、同様のベンダーが独自の製品を Red Hat OpenStack Platform のエコシステムに統合するのに役立ちます。

1.2. パートナーソリューションの統合に関する要件
リンクのコピー

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

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

第2章 アーキテクチャー
リンクのコピー

director には、OpenStack 環境自体の設定、デプロイ、管理にネイティブの OpenStack API を使用することを推奨します。つまり、director を使用した統合には、それらのネイティブ OpenStack API および補助コンポーネントとの統合が必要となることになります。このような API を使用する主な利点は、十分に文書化されていること、アップストリームで統合テストが幅広く行われていること、成熟していること、また OpenStack 基本知識を持つユーザーであればより簡単に director の機能の仕組みを理解できることなどです。また、OpenStack API を使用すると、director が自動的に OpenStack のコア機能拡張、セキュリティー修正プログラム、バグの修正を自動的に継承することになります。

Red Hat OpenStack Platform director は、完全な OpenStack 環境のインストールおよび管理を行うためのツールセットです。director は、主に OpenStack プロジェクト TripleO (OpenStack-On-OpenStack の略語) をベースとしてます。このプロジェクトは、OpenStack のコンポーネントを活用して、完全に機能する OpenStack 環境をインストールします。これには、OpenStack ノードとして使用するベアメタルシステムのプロビジョニングや制御を行う新たな OpenStack のコンポーネントが含まれます。director により、効率的で堅牢性の高い、完全な Red Hat OpenStack Platform 環境を簡単にインストールできます。

Red Hat OpenStack Platform director は、アンダークラウドとオーバークラウドという 2 つの主要な概念を使用します。この director 自体は、アンダークラウドとして知られている単一システムの OpenStack 環境を形成する OpenStack コンポーネントのサブセットで設定されています。アンダークラウドは、ワークロードを実行できるように実稼働レベルのクラウドを構築できる管理システムとして機能します。この実稼働レベルのクラウドはオーバークラウドです。オーバークラウドおよびアンダークラウドに関する詳細は、director の インストールおよび使用方法 ガイド を参照してください。

director には、オーバークラウド設定を構築するためのツール、ユーティリティー、テンプレートのサンプルが同梱されています。director は、設定データ、パラメーター、ネットワークトポロジーの情報を取得し、Ironic、Heat、Puppet などのコンポーネントとともにその情報を使用して、オーバークラウドのインストール環境をオーケストレーションします。

パートナーにはさまざまな異なる要件があります。director のアーキテクチャーを理解すると、統合の際にどのコンポーネントが重要となるかを理解するのに役立ちます。

2.1. コアコンポーネント
リンクのコピー

本セクションでは、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、Cisco UCS または 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"
Copy to Clipboard Toggle word wrap

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

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

2.1.3. Puppet
リンクのコピー

Puppet は、設定管理および実行ツールです。マシンの最終的な状態を記述して、その状態を保持するメカニズムとして使用します。この最終的な状態は、Puppet マニフェストで定義します。Puppet では、以下の 2 つのモードがサポートされています。

  • マニフェスト形式の手順がローカルで実行されるスタンドアロンモード
  • Puppet マスターと呼ばれる中央サーバーからマニフェストを取得するサーバーモード

管理者は、ノードに新しいマニフェストをアップロードしてローカルで実行する方法と、クライアント/サーバーモデルで Puppet マスターで変更する方法のいずれかを使用して変更を加えます。

Puppet は director のさまざまな場所で使用されています。

  • アンダークラウドホストで Puppet をローカルで使用して、undercloud.conf に記述された設定に従ってパッケージのインストールや設定を行います。
  • ベースのオーバークラウドイメージに openstack-puppet-modules パッケージを注入します。これらの Puppet モジュールは、デプロイメント後の設定に使用できます。デフォルトでは、すべての OpenStack サービスが含まれたイメージを作成して、各ノードに使用します。
  • Heat 経由で追加の Puppet マニフェストとパラメーターをノードに渡して、オーバークラウドのデプロイメントの後にその設定を適用します。これには、ノードの種別に依存するサービスの有効化や起動、OpenStack の設定の適用などが含まれます。

  • ノードに Puppet hieradata を渡します。Puppet モジュールやマニフェストには、マニフェストの一貫性を確保するためのサイトやノード固有のパラメーターはありません。hieradata はパラメーター値の形式で機能し、Puppet モジュールをプッシュして、他のエリアで参照することができます。たとえば、マニフェスト内の MySQL パスワードを参照するには、この情報を hieradata として保存して、マニフェスト内でこの hieradata を参照します。

    hieradata を表示します。 

    [root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file
openstack::controller::mysql_root_password: ‘redhat123'
    Copy to Clipboard Toggle word wrap

    Puppet マニフェストで hieradata を参照します。 

    [root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest
mysql_root_password  => hiera(‘openstack::controller::mysql_root_password')
    Copy to Clipboard Toggle word wrap

パートナーが統合するサービスで、パッケージをインストールしたり、サービスを有効化したりする必要がある場合には、その要件を満たすための Puppet モジュールを作成することを検討してください。たとえば、現在の Openstack Puppet モジュールの取得方法に関する情報は、「OpenStack Puppet モジュールの取得」を参照してください。

2.1.4. TripleO および TripleO Heat テンプレート
リンクのコピー

前述したように、director はアップストリームの TripleO プロジェクトをベースにしています。このプロジェクトは、以下の作業を行う OpenStack サービスセットを統合します。

  • オーバークラウドイメージの保存 (Glance)
  • オーバークラウドのオーケストレーション (Heat)
  • ベアメタルマシンのプロビジョニング(Ironic)

TripleO には、Red Hat がサポートするオーバークラウド環境を定義する Heat テンプレートコレクションが含まれます。director は、Heat を使用してこのテンプレートコレクションを読み込み、オーバークラウドスタックをオーケストレーションします。heat は、これらのコア Heat テンプレート内の特定のリソースのソフトウェア設定も起動します。このソフトウェア設定は通常 Bash スクリプトまたは Puppet マニフェストのいずれかです。

一般的なソフトウェア設定は、2 つの主要な Heat リソースに依存します。

  • 設定を含むリソース(OS::Heat::SoftwareConfig)
  • ノードに設定を実装するリソース(OS::Heat::SoftwareDeployment)

たとえば、Heat テンプレートコレクションでは、コンピュートノードのデプロイ後のテンプレート(puppet/compute-post.yaml)には、以下のセクションが含まれます。 

resources:

  ComputePuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: puppet
      options:
        enable_debug: {get_param: ConfigDebug}
      outputs:
      - name: result
      config:
        get_file: manifests/overcloud_compute.pp

  ComputePuppetDeployment:
    type: OS::Heat::StructuredDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ComputePuppetConfig}
      input_values:
        update_identifier: {get_param: NodeConfigIdentifiers}
Copy to Clipboard Toggle word wrap

ComputePuppetConfig リソースは、コンピュートノードの設定が含まれる Puppet マニフェスト(puppet/manifests/overcloud_compute.pp)を読み込みます。ComputePuppetDeployment リソースは、親 Heat テンプレートがコンピュートノードとして定義するサーバーのリスト(サーバー：{get_param: servers})に ComputePuppetConfig の設定を適用します。Puppet が完全なマニフェストを正常に適用したかどうかに応じて、ノードは ComputePuppetDeployment が成功または失敗であるかどうかを報告します。

このソフトウェア設定データフローは、director を介してサードパーティーのソリューションを統合する方法を理解する上で重要です。本ガイドでは、このデータフローを使用して、コア設定の前後にオーバークラウドにカスタム設定を含める方法を説明します。カスタム設定の実装に使用されるソフトウェア設定データフローの例は、以下を参照してください。

第3章 オーバークラウドイメージ
リンクのコピー

Red Hat OpenStack Platform director は、オーバークラウドのイメージを提供します。このコレクションの QCOW イメージには、ベースのソフトウェアコンポーネントが含まれており、これらを統合してコンピュート、コントローラー、ストレージノードなどさまざまなオーバークラウドのロールを形成します。場合によっては、追加のコンポーネントをノードにインストールするなど、ニーズにあわせてオーバークラウドイメージの特定の機能を変更することもできます。

本書では、virt-customize ツールを使用して、既存のコントローラーノードを増強するために既存のオーバークラウドイメージを変更する各種アクションについて説明します。たとえば、以下の手順を使用して、初期イメージには装備されていない ml2 プラグイン、Cinder バックエンド、監視エージェントを追加でインストールすることができます。

3.1. オーバークラウドイメージの取得
リンクのコピー

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

  • 検出カーネルと ramdisk: PXE ブートでのベアメタルシステムの検出に使用します。
  • デプロイメントカーネルおよび ramdisk: システムのプロビジョニングおよびデプロイメントに使用
  • オーバークラウドカーネル、ramdisk、完全なイメージ: ノードのハードディスクに書き込まれるベースのオーバークラウドシステム

Red Hat カスタマーポータルの Red Hat OpenStack Platform のダウンロードページ( https://access.redhat.com/downloads/content/191/ver=7/rhel---7/7/x86_64/product-downloads )から、これらのイメージを取得します。カスタマーポータルのこの場所には、TAR アーカイブ内のイメージが含まれています。これらのイメージアーカイブを、ディレクトリーホスト(/home/ stack / images /)上の stack ユーザーのホームディレクトリーにある images ディレクトリーにダウンロードし、アーカイブからイメージを展開します。 

$ cd ~/images
$ for tarfile in *.tar; do tar -xf $tarfile; done
Copy to Clipboard Toggle word wrap

3.2. director への virt-customize のインストール
リンクのコピー

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

$ sudo yum install libguestfs-tools
Copy to Clipboard Toggle word wrap

3.3. オーバークラウドイメージの検査
リンクのコピー

overcloud-full.qcow2 の内容を調べる場合があります。qemu-system-x86_64 コマンドを使用して仮想マシンインスタンスを作成します。 

$ sudo qemu-system-x86_64 --kernel overcloud-full.vmlinuz --initrd overcloud-full.initrd -m 1024 --append root=/dev/sda --enable-kvm overcloud-full.qcow2
Copy to Clipboard Toggle word wrap

または、virt-manager で次の起動オプションを使用します。

  • カーネルのパス: /overcloud-full.vmlinuz
  • initrd のパス: /overcloud-full.initrd
  • カーネルの引数: root=/dev/sda

3.4. root パスワードの設定
リンクのコピー

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

$ virt-customize -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
Copy to Clipboard Toggle word wrap

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

3.5. システムの登録
リンクのコピー

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

$ virt-customize -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
Copy to Clipboard Toggle word wrap

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

subscription-manager register --username=[username] --password=[password]
Copy to Clipboard Toggle word wrap

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

3.6. サブスクリプションのアタッチと Red Hat リポジトリーの有効化
リンクのコピー

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

$ sudo subscription-manager list
Copy to Clipboard Toggle word wrap

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

$ virt-customize -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
Copy to Clipboard Toggle word wrap

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

subscription-manager attach --pool [subscription-pool]
Copy to Clipboard Toggle word wrap

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

$ subscription-manager repos --enable=[repo-id]
Copy to Clipboard Toggle word wrap

3.7. カスタムリポジトリーファイルのコピー
リンクのコピー

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

$ cat opendaylight.repo

[opendaylight]
name=OpenDaylight Repository
baseurl=https://nexus.opendaylight.org/content/repositories/opendaylight-yum-epel-6-x86_64/
gpgcheck=0
Copy to Clipboard Toggle word wrap

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

$ virt-customize -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 to Clipboard Toggle word wrap

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

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

3.8. RPM のインストール
リンクのコピー

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

$ virt-customize -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
Copy to Clipboard Toggle word wrap

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

3.9. サブスクリプションプールのクリーニング
リンクのコピー

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

$ virt-customize -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
Copy to Clipboard Toggle word wrap

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

3.10. イメージの登録解除
リンクのコピー

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

$ virt-customize -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
Copy to Clipboard Toggle word wrap

3.11. director へのイメージのアップロード
リンクのコピー

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

$ source stackrc
$ openstack overcloud image upload --image-path /home/stack/images/
Copy to Clipboard Toggle word wrap

これにより、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 |
+--------------------------------------+------------------------+
Copy to Clipboard Toggle word wrap

このリストには、検出 PXE イメージ(discovery-ramdisk.*)は表示されません。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 discoverd.ipxe
-rwxr-xr-x. 1 root   root     5027584 Sep 10 16:32 discovery.kernel
-rw-r--r--. 1 root   root   150230861 Sep 10 16:32 discovery.ramdisk
drwxr-xr-x. 2 ironic ironic      4096 Sep 19 02:45 pxelinux.cfg
Copy to Clipboard Toggle word wrap

第4章 設定
リンクのコピー

本章では、OpenStack Puppet モジュールに設定を追加する方法を考察します。これには、Puppet モジュール開発の基本指針も含まれます。

4.1. Puppet の基礎知識
リンクのコピー

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

4.1.1. Puppet モジュールの内容の検証
リンクのコピー

OpenStack モジュールに貢献する前に、Puppet モジュールを作成するコンポーネントについて理解する必要があります。

マニフェスト

マニフェストとは、リソースセットおよび属性を定義するコードが含まれるファイルのことです。リソースは、システムの設定可能なコンポーネントです。リソースの例として、パッケージ、サービス、ファイル、ユーザーとグループ、SELinux 設定、SSH キー認証、cron ジョブなどが挙げられます。マニフェストは、属性のキーと値のペアのセットを使用して必要な各リソースを定義します。以下に例を示します。 

  package { 'httpd':
    ensure => installed,
  }
Copy to Clipboard Toggle word wrap

この宣言では、httpd パッケージがインストールされているかどうかを確認します。されていない場合は、マニフェストにより yum が実行されて、httpd パッケージがインストールされます。マニフェストは、モジュールの manifest ディレクトリーに置かれています。また Puppet モジュールは、テストマニフェストのテストディレクトリーを使用します。これらのマニフェストを使用して、正式なマニフェストが含まれている特定のクラスをテストします。

クラス
クラスは、マニフェスト内の複数のリソースを統一する方法として機能します。たとえば、HTTP サーバーをインストールして設定する場合には、HTTP サーバーパッケージをインストールするリソース、HTTP サーバーを設定するリソース、サーバーを起動または有効化するリソースの 3 つのリソースでクラスを作成します。また、他のモジュールからのクラスを参照して設定に適用することもできます。たとえば、Web サーバーも必要なアプリケーションを設定する必要がある場合に、上述した HTTP サーバーのクラスを参照することができます。
静的ファイル

モジュールには、システムの特定の場所に、Puppet がコピーできる静的ファイルが含まれます。これらの場所や、アクセス権限などのその他の属性は、マニフェストのファイルのリソース宣言で定義されます。

静的ファイルは、モジュールの files ディレクトリーに配置されています。

テンプレート

設定ファイルにはカスタムのコンテンツが必要な場合があります。このような場合、ユーザーは静的ファイルの代わりにテンプレートを作成します。静的ファイルと同様に、テンプレートはマニフェストで定義され、システム上の場所にコピーされます。相違点は、テンプレートでは Ruby 表現でカスタマイズのコンテンツや変数入力を定義することができる点です。たとえば、カスタマイズ可能なポートで httpd を設定する場合には、設定ファイルのテンプレートには以下が含まれます。 

Listen <%= @httpd_port %>
Copy to Clipboard Toggle word wrap

この場合の httpd_port 変数はこのテンプレートを参照するマニフェストで定義されています。

テンプレートは、モジュールの templates ディレクトリーに配置されています。

プラグイン

プラグインにより、Puppet のコア機能を拡張することができます。たとえば、プラグインを使用してカスタムファクト、カスタムリソース、または新機能を定義することができます。また、データベースの管理者が、PostgreSQL データベース向けのリソース種別を必要とする場合があります。プラグインを使用すると、データベース管理者は PostgreSQL のインストール後に新規データベースセットで PostgreSQL にデータを投入しやすくなります。その結果、データベース管理者は、PostgreSQL のインストールとその後のデータベース作成を確実に行う Puppet マニフェストのみを作成するだけで良くなります。

プラグインは、モジュールの lib ディレクトリーに配置されています。このディレクトリーには、プラグインの種別に応じたサブディレクトリーセットが含まれます。以下に例を示します。

  • /lib/facter: カスタムファクトの場所
  • /lib/puppet/type: 属性のキーと値のペアを記述するカスタムリソース種別の定義の場所
  • /lib/puppet/provider: リソースを制御するためのリソース種別の定義と併用するカスタムリソースプロバイダーの場所
  • /lib/puppet/parser/functions: カスタム関数の場所

4.1.2. サービスのインストール
リンクのコピー

一部のソフトウェアには、パッケージのインストールが必要です。これは、Puppet モジュールが実行可能な機能です。これには、特定のパッケージの設定を定義するリソース定義が必要です。

たとえば、mymodule モジュールを使用して httpd パッケージをインストールするには、mymodule モジュールの Puppet マニフェストに以下のコンテンツを追加します。 

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
}
Copy to Clipboard Toggle word wrap

このコードは、httpd と呼ばれる mymodule のサブクラスを定義します。続いて、httpd パッケージのパッケージリソース宣言を定義します。ensure => installed の属性は、パッケージがインストールされているかどうかを確認するように Puppet に指示を出します。インストールされていない場合には、Puppet は yum を実行してパッケージをインストールします。

4.1.3. サービスの起動と有効化
リンクのコピー

パッケージのインストール後に、サービスを起動します。service と呼ばれる別のリソース宣言を使用します。これには、以下の内容が含まれるようにマニフェストを編集する必要があります。 

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
}
Copy to Clipboard Toggle word wrap

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

  • ensure => running 属性は、サービスが実行さているかどうかを確認します。実行されていない場合は Puppet により有効化されます。
  • enable => true 属性は、システムの起動時にサービスが実行されるように設定します。
  • require => Package["httpd"] 属性は、リソース宣言同士の順序関係を定義します。今回の場合は、httpd サービスが httpd パッケージのインストールの後に起動されるようにします。この属性により、サービスと関連のパッケージの間で依存関係が生まれます。

4.1.4. サービスの設定
リンクのコピー

上記の 2 つの手順では、Puppet を使用したサービスのインストールおよび有効化の方法を説明しました。しかし、サービスにカスタム設定を指定することもできます。本書の例では、ポート 80 に Web ホストを設定するように、すでに /etc/httpd/conf/httpd.conf に HTTP サーバーのデフォルト設定が指定されています。本セクションでは、ユーザー指定のポートに追加の Web ホストを提供するために、追加の設定を追加します。

そのためには、HTTP 設定ファイルを保存するテンプレートファイルを使用します。これは、ユーザー定義のポートには、変数入力が必要なためです。モジュールの templates ディレクトリーに、以下の内容が含まれた myserver.conf.erb と呼ばれるファイルを追加します。 

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>
Copy to Clipboard Toggle word wrap

このテンプレートは、Apache Web サーバー設定の標準構文に従います。唯一の相違点は、モジュールから変数を注入する際に Ruby のエスケープ文字が含まれる点です。たとえば、Web サーバーポートを指定するために使用する httpd_port などがあります。

fqdn が追加されている点に注意してください。これは、システムの完全修飾ドメイン名を保存する変数で、システムファクト として知られています。システムファクトは、各該当システムの Puppet カタログを生成する前に各システムから取得します。Puppet は facter コマンドを使用して、これらのシステムファクトを収集します。また、これらのファクトのリストを表示するには、facter を実行します。

このファイルを保存した後には、モジュールの Puppet マニフェストにリソースを追加します。 

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",
  }
}
Copy to Clipboard Toggle word wrap

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

  • サーバー設定ファイル (/etc/httpd/conf.d/myserver.conf) のファイルリソース宣言を追加します。このファイルのコンテンツは、以前に作成した myserver.conf.erb テンプレートです。このファイルを追加する前に、httpd パッケージがインストールされていることも確認します。
  • 2 番目のファイルリソース宣言も追加します。これにより、Web サーバーのディレクトリー (/var/www/myserver) が作成されます。
  • notify => Service["httpd"] 属性を使用して、設定ファイルと httpd サービスの間の関係も追加します。これにより、設定ファイルへの変更の有無がチェックされます。ファイルが変更された場合には、Puppet によりサービスが再起動されます。

4.2. OpenStack Puppet モジュールの取得
リンクのコピー

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
Copy to Clipboard Toggle word wrap

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

4.3. 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)

}
Copy to Clipboard Toggle word wrap

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

  • define ステートメントでは、cinder::backend::nfs と呼ばれる定義型が作成されます。定義型はクラスによく似ていますが、主な相違点は Puppet は定義型を複数回評価する点です。たとえば、複数の NFS バックエンドが必要なため、この設定では NFS 共有ごとに評価を複数回実行する必要があります。
  • 次の数行では、この設定内のパラメーターとそのデフォルト値を定義します。cinder::backend::nfs の定義型に新しい値が渡された場合には、デフォルト値は上書きされます。
  • file 関数は、ファイルの作成を呼び出すリソース宣言です。このファイルには、NFS 共有のリストが含まれており、このファイルの名前はパラメーターで定義されます ($nfs_shares_config = '/etc/cinder/shares.conf')。以下は追加の属性です。
  • content 属性は、$nfs_servers パラメーターを使用してリストを作成します。
  • require 属性は、cinder パッケージが確実にインストールされるようにします。
  • notify 属性は cinder-volume サービスにリセットするように指示を出します。

  • cinder_config 関数は、モジュールの lib/puppet/ ディレクトリーからプラグインを使用するリソース宣言です。このプラグインは /etc/cinder/cinder.conf ファイルに設定を追加します。このリソースのそれぞれの行により、cinder.conf ファイルの適切なセクションに設定オプションが追加されます。たとえば、$name パラメーターが mynfs の場合には、属性は以下のようになります。 

      "${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;
    Copy to Clipboard Toggle word wrap

    上記の属性により、cinder.conf のファイルに以下が追加されます。 

    [mynfs]
volume_backend_name=mynfs
volume_driver=cinder.volume.drivers.nfs.NfsDriver
nfs_shares_config=/etc/cinder/shares.conf
    Copy to Clipboard Toggle word wrap
  • create_resources 関数は、ハッシュをリソースセットに変換します。この場合は、マニフェストにより $extra_options ハッシュがバックエンドの追加設定オプションセットに変換されます。これは、マニフェストのコアパラメーターに含まれていない設定オプションを追加する柔軟な方法を提供します。

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

4.4. Puppet 設定への階層データの追加
リンクのコピー

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

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

  $nfs_mount_options    = undef,
Copy to Clipboard Toggle word wrap

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

  cinder::backend::nfs { $cinder_nfs_backend:
    nfs_mount_options   => hiera('cinder_nfs_mount_options'),
  }
Copy to Clipboard Toggle word wrap

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

cinder_nfs_mount_options: rsize=8192,wsize=8192
Copy to Clipboard Toggle word wrap

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

cinder::backend::nfs::nfs_mount_options: rsize=8192,wsize=8192
Copy to Clipboard Toggle word wrap

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

第5章 オーケストレーション
リンクのコピー

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

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

5.1. Heat テンプレートの基礎知識
リンクのコピー

5.1.1. Heat テンプレートの概要
リンクのコピー

The structure of a Heat template has three main sections:
Copy to Clipboard Toggle word wrap
パラメーター
これらは、Heat に渡される設定（スタックのカスタマイズが可能）およびパラメーターのデフォルト値（値を渡さない場合）です。これらがテンプレートの parameters セクションで定義されます。
リソース
これらは、スタックの一部として作成/設定する固有のオブジェクトです。OpenStack には全コンポーネントに対応するコアのリソースセットが含まれています。これらがテンプレートの resources セクションで定義されます。
出力
これらは、スタックの作成後に 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 ] }
Copy to Clipboard Toggle word wrap

このテンプレートは、リソース種別 type : OS::Nova::Server を使用して、特定のフレーバー、イメージ、キーで my_instance というインスタンスを作成します。スタックは、My Cirros Instance の instance_name の値を返します。

重要

Heat テンプレートは、利用可能な関数や使用する構文のバージョンを定義する heat_template_version パラメーターも必要とします。詳しい情報は Heat の正式なドキュメント を参照してください。

5.1.2. 環境ファイルの理解
リンクのコピー

環境ファイルとは、Heat テンプレートをカスタマイズする特別な種類のテンプレートです。このファイルは、3 つの主要な部分で設定されます。

パラメーター
これらは、テンプレートのパラメーターに適用する共通設定です。これらが環境ファイルの parameters セクションで定義されます。
パラメーターのデフォルト
これらのパラメーターは、テンプレート内のパラメーターのデフォルト値を変更します。これらが環境ファイルの parameter_defaults セクションで定義されています。
リソースレジストリー
このセクションでは、カスタムリソース名を定義し、他の Heat テンプレートにリンクします。これは実質的に、コアリソースコレクションに存在しないカスタムのリソースを作成する方法を提供します。この設定は、環境ファイルの resource_registry セクションで定義されます。

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

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

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1
Copy to Clipboard Toggle word wrap

これにより、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
Copy to Clipboard Toggle word wrap
注記

このテンプレートコレクションの 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 Satellite Server に登録できるようにします。
firstboot
ノードを最初に作成する際に director が使用する first_boot スクリプトの例を提供。
network
分離ネットワークおよびポートの作成に役立つ Heat テンプレートセット。
puppet
主に Puppet を使用した設定により動作するテンプレート。前述の overcloud-resource-registry-puppet.yaml 環境ファイルは、このディレクトリーのファイルを使用して、各ノードに Puppet の設定が適用されるようにします。
validation-scripts
すべてのデプロイメント設定で便利な検証スクリプトが含まれています。

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

5.3. 最初の起動時にの設定のカスタマイズ
リンクのコピー

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

以下の例では、全ノード上でカスタム IP アドレスを使用してネームサーバーを更新します。まず、各ノードの resolv.conf に特定のネームサーバーを追加するスクリプトを実行する基本的な Heat テンプレート(nameserver.yaml)を作成します。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}
Copy to Clipboard Toggle word wrap

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

resource_registry:
  OS::TripleO::NodeUserData: nameserver.yaml
Copy to Clipboard Toggle word wrap

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

  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
Copy to Clipboard Toggle word wrap

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

5.4. オーバークラウド設定前の設定のカスタマイズ
リンクのコピー

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

OS::TripleO::ControllerExtraConfigPre
Puppet のコア設定前にコントローラーノードに適用される追加の設定
OS::TripleO::ComputeExtraConfigPre
Puppet のコア設定前にコンピュートノードに適用される追加の設定
OS::TripleO::CephStorageExtraConfigPre
Puppet のコア設定前に CephStorage ノードに適用される追加の設定
OS::TripleO::NodeExtraConfig
Puppet のコア設定前に全ノードロールに適用される追加の設定

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

heat_template_version: 2014-10-16

parameters:
  server:
    type: server
  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]}
Copy to Clipboard Toggle word wrap
重要

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
Copy to Clipboard Toggle word wrap

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

  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
    Copy to Clipboard Toggle word wrap

  5. ExtraPreDeployments は、ExtraPreConfig 設定をノードにデプロイします。以下の点に注意してください。

    • config 属性は ExtraPreConfig リソースを参照し、適用する設定を Heat が理解できるようにします。
    • 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 タイプを使用して設定を適用します。これにより、オーバークラウドの主な設定が完了した後に追加の設定が適用されます。

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

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']
Copy to Clipboard Toggle word wrap
重要

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
Copy to Clipboard Toggle word wrap

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

  1. OS::TripleO::NodeExtraConfigPost は、コレクション内の設定後のテンプレートで使用する 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
    Copy to Clipboard Toggle word wrap

  5. ExtraDeployments は、ExtraConfig 設定をノードにデプロイします。以下の点に注意してください。

    • config 属性は ExtraConfig リソースを参照し、適用する設定を Heat が理解できるようにします。
    • 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'],
}
Copy to Clipboard Toggle word wrap

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']
Copy to Clipboard Toggle word wrap

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

resource_registry:
  OS::TripleO::NodeExtraConfigPost: puppet_config.yaml
Copy to Clipboard Toggle word wrap

この例は、前項の script フックの例から SoftwareConfig および SoftwareDeployments を使用する点で似ています。ただし、この例では以下の点が異なります。

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

  3. options 属性には、Puppet 設定固有のオプションが含まれます。

    • enable_hiera オプションは、Puppet 設定で Hiera データを使用できるようにします。
    • enable_facter オプションは、facter コマンドからシステムファクトを使用する Puppet 設定を有効にします。

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

5.7. オーバークラウド内の階層データの変更
リンクのコピー

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

director の Heat テンプレートコレクションのパラメーターセットを使用して、この階層データを渡します。これらのパラメーターの特徴は以下の通りです。

ExtraConfig
すべてのノードに追加する設定
NovaComputeExtraConfig
すべてのコンピュートノードに追加する設定
controllerExtraConfig
すべてのコントローラーノードに追加する設定
BlockStorageExtraConfig
すべての Block Storage ノードに追加する設定
ObjectStorageExtraConfig
すべてのオブジェクトストレージノードに追加する設定
CephStorageExtraConfig
すべての Ceph Storage ノードに追加する設定

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

parameter_defaults:
  NovaComputeExtraConfig:
    nova::compute::reserved_host_memory: 1024
Copy to Clipboard Toggle word wrap

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

環境ファイルは、順序通りにスタックされます。これは、主要な Heat テンプレートコレクションとこれまでの全環境ファイル両方の上に後続のファイルがスタックされることを意味します。この方法により、リソースの定義の上書きが可能となります。たとえば、オーバークラウドのデプロイメントにある全環境ファイルが NodeExtraConfigPost リソースを定義する場合、その後に Heat は最後の環境ファイルで定義した NodeExtraConfigPost を使用します。そのため、環境ファイルの順序は重要です。環境ファイルを正しく処理してスタックできるように、環境ファイルは順序付けてください。

警告

-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。director は、再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する場合があります。

[[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
    Copy to Clipboard Toggle word wrap

    これにより、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 はインスタンスの仮想ストレージデバイスを提供します。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 リポジトリーには、Glance 設定ファイルに属性を追加するための 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 リポジトリーには、Manila 設定ファイルに属性を追加するための manila_config と呼ばれるライブラリーが含まれます。

第6章 例
リンクのコピー

本章では、Red Hat OpenStack Platform の一部としてベンダー統合の例を説明します。

6.1. Cisco Nexus 1000V
リンクのコピー

Cisco Nexus 1000V は、仮想マシンへのアクセス用に設計されたネットワークスイッチです。また、VXLAN、ACL、および IGMP スヌーピングを使用した高度なスイッチングおよびセキュリティーも提供します。Cisco Nexus 1000V の ml2 ドライバーは networking-cisco リポジトリーに含まれています。これは、Neutron サービスと一緒にインストールできます。

オーバークラウドのイメージには Neutron Puppet モジュール(puppet-neutron)が含まれています。このモジュールには、クラス(neutron::plugins::ml2::cisco::nexus1000v)が含まれており、Neutron が Cisco Nexus 1000V を使用するように設定します。このクラスは、モジュールの manifests/plugins/ml2/cisco/nexus1000v.pp マニフェストにあります。クラスはデフォルトパラメーターのセットを使用してオーバーライドでき、neutron_plugin_ml2 ライブラリーを使用して ml2 プラグインが Cisco Nexus 1000V を使用するように設定します。 

neutron_plugin_ml2 {
  'ml2/extension_drivers'                          : value => $extension_drivers;
  'ml2_cisco_n1kv/n1kv_vsm_ips'                    : value => $n1kv_vsm_ip;
  'ml2_cisco_n1kv/username'                        : value => $n1kv_vsm_username;
  'ml2_cisco_n1kv/password'                        : value => $n1kv_vsm_password;
  'ml2_cisco_n1kv/default_policy_profile'          : value => $default_policy_profile;
  'ml2_cisco_n1kv/default_vlan_network_profile'    : value => $default_vlan_network_profile;
  'ml2_cisco_n1kv/default_vxlan_network_profile'   : value => $default_vxlan_network_profile;
  'ml2_cisco_n1kv/poll_duration'                   : value => $poll_duration;
  'ml2_cisco_n1kv/http_pool_size'                  : value => $http_pool_size;
  'ml2_cisco_n1kv/http_timeout'                    : value => $http_timeout;
  'ml2_cisco_n1kv/sync_interval'                   : value => $sync_interval;
  'ml2_cisco_n1kv/max_vsm_retries'                 : value => $max_vsm_retries;
  'ml2_cisco_n1kv/restrict_policy_profiles'        : value => $restrict_policy_profiles;
  'ml2_cisco_n1kv/enable_vif_type_n1kv'            : value => $enable_vif_type_n1kv;
}
Copy to Clipboard Toggle word wrap

director の Heat テンプレートコレクションには、Cisco Nexus 1000V の Hiera データを設定するための環境ファイルと登録済みテンプレートが含まれています。環境ファイルは environments/cisco-n1kv-config.yaml にあり、以下のデフォルトコンテンツが含まれています。 

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml
  OS::TripleO::ComputeExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml

parameter_defaults:
  N1000vVSMIP: '192.0.2.50'
  N1000vMgmtGatewayIP: '192.0.2.1'
  N1000vVSMDomainID: '100'
  N1000vVSMHostMgmtIntf: 'br-ex'
Copy to Clipboard Toggle word wrap

resource_registry は、事前設定に使用するテンプレートとして puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml を使用するように、コントローラーノードおよび コンピュートノードの事前設定リソース(OS::TripleO::Controller ExtraConfigPre および OS::TripleO::ComputeExtraConfigPre)を設定します。parameter_defaults セクションには、これらのリソースに渡すパラメーターが含まれています。

デプロイメントにこの環境ファイルを含めると、Puppet が設定中に Neutron Puppet モジュールのパラメーターに使用する Hiera データを定義します。

Puppet 設定の実際のアプリケーションの起動は自動的に行われます。Heat テンプレートコレクションには、コントローラーノードおよびコンピュートノードを設定するためのコア Puppet マニフェストのセットが含まれています。これらのファイルには、Cisco Nexus 1000V Hiera データが設定されているかどうかを検出するロジックが含まれています。その場合（デプロイメントに cisco-n1kv.yaml を含む）、マニフェストには neutron::plugins::ml2::cisco::nexus1000v クラスと Cisco Nexus 1000V の VEM および VSM エージェントが含まれます。 

  if 'cisco_n1kv' in hiera('neutron_mechanism_drivers') {
    include neutron::plugins::ml2::cisco::nexus1000v

    class { 'neutron::agents::n1kv_vem':
      n1kv_source          => hiera('n1kv_vem_source', undef),
      n1kv_version         => hiera('n1kv_vem_version', undef),
    }

    class { 'n1k_vsm':
      n1kv_source       => hiera('n1kv_vsm_source', undef),
      n1kv_version      => hiera('n1kv_vsm_version', undef),
    }
  }
Copy to Clipboard Toggle word wrap

これは、オーバークラウドが Cisco Nexus 1000V を使用するように設定するには、いくつかのステップのみが必要です。

  1. environments/cisco-n1kv-config.yaml ファイルをローカルの場所にコピーして、編集できるようにします。 

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/cisco-n1kv-config.yaml ~/templates/.
    Copy to Clipboard Toggle word wrap

  2. cisco-n1kv-config.yaml ファイルを編集します。

    • resource_registery セクションを変更して cisco-n1kv.yamlを参照の絶対パスを使用します。

    • parameter_defaults セクションを変更して、Cisco Nexus 1000V パラメーターを追加します。詳細は cisco-n1kv.yaml を参照してください。

      以下に例を示します。 

      resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml
  OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml

parameter_defaults:
  N1000vVSMIP: '192.0.2.50'
  N1000vMgmtGatewayIP: '192.0.2.1'
  N1000vVSMDomainID: '100'
  N1000vVSMHostMgmtIntf: 'br-ex'
  N1000vVSMUser: admin
  N1000vVSMPassword: p@55w0rd!
      Copy to Clipboard Toggle word wrap

  3. デプロイメントに cisco-n1kv-config.yaml ファイルを含めます。 

    $ openstack overcloud deploy --templates -e ~/templates/cisco-n1kv-config.yaml
    Copy to Clipboard Toggle word wrap

Cisco Nexus 1000V 設定をオーバークラウドの Hiera データの一部として定義します。その後、オーバークラウドはこの Hieradata を使用して、コアの設定中に Neutron の Nexus 1000V ml2 ドライバーを設定します。

以下の例で、director が認定済みベンダーのネットワークコンポーネントをオーバークラウドの Neutron サービスと統合する方法を実証します。

6.2. NetApp ストレージ
リンクのコピー

NetApp は、OpenStack ストレージコンポーネントと統合するための複数のソリューションを提供します。この例は、NetApp Storage を Cinder と統合して、ブロックストレージのバックエンドを提供する方法を示しています。

Cinder のドライバーはプロジェクト自体に含まれており、https://github.com/openstack/cinder の GitHub で公開されます。NetApp Storage 用のドライバーは、リポジトリーの cinder/volume/drivers/netapp/ ディレクトリーにあります。これは、ドライバーが Red Hat OpenStack Platform に自動的に含まれることを意味します。

NetApp の設定は、cinder (puppet-cinder)の Puppet モジュールに含まれています。このモジュールには、オーバークラウドイメージも含まれます。設定を含む Puppet モジュールのマニフェストは manifests/backend/netapp.pp にあります。このマニフェストは、cinder_config ライブラリーを使用して、Cinder 設定ファイルに netapp 設定を追加します。 

cinder_config {
  "${name}/nfs_mount_options":            value => $nfs_mount_options;
  "${name}/volume_backend_name":          value => $volume_backend_name;
  "${name}/volume_driver":                value => 'cinder.volume.drivers.netapp.common.NetAppDriver';
  "${name}/netapp_login":                 value => $netapp_login;
  "${name}/netapp_password":              value => $netapp_password, secret => true;
  "${name}/netapp_server_hostname":       value => $netapp_server_hostname;
  "${name}/netapp_server_port":           value => $netapp_server_port;
  "${name}/netapp_size_multiplier":       value => $netapp_size_multiplier;
  "${name}/netapp_storage_family":        value => $netapp_storage_family;
  "${name}/netapp_storage_protocol":      value => $netapp_storage_protocol;
  "${name}/netapp_transport_type":        value => $netapp_transport_type;
  "${name}/netapp_vfiler":                value => $netapp_vfiler;
  "${name}/netapp_volume_list":           value => $netapp_volume_list;
  "${name}/netapp_vserver":               value => $netapp_vserver;
  "${name}/netapp_partner_backend_name":  value => $netapp_partner_backend_name;
  "${name}/expiry_thres_minutes":         value => $expiry_thres_minutes;
  "${name}/thres_avl_size_perc_start":    value => $thres_avl_size_perc_start;
  "${name}/thres_avl_size_perc_stop":     value => $thres_avl_size_perc_stop;
  "${name}/nfs_shares_config":            value => $nfs_shares_config;
  "${name}/netapp_copyoffload_tool_path": value => $netapp_copyoffload_tool_path;
  "${name}/netapp_controller_ips":        value => $netapp_controller_ips;
  "${name}/netapp_sa_password":           value => $netapp_sa_password, secret => true;
  "${name}/netapp_storage_pools":         value => $netapp_storage_pools;
  "${name}/netapp_eseries_host_type":     value => $netapp_eseries_host_type;
  "${name}/netapp_webservice_path":       value => $netapp_webservice_path;
}
Copy to Clipboard Toggle word wrap

director の Heat テンプレートコレクションには、NetApp ストレージバックエンド用の Hiera データを設定するための環境ファイルおよび登録済みテンプレートが含まれています。環境ファイルは environments/cinder-netapp-config.yaml にあり、以下のデフォルトコンテンツが含まれています。 

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml

parameter_defaults:
  CinderEnableNetappBackend: true
  CinderNetappBackendName: 'tripleo_netapp'
  CinderNetappLogin: ''
  CinderNetappPassword: ''
  CinderNetappServerHostname: ''
  CinderNetappServerPort: '80'
  CinderNetappSizeMultiplier: '1.2'
  CinderNetappStorageFamily: 'ontap_cluster'
  CinderNetappStorageProtocol: 'nfs'
  CinderNetappTransportType: 'http'
  CinderNetappVfiler: ''
  CinderNetappVolumeList: ''
  CinderNetappVserver: ''
  CinderNetappPartnerBackendName: ''
  CinderNetappNfsShares: ''
  CinderNetappNfsSharesConfig: '/etc/cinder/shares.conf'
  CinderNetappNfsMountOptions: ''
  CinderNetappCopyOffloadToolPath: ''
  CinderNetappControllerIps: ''
  CinderNetappSaPassword: ''
  CinderNetappStoragePools: ''
  CinderNetappEseriesHostType: 'linux_dm_mp'
  CinderNetappWebservicePath: '/devmgr/v2'
Copy to Clipboard Toggle word wrap

resource_registry は、事前設定で使用するテンプレートとして puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml を使用するように、コントローラーノードの事前設定リソース(OS::TripleO::ControllerExtraConfigPre)を設定します。parameter_defaults セクションには、これらのリソースに渡すパラメーターが含まれています。

デプロイメントにこの環境ファイルを含めると、Puppet が設定中に Cinder Puppet モジュールのパラメーターに使用する Hiera データを定義します。

Puppet 設定の実際のアプリケーションを起動するには、CinderEnableNetappBackend パラメーターにより異なります。Heat テンプレートコレクションには、コントローラーノードを設定するためのコア Puppet マニフェストのセットが含まれています。これらのファイルには、cinder_enable_netapp_backend Hiera データが設定されているかどうかを検出するロジックが含まれています。Hiera データは、事前設定の CinderEnableNetappBackend パラメーターを使用して設定します。デプロイメントに cinder-netapp-config.yaml を含め、CinderEnableNetappBackend: true のままにすると、コントローラー Puppet マニフェストには cinder::backend::netapp クラスが含まれ、環境ファイルから Hiera データ値を渡します。 

  if hiera('cinder_enable_netapp_backend', false) {
    $cinder_netapp_backend = hiera('cinder::backend::netapp::title')

    cinder_config {
      "${cinder_netapp_backend}/host": value => 'hostgroup';
    }

    if hiera('cinder::backend::netapp::nfs_shares', undef) {
      $cinder_netapp_nfs_shares = split(hiera('cinder::backend::netapp::nfs_shares', undef), ',')
    }

    cinder::backend::netapp { $cinder_netapp_backend :
      netapp_login                 => hiera('cinder::backend::netapp::netapp_login', undef),
      netapp_password              => hiera('cinder::backend::netapp::netapp_password', undef),
      netapp_server_hostname       => hiera('cinder::backend::netapp::netapp_server_hostname', undef),
      netapp_server_port           => hiera('cinder::backend::netapp::netapp_server_port', undef),
      netapp_size_multiplier       => hiera('cinder::backend::netapp::netapp_size_multiplier', undef),
      netapp_storage_family        => hiera('cinder::backend::netapp::netapp_storage_family', undef),
      netapp_storage_protocol      => hiera('cinder::backend::netapp::netapp_storage_protocol', undef),
      netapp_transport_type        => hiera('cinder::backend::netapp::netapp_transport_type', undef),
      netapp_vfiler                => hiera('cinder::backend::netapp::netapp_vfiler', undef),
      netapp_volume_list           => hiera('cinder::backend::netapp::netapp_volume_list', undef),
      netapp_vserver               => hiera('cinder::backend::netapp::netapp_vserver', undef),
      netapp_partner_backend_name  => hiera('cinder::backend::netapp::netapp_partner_backend_name', undef),
      nfs_shares                   => $cinder_netapp_nfs_shares,
      nfs_shares_config            => hiera('cinder::backend::netapp::nfs_shares_config', undef),
      netapp_copyoffload_tool_path => hiera('cinder::backend::netapp::netapp_copyoffload_tool_path', undef),
      netapp_controller_ips        => hiera('cinder::backend::netapp::netapp_controller_ips', undef),
      netapp_sa_password           => hiera('cinder::backend::netapp::netapp_sa_password', undef),
      netapp_storage_pools         => hiera('cinder::backend::netapp::netapp_storage_pools', undef),
      netapp_eseries_host_type     => hiera('cinder::backend::netapp::netapp_eseries_host_type', undef),
      netapp_webservice_path       => hiera('cinder::backend::netapp::netapp_webservice_path', undef),
    }
  }
Copy to Clipboard Toggle word wrap

これは、NetApp Storage を使用するようにオーバークラウドを設定するには、いくつかのステップのみが必要となります。

  1. environments/cinder-netapp-config.yaml ファイルをローカルの場所にコピーし、編集できるようにします。 

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-netapp-config.yaml ~/templates/.
    Copy to Clipboard Toggle word wrap

  2. cinder-netapp-config.yaml ファイルを編集します。

    • resource_registery セクションを変更して、cinder-netapp.yamlを参照する絶対パスを使用します。

    • parameter_defaults セクションを変更して NetApp パラメーターを追加します。詳細は、cinder-netapp.yaml を参照してください。

      以下に例を示します。 

      resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml

parameter_defaults:
  CinderEnableNetappBackend: true
  CinderNetappBackendName: 'tripleo_netapp'
  CinderNetappLogin: 'admin'
  CinderNetappPassword: 'p@55w0rd!'
  CinderNetappServerHostname: 'netapp.example.com'
  CinderNetappServerPort: '80'
  CinderNetappSizeMultiplier: '1.2'
  CinderNetappStorageFamily: 'ontap_cluster'
  CinderNetappStorageProtocol: 'nfs'
  CinderNetappTransportType: 'http'
  CinderNetappNfsShares: '192.168.1.200:/storage1,192.168.1.200:/storage2'
  CinderNetappNfsSharesConfig: '/etc/cinder/shares.conf'
  CinderNetappEseriesHostType: 'linux_dm_mp'
  CinderNetappWebservicePath: '/devmgr/v2'
      Copy to Clipboard Toggle word wrap

      CinderEnableNetappBackend は true に設定したままにしてください。

  3. デプロイメントに cinder-netapp-config.yaml ファイルを追加します。 

    $ openstack overcloud deploy --templates -e ~/templates/cinder-netapp-config.yaml
    Copy to Clipboard Toggle word wrap

これは、オーバークラウドの Hiera データの一部として NetApp ストレージ設定を定義します。次に、オーバークラウドはこの Hieradata を使用して、コアの設定中に Cinder の NetApp バックエンドを設定します。

以下の例で、director が認定されたベンダーのストレージコンポーネントをオーバークラウドの Cinder サービスと統合する方法を実証します。

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat