オーバークラウドの高度なカスタマイズ

1. コア heat テンプレートコレクションからデフォルト設定を読み込みます。
2. environment-file-1.yaml の設定を適用します。この設定により、デフォルト設定と共通している設定は上書きされます。
3. environment-file-2.yaml の設定を適用します。この設定により、デフォルト設定および environment-file-1.yaml と共通している設定は上書きされます。

1. 設定するオプションを特定します。そのオプションを使用するサービスを書き留めておきます。

2. このオプションに対応する Puppet モジュールを確認します。Red Hat OpenStack Platform 用の Puppet モジュールは director ノードの /etc/puppet/modules にあります。各モジュールは、特定のサービスに対応しています。たとえば、keystone モジュールは OpenStack Identity (keystone) に対応しています。

   • 選択したオプションを制御する変数が Puppet モジュールに含まれている場合には、次のステップに進んでください。
   • 選択したオプションを制御する変数が Puppet モジュールに含まれていない場合には、そのオプションには hieradata は存在しません。可能な場合には、オーバークラウドがデプロイメントを完了した後でオプションを手動で設定することができます。

3. コア heat テンプレートコレクションに hieradata 形式の Puppet 変数が含まれているかどうかを確認します。deployment/* は通常、同じサービスの Puppet モジュールに対応します。たとえば、deployment/keystone/keystone-container-puppet.yaml テンプレートは、keystone モジュールの hieradata を提供します。

   • heat テンプレートが Puppet 変数用の hieradata を設定している場合には、そのテンプレートは変更することのできる director ベースのパラメーターも開示する必要があります。
   • heat テンプレートが Puppet 変数用の hieradata を設定していない場合には、環境ファイルを使用して、設定フックにより hieradata を渡します。hieradata のカスタマイズに関する詳細は、「Puppet: ロール用 hieradata のカスタマイズ」 を参照してください。

手順

1. OpenStack Identity (keystone) の通知の形式を変更するには、ワークフローを使用して、以下の手順を実施します。

   1. 設定する OpenStack パラメーターを特定します (notification_format)。

   2. keystone Puppet モジュールで notification_format の設定を検索します。

      $ grep notification_format /etc/puppet/modules/keystone/manifests/*

      この場合は、keystone モジュールは keystone::notification_format の変数を使用してこのオプションを管理します。

   3. keystone サービステンプレートでこの変数を検索します。

      $ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml

      このコマンドの出力には、director が KeystoneNotificationFormat パラメーターを使用して keystone::notification_format hieradata を設定していると表示されます。

手順

1. 各ノードの resolv.conf に特定のネームサーバーを追加するスクリプトを実行するために、まず基本的な heat テンプレート (~/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}

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

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

3. オーバークラウドに初回ブートの設定を追加するには、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。

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

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

手順

1. ノードの resolv.conf ファイルに変数のネームサーバーを書き込むスクリプトを実行するために、基本的な heat テンプレート ~/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 セクションには以下のパラメーターが含まれます。

   CustomExtraConfigPre

   ここでは、ソフトウェア設定を定義します。上記の例では、Bash スクリプト を定義し、heat が _NAMESERVER_IP_ を nameserver_ip パラメーターに保管された値に置き換えます。

   CustomExtraDeploymentPre

   この設定により、CustomExtraConfigPre リソースで定義したソフトウェア設定を実行します。以下の点に注意してください。

   • config パラメーターは CustomExtraConfigPre リソースを参照し、適用する設定を heat が理解できるようにします。
   • server パラメーターは、オーバークラウドノードのマッピングを取得します。これは親テンプレートにより提供されるパラメーターで、このフックのテンプレートには必須です。
   • actions パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時に設定を適用します。設定可能なアクションは CREATE、UPDATE、DELETE、SUSPEND、および RESUME です。
   • input_values では deploy_identifier というパラメーターを定義し、親テンプレートからの DeployIdentifier を格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。

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

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

3. その他の環境ファイルと共に環境ファイルをスタックに追加します。

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

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

手順

1. 各ノードの resolv.conf に変数のネームサーバーを追加するスクリプトを実行するために、まず基本的な heat テンプレート (~/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 セクションには以下のパラメーターが含まれます。

   CustomExtraConfigPre

   このパラメーターは、ソフトウェア設定を定義します。上記の例では、Bash スクリプト を定義し、heat が _NAMESERVER_IP_ を nameserver_ip パラメーターに保管された値に置き換えます。

   CustomExtraDeploymentPre

   このパラメーターにより、CustomExtraConfigPre リソースで定義したソフトウェア設定を実行します。以下の点に注意してください。

   • config パラメーターは CustomExtraConfigPre リソースを参照し、適用する設定を heat が理解できるようにします。
   • server パラメーターは、オーバークラウドノードのマッピングを取得します。これは親テンプレートにより提供されるパラメーターで、このフックのテンプレートには必須です。
   • actions パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時にのみ設定を適用します。設定可能なアクションは CREATE、UPDATE、DELETE、SUSPEND、および RESUME です。
   • input_values パラメーターでは deploy_identifier というサブパラメーターを定義し、親テンプレートからの DeployIdentifier を格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。

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

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

3. その他の環境ファイルと共に環境ファイルをスタックに追加します。

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

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

手順

1. 各ノードの resolv.conf に変数のネームサーバーを追加するスクリプトを実行するために、まず基本的な heat テンプレート (~/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 セクションには以下のパラメーターが含まれます。

   CustomExtraConfig

   ここでは、ソフトウェア設定を定義します。上記の例では、Bash スクリプト を定義し、heat が _NAMESERVER_IP_ を nameserver_ip パラメーターに保管された値に置き換えます。

   CustomExtraDeployments

   この設定により、CustomExtraConfig リソースで定義したソフトウェア設定を実行します。以下の点に注意してください。

   • config パラメーターは CustomExtraConfig リソースを参照し、適用する設定を heat が理解できるようにします。
   • servers パラメーターは、オーバークラウドノードのマッピングを取得します。これは親テンプレートにより提供されるパラメーターで、このフックのテンプレートには必須です。
   • actions パラメーターは、設定を適用するタイミングを定義します。上記の例では、オーバークラウドが作成または更新された時に設定を適用します。設定可能なアクションは CREATE、UPDATE、DELETE、SUSPEND、および RESUME です。
   • input_values では deploy_identifier というパラメーターを定義し、親テンプレートからの DeployIdentifier を格納します。このパラメーターにより、各デプロイメント更新のリソースにタイムスタンプが提供されます。これにより、これ以降のオーバークラウド更新時にリソースが再度適用されるようになります。

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

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

3. その他の環境ファイルと共に環境ファイルをスタックに追加します。

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

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

手順

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

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

2. ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを openstack overcloud deploy コマンドに追加します。

手順

1. ノードのイントロスペクションデータからシステム UUID を特定します。

   $ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid

   このコマンドは、システム UUID を返します。以下に例を示します。

   "f5055c6c-477f-47fb-afe5-95c6928c407f"

2. ノード固有の hieradata を定義して per_node.yaml テンプレートを事前設定フックに登録する環境ファイルを作成します。NodeDataLookup パラメーターに、設定するノードのシステム UUID を指定します。

   resource_registry:
     OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
   parameter_defaults:
     NodeDataLookup: '{"f5055c6c-477f-47fb-afe5-95c6928c407f": {"nova::compute::vcpu_pin_set": [ "2", "3" ]}}'

3. ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを openstack overcloud deploy コマンドに追加します。

手順

1. Puppet 設定を起動する heat テンプレート ~/templates/custom_puppet_config.yaml を作成します。

   heat_template_version: 2014-10-16
   
   description: >
     Run Puppet extra configuration to set new MOTD
   
   parameters:
     servers:
       type: json
     DeployIdentifier:
       type: string
     EndpointMap:
       default: {}
       type: json
   
   resources:
     ExtraPuppetConfig:
       type: OS::Heat::SoftwareConfig
       properties:
         config: {get_file: motd.pp}
         group: puppet
         options:
           enable_hiera: True
           enable_facter: False
   
     ExtraPuppetDeployments:
       type: OS::Heat::SoftwareDeploymentGroup
       properties:
         config: {get_resource: ExtraPuppetConfig}
         servers: {get_param: servers}

   この例は、テンプレート内に /home/stack/templates/motd.pp を追加し、設定するノードに渡します。motd.pp ファイルには、motd のインストールと設定に必要な Puppet クラスが含まれています。

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

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

3. ご自分のデプロイメントに該当するその他の環境ファイルと共に、この環境ファイルを openstack overcloud deploy コマンドに追加します。

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

   これにより、motd.pp からの設定がオーバークラウド内の全ノードに適用されます。

手順

1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。

2. 環境ファイルに設定を追加します。以下に例を示します。

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     RhsmVars:
       rhsm_repos:
         - rhel-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         …​
       rhsm_username: "myusername"
       rhsm_password: "p@55w0rd!"
       rhsm_org_id: "1234567"
       rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
       rhsm_method: "portal"
       rhsm_release: 8.4

   • resource_registry セクションは、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。
   • RhsmVars の変数は、Red Hat の登録を設定するためにパラメーターを Ansible に渡します。
3. 環境ファイルを保存します。

手順

1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。

2. 環境ファイルに設定を追加します。以下に例を示します。

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     ControllerParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-eus-rpms
           - rhel-8-for-x86_64-appstream-eus-rpms
           - rhel-8-for-x86_64-highavailability-eus-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-for-rhel-8-x86_64-rpms
           - fast-datapath-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 8.4
     ComputeParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-eus-rpms
           - rhel-8-for-x86_64-appstream-eus-rpms
           - rhel-8-for-x86_64-highavailability-eus-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-for-rhel-8-x86_64-rpms
           - fast-datapath-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 8.4
     CephStorageParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-rpms
           - rhel-8-for-x86_64-appstream-rpms
           - rhel-8-for-x86_64-highavailability-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
         rhsm_method: "portal"
         rhsm_release: 8.4

   resource_registry は、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。

   ControllerParameters、ComputeParameters、および CephStorageParameters パラメーターはいずれも、個別の RhsmVars パラメーターを使用してサブスクリプションの情報をそれぞれのロールに渡します。

   注記

   Red Hat Ceph Storage のサブスクリプションおよび Ceph Storage 固有のリポジトリーを使用するように、CephStorageParameters パラメーター内の RhsmVars パラメーターを設定します。rhsm_repos パラメーターに、コントローラーノードおよび Compute ノードに必要な Extended Update Support (EUS) リポジトリーではなく、標準の Red Hat Enterprise Linux リポジトリーが含まれるようにします。

3. 環境ファイルを保存します。

手順

1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。

2. 環境ファイルに設定を追加します。以下に例を示します。

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     RhsmVars:
       rhsm_activation_key: "myactivationkey"
       rhsm_method: "satellite"
       rhsm_org_id: "ACME"
       rhsm_server_hostname: "satellite.example.com"
       rhsm_baseurl: "https://satellite.example.com/pulp/repos"
       rhsm_release: 8.4

   resource_registry は、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。

   RhsmVars の変数は、Red Hat の登録を設定するためにパラメーターを Ansible に渡します。

3. 環境ファイルを保存します。

手順

1. rhel-registration 環境ファイルは、今後のデプロイメント操作から除外します。通常は、以下のファイルを除外します。

   • rhel-registration/environment-rhel-registration.yaml
   • rhel-registration/rhel-registration-resource-registry.yaml

2. カスタムの roles_data ファイルを使用する場合には、roles_data ファイルの各ロールに必ず OS::TripleO::Services::Rhsm コンポーザブルサービスを含めてください。以下に例を示します。

   - name: Controller
     description: |
       Controller role that has all the controller services loaded and handles
       Database, Messaging and Network functions.
     CountDefault: 1
     ...
     ServicesDefault:
       ...
       - OS::TripleO::Services::Rhsm
       ...

3. rhsm コンポーザブルサービスのパラメーター用の環境ファイルを今後のデプロイメント操作に追加します。

手順

1. openstack overcloud deploy コマンドに rhsm.yml 環境ファイルを追加します。

   openstack overcloud deploy \
       <other cli args> \
       -e ~/templates/rhsm.yaml

   これにより、Ansible のオーバークラウドの設定と、Ansible ベースの登録が有効化されます。

2. オーバークラウドのデプロイメントが完了するまで待ちます。

3. オーバークラウドノードのサブスクリプション情報を確認します。たとえば、コントローラーノードにログインして、以下のコマンドを実行します。

   $ sudo subscription-manager status
   $ sudo subscription-manager list --consumed

手順

1. ノードを登録する redhat_subscription モジュールを使用して Playbook を作成します。たとえば、以下の Playbook はコントローラーノードに適用されます。

   ---
   - name: Register Controller nodes
     hosts: Controller
     become: yes
     vars:
       repos:
         - rhel-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         - ansible-2.9-for-rhel-8-x86_64-rpms
         - openstack-beta-for-rhel-8-x86_64-rpms
         - fast-datapath-for-rhel-8-x86_64-rpms
     tasks:
       - name: Register system
         redhat_subscription:
           username: myusername
           password: p@55w0rd!
           org_id: 1234567
           release: 8.4
           pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
       - name: Disable all repos
         command: "subscription-manager repos --disable *"
       - name: Enable Controller node repos
         command: "subscription-manager repos --enable {{ item }}"
         with_items: "{{ repos }}"

   • このプレイには 3 つのタスクが含まれます。

     • ノードを登録する。
     • 自動的に有効化されるリポジトリーをすべて無効にする。
     • コントローラーノードに関連するリポジトリーだけを有効にする。リポジトリーは repos 変数でリストされます。

2. オーバークラウドのデプロイ後には、以下のコマンドを実行して、Ansible がオーバークラウドに対して Playbook (ansible-osp-registration.yml) を実行することができます。

   $ ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml

   このコマンドにより、以下のアクションが行われます。

   • 動的インベントリースクリプトを実行し、ホストとそのグループのリストを取得する。
   • Playbook の hosts パラメーターで定義されているグループ (この場合はコントローラーグループ) 内のノードに、その Playbook のタスクを適用する。

手順

1. デフォルトロールのテンプレートをリスト表示します。

   $ openstack overcloud roles list
   BlockStorage
   CephStorage
   Compute
   ComputeHCI
   ComputeOvsDpdk
   Controller
   ...

2. openstack overcloud roles show コマンドを使用して、YAML 形式のロール定義を表示します。

   $ openstack overcloud roles show Compute

3. カスタムの roles_data ファイルを生成します。openstack overcloud roles generate コマンドを使用して、複数の事前定義済みロールを単一のロールに統合します。たとえば、以下のコマンドを実行して、Controller、Compute、および Networker ロールが含まれる roles_data.yaml ファイルを生成します。

   $ openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker

   -o オプションを使用して、出力ファイルの名前を定義します。

   このコマンドにより、カスタムの roles_data ファイルが作成されます。ただし、上記の例では、Controller と Networker ロールを使用しており、その両方に同じネットワークエージェントが含まれています。つまり、ネットワークサービスは Controller ロールから Networker ロールにスケーリングされ、オーバークラウドは Controller ノードと Networker ノード間にネットワークサービスの負荷のバランスを取ります。

   この Networker ロールをスタンドアロンにするには、独自のカスタム Controller ロールと、その他の必要なロールを作成することができます。これにより、独自のカスタムロールから roles_data ファイルを生成できるようになります。

4. コア heat テンプレートコレクションから stack ユーザーのホームディレクトリーにディレクトリーをコピーします。

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

5. このディレクトリー内でカスタムロールファイルを追加または変更します。このディレクトリーをカスタムロールのソースとして使用するには、ロールのサブコマンドに --roles-path オプションを指定します。

   $ openstack overcloud roles generate -o my_roles_data.yaml \
     --roles-path ~/roles \
     Controller Compute Networker

   このコマンドにより、~/roles ディレクトリー内の個々のロールから、単一の my_roles_data.yaml ファイルが生成されます。

手順

1. デフォルトの roles ディレクトリーのカスタムコピーを作成します。

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

2. ~/roles/Horizon.yaml という名前の新規ファイルを作成して、ベースおよびコアの OpenStack Dashboard サービスが含まれた Horizon ロールを新規作成します。

   - name: Horizon
     CountDefault: 1
     HostnameFormatDefault: '%stackname%-horizon-%index%'
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Sshd
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::MySQLClient
       - OS::TripleO::Services::Apache
       - OS::TripleO::Services::Horizon

   • name パラメーターをカスタムロールの名前に設定します。カスタムロール名の最大長は 47 文字です。
   • CountDefault パラメーターを 1 に設定して、デフォルトのオーバークラウドに常に Horizon ノードが含まれるようにすると良いでしょう。

3. (オプション) 既存のオーバークラウド内でサービスをスケーリングする場合は、既存のサービスを Controller ロール上に保持します。新規オーバークラウドを作成して、OpenStack Dashboard がスタンドアロンのロールに残るようにするには、Controller ロールの定義から OpenStack Dashboard コンポーネントを削除します。

   - name: Controller
     CountDefault: 1
     ServicesDefault:
       ...
       - OS::TripleO::Services::GnocchiMetricd
       - OS::TripleO::Services::GnocchiStatsd
       - OS::TripleO::Services::HAproxy
       - OS::TripleO::Services::HeatApi
       - OS::TripleO::Services::HeatApiCfn
       - OS::TripleO::Services::HeatApiCloudwatch
       - OS::TripleO::Services::HeatEngine
       # - OS::TripleO::Services::Horizon                # Remove this service
       - OS::TripleO::Services::IronicApi
       - OS::TripleO::Services::IronicConductor
       - OS::TripleO::Services::Iscsid
       - OS::TripleO::Services::Keepalived
       ...

4. ~/roles ディレクトリーをソースに使用して、新しい roles_data-horizon.yaml ファイルを生成します。

   $ openstack overcloud roles generate -o roles_data-horizon.yaml \
     --roles-path ~/roles \
     Controller Compute Horizon

5. 特定のノードにタグ付けできるように、このロールの新しいフレーバーを定義します。この例では、以下のコマンドを使用して horizon フレーバーを作成します。

   1. horizon フレーバーを作成します。

      (undercloud)$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon

      注記

      これらのプロパティーはインスタンスのスケジューリングには使用されませんが、Compute スケジューラーはディスクサイズを使用してルートパーティションサイズを決定します。

   2. ダッシュボードサービス (horizon) 用に指定する各ベアメタルノードに、カスタムリソースクラスでタグを付けます。

      (undercloud)$ openstack baremetal node set --resource-class baremetal.HORIZON <NODE>

      <NODE> をベアメタルノードの ID に置き換えます。

   3. Horizon フレーバーをカスタムリソースクラスに関連付けます。

      (undercloud)$ openstack flavor set --property resources:CUSTOM_BAREMETAL_HORIZON=1 horizon

      ベアメタルノードのリソースクラスに対応するカスタムリソースクラスの名前を指定するには、リソースクラスを大文字に変換し、句読点をアンダースコアに置き換え、CUSTOM_ が付いた値の接頭辞を追加します。

      注記

      フレーバーが要求できるのは、ベアメタルリソースクラスの 1 つのインスタンスだけです。

   4. 以下のフレーバー属性を設定して、Compute スケジューラーがインスタンスのスケジューリングにベアメタルフレーバー属性を使用するのを防ぎます。

      (undercloud)$ openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 horizon

6. 以下の環境ファイルのスニペットを使用して、Horizon ノードの数とフレーバーを定義します。

   parameter_defaults:
     OvercloudHorizonFlavor: horizon
     HorizonCount: 1

7. ご自分のデプロイメントに該当するその他の環境ファイルと共に、新しい roles_data-horizon.yaml ファイルおよび環境ファイルを openstack overcloud deploy コマンドに追加します。

   $ openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml

   この設定により、コントローラーノードが 1 台、コンピュートノードが 1 台、ネットワーカーノードが 1 台の 3 ノード設定のオーバークラウドが作成されます。オーバークラウドのノードリストを表示するには、以下のコマンドを実行します。

   $ openstack server list

手順

1. デフォルトの roles ディレクトリーのカスタムコピーを作成します。

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

2. ~/roles/Controller.yaml ファイルを編集して、ServicesDefault パラメーターのサービスリストを変更します。OpenStack Orchestration のサービスまでスクロールしてそれらを削除します。

       - OS::TripleO::Services::GlanceApi
       - OS::TripleO::Services::GlanceRegistry
       - OS::TripleO::Services::HeatApi            # Remove this service
       - OS::TripleO::Services::HeatApiCfn         # Remove this service
       - OS::TripleO::Services::HeatApiCloudwatch  # Remove this service
       - OS::TripleO::Services::HeatEngine         # Remove this service
       - OS::TripleO::Services::MySQL
       - OS::TripleO::Services::NeutronDhcpAgent

3. 新しい roles_data ファイルを生成します。

   $ openstack overcloud roles generate -o roles_data-no_heat.yaml \
     --roles-path ~/roles \
     Controller Compute Networker

4. openstack overcloud deploy コマンドを実行する際には、この新しい roles_data ファイルを指定します。

   $ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml

   このコマンドにより、コントローラーノードには OpenStack Orchestration のサービスがインストールされない状態でオーバークラウドがデプロイされます。

手順

1. CinderBackup サービスを cinder-backup 設定を含む heat テンプレートにリンクする環境ファイルにエントリーを追加します。

   resource_registry:
     OS::TripleO::Services::CinderBackup: ../podman/services/pacemaker/cinder-backup.yaml
   ...

   このエントリーにより、デフォルトの null 操作のリソースが上書きされ、これらのサービスが有効になります。

2. openstack overcloud deploy コマンドの実行時に、この環境ファイルを指定します。

   $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml

手順

1. カスタムの roles_data.yaml ファイルに ServicesDefault のリストが含まれない汎用ロールを作成します。

   - name: Generic
   - name: Controller
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephClient
       ...
   - name: Compute
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephClient
       ...

   既存の Controller ロールおよび Compute ロールを維持するようにしてください。

2. また、プロビジョニングするノードを選択する際には、必要な汎用 Red Hat Enterprise Linux 8 ノード数とフレーバーを指定する環境ファイル (generic-node-params.yaml) も追加することができます。

   parameter_defaults:
     OvercloudGenericFlavor: baremetal
     GenericCount: 1

3. openstack overcloud deploy コマンドを実行する際に、ロールのファイルと環境ファイルの両方を指定します。

   $ openstack overcloud deploy --templates \
   -r ~/templates/roles_data_with_generic.yaml \
   -e ~/templates/generic-node-params.yaml

   この設定により、コントローラーノードが 1 台、コンピュートノードが 1 台、汎用 Red Hat Enterprise Linux 8 ノードが 1 台の 3 ノード設定の環境がデプロイされます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. デフォルトのコンテナーイメージ準備ファイルを生成します。

   $ sudo openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

   上記のコマンドでは、以下の追加オプションを使用しています。

   • --local-push-destination: コンテナーイメージの保管場所として、アンダークラウド上のレジストリーを設定します。つまり、director は必要なイメージを Red Hat Container Catalog からプルし、それをアンダークラウド上のレジストリーにプッシュします。director はこのレジストリーをコンテナーイメージのソースとして使用します。Red Hat Container Catalog から直接プルする場合には、このオプションを省略します。

   • --output-env-file: 環境ファイルの名前です。このファイルには、コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名は containers-prepare-parameter.yaml です。

     注記

     アンダークラウドとオーバークラウド両方のコンテナーイメージのソースを定義するのに、同じ containers-prepare-parameter.yaml ファイルを使用することができます。

3. 要件に合わせて containers-prepare-parameter.yaml を変更します。

手順

1. 以下の例では、nova-compute イメージでカスタム Dockerfile が実行されます。

   ContainerImagePrepare:
   - push_destination: true
     ...
     includes:
     - nova-compute
     modify_role: tripleo-modify-image
     modify_append_tag: "-hotfix"
     modify_vars:
       tasks_from: modify_image.yml
       modify_dir_path: /home/stack/nova-custom
     ...

2. /home/stack/nova-custom/Dockerfile ファイルの例を以下に示します。USER root ディレクティブを実行した後は、元のイメージのデフォルトユーザーに戻す必要があります。

   FROM registry.redhat.io/rhosp-rhel8/openstack-nova-compute:latest
   
   USER "root"
   
   COPY customize.sh /tmp/
   RUN /tmp/customize.sh
   
   USER "nova"

手順

1. オーバークラウド用に新たなコンテナーイメージファイルを作成します。

   $ sudo openstack tripleo container image prepare default \
       --local-push-destination \
       --output-env-file containers-prepare-parameter-dellemc.yaml

2. containers-prepare-parameter-dellemc.yaml ファイルを編集します。

3. メインの Red Hat OpenStack Platform コンテナーイメージの設定に exclude パラメーターを追加します。このパラメーターを使用して、ベンダーコンテナーイメージで置き換えるコンテナーイメージを除外します。以下の例では、コンテナーイメージは cinder-volume イメージです。

   parameter_defaults:
     ContainerImagePrepare:
       - push_destination: true
         excludes:
     	   - cinder-volume
         set:
           namespace: registry.redhat.io/rhosp-rhel8
           name_prefix: openstack-
           name_suffix: ''
           tag: 16.2
           ...
         tag_from_label: "{version}-{release}"

4. ContainerImagePrepare パラメーターに、ベンダープラグインの代替コンテナーイメージが含まれる新しい設定を追加します。

   parameter_defaults:
     ContainerImagePrepare:
       ...
       - push_destination: true
         includes:
           - cinder-volume
         set:
           namespace: registry.connect.redhat.com/dellemc
           name_prefix: openstack-
           name_suffix: -dellemc-rhosp16
           tag: 16.2-2
           ...

5. ContainerImageRegistryCredentials パラメーターに registry.connect.redhat.com レジストリーの認証情報を追加します。

   parameter_defaults:
     ContainerImageRegistryCredentials:
       registry.redhat.io:
         [service account username]: [service account password]
       registry.connect.redhat.com:
         [service account username]: [service account password]

6. containers-prepare-parameter-dellemc.yaml ファイルを保存します。

7. openstack overcloud deploy などのデプロイメントコマンドに containers-prepare-parameter-dellemc.yaml ファイルを追加します。

   $ openstack overcloud deploy --templates
       ...
       -e containers-prepare-parameter-dellemc.yaml
       ...

   director がオーバークラウドをデプロイする際に、オーバークラウドは標準のコンテナーイメージの代わりにベンダーのコンテナーイメージを使用します。

   IMPORTANT

   containers-prepare-parameter-dellemc.yaml ファイルは、オーバークラウドデプロイメント内の標準の containers-prepare-parameter.yaml ファイルを置き換えます。オーバークラウドのデプロイメントに、標準の containers-prepare-parameter.yaml ファイルを含めないでください。アンダークラウドのインストールおよび更新には、標準の containers-prepare-parameter.yaml ファイルを維持します。

手順

1. デフォルトの network_data.yaml ファイルのコピーします。

   $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.

2. network_data.yaml ファイルのローカルコピーを編集し、ご自分のネットワーク要件に応じてパラメーターを変更します。たとえば、内部 API ネットワークには以下のデフォルトネットワーク情報が含まれます。

   - name: InternalApi
     name_lower: internal_api
     vip: true
     vlan: 201
     ip_subnet: '172.16.2.0/24'
     allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]

手順

1. openstack overcloud deploy コマンドを実行する際に、以下のレンダリング済みファイルを追加するようにしてください。

   • カスタム network_data.yaml ファイル
   • デフォルトネットワーク分離ファイルのレンダリング済みファイル名
   • デフォルトネットワーク環境ファイルのレンダリング済みファイル名
   • デフォルトネットワークインターフェイス設定ファイルのレンダリング済みファイル名
   • 設定に必要なその他の環境ファイル

手順

1. デフォルトの network_data.yaml ファイルのコピーします。

   $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.

2. network_data.yaml ファイルのローカルコピーを編集し、新規ネットワーク用のセクションを追加します。

   - name: StorageBackup
     name_lower: storage_backup
     vlan: 21
     vip: true
     ip_subnet: '172.21.1.0/24'
     allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
     gateway_ip: '172.21.1.1'

   network_data.yaml ファイルでは、以下のパラメーターを使用することができます。

   name

   人間が判読可能なネットワークの名前を設定します。必須のパラメーターは、このパラメーターだけです。判読性を向上させるために、name_lower を使用して名前を正規化することもできます。たとえば、InternalApi を internal_api に変更します。

   name_lower

   ネットワーク名の小文字バージョンを設定します。director は、この名前を roles_data.yaml ファイルのロールに割り当てられる該当ネットワークにマッピングします。

   vlan

   このネットワークに使用する VLAN を設定します。

   vip: true

   新規ネットワーク上に仮想 IP アドレス (VIP) を作成します。この IP は、サービス/ネットワーク間のマッピングパラメーター (ServiceNetMap) にリスト表示されるサービスのターゲット IP として使用されます。仮想 IP は Pacemaker を使用するロールにしか使用されない点に注意してください。オーバークラウドの負荷分散サービスにより、トラフィックがこれらの IP から対応するサービスのエンドポイントにリダイレクトされます。

   ip_subnet

   デフォルトの IPv4 サブネットを CIDR 形式で設定します。

   allocation_pools

   IPv4 サブネットの IP 範囲を設定します。

   gateway_ip

   ネットワークのゲートウェイを設定します。

   routes

   ネットワークに新たなルートを追加します。それぞれの追加ルートが含まれる JSON リストを使用します。それぞれのリスト項目には、ディクショナリーの値のマッピングが含まれます。構文例を以下に示します。

     routes: [{'destination':'10.0.0.0/16', 'nexthop':'10.0.2.254'}]

   subnets

   このネットワーク内にある追加のルーティングされたサブネットを作成します。このパラメーターでは、ルーティングされたサブネット名の小文字バージョンが含まれる dict 値をキーとして指定し、vlan、ip_subnet、allocation_pools、および gateway_ip パラメーターをサブネットにマッピングする値として指定します。このレイアウトの例を以下に示します。

   - name: StorageBackup
     name_lower: storage_backup
     vlan: 200
     vip: true
     ip_subnet: '172.21.0.0/24'
     allocation_pools: [{'start': '171.21.0.4', 'end': '172.21.0.250'}]
     gateway_ip: '172.21.0.1'
     subnets:
       storage_backup_leaf1:
         vlan: 201
         ip_subnet: '172.21.1.0/24'
         allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
         gateway_ip: '172.19.1.254'

   このマッピングは、スパイン/リーフ型デプロイメントで一般的に使用されます。詳しくは、Spine Leaf Networking を参照してください。

3. 仮想 IP を含むコンポーザブルネットワークを追加し、一部の API サービスをこのネットワークにマッピングする場合は、CloudName{network.name} 定義を使用して API エンドポイントの DNS 名を設定します。

   CloudName{{network.name}}

   以下に例を示します。

   parameter_defaults:
     ...
     CloudNameOcProvisioning: baremetal-vip.example.com

4. -n オプションを使用して、カスタム network_data.yaml ファイルをデプロイメントに含めます。-n オプションを指定しないと、デプロイメントコマンドはデフォルトのネットワークセットを使用します。

5. 予測可能な仮想 IP アドレス (VIP) が必要な場合は、カスタムネットワークの VirtualFixedIPs パラメーターを heat 環境ファイルの parameter_defaults セクションに追加します (例: my_network_vips.yaml)。

   <% my_customer_network %>VirtualFixedIPs:  [{'ip_address':'<% ipaddres %>'}]

   以下に例を示します。

   parameter_defaults:
     ...
     # Predictable VIPs
     StorageBackuptVirtualFixedIPs:  [{'ip_address':'172.21.1.9'}]

6. -e オプションを使用して、heat 環境ファイル my_network_vips.yaml をデプロイメントコマンドに含めます。

手順

1. カスタム roles_data.yaml ファイルがまだない場合には、デフォルトをご自分のホームディレクトリーにコピーします。

   $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.

2. カスタムの roles_data.yaml ファイルを編集します。

3. ネットワークを追加するロールの networks リストにネットワーク名を追加します。たとえば、StorageBackup ネットワークを Ceph Storage ロールに追加するには、以下のスニペット例を使用します。

   - name: CephStorage
     description: |
       Ceph OSD Storage node role
     networks:
       - Storage
       - StorageMgmt
       - StorageBackup

4. カスタムネットワークを対応するロールに追加したら、ファイルを保存します。

手順

1. openstack overcloud deploy コマンドを実行する際に、以下のファイルを追加するようにしてください。

   • カスタム network_data.yaml ファイル
   • ネットワーク/ロール間の割り当てを定義するカスタム roles_data.yaml ファイル
   • デフォルトネットワーク分離のレンダリング済みファイル名
   • デフォルトネットワーク環境ファイルのレンダリング済みファイル名
   • デフォルトネットワークインターフェイス設定のレンダリング済みファイル名
   • サービスの再割り当て等、ネットワークに関連するその他の環境ファイル

手順

1. network_data.yaml ファイルで、名前を変更する各ネットワークの name_lower パラメーターに新しい名前を入力します。

   - name: InternalApi
     name_lower: MyCustomInternalApi

2. service_net_map_replace パラメーターに、name_lower パラメーターのデフォルト値を追加します。

   - name: InternalApi
     name_lower: MyCustomInternalApi
     service_net_map_replace: internal_api

手順

1. process-templates.py スクリプトを使用して、openstack-tripleo-heat-templates コレクションのコピーをレンダリングします。

   $ cd /usr/share/openstack-tripleo-heat-templates
   $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

   これにより、すべての Jinja2 テンプレートがレンタリング済みの YAML バージョンに変換され、結果が ~/openstack-tripleo-heat-templates-rendered に保存されます。

   カスタムネットワークファイルまたはカスタムロールファイルを使用する場合には、それぞれ -n および -r オプションを使用して、それらのファイルを含めることができます。

   $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered -n /home/stack/network_data.yaml -r /home/stack/roles_data.yaml

2. 複数 NIC の例をコピーします。

   $ cp -r ~/openstack-tripleo-heat-templates-rendered/network/config/multiple-nics/ ~/templates/custom-nics/

3. ご自分のネットワーク設定に適するように、custom-nics のテンプレートセットを編集します。

手順

1. openstack overcloud deploy コマンドを実行し、以下の情報を追加します。

   • カスタム network_data.yaml ファイル
   • デフォルトネットワーク分離のレンダリング済みファイル名
   • デフォルトネットワーク環境ファイルのレンダリング済みファイル名
   • カスタム NIC テンプレートへのリソースの参照を含むカスタム環境ネットワーク設定
   • 設定に必要なその他の環境ファイル

手順

1. ~/templates/custom-nics ディレクトリーからのカスタム NIC テンプレートに route_table および interface エントリーを作成し、インターフェイスのルートを定義し、デプロイメントに関連するルールを定義します。

   $network_config:
     network_config:
   
     - type: route_table
       name: custom
       table_id: 200
   
     - type: interface
       name: em1
       use_dhcp: false
       addresses:
         - ip_netmask: 192.0.2.1/24
   
       routes:
         - ip_netmask: 10.1.3.0/24
           next_hop: 192.0.2.5
           route_options: "metric 10"
           table: 200
       rules:
         - rule: "iif em1 table 200"
           comment: "Route incoming traffic to em1 with table 200"
         - rule: "from 192.0.2.0/24 table 200"
           comment: "Route all traffic from 192.0.2.0/24 with table 200"
         - rule: "add blackhole from 172.19.40.0/24 table 200"
         - rule: "add unreachable iif em1 from 192.168.1.0/24"

2. run-os-net-config.sh スクリプトの場所を、作成する各カスタム NIC テンプレートの絶対パスに設定します。スクリプトは、アンダークラウドの /usr/share/openstack-tripleo-heat-templates/network/scripts/ ディレクトリーにあります。

   resources:
     OsNetConfigImpl:
       type: OS::Heat::SoftwareConfig
       properties:
         group: script
         config:
           str_replace:
             template:
               get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh

3. ご自分のデプロイメントに該当するその他の環境ファイルと共に、カスタム NIC 設定およびネットワーク環境ファイルをデプロイメントコマンドに追加します。

   $ openstack overcloud deploy --templates \
   -e ~/templates/<custom-nic-template>
   -e <OTHER_ENVIRONMENT_FILES>

手順

1. カーネルバージョンを確認します。

   ovs-appctl -t ovs-vswitchd dpif/show-dp-features br-int

2. 出力に Check pkt length action: No の文字列が含まれる場合、または Check pkt length action の文字列が含まれない場合は、RHEL 8.2.0.4 またはそれ以降にアップグレードしてください。あるいは、MTU がより小さい外部ネットワークにジャンボフレームを送信しないでください。

3. 出力に Check pkt length action: Yes の文字列が含まれる場合は、ml2_conf.ini の [ovn] セクションに以下の値を設定します。

   ovn_emit_need_to_frag = True

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. source コマンドでアンダークラウドの認証情報ファイルを読み込みます。

   $ source ~/stackrc

3. カスタム YAML 環境ファイルを作成します。

   例

   $ vi /home/stack/templates/my-environment.yaml

4. 環境ファイルには、キーワード parameter_defaults および ExtraSysctlSettings が含まれている必要があります。netfilter が追跡できる接続の最大数の新しい値を変数 net.nf_conntrack_max に入力します。

   例

   この例では、RHOSP デプロイメント内のすべてのホストにわたって conntrack 制限を設定できます。

   parameter_defaults:
     ExtraSysctlSettings:
       net.nf_conntrack_max:
         value: 500000

   <role>Parameter パラメーターを使用して、特定のロールの conntrack 制限を設定します。

   parameter_defaults:
     <role>Parameters:
       ExtraSysctlSettings:
         net.nf_conntrack_max:
           value: <simultaneous_connections>

   • <role> をロールの名前に置き換えます。

     たとえば、ControllerParameters を使用して Controller ロールの conntrack 制限を設定するか、ComputeParameters を使用して Compute ロールの conntrack 制限を設定します。

   • <simultaneous_connections> を、許可する同時接続数に置き換えます。

     例

     この例では、RHOSP デプロイメントの Controller ロールのみに conntrack 制限を設定できます。

     parameter_defaults:
       ControllerParameters:
         ExtraSysctlSettings:
           net.nf_conntrack_max:
             value: 500000

     注記

     net.nf_conntrack_max のデフォルト値は 500000 接続です。最大値は 4294967295 です。

5. コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、deployment コマンドを実行します。

   重要

   後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

   例

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

手順

1. デプロイメント時に Compute スケジューラーが照合するノード別ケイパビリティーとして、この ID を割り当てます。

   openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>

   このコマンドにより、node:controller-0 のケイパビリティーがノードに割り当てられます。0 から始まる一意の連番のインデックスを使用して、すべてのノードに対してこのパターンを繰り返します。指定したロール (Controller、Compute、各ストレージロール) のすべてのノードが同じようにタグ付けされるようにします。このようにタグ付けしないと、Compute スケジューラーはこのケイパビリティーを正しく照合することができません。

2. heat 環境ファイル (例: scheduler_hints_env.yaml) を作成します。このファイルは、スケジューラーヒントを使用して、各ノードのケイパビリティーと照合します。

   parameter_defaults:
     ControllerSchedulerHints:
       'capabilities:node': 'controller-%index%'

   以下のパラメーターを使用して、他のロール種別のスケジューラーヒントを設定します。

   • コントローラーノードの場合は ControllerSchedulerHints。
   • コンピュートノードの場合は ComputeSchedulerHints。
   • Block Storage ノードの場合は BlockStorageSchedulerHints。
   • Object Storage ノードの場合は ObjectStorageSchedulerHints。
   • Ceph Storage ノードの場合は CephStorageSchedulerHints。
   • カスタムロールの場合は [ROLE]SchedulerHints。[ROLE] はロール名に置き換えます。
3. overcloud deploy command コマンドに scheduler_hints_env.yaml 環境ファイルを追加します。

手順

1. 予測可能な IP アドレス設定を定義する環境ファイルを作成します。

   $ touch ~/templates/predictive_ips.yaml

2. ~/templates/predictive_ips.yaml ファイルに parameter_defaults セクションを作成し、以下の構文を使用してネットワークごとに各ノードの予測可能な IP アドレス設定を定義します。

   parameter_defaults:
     <role_name>IPs:
       <network>:
       - <IP_address>
       <network>:
       - <IP_address>

   各ノードロールには固有のパラメーターがあります。<role_name>IPs を該当するパラメーターに置き換えます。

   • コントローラーノードの場合は ControllerIPs。
   • コンピュートノードの場合は ComputeIPs。
   • Ceph Storage ノードの場合は CephStorageIPs。
   • Block Storage ノードの場合は BlockStorageIPs。
   • Object Storage ノードの場合は SwiftStorageIPs。

   • カスタムロールの場合は [ROLE]IPs。[ROLE] はロール名に置き換えます。

     各パラメーターは、アドレスのリストへのネットワーク名のマッピングです。各ネットワーク種別には、最低でもそのネットワークにあるノード数と同じ数のアドレスが必要です。director はアドレスを順番に割り当てます。各種別の最初のノードは、適切なリストにある最初のアドレスが割り当てられ、2 番目のノードは 2 番目のアドレスというように割り当てられていきます。

     たとえば、予測可能な IP アドレスを持つ 3 つの Ceph Storage ノードをオーバークラウドにデプロイする場合は、以下の構文例を使用します。

     parameter_defaults:
       CephStorageIPs:
         storage:
         - 172.16.1.100
         - 172.16.1.101
         - 172.16.1.102
         storage_mgmt:
         - 172.16.3.100
         - 172.16.3.101
         - 172.16.3.102

     最初の Ceph Storage ノードは 172.16.1.100 と 172.16.3.100 の 2 つのアドレスを取得します。2 番目は 172.16.1.101 と 172.16.3.101、3 番目は 172.16.1.102 と 172.16.3.102 を取得します。他のノード種別でも同じパターンが適用されます。

     コントロールプレーンに予測可能な IP アドレスを設定するには、/usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml ファイルを stack ユーザーの templates ディレクトリーにコピーします。

     $ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml ~/templates/.

     以下の例に示すパラメーターで、新たな ips-from-pool-ctlplane.yaml ファイルを設定します。コントロールプレーンの IP アドレスの宣言に他のネットワークの IP アドレスの宣言を組み合わせ、1 つのファイルだけを使用してすべてのロールの全ネットワークの IP アドレスを宣言することができます。また、スパイン/リーフ型ネットワークに予測可能な IP アドレスを使用することもできます。それぞれのノードには、正しいサブネットからの IP アドレスを設定する必要があります。

     parameter_defaults:
       ControllerIPs:
         ctlplane:
         - 192.168.24.10
         - 192.168.24.11
         - 192.168.24.12
         internal_api:
         - 172.16.1.20
         - 172.16.1.21
         - 172.16.1.22
         external:
         - 10.0.0.40
         - 10.0.0.57
         - 10.0.0.104
       ComputeLeaf1IPs:
         ctlplane:
         - 192.168.25.100
         - 192.168.25.101
         internal_api:
         - 172.16.2.100
         - 172.16.2.101
       ComputeLeaf2IPs:
         ctlplane:
         - 192.168.26.100
         - 192.168.26.101
         internal_api:
         - 172.16.3.100
         - 172.16.3.101

     選択する IP アドレスは、ネットワーク環境ファイルで定義する各ネットワークの割り当てプールの範囲に入らないようにしてください。たとえば、internal_api の割り当ては InternalApiAllocationPools の範囲外にし、自動的に選択される IP との競合を避けるようにします。また、標準の予測可能な仮想 IP 配置 (「予測可能な仮想 IP の割り当て」 を参照) または外部の負荷分散 (「外部の負荷分散機能の設定」 を参照) のいずれでも、IP アドレスの割り当てが仮想 IP 設定と競合しないようにしてください。

     重要

     オーバークラウドノードが削除された場合に、そのノードのエントリーを IP のリストから削除しないでください。IP のリストは、下層の heat インデックスをベースとしています。このインデックスは、ノードを削除した場合でも変更されません。IP のリストで特定のエントリーが使用されなくなったことを示すには、IP の値を DELETED または UNUSED などに置き換えてください。エントリーは変更または追加するのみとし、IP のリストから決して削除すべきではありません。

3. デプロイメント中にこの設定を適用するには、openstack overcloud deploy コマンドで predictive_ips.yaml 環境ファイルを指定します。

   重要

   ネットワーク分離の機能を使用する場合には、network-isolation.yaml ファイルの後に predictive_ips.yaml ファイルを追加してください。

   $ openstack overcloud deploy --templates \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e ~/templates/predictive_ips.yaml \
     [OTHER OPTIONS]

手順

1. すべての署名済み証明書の記録は、/etc/pki/CA/index.txt ファイルに含まれます。ファイルシステムパスと index.txt ファイルが存在することを確認します。

   $ sudo mkdir -p /etc/pki/CA
   $ sudo touch /etc/pki/CA/index.txt

2. /etc/pki/CA/serial ファイルは、次に署名する証明書に使用する次のシリアル番号を特定します。このファイルが存在しているかどうかを確認してください。ファイルが存在しない場合には、新規ファイルを作成して新しい開始値を指定します。

   $ echo '1000' | sudo tee /etc/pki/CA/serial

手順

1. 鍵と証明書のペアを生成して、認証局として機能するようにします。

   $ openssl genrsa -out ca.key.pem 4096
   $ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem

2. openssl req コマンドは、認証局に関する特定の情報を要求します。要求されたら、それらの情報を入力してください。これらのコマンドにより、ca.crt.pem という名前の認証局ファイルが作成されます。

3. 証明書の場所を enable-tls.yaml ファイルの PublicTLSCAFile パラメーターの値として設定します。証明書の場所を PublicTLSCAFile パラメーターの値として設定する場合、CA 証明書パスが clouds.yaml 認証ファイルに追加されていることを確認してください。

   parameter_defaults:
       PublicTLSCAFile: /etc/pki/ca-trust/source/anchors/cacert.pem

手順

1. 認証局をクライアントシステムにコピーします。

   $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/

2. 各クライアントに認証局ファイルをコピーしたら、それぞれのクライアントで以下のコマンドを実行し、証明書を認証局のトラストバンドルに追加します。

   $ sudo update-ca-trust extract

手順

1. 以下のコマンドを実行し、SSL/TLS 鍵 (server.key.pem) を生成します。

   $ openssl genrsa -out server.key.pem 2048

手順

1. デフォルトの OpenSSL 設定ファイルをコピーします。

   $ cp /etc/pki/tls/openssl.cnf .

2. 新しい openssl.cnf ファイルを編集して、director に使用する SSL パラメーターを設定します。変更するパラメーターの種別には以下のような例が含まれます。

   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_req
   
   [req_distinguished_name]
   countryName = Country Name (2 letter code)
   countryName_default = AU
   stateOrProvinceName = State or Province Name (full name)
   stateOrProvinceName_default = Queensland
   localityName = Locality Name (eg, city)
   localityName_default = Brisbane
   organizationalUnitName = Organizational Unit Name (eg, section)
   organizationalUnitName_default = Red Hat
   commonName = Common Name
   commonName_default = 192.168.0.1
   commonName_max = 64
   
   [ v3_req ]
   # Extensions to add to a certificate request
   basicConstraints = CA:FALSE
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName = @alt_names
   
   [alt_names]
   IP.1 = 192.168.0.1
   DNS.1 = instack.localdomain
   DNS.2 = vip.localdomain
   DNS.3 = 192.168.0.1

   commonName_default を、以下のエントリーのいずれかに設定します。

   • IP アドレスを使用して SSL/TLS 経由で director にアクセスする場合には、undercloud.conf ファイルの undercloud_public_host パラメーターを使用します。
   • 完全修飾ドメイン名を使用して SSL/TLS 経由で director にアクセスする場合には、ドメイン名を使用します。

   alt_names セクションを編集して、以下のエントリーを追加します。

   • IP: SSL 経由で director にアクセスするためにクライアントが使用する IP アドレスリスト
   • DNS: SSL 経由で director にアクセスするためにクライアントが使用するドメイン名リスト。alt_names セクションの最後に DNS エントリーとしてパブリック API の IP アドレスも追加します。
   注記

   openssl.cnf に関する詳しい情報については、man openssl.cnf コマンドを実行してください。

3. 以下のコマンドを実行し、証明書署名要求 (server.csr.pem) を生成します。

   $ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

   -key オプションを使用して、OpenStack SSL/TLS 鍵を指定するようにしてください。

手順

1. newcerts ディレクトリーが存在しない場合は作成します。

   sudo mkdir -p /etc/pki/CA/newcerts

2. 以下のコマンドを実行し、アンダークラウドまたはオーバークラウドの証明書を作成します。

   $ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

   コマンドは、以下のオプションを使用します。

   -config

   カスタム設定ファイルを使用します (ここでは、v3 拡張機能を指定した openssl.cnf ファイル)。

   -extensions v3_req

   v3 拡張機能を有効にします。

   -days

   証明書の有効期限が切れるまでの日数を定義します。

   -in

   証明書署名要求

   -out

   作成される署名済み証明書

   -cert

   認証局ファイル

   -keyfile

   認証局の秘密鍵

手順

1. heat テンプレートコレクションから enable-tls.yaml の環境ファイルをコピーします。

   $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.

2. このファイルを編集して、下記のパラメーターに以下の変更を加えます。

   SSLCertificate

   証明書ファイル (server.crt.pem) のコンテンツを SSLCertificate パラメーターにコピーします。

   parameter_defaults:
     SSLCertificate: |
       -----BEGIN CERTIFICATE-----
       MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGS
       ...
       sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQ
       -----END CERTIFICATE-----

   重要

   この証明書の内容に新しく追加する行は、すべて同じレベルにインデントする必要があります。

   SSLIntermediateCertificate

   中間証明書がある場合、中間証明書のコンテンツを SSLIntermediateCertificate パラメーターにコピーします。

   parameter_defaults:
     SSLIntermediateCertificate: |
       -----BEGIN CERTIFICATE-----
       sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvpBCwUAMFgxCzAJB
       ...
       MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQE
       -----END CERTIFICATE-----

   重要

   この証明書の内容に新しく追加する行は、すべて同じレベルにインデントする必要があります。

   SSLKey

   秘密鍵 (server.key.pem) の内容を SSLKey パラメーターにコピーします。

   parameter_defaults:
     ...
     SSLKey: |
       -----BEGIN RSA PRIVATE KEY-----
       MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO
       ...
       ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4X
       -----END RSA PRIVATE KEY-----

   重要

   この秘密鍵の内容に新しく追加する行は、すべて同じレベルにインデントする必要があります。

手順

1. Heat テンプレートコレクションから inject-trust-anchor-hiera.yaml 環境ファイルをコピーします。

   $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor-hiera.yaml ~/templates/.

手順

1. 以下のように heat テンプレートを編集します。

   • enable-tls.yaml ファイルを編集して、SSLCertificate、SSLKey、SSLIntermediateCertificate のパラメーターを更新してください。
   • 認証局が変更された場合には、inject-trust-anchor-hiera.yaml ファイルを編集して、CAMap パラメーターを更新してください。

2. プロイメントコマンドを再度実行します。

   $ openstack overcloud deploy --templates \
   [...]
   -e /home/stack/templates/enable-tls.yaml \
   -e ~/templates/custom-domain.yaml \
   -e ~/templates/inject-trust-anchor-hiera.yaml \
   -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml

1. /etc/resolv.conf ファイルを設定します。

   アンダークラウドの /etc/resolv.conf に、適切な検索ドメインおよびネームサーバーを設定します。たとえば、デプロイメントドメインが example.com で FreeIPA サーバーのドメインが bigcorp.com の場合、以下の行を /etc/resolv.conf に追加します。

   search example.com bigcorp.com
   nameserver $IDM_SERVER_IP_ADDR

2. 必要なソフトウェアをインストールします。

   sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel

3. ご自分の環境に固有の値で環境変数をエクスポートします。

   export IPA_DOMAIN=bigcorp.com
   export IPA_REALM=BIGCORP.COM
   export IPA_ADMIN_USER=$IPA_USER 1
   export IPA_ADMIN_PASSWORD=$IPA_PASSWORD 2
   export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
   export UNDERCLOUD_FQDN=undercloud.example.com 3
   export USER=stack
   export CLOUD_DOMAIN=example.com

   1 2

   IdM のユーザー認証情報は、新しいホストおよびサービスを追加できる管理ユーザーでなければなりません。

   3

   UNDERCLOUD_FQDN パラメーターの値は、/etc/hosts の最初のホスト名から IP へのマッピングと一致します。

4. アンダークラウドで undercloud-ipa-install.yaml Ansible Playbook を実行します。

   ansible-playbook \
   --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \
   /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml

5. undercloud.conf に以下のパラメーターを追加します。

   undercloud_nameservers = $IDM_SERVER_IP_ADDR
   overcloud_domain_name = example.com

6. [オプション] IPA レルムが IPA ドメインと一致しない場合は、certmonger_krb_realm パラメーターの値を設定します。

   1. /home/stack/hiera_override.yaml で certmonger_krb_realm の値を設定します。

      parameter_defaults:
        certmonger_krb_realm: EXAMPLE.COMPANY.COM

   2. undercloud.conf で custom_env_files パラメーターの値を /home/stack/hiera_override.yaml に設定します。

      custom_env_files = /home/stack/hiera_override.yaml

7. アンダークラウドをデプロイします。

   openstack undercloud install

1. IdM のホストをリスト表示します。

   $ kinit admin
   $ ipa host-find

2. アンダークラウドに /etc/novajoin/krb5.keytab が存在することを確認します。

   ls /etc/novajoin/krb5.keytab

1. オーバークラウドをデプロイする前に、以下のような内容で YAML ファイル tls-parameters.yaml を作成します。お使いの環境に固有の値を選択してください。

   parameter_defaults:
       DnsSearchDomains: ["example.com"]
       DnsServers: ["192.168.1.13"]
       CloudDomain: example.com
       CloudName: overcloud.example.com
       CloudNameInternal: overcloud.internalapi.example.com
       CloudNameStorage: overcloud.storage.example.com
       CloudNameStorageManagement: overcloud.storagemgmt.example.com
       CloudNameCtlplane: overcloud.ctlplane.example.com
       IdMServer: freeipa-0.redhat.local
       IdMDomain: redhat.local
       IdMInstallClientPackages: False
   
   resource_registry:
         OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml

   • OS::TripleO::Services::IpaClient パラメーターに示す値は、enable-internal-tls.yaml ファイルのデフォルト設定を上書きします。openstack overcloud deploy コマンドで、enable-internal-tls.yaml の後に tls-parameters.yaml ファイルを指定するようにします。

2. [オプション] IPA レルムが IPA ドメインと一致しない場合は、tls-parameters.yaml ファイルに CertmongerKerberosRealm パラメーターの値も含める必要があります。

       CertmongerKerberosRealm: EXAMPLE.COMPANY.COM

3. オーバークラウドをデプロイする。デプロイメントコマンドに tls-parameters.yaml を追加する必要があります。

   DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
   CUSTOM_TEMPLATES=/home/stack/templates
   
   openstack overcloud deploy \
   -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \
   -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \
   -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \
   -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \
   ...

4. keystone にエンドポイントリストのクエリーを行い、各エンドポイントが HTTPS を使用していることを確認します。

   openstack endpoint list

1. アンダークラウドノードを認証局 (CA) に追加する
2. アンダークラウドノードを IdM に追加する
3. (オプション) オーバークラウドの DNS サーバーとして IdM サーバーを設定する
4. 環境ファイルを準備しオーバークラウドをデプロイする
5. IdM および RHOSP でオーバークラウドの登録をテストする
6. (オプション) IdM に novajoin の DNS エントリーを追加する

手順

1. アンダークラウドノードで、python3-novajoin パッケージをインストールします。

   $ sudo dnf install python3-novajoin

2. アンダークラウドノードで novajoin-ipa-setup スクリプトを実行します。値はデプロイメントに応じて調整します。

   $ sudo /usr/libexec/novajoin-ipa-setup \
       --principal admin \
       --password <IdM admin password> \
       --server <IdM server hostname> \
       --realm <realm> \
       --domain <overcloud cloud domain> \
       --hostname <undercloud hostname> \
       --precreate

   ここで設定したワンタイムパスワード (OTP) を使用して、アンダークラウドを登録します。

手順

1. novajoin サービスを有効にします。

   [DEFAULT]
   enable_novajoin = true

2. アンダークラウドノードを IdM に登録できるように、ワンタイムパスワード (OTP) を設定します。

   ipa_otp = <otp>

3. neutron の DHCP サーバーにより提供されるように、オーバークラウドのドメイン名を設定します。

   overcloud_domain_name = <domain>

4. アンダークラウドのホスト名を設定します。

   undercloud_hostname = <undercloud FQDN>

5. アンダークラウドのネームサーバーとして IdM を設定します。

   undercloud_nameservers = <IdM IP>

6. より大規模な環境の場合には、novajoin の接続タイムアウト値を見直します。undercloud.conf ファイルで、undercloud-timeout.yaml という名前の新規ファイルへの参照を追加します。

   hieradata_override = /home/stack/undercloud-timeout.yaml

   undercloud-timeout.yaml に以下のオプションを追加します。タイムアウト値は秒単位で指定することができます (例: 5)。

   nova::api::vendordata_dynamic_connect_timeout: <timeout value>
   nova::api::vendordata_dynamic_read_timeout: <timeout value>

7. オプション: ローカルの openSSL 認証局に director のパブリックエンドポイントの SSL 証明書を生成させる場合は、generate_service_certificate パラメーターを true に設定します。

   generate_service_certificate = true

8. undercloud.conf ファイルを保存します。

9. アンダークラウドのデプロイコマンドを実行して、既存のアンダークラウドに変更を適用します。

   $ openstack undercloud install

1. IdM のホストをリスト表示します。

   $ kinit admin
   $ ipa host-find

2. アンダークラウドに /etc/novajoin/krb5.keytab が存在することを確認します。

   ls /etc/novajoin/krb5.keytab

手順

1. アンダークラウドに接続します。

   $ source ~/stackrc

2. DNS ネームサーバーとして IdM を使用するようにコントロールプレーンサブネットを設定します。

   $ openstack subnet set ctlplane-subnet --dns-nameserver  <idm_server_address>

3. IdM サーバーを使用するように環境ファイルの DnsServers パラメーターを設定します。

   parameter_defaults:
     DnsServers: ["<idm_server_address>"]

   このパラメーターは、通常カスタムの network-environment.yaml ファイルで定義されます。

手順

1. /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 環境ファイルのコピーを作成します。

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \
     /home/stack/templates/custom-domain.yaml

2. /home/stack/templates/custom-domain.yaml 環境ファイルを編集して、デプロイメントに適した CloudDomain と CloudName* の値を設定します。

   parameter_defaults:
     CloudDomain: lab.local
     CloudName: overcloud.lab.local
     CloudNameInternal: overcloud.internalapi.lab.local
     CloudNameStorage: overcloud.storage.lab.local
     CloudNameStorageManagement: overcloud.storagemgmt.lab.local
     CloudNameCtlplane: overcloud.ctlplane.lab.local

3. 環境に適した TLS の実装を選択します。

   • enable-tls.yaml 環境ファイルを使用して、カスタム証明書が含まれる外部エンドポイントを保護します。

     1. /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml を /home/stack/templates にコピーします。
     2. カスタム証明書および鍵が含まれるように /home/stack/enable-tls.yaml 環境ファイル変更します。

     3. 以下の環境ファイルをデプロイメントに追加して、内部および外部エンドポイントを保護します。

        • enable-internal-tls.yaml
        • tls-every-endpoints-dns.yaml
        • custom-domain.yaml

        • enable-tls.yaml

          openstack overcloud deploy \
            --templates \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
            -e /home/stack/templates/custom-domain.yaml \
            -e /home/stack/templates/enable-tls.yaml

   • haproxy-public-tls-certmonger.yaml 環境ファイルを使用して、IdM が発行した証明書が含まれる外部エンドポイントを保護します。この実装では、novajoin が使用する VIP エンドポイントの DNS エントリーを作成する必要があります。

     1. novajoin が使用する VIP エンドポイントの DNS エントリーを作成する必要があります。/home/stack/templates のカスタム network-environment.yaml ファイルにあるオーバークラウドのネットワークを特定します。

        parameter_defaults:
            ControlPlaneDefaultRoute: 192.168.24.1
            ExternalAllocationPools:
            -   end: 10.0.0.149
                start: 10.0.0.101
            InternalApiAllocationPools:
            -   end: 172.17.1.149
                start: 172.17.1.10
            StorageAllocationPools:
            -   end: 172.17.3.149
                start: 172.17.3.10
            StorageMgmtAllocationPools:
            -   end: 172.17.4.149
                start: 172.17.4.10

     2. /home/stack/public_vip.yaml などの heat テンプレートでオーバークラウドネットワークごとに仮想 IP アドレスのリストを作成します。

        parameter_defaults:
            ControlFixedIPs: [{'ip_address':'192.168.24.101'}]
            PublicVirtualFixedIPs: [{'ip_address':'10.0.0.101'}]
            InternalApiVirtualFixedIPs: [{'ip_address':'172.17.1.101'}]
            StorageVirtualFixedIPs: [{'ip_address':'172.17.3.101'}]
            StorageMgmtVirtualFixedIPs: [{'ip_address':'172.17.4.101'}]
            RedisVirtualFixedIPs: [{'ip_address':'172.17.1.102'}]

     3. それぞれの VIP について、DNS エントリーおよびゾーン (必要に応じて) を IdM に追加します。

        ipa dnsrecord-add lab.local overcloud --a-rec 10.0.0.101
        ipa dnszone-add ctlplane.lab.local
        ipa dnsrecord-add ctlplane.lab.local overcloud --a-rec 192.168.24.101
        ipa dnszone-add internalapi.lab.local
        ipa dnsrecord-add internalapi.lab.local overcloud --a-rec 172.17.1.101
        ipa dnszone-add storage.lab.local
        ipa dnsrecord-add storage.lab.local overcloud --a-rec 172.17.3.101
        ipa dnszone-add storagemgmt.lab.local
        ipa dnsrecord-add storagemgmt.lab.local overcloud --a-rec 172.17.4.101

     4. 以下の環境ファイルをデプロイメントに追加して、内部および外部エンドポイントを保護します。

        • enable-internal-tls.yaml
        • tls-everywhere-endpoints-dns.yaml
        • haproxy-public-tls-certmonger.yaml
        • custom-domain.yaml

        • public_vip.yaml

          openstack overcloud deploy \
            --templates \
             -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \
             -e /home/stack/templates/custom-domain.yaml \
             -e /home/stack/templates/public-vip.yaml

手順

1. 新規ファイルを作成します (例: glance-settings.yaml)。サンプルの構文を使用して、このファイルを設定します。

2. デプロイメントに該当するその他の環境ファイルと共に、openstack overcloud deploy コマンドに glance-settings.yaml ファイルを追加します。

   $ openstack overcloud deploy --templates -e glance-settings.yaml

1. スキームを確認する。

   1. スキームが定義されていない場合: 拒否する。
   2. 許可リストがあり、そのスキームが許可リストに記載されていない場合: 拒否する。記載されている場合: c 項をスキップして 2 項に進む。
   3. ブロックリストがあり、そのスキームがブロックリストに記載されている場合: 拒否する。

2. ホスト名を確認する。

   1. ホスト名が定義されていない場合: 拒否する。
   2. 許可リストがあり、そのホスト名が許可リストに記載されていない場合: 拒否する。記載されている場合: c 項をスキップして 3 項に進む。
   3. ブロックリストがあり、そのホスト名がブロックリストに記載されている場合: 拒否する。

3. URI にポートが含まれていれば、ポートを確認する。

   1. 許可リストがあり、そのポートが許可リストに記載されていない場合: 拒否する。記載されている場合: b 項をスキップして 4 項に進む。
   2. ブロックリストがあり、そのポートがブロックリストに記載されている場合: 拒否する。
4. 有効な URI として受け入れる。

手順

1. 以下の内容を記載した swift-external-params.yaml という名前の新しいファイルを作成します。

   • EXTERNAL.IP:PORT は、外部プロキシーの IP アドレスとポートに置き換えます。

   • SwiftPassword の行の AUTHTOKEN は、外部プロキシーの authtoken パスワードに置き換えます。

     parameter_defaults:
       ExternalSwiftPublicUrl: 'https://EXTERNAL.IP:PORT/v1/AUTH_%(tenant_id)s'
       ExternalSwiftInternalUrl: 'http://192.168.24.9:8080/v1/AUTH_%(tenant_id)s'
       ExternalSwiftAdminUrl: 'http://192.168.24.9:8080'
       ExternalSwiftUserTenant: 'service'
       SwiftPassword: AUTHTOKEN

2. このファイルを swift-external-params.yaml として保存します。

3. デプロイメントに該当するその他の環境ファイルと共に、以下の外部 Object Storage サービスの環境ファイルを指定して、オーバークラウドをデプロイします。

   openstack overcloud deploy --templates \
   -e [your environment files] \
   -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml \
   -e swift-external-params.yaml

手順

1. カスタム環境ファイル (swift-external-params.yaml 等) に以下の parameter_defaults を追加し、実際のデプロイメントに合わせて値を調整します。

   parameter_defaults:
      ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftUserTenant: 'service'
      SwiftPassword: 'choose_a_random_password'

   注記

   サンプルコードスニペットには、お使いの環境で使用する値とは異なるパラメーター値が含まれる場合があります。

   • リモート RGW インスタンスがリッスンするデフォルトのポートは 8080 です。外部 RGW の設定方法によっては、ポートが異なる場合があります。
   • オーバークラウドで作成した swift ユーザーは、SwiftPassword パラメーターで定義したパスワードを使用します。rgw_keystone_admin_password を使用し、Identity サービスに対する認証に同じパスワードを使用するように外部 RGW インスタンスを設定する必要があります。

2. Ceph 設定ファイルに以下のコードを追加して、Identity サービスを使用するように RGW を設定します。変数の値を実際の環境に応じて置き換えます。

       rgw_keystone_api_version = 3
       rgw_keystone_url = http://<public Keystone endpoint>:5000/
       rgw_keystone_accepted_roles = member, Member, admin
       rgw_keystone_accepted_admin_roles = ResellerAdmin, swiftoperator
       rgw_keystone_admin_domain = default
       rgw_keystone_admin_project = service
       rgw_keystone_admin_user = swift
       rgw_keystone_admin_password = <password_as_defined_in_the_environment_parameters>
       rgw_keystone_implicit_tenants = true
       rgw_keystone_revocation_interval = 0
       rgw_s3_auth_use_keystone = true
       rgw_swift_versioning_enabled = true
       rgw_swift_account_in_url = true

   注記

   デフォルトでは、director は Identity サービスに以下のロールとユーザーを作成します。

   • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
   • rgw_keystone_admin_domain: default
   • rgw_keystone_admin_project: service
   • rgw_keystone_admin_user: swift

3. デプロイメントに該当するその他の環境ファイルと共に、追加の環境ファイルを指定して、オーバークラウドをデプロイします。

   openstack overcloud deploy --templates \
   -e <your_environment_files>
   -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
   -e swift-external-params.yaml

検証

1. アンダークラウドに stack ユーザーとしてログインします。

2. source コマンドで overcloudrc ファイルを読み込みます。

   $ source ~/stackrc

3. エンドポイントが Identity サービス (keystone) に存在することを確認します。

   $ openstack endpoint list --service object-store
   
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | ID | Region    | Service Name | Service Type | Enabled | Interface | URL |
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | 233b7ea32aaf40c1ad782c696128aa0e | regionOne | swift | object-store | True    | admin     | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   | 4ccde35ac76444d7bb82c5816a97abd8 | regionOne | swift | object-store | True    | public    | https://192.168.24.2:13808/v1/AUTH_%(project_id)s |
   | b4ff283f445348639864f560aa2b2b41 | regionOne | swift | object-store | True    | internal  | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   +---------+-----------+-------+-------+---------+-----------+---------------+

4. テストコンテナーを作成します。

   $ openstack container create <testcontainer>
   +----------------+---------------+------------------------------------+
   | account | container | x-trans-id |
   +----------------+---------------+------------------------------------+
   | AUTH_2852da3cf2fc490081114c434d1fc157 | testcontainer | tx6f5253e710a2449b8ef7e-005f2d29e8 |
   +----------------+---------------+------------------------------------+

5. 設定ファイルを作成し、データをコンテナーにアップロードできることを確認します。

   $ openstack object create testcontainer undercloud.conf
   +-----------------+---------------+----------------------------------+
   | object          | container     | etag                             |
   +-----------------+---------------+----------------------------------+
   | undercloud.conf | testcontainer | 09fcffe126cac1dbac7b89b8fd7a3e4b |
   +-----------------+---------------+----------------------------------+

6. テストコンテナーを削除します。

   $ openstack container delete -r <testcontainer>

手順

1. Image サービスのバックエンドに cinder を設定するには、以下の行を環境ファイルに追加します。

   parameter_defaults:
     GlanceBackend: cinder

2. cinder バックエンドが有効な場合には、デフォルトで以下のパラメーターおよび値が設定されます。

   cinder_store_auth_address = http://172.17.1.19:5000/v3
   cinder_store_project_name = service
   cinder_store_user_name = glance
   cinder_store_password = ****secret****

3. カスタムのユーザー名または cinder_store_ パラメーターにカスタムの値を使用する場合には、parameter_defaults に ExtraConfig 設定を追加してカスタムの値を渡します。

   ExtraConfig:
       glance::config::api_config:
         glance_store/cinder_store_auth_address:
           value: "%{hiera('glance::api::authtoken::auth_url')}/v3"
         glance_store/cinder_store_user_name:
           value: <user-name>
         glance_store/cinder_store_password:
           value: "%{hiera('glance::api::authtoken::password')}"
         glance_store/cinder_store_project_name:
           value: "%{hiera('glance::api::authtoken::project_name')}"

手順

1. 環境ファイルの GlanceCacheEnabled パラメーターの値を true に設定します。これにより、glance-api.conf Heat テンプレートの flavor の値が自動的に keystone+cachemanagement に設定されます。

   parameter_defaults:
       GlanceCacheEnabled: true

2. オーバークラウドを再デプロイする際に、openstack overcloud deploy コマンドにその環境ファイルを追加します。

3. オプション: オーバークラウドを再デプロイする際に、glance_cache_pruner を異なる頻度に調節します。5 分間の頻度の例を以下に示します。

   parameter_defaults:
     ControllerExtraConfig:
       glance::cache::pruner::minute: '*/5'

   ファイルシステムを使い果たす状況を回避するために、ご自分のニーズに合わせて頻度を調節します。異なる頻度を選択する場合は、以下の要素を考慮に入れます。

   • 実際の環境でキャッシュするファイルのサイズ
   • 利用可能なファイルシステムの容量
   • 環境がイメージをキャッシュする頻度

手順

1. アンダークラウドノードに stack ユーザーとしてログインします。
2. 各オーバークラウドノードには heat-admin ユーザーアカウントがあります。このユーザーアカウントにはアンダークラウドのパブリック SSH キーが含まれています。これにより、アンダークラウドからオーバークラウドノードへのパスワードなしの SSH アクセスが可能になります。アンダークラウドノードで、heat-admin ユーザーとして SSH 経由でオーバークラウドノードにログインします。
3. sudo -i で root ユーザーに切り替えます。

1. tls-ciphers.yaml という名前の Heat テンプレート環境ファイルを作成します。

   touch ~/templates/tls-ciphers.yaml

2. 環境ファイルで ExtraConfig フックを使用して、値を tripleo::haproxy::ssl_cipher_suite および tripleo::haproxy::ssl_options hieradata に適用します。

   parameter_defaults:
     ExtraConfig:
       tripleo::haproxy::ssl_cipher_suite: 'DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305'
   
       tripleo::haproxy::ssl_options: 'no-sslv3 no-tls-tickets'

   注記

   暗号のコレクションは、改行せずに 1 行に記述します。

3. オーバークラウドをデプロイする際に、overcloud deploy コマンドで tls-ciphers.yaml 環境ファイルを含めます。

   openstack overcloud deploy --templates \
   ...
   -e /home/stack/templates/tls-ciphers.yaml
   ...

手順

1. 環境ファイルを templates サブディレクトリーにコピーします。

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml /home/stack/templates/

2. resource_registry で絶対パスを使用するように編集します。

   resource_registry:
     OS::TripleO::Services::NeutronML2FujitsuCfab: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-cfab.yaml

3. /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml の parameter_defaults を確認します。

   • NeutronFujitsuCfabAddress: C-Fabric の telnet IP アドレス (文字列)
   • NeutronFujitsuCfabUserName: 使用する C-Fabric ユーザー名 (文字列)
   • NeutronFujitsuCfabPassword: C-Fabric ユーザーアカウントのパスワード (文字列)
   • NeutronFujitsuCfabPhysicalNetworks: physical_network 名と対応する vfab ID を指定する <physical_network>:<vfab_id> タプルのリスト (コンマ区切りリスト)
   • NeutronFujitsuCfabSharePprofile: 同じ VLAN ID を使用する neutron ポート間で C-Fabric pprofile を共有するかどうかを決定するパラメーター (ブール値)
   • NeutronFujitsuCfabPprofilePrefix: pprofile 名の接頭辞文字列 (文字列)。
   • NeutronFujitsuCfabSaveConfig: 設定を保存するかどうかを決定するパラメーター (ブール値)

4. デプロイメントにテンプレートを適用するには、openstack overcloud deploy コマンドで環境ファイルを指定します。

   $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml [OTHER OPTIONS] ...

手順

1. 環境ファイルを templates サブディレクトリーにコピーします。

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml /home/stack/templates/

2. resource_registry で絶対パスを使用するように編集します。

   resource_registry:
     OS::TripleO::Services::NeutronML2FujitsuFossw: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-fossw.yaml

3. /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml の parameter_defaults を確認します。

   • NeutronFujitsuFosswIps: 全 FOS スイッチの IP アドレス (コンマ区切りリスト)
   • NeutronFujitsuFosswUserName: 使用する FOS ユーザー名 (文字列)
   • NeutronFujitsuFosswPassword: FOS ユーザーアカウントのパスワード (文字列)
   • NeutronFujitsuFosswPort: SSH 接続に使用するポート番号 (数値)
   • NeutronFujitsuFosswTimeout: SSH 接続のタイムアウト時間 (数値)
   • NeutronFujitsuFosswUdpDestPort: FOS スイッチ上の VXLAN UDP 宛先のポート番号 (数値)
   • NeutronFujitsuFosswOvsdbVlanidRangeMin: VNI および物理ポートのバインディングに使用する範囲内の最小の VLAN ID (数値)
   • NeutronFujitsuFosswOvsdbPort: FOS スイッチ上の OVSDB サーバー用のポート番号 (数値)

4. デプロイメントにテンプレートを適用するには、openstack overcloud deploy コマンドで環境ファイルを指定します。

   $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml [OTHER OPTIONS] ...

デプロイメント時の heat を使用した KernelArgs の変更

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. source コマンドで stackrc 認証情報ファイルを読み込みます。

   $ source stackrc

3. 環境ファイル overcloud-console.yaml を作成して、以下の内容を記載します。

   parameter_defaults:
     <role>Parameters:
       KernelArgs: "console=<console-name>"

   <role> を設定するオーバークラウドロールの名前に置き換え、<console-name> を使用するコンソールの ID に置き換えます。たとえば、デフォルトロールのすべてのオーバークラウドノードが tty0 を使用するように設定するには、以下のスニペットを使用します。

   parameter_defaults:
     ControllerParameters:
       KernelArgs: "console=tty0"
     ComputeParameters:
       KernelArgs: "console=tty0"
     BlockStorageParameters:
       KernelArgs: "console=tty0"
     ObjectStorageParameters:
       KernelArgs: "console=tty0"
     CephStorageParameters:
       KernelArgs: "console=tty0"

4. -e オプションを使用して、overcloud-console-tty0.yaml ファイルをデプロイメントコマンドに追加します。

overcloud-full.qcow2 イメージの変更

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. source コマンドで stackrc 認証情報ファイルを読み込みます。

   $ source stackrc

3. overcloud-full.qcow2 イメージのカーネル引数を変更して、ハードウェアの正しいコンソールを設定します。たとえば、コンソールを tty0 に設定します。

   $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'grubby --update-kernel=ALL --args="console=tty0"'

4. イメージを director にインポートします。

   $ openstack overcloud image upload --image-path /home/stack/images/overcloud-full.qcow2

5. オーバークラウドをデプロイします。

検証

1. アンダークラウドからオーバークラウドノードにログインします。

   $ ssh heat-admin@<IP-address>

   <IP-address> をオーバークラウドノードの IP アドレスに置き換えます。

2. /proc/cmdline ファイルの内容を調べ、console= パラメーターが使用するコンソールの値に設定されていることを確認します。

   [heat-admin@controller-0 ~]$ cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos2)/boot/vmlinuz-4.18.0-193.29.1.el8_2.x86_64 root=UUID=0ec3dea5-f293-4729-b676-5d38a611ce81 ro console=tty0 console=ttyS0,115200n81 no_timer_check crashkernel=auto rhgb quiet