director のインストールと使用方法

手順

1. お使いのアンダークラウドに root ユーザーとしてログインします。

2. stack ユーザーを作成します。

   [root@director ~]# useradd stack

3. ユーザーのパスワードを設定します。

   [root@director ~]# passwd stack

4. sudo を使用する場合にパスワードを要求されないようにします。

   [root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
   [root@director ~]# chmod 0440 /etc/sudoers.d/stack

5. 新規作成した stack ユーザーに切り替えます。

   [root@director ~]# su - stack
   [stack@director ~]$

6. システムイメージおよび heat テンプレート用のディレクトリーを作成します。

   [stack@director ~]$ mkdir ~/images
   [stack@director ~]$ mkdir ~/templates

   director はシステムのイメージと heat テンプレートを使用して、オーバークラウド環境を構築します。ローカルファイルシステムの管理を容易にするために、Red Hat ではこれらのディレクトリーを作成することを推奨します。

7. アンダークラウドのベースおよび完全なホスト名を確認します。

   [stack@director ~]$ hostname
   [stack@director ~]$ hostname -f

   上記のコマンドのいずれかで正しい完全修飾ホスト名が出力されない、またはエラーが表示される場合には、hostnamectl でホスト名を設定します。

   [stack@director ~]$ sudo hostnamectl set-hostname undercloud.example.com
   [stack@director ~]$ sudo hostnamectl set-hostname --transient undercloud.example.com

8. アンダークラウドホストの完全修飾ドメイン名 (FQDN) を解決できる DNS サーバーを使用していない場合は、/etc/hosts を編集してシステムホスト名のエントリーを追加します。/etc/hosts の IP アドレスは、アンダークラウドのパブリック API に使用する予定のアドレスと一致する必要があります。たとえば、システムの FQDN に undercloud.example.com が使用され、IP アドレスに 10.0.0.1 を使用する場合には、/etc/hosts ファイルに以下の行を追加します。

   10.0.0.1  undercloud.example.com undercloud

9. Red Hat OpenStack Platform director をオーバークラウドまたはその認証プロバイダーとは別のドメインに配置する予定の場合には、追加のドメインを /etc/resolv.conf に加える必要があります。

   search overcloud.com idp.overcloud.com

手順

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

2. Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のどちらかにシステムを登録します。たとえば、システムをコンテンツ配信ネットワークに登録するには、以下のコマンドを実行します。要求されたら、カスタマーポータルのユーザー名およびパスワードを入力します。

   [stack@director ~]$ sudo subscription-manager register

3. Red Hat OpenStack Platform (RHOSP) director のエンタイトルメントプール ID を検索します。

   [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
   Subscription Name:   Name of SKU
   Provides:            Red Hat Single Sign-On
                        Red Hat Enterprise Linux Workstation
                        Red Hat CloudForms
                        Red Hat OpenStack
                        Red Hat Software Collections (for RHEL Workstation)
                        Red Hat Virtualization
   SKU:                 SKU-Number
   Contract:            Contract-Number
   Pool ID:             Valid-Pool-Number-123456
   Provides Management: Yes
   Available:           1
   Suggested:           1
   Service Level:       Support-level
   Service Type:        Service-Type
   Subscription Type:   Sub-type
   Ends:                End-date
   System Type:         Physical

4. Pool ID の値を特定して、Red Hat OpenStack Platform 16.1 のエンタイトルメントをアタッチします。

   [stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456

5. アンダークラウドを Red Hat Enterprise Linux 8.2 にロックします。

   $ sudo subscription-manager release --set=8.2

手順

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

2. デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。

   [stack@director ~]$ sudo subscription-manager repos --disable=*
   [stack@director ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-tus-rpms --enable=rhel-8-for-x86_64-appstream-tus-rpms --enable=rhel-8-for-x86_64-highavailability-tus-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms --enable=advanced-virt-for-rhel-8-x86_64-eus-rpms

   これらのリポジトリーには、director のインストールに必要なパッケージが含まれます。

3. container-tools リポジトリーモジュールをバージョン 2.0 に設定します。

   [stack@director ~]$ sudo dnf module reset container-tools
   [stack@director ~]$ sudo dnf module enable -y container-tools:2.0

4. システムで更新を実行して、ベースシステムパッケージを最新の状態にします。

   [stack@director ~]$ sudo dnf update -y
   [stack@director ~]$ sudo reboot

手順

1. director のインストールと設定を行うためのコマンドラインツールをインストールします。

   [stack@director ~]$ sudo dnf install -y python3-tripleoclient

手順

1. Ceph Tools リポジトリーを有効にします。

   [stack@director ~]$ sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

2. ceph-ansible パッケージをインストールします。

   [stack@director ~]$ sudo dnf install -y ceph-ansible

手順

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. containers-prepare-parameter.yaml ファイルを編集し、Ceph Storage コンテナーを除外します。

   parameter_defaults:
     ContainerImagePrepare:
     - push_destination: true
       excludes:
         - ceph
         - prometheus
       set:
         …​

   excludes パラメーターは正規表現を使用して、ceph または prometheus 文字列を含むコンテナーイメージを除外します。

2. 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 podman search --limit 1000 "registry.redhat.io/rhosp-rhel8/openstack" --format="{{ .Name }}" | sort > satellite_images
   $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-dashboard-rhel8
   $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-rhel8
   $ sudo podman search --limit 1000 "registry.redhat.io/openshift" | grep ose-prometheus

   • Ceph をインストールして Ceph Dashboard を有効にする場合は、次の ose-prometheus コンテナーが必要です。

     registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
     registry.redhat.io/openshift4/ose-prometheus:v4.6
     registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6

2. Satellite 6 の hammer ツールがインストールされているシステムに satellite_images ファイルをコピーします。あるいは、Hammer CLI ガイド に記載の手順に従って、アンダークラウドに hammer ツールをインストールします。

3. 以下の hammer コマンドを実行して、実際の Satellite 組織に新規製品 (OSP16.1 Containers) を作成します。

   $ hammer product create \
     --organization "ACME" \
     --name "OSP Containers"

   このカスタム製品に、イメージを保管します。

4. satellite_images ファイルからオーバークラウドのコンテナーイメージを追加します。

   $ while read IMAGE; do \
     IMAGE_NAME=$(echo $IMAGE | cut -d"/" -f3 | sed "s/openstack-//g") ; \
     IMAGE_NOURL=$(echo $IMAGE | sed "s/registry.redhat.io\///g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name $IMAGE_NOURL \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name $IMAGE_NAME ; done < satellite_images

5. Ceph Storage 4 コンテナーイメージを追加します。

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhceph/rhceph-4-rhel8 \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name rhceph-4-rhel8

   注記

   Ceph Dashboard をインストールする場合は、hammer repository create コマンドに --name rhceph-4-dashboard-rhel8 を含めます。

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhceph/rhceph-4-dashboard-rhel8 \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name rhceph-4-dashboard-rhel8

6. コンテナーイメージを同期します。

   $ hammer product synchronize \
     --organization "ACME" \
     --name "OSP Containers"

   Satellite Server が同期を完了するまで待ちます。

   注記

   設定によっては、hammer から Satellite Server のユーザー名およびパスワードが要求される場合があります。設定ファイルを使用して自動的にログインするように hammer を設定することができます。詳しくは、Red Hat Satellite Hammer CLI ガイドの 認証 セクションを参照してください。

7. お使いの Satellite 6 サーバーでコンテンツビューが使われている場合には、新たなバージョンのコンテンツビューを作成してイメージを反映し、アプリケーションライフサイクルの環境に従ってプロモートします。この作業は、アプリケーションライフサイクルをどのように設定するかに大きく依存します。たとえば、ライフサイクルに production という名称の環境があり、その環境でコンテナーイメージを利用可能にする場合には、コンテナーイメージを含むコンテンツビューを作成し、そのコンテンツビューを production 環境にプロモートします。詳しくは、Red Hat Satellite コンテンツ管理ガイドの コンテンツビューの管理 を参照してください。

8. base イメージに使用可能なタグを確認します。

   $ hammer docker tag list --repository "base" \
     --organization "ACME" \
     --lifecycle-environment "production" \
     --product "OSP Containers"

   このコマンドにより、特定環境のコンテンツビューでの OpenStack Platform コンテナーイメージのタグが表示されます。

9. アンダークラウドに戻り、Satellite サーバーをソースとして使用して、イメージを準備するデフォルトの環境ファイルを生成します。以下のサンプルコマンドを実行して環境ファイルを生成します。

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

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

10. containers-prepare-parameter.yaml ファイルを編集して以下のパラメーターを変更します。

    • push_destination: 選択したコンテナーイメージの管理手段に応じて、これを true または false に設定します。このパラメーターを false に設定すると、オーバークラウドノードはイメージを直接 Satellite からプルします。このパラメーターを true に設定すると、director はイメージを Satellite からアンダークラウドレジストリーにプルし、オーバークラウドはそのイメージをアンダークラウドレジストリーからプルします。
    • namespace: Satellite サーバー上のレジストリーの URL およびポート。Red Hat Satellite のデフォルトのレジストリーポートは 443 です。

    • name_prefix: 接頭辞は Satellite 6 の命名規則に基づきます。これは、コンテンツビューを使用するかどうかによって異なります。

      • コンテンツビューを使用する場合、設定は [org]-[environment]-[content view]-[product]- です。例: acme-production-myosp16-osp_containers-。
      • コンテンツビューを使用しない場合、設定は [org]-[product]- です。例: acme-osp_containers-。
    • ceph_namespace、ceph_image、ceph_tag: Ceph Storage を使用する場合には、Ceph Storage コンテナーイメージの場所を定義するこれらの追加パラメーターを指定します。ceph_image に Satellite 固有の接頭辞が追加された点に注意してください。この接頭辞は、name_prefix オプションと同じ値です。

手順

1. デフォルトのテンプレートを stack ユーザーのホームディレクトリーにコピーします。

   [stack@director ~]$ cp \
     /usr/share/python-tripleoclient/undercloud.conf.sample \
     ~/undercloud.conf

2. undercloud.conf ファイルを編集します。このファイルには、アンダークラウドを設定するための設定値が含まれています。パラメーターを省略したり、コメントアウトした場合には、アンダークラウドのインストールでデフォルト値が使用されます。

手順

1. /home/stack/templates/custom-undercloud-params.yaml という名前で環境ファイルを作成します。

2. このファイルを編集して、必要な heat パラメーターを追加します。たとえば、特定の OpenStack Platform サービスのデバッグを有効にするには、custom-undercloud-params.yaml ファイルに以下のスニペットを追加します。

   parameter_defaults:
     Debug: True

   完了したら、このファイルを保存します。

3. undercloud.conf ファイルを編集し、custom_env_files パラメーターまでスクロールします。作成した custom-undercloud-params.yaml 環境ファイルをポイントするようにパラメーターを編集します。

   custom_env_files = /home/stack/templates/custom-undercloud-params.yaml

   注記

   コンマ区切りリストを使用して、複数の環境ファイルを指定することができます。

手順

1. hieradata オーバーライドファイルを作成します (例: /home/stack/hieradata.yaml)。

2. カスタマイズした hieradata をファイルに追加します。たとえば、Compute (nova) サービスのパラメーター force_raw_images をデフォルト値の True から False に変更するには、以下のスニペットを追加します。

   nova::compute::force_raw_images: False

   設定するパラメーターに Puppet 実装がない場合には、以下の手段によりパラメーターを設定します。

   nova::config::nova_config:
     DEFAULT/<parameter_name>:
       value: <parameter_value>

   以下に例を示します。

   nova::config::nova_config:
     DEFAULT/network_allocate_retries:
       value: 20
     ironic/serial_console_state_timeout:
       value: 15

3. undercloud.conf ファイルの hieradata_override パラメーターを、新しい /home/stack/hieradata.yaml ファイルのパスに設定します。

   hieradata_override = /home/stack/hieradata.yaml

手順

1. undercloud.conf ファイルを開きます。

2. IPv6 アドレスモードをステートレスまたはステートフルのいずれかに指定します。

   [DEFAULT]
   ipv6_address_mode = <address_mode>
   ...

   • NIC がサポートするモードに基づいて、<address_mode> を dhcpv6-stateless または dhcpv6-stateful に置き換えます。
   注記

   ステートフルアドレスモードを使用する場合、ファームウェア、チェーンローダー、およびオペレーティングシステムは、DHCP サーバーが追跡する ID を生成するために異なるアルゴリズムを使用する場合があります。DHCPv6 は MAC によってアドレスを追跡せず、リクエスターからの ID 値が変更されても、MAC アドレスが同じままである場合、同じアドレスを提供しません。したがって、ステートフル DHCPv6 を使用する場合は、次の手順を実行してネットワークインターフェイスを設定する必要もあります。

3. ステートフル DHCPv6 を使用するようにアンダークラウドを設定した場合は、ベアメタルノードに使用するネットワークインターフェイスを指定します。

   [DEFAULT]
   ipv6_address_mode = dhcpv6-stateful
   ironic_enabled_network_interfaces = neutron,flat
   ...

4. ベアメタルノードのデフォルトのネットワークインターフェイスを設定します。

   [DEFAULT]
   ...
   ironic_default_network_interface = neutron
   ...

5. アンダークラウドがプロビジョニングネットワーク上にルーターを作成するかどうかを指定します。

   [DEFAULT]
   ...
   enable_routed_networks: <true/false>
   ...

   • <true/false> を true に置き換えて、ルーティングされたネットワークを有効にし、アンダークラウドがプロビジョニングネットワーク上にルーターを作成しないようにします。true の場合、データセンタールーターはルーターアドバタイズメントを提供する必要があります。
   • <true/false> を false に置き換えて、ルーティングされたネットワークを無効にし、プロビジョニングネットワーク上にルーターを作成します。

6. ローカル IP アドレス、および SSL/TLS を介した director Admin API および Public API エンドポイントの IP アドレスを設定します。

   [DEFAULT]
   ...
   local_ip = <ipv6_address>
   undercloud_admin_host = <ipv6_address>
   undercloud_public_host = <ipv6_address>
   ...

   • <ipv6_address> をアンダークラウドの IPv6 アドレスに置き換えます。

7. オプション: director がインスタンスの管理に使用するプロビジョニングネットワークを設定します。

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   ...

   • <ipv6_address> を、デフォルトのプロビジョニングネットワークを使用していないときにインスタンスの管理に使用するネットワークの IPv6 アドレスに置き換えます。
   • <ipv6_prefix> を、デフォルトのプロビジョニングネットワークを使用していないときにインスタンスの管理に使用するネットワークの IP アドレス接頭辞に置き換えます。

8. プロビジョニングノードの DHCP 割り当て範囲を設定します。

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   dhcp_start = <ipv6_address_dhcp_start>
   dhcp_end = <ipv6_address_dhcp_end>
   ...

   • <ipv6_address_dhcp_start> を、オーバークラウドノードに使用するネットワーク範囲の開始点の IPv6 アドレスに置き換えます。
   • <ipv6_address_dhcp_end> を、オーバークラウドノードに使用するネットワーク範囲の終わりの IPv6 アドレスに置き換えます。

9. オプション: トラフィックを External ネットワークに転送するようにゲートウェイを設定します。

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   dhcp_start = <ipv6_address_dhcp_start>
   dhcp_end = <ipv6_address_dhcp_end>
   gateway = <ipv6_gateway_address>
   ...

   • デフォルトゲートウェイを使用しない場合は、<ipv6_gateway_address> をゲートウェイの IPv6 アドレスに置き換えます。

10. 検査プロセス中に使用する DHCP 範囲を設定します。

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    inspection_iprange = <ipv6_address_inspection_start>,<ipv6_address_inspection_end>
    ...

    • <ipv6_address_inspection_start> を、検査プロセス中に使用するネットワーク範囲の開始点の IPv6 アドレスに置き換えます。
    • <ipv6_address_inspection_end> を、検査プロセス中に使用するネットワーク範囲の終わりの IPv6 アドレスに置き換えます。
    注記

    この範囲は、dhcp_start と dhcp_end で定義された範囲と重複することはできませんが、同じ IP サブネット内になければなりません。

11. サブネットの IPv6 ネームサーバーを設定します。

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    inspection_iprange = <ipv6_address_inspection_start>,<ipv6_address_inspection_end>
    dns_nameservers = <ipv6_dns>

    • <ipv6_dns> をサブネットに固有の DNS ネームサーバーに置き換えます。

手順

1. アンダークラウドのホストにログインします。

2. 新規ファイル undercloud-os-net-config.yaml を作成し、必要なネットワーク設定を追加します。

   詳細は、ネットワークインターフェイスのリファレンス を参照してください。

   以下に例を示します。

   network_config:
   - name: br-ctlplane
     type: ovs_bridge
     use_dhcp: false
     dns_servers: 192.168.122.1
     domain: lab.example.com
     ovs_extra:
     - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
     addresses:
     - ip_netmask: 172.20.0.1/26
     members:
     - type: interface
       name: nic2

   特定のインターフェイスのネットワークボンディングを作成するには、次のサンプルを使用します。

   network_config:
   - name: br-ctlplane
     type: ovs_bridge
     use_dhcp: false
     dns_servers: 192.168.122.1
     domain: lab.example.com
     ovs_extra:
     - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
     addresses:
     - ip_netmask: 172.20.0.1/26
     members:
     - name: bond-ctlplane
       type: linux_bond
       use_dhcp: false
       bonding_options: "mode=active-backup"
       mtu: 1500
       members:
       - type: interface
         name: nic2
       - type: interface
         name: nic3

3. undercloud.conf ファイルの net_config_override パラメーターに、undercloud-os-net-config.yaml ファイルへのパスを追加します。

   [DEFAULT]
   ...
   net_config_override=undercloud-os-net-config.yaml
   ...

   注記

   director は、net_config_override パラメーターに追加するファイルをテンプレートとして使用し、/etc/os-net-config/config.yaml ファイルを生成します。os-net-config はテンプレートで定義するインターフェイスを管理するので、このファイルですべてのアンダークラウドネットワークインターフェイスのカスタマイズを実行する必要があります。

4. アンダークラウドをインストールします。

手順

1. 以下のコマンドを実行して、アンダークラウドに director をインストールします。

   [stack@director ~]$ openstack undercloud install

   このコマンドにより、director の設定スクリプトが起動します。director は追加のパッケージをインストールし、undercloud.conf の設定に従ってサービスを設定し、すべての RHOSP サービスコンテナーを起動します。このスクリプトは、完了までに数分かかります。

   スクリプトにより、2 つのファイルが生成されます。

   • undercloud-passwords.conf: director サービスの全パスワードリスト
   • stackrc: director コマンドラインツールへアクセスできるようにする初期化変数セット

2. RHOSP サービスコンテナーが実行中であることを確認します。

   [stack@director ~]$ sudo podman ps -a --format "{{.Names}} {{.Status}}"

   次のコマンド出力は、RHOSP サービスコンテナーが実行中 (Up) であることを示しています。

   memcached Up 3 hours (healthy)
   haproxy Up 3 hours
   rabbitmq Up 3 hours (healthy)
   mysql Up 3 hours (healthy)
   iscsid Up 3 hours (healthy)
   keystone Up 3 hours (healthy)
   keystone_cron Up 3 hours (healthy)
   neutron_api Up 3 hours (healthy)
   logrotate_crond Up 3 hours (healthy)
   neutron_dhcp Up 3 hours (healthy)
   neutron_l3_agent Up 3 hours (healthy)
   neutron_ovs_agent Up 3 hours (healthy)
   ironic_api Up 3 hours (healthy)
   ironic_conductor Up 3 hours (healthy)
   ironic_neutron_agent Up 3 hours (healthy)
   ironic_pxe_tftp Up 3 hours (healthy)
   ironic_pxe_http Up 3 hours (unhealthy)
   ironic_inspector Up 3 hours (healthy)
   ironic_inspector_dnsmasq Up 3 hours (healthy)
   neutron-dnsmasq-qdhcp-30d628e6-45e6-499d-8003-28c0bc066487 Up 3 hours
   ...

3. stack ユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。

   [stack@director ~]$ source ~/stackrc

   プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。

   (undercloud) [stack@director ~]$

手順

1. source コマンドで stackrc ファイルを読み込み、director コマンドラインツールを有効にします。

   [stack@director ~]$ source ~/stackrc

2. ctlplane-subnet サブネット用のネームサーバーを設定します。

   (undercloud) [stack@director images]$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] ctlplane-subnet

   各ネームサーバーに --dns-nameserver オプションを使用します。

3. サブネットを表示してネームサーバーを確認します。

   (undercloud) [stack@director images]$ openstack subnet show ctlplane-subnet
   +-------------------+-----------------------------------------------+
   | Field             | Value                                         |
   +-------------------+-----------------------------------------------+
   | ...               |                                               |
   | dns_nameservers   | 8.8.8.8                                       |
   | ...               |                                               |
   +-------------------+-----------------------------------------------+

手順

1. アンダークラウドの設定ファイルを変更します。以下の例では、undercloud.conf ファイルを編集して、有効なハードウェア種別のリストに idrac ハードウェア種別を追加しています。

   enabled_hardware_types = ipmi,redfish,idrac

2. openstack undercloud install コマンドを実行し、新たな変更を反映させてアンダークラウドを更新します。

   [stack@director ~]$ openstack undercloud install

   コマンドの実行が完了するまで待ちます。

3. stack ユーザーを初期化し、コマンドラインツールを使用します。

   [stack@director ~]$ source ~/stackrc

   プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。

   (undercloud) [stack@director ~]$

4. director が新しい設定を適用していることを確認します。この例では、有効なハードウェア種別のリストを確認しています。

   (undercloud) [stack@director ~]$ openstack baremetal driver list
   +---------------------+----------------------+
   | Supported driver(s) | Active host(s)       |
   +---------------------+----------------------+
   | idrac               | director.example.com |
   | ipmi                | director.example.com |
   | redfish             | director.example.com |
   +---------------------+----------------------+

手順

1. ミニオンホストに root ユーザーとしてログインします。

2. stack ユーザーを作成します。

   [root@minion ~]# useradd stack

3. stack ユーザーのパスワードを設定します。

   [root@minion ~]# passwd stack

4. sudo を使用する場合にパスワードを要求されないようにします。

   [root@minion ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
   [root@minion ~]# chmod 0440 /etc/sudoers.d/stack

5. 新規作成した stack ユーザーに切り替えます。

   [root@minion ~]# su - stack
   [stack@minion ~]$

6. ミニオンのベースおよび完全なホスト名を確認します。

   [stack@minion ~]$ hostname
   [stack@minion ~]$ hostname -f

   上記のコマンドのいずれかで正しい完全修飾ホスト名が出力されない、またはエラーが表示される場合には、hostnamectl でホスト名を設定します。

   [stack@minion ~]$ sudo hostnamectl set-hostname minion.example.com
   [stack@minion ~]$ sudo hostnamectl set-hostname --transient minion.example.com

7. /etc/hosts ファイルを編集して、システムホスト名のエントリーを追加します。たとえば、システムの名前が minion.example.com で、IP アドレスに 10.0.0.1 を使用する場合には、/etc/hosts ファイルに以下の行を追加します。

   10.0.0.1  minion.example.com manager

8. Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のどちらかにシステムを登録します。たとえば、システムをコンテンツ配信ネットワークに登録するには、以下のコマンドを実行します。要求されたら、カスタマーポータルのユーザー名およびパスワードを入力します。

   [stack@minion ~]$ sudo subscription-manager register

9. Red Hat OpenStack Platform (RHOSP) director のエンタイトルメントプール ID を検索します。

   [stack@minion ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
   Subscription Name:   Name of SKU
   Provides:            Red Hat Single Sign-On
                        Red Hat Enterprise Linux Workstation
                        Red Hat CloudForms
                        Red Hat OpenStack
                        Red Hat Software Collections (for RHEL Workstation)
                        Red Hat Virtualization
   SKU:                 SKU-Number
   Contract:            Contract-Number
   Pool ID:             Valid-Pool-Number-123456
   Provides Management: Yes
   Available:           1
   Suggested:           1
   Service Level:       Support-level
   Service Type:        Service-Type
   Subscription Type:   Sub-type
   Ends:                End-date
   System Type:         Physical

10. Pool ID の値を特定して、Red Hat OpenStack Platform 16.1 のエンタイトルメントをアタッチします。

    [stack@minion ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456

11. デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。

    [stack@minion ~]$ sudo subscription-manager repos --disable=*
    [stack@minion ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms

    これらのリポジトリーには、ミニオンのインストールに必要なパッケージが含まれます。

12. システムで更新を実行して、ベースシステムパッケージを最新の状態にします。

    [stack@minion ~]$ sudo dnf update -y
    [stack@minion ~]$ sudo reboot

13. ミニオンのインストールと設定を行うためのコマンドラインツールをインストールします。

    [stack@minion ~]$ sudo dnf install -y python3-tripleoclient

手順

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

2. ファイルをアンダークラウドからミニオンにコピーします。

   $ scp ~/tripleo-undercloud-outputs.yaml ~/tripleo-undercloud-passwords.yaml stack@<minion-host>:~/.

   • <minion-host> は、ミニオンのホスト名または IP アドレスに置き換えます。

手順

1. ミニオンホストに root ユーザーとしてログインします。

2. 認証局ファイルをアンダークラウドからミニオンにコピーします。

   [root@minion ~]# scp \
       root@<undercloud-host>:/etc/pki/ca-trust/source/anchors/cm-local-ca.pem \
       /etc/pki/ca-trust/source/anchors/undercloud-ca.pem

   • <undercloud-host> は、アンダークラウドのホスト名または IP アドレスに置き換えます。

3. ミニオンホストの信頼済み認証局を更新します。

   [root@minion ~]# update-ca-trust enable
   [root@minion ~]# update-ca-trust extract

手順

1. ミニオンホストに stack ユーザーとしてログインします。

2. デフォルトのテンプレートを stack ユーザーのホームディレクトリーにコピーします。

   [stack@minion ~]$ cp \
     /usr/share/python-tripleoclient/minion.conf.sample \
     ~/minion.conf

3. minion.conf ファイルを編集します。このファイルには、ミニオンを設定するためのパラメーターが含まれています。パラメーターを省略したり、コメントアウトした場合には、ミニオンのインストールでデフォルト値が使用されます。以下の推奨パラメーターを確認してください。

   • minion_hostname: ミニオンのホスト名に設定します。
   • minion_local_interface: プロビジョニングネットワークを介してアンダーグラウンドに接続するインターフェイスに設定します。
   • minion_local_ip: プロビジョニングネットワークのフリー IP アドレスに設定します。
   • minion_nameservers: ミニオンがホスト名を解決できるように DNS ネームサーバーに設定します。
   • enable_ironic_conductor: ironic-conductor サービスを有効にするかどうかを定義します。
   • enable_heat_engine: heat-engine サービスを有効にするかどうかを定義します。

手順

1. ミニオンホストに stack ユーザーとしてログインします。

2. 以下のコマンドを実行して、ミニオンをインストールします。

   [stack@minion ~]$ openstack undercloud minion install

   このコマンドによりミニオンの設定スクリプトが起動し、追加のパッケージがインストールされ、minion.conf ファイルの設定に応じてミニオンサービスが設定されます。このスクリプトは、完了までに数分かかります。

手順

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

2. stackrc ファイルを取得します。

   [stack@director ~]$ source ~/stackrc

3. ミニオンで heat engine サービスを有効にしている場合には、ミニオンからの heat-engine サービスがアンダークラウドサービスのリストに表示されることを確認します。

   [stack@director ~]$ $ openstack orchestration service list

   このコマンド出力には、アンダークラウドとミニオン両方の heat-engine ワーカーが記載された表が表示されます。

4. ミニオンで ironic conductor サービスを有効にしている場合には、ミニオンからの ironic-conductor サービスがアンダークラウドサービスのリストに表示されることを確認します。

   [stack@director ~]$ $ openstack baremetal conductor list

   このコマンド出力には、アンダークラウドとミニオン両方の ironic-conductor ワーカーが記載された表が表示されます。

手順

1. ノードをリスト表示する nodes.json または nodes.yaml という名前のテンプレートを作成します。以下の例に示す JSON および YAML テンプレートを使用して、ノード定義のテンプレートを設定する方法を説明します。

   JSON テンプレートの例

   {
   	"nodes": [{
   			"ports": [{
   				"address": "aa:aa:aa:aa:aa:aa",
   				"physical_network": "ctlplane",
   				"local_link_connection": {
   					"switch_id": "52:54:00:00:00:00",
   					"port_id": "p0"
   				}
   			}],
   			"name": "node01",
   			"cpu": "4",
   			"memory": "6144",
   			"disk": "40",
   			"arch": "x86_64",
   			"pm_type": "ipmi",
   			"pm_user": "admin",
   			"pm_password": "p@55w0rd!",
   			"pm_addr": "192.168.24.205"
   		},
   		{
   			"ports": [{
   				"address": "bb:bb:bb:bb:bb:bb",
   				"physical_network": "ctlplane",
   				"local_link_connection": {
   					"switch_id": "52:54:00:00:00:00",
   					"port_id": "p0"
   				}
   			}],
   			"name": "node02",
   			"cpu": "4",
   			"memory": "6144",
   			"disk": "40",
   			"arch": "x86_64",
   			"pm_type": "ipmi",
   			"pm_user": "admin",
   			"pm_password": "p@55w0rd!",
   			"pm_addr": "192.168.24.206"
   		}
   	]
   }

   YAML テンプレートの例

   nodes:
     - ports:
         - address: aa:aa:aa:aa:aa:aa
           physical_network: ctlplane
           local_link_connection:
             switch_id: 52:54:00:00:00:00
             port_id: p0
       name: "node01"
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.205"
     - ports:
         - address: bb:bb:bb:bb:bb:bb
           physical_network: ctlplane
           local_link_connection:
             switch_id: 52:54:00:00:00:00
             port_id: p0
       name: "node02"
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.206"

   このテンプレートには、以下の属性が含まれます。

   name

   ノードの論理名

   pm_type

   使用する電源管理ドライバー。この例では IPMI ドライバー (ipmi) を使用しています。

   注記

   IPMI が推奨されるサポート対象電源管理ドライバーです。サポート対象電源管理ドライバーの種別およびそのオプションに関する詳細は、30章電源管理ドライバー を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。

   pm_user、pm_password

   IPMI のユーザー名およびパスワード

   pm_addr

   IPMI デバイスの IP アドレス

   pm_port (オプション)

   特定の IPMI デバイスにアクセスするためのポート

   address

   (オプション) ノード上のネットワークインターフェイスの MAC アドレスリスト。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。

   physical_network

   (オプション) プロビジョニング NIC に接続される物理ネットワーク

   local_link_connection

   (オプション) IPv6 プロビジョニングを使用し、イントロスペクション中に LLDP がローカルリンク接続を正しく反映しない場合は、local_link_connection パラメーターの switch_id および port_id フィールドにダミーのデータを含める必要があります。偽のデータを含める方法の詳細は、Using director introspection to collect bare metal node hardware information を参照してください。

   cpu

   (オプション) ノード上の CPU 数

   memory

   (オプション) メモリーサイズ (MB 単位)

   disk

   (オプション) ハードディスクのサイズ (GB 単位)

   arch

   (オプション) システムアーキテクチャー

   重要

   マルチアーキテクチャークラウドをビルドする場合には、x86_64 アーキテクチャーを使用するノードと ppc64le アーキテクチャーを使用するノードを区別するために arch キーが必須です。

2. テンプレートを作成したら、以下のコマンドを実行してフォーマットおよび構文を検証します。

   $ source ~/stackrc
   (undercloud)$ openstack overcloud node import --validate-only ~/nodes.json

   重要

   マルチアーキテクチャーノードの場合は、--http-boot /var/lib/ironic/tftpboot/ オプションも追加する必要があります。

3. stack ユーザーのホームディレクトリーにファイルを保存し (/home/stack/nodes.json)、続いて以下のコマンドを実行してテンプレートを director にインポートします。

   (undercloud)$ openstack overcloud node import ~/nodes.json

   このコマンドにより、それぞれのノードがテンプレートから director に登録されます。UEFI ブートモードを使用する場合は、各ノードでブートモードも設定する必要があります。UEFI ブートモードを設定せずにノードをイントロスペクトすると、ノードはレガシーモードでブートします。詳細は、Setting the boot mode to UEFI boot mode を参照してください。

4. ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。

   (undercloud)$ openstack baremetal node list

手順

1. 特定のプロファイルにノードをタグ付けする場合には、各ノードの properties/capabilities パラメーターに profile オプションを追加します。たとえば、特定のプロファイルを使用するように特定のノードをタグ付けするには、以下のコマンドを使用します。

   (undercloud) $ NODE=<NODE NAME OR ID>
   (undercloud) $ PROFILE=<PROFILE NAME>
   (undercloud) $ openstack baremetal node set --property capabilities="profile:$PROFILE,boot_option:local" $NODE

   • $NODE 変数にノードの名前または UUID を設定します。
   • $PROFILE 変数は、control または compute などの特定のプロファイルに設定します。
   • properties/capabilities の profile オプションには、profile:control または profile:compute などの対応するプロファイルとノードをタグ付けする $PROFILE 変数が含まれます。
   • 各ノードのブート方法を定義するには、boot_option:local オプションを設定します。

   追加の openstack baremetal node show コマンドおよび jq フィルタリングを使用して、既存の capabilities の値を保持することもできます。

   (undercloud) $ openstack baremetal node set --property capabilities="profile:$PROFILE,boot_option:local,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE

2. ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。

   (undercloud) $ openstack overcloud profiles list

手順

1. undercloud.conf ファイルで以下のパラメーターを設定します。

   ipxe_enabled = True

2. undercloud.conf ファイルを保存して、アンダークラウドのインストールを実行します。

   $ openstack undercloud install

   インストールスクリプトが完了するまで待ちます。

3. 登録された各ノードの既存の機能を確認します。

   $ openstack baremetal node show <node> -f json -c properties | jq -r .properties.capabilities

   • <node> をベアメタルノードの ID に置き換えてください。

4. ノードの既存の機能に boot_mode:uefi を追加して、登録されている各ノードのブートモードを uefi に設定します。

   $ openstack baremetal node set --property capabilities="boot_mode:uefi,<capability_1>,...,<capability_n>" <node>

   • <node> をベアメタルノードの ID に置き換えてください。

   • <capability_1> および <capability_n> までのすべての機能を、手順 3 で取得した各機能に置き換えます。

     たとえば、次のコマンドを使用して、ローカルブートでブートモードを uefi に設定します。

   $ openstack baremetal node set --property capabilities="boot_mode:uefi,boot_option:local" <node>

5. ベアメタルフレーバーごとに、ブートモードを uefi に設定します。

   $ openstack flavor set --property capabilities:boot_mode='uefi' <flavor>

手順

1. Bare Metal サービス (ironic) のブートインターフェイスを redfish-virtual-media に設定します。

   $ openstack baremetal node set --boot-interface redfish-virtual-media $NODE_NAME

   • $NODE_NAME はノード名に置き換えてください。

2. UEFI ノードの場合は、ブートモードを uefi に設定します。

   NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE

   • $NODE はノード名に置き換えてください。

     注記

     BIOS ノードの場合は、このステップを実施しないでください。

3. UEFI ノードの場合は、EFI システムパーティション (ESP) イメージを定義します。

   $ openstack baremetal node set --driver-info bootloader=$ESP $NODE_NAME

   • $ESP は glance イメージの UUID または ESP イメージの URL に、$NODE_NAME はノードの名前に、それぞれ置き換えてください。

     注記

     BIOS ノードの場合は、このステップを実施しないでください。

4. ベアメタルノードにポートを作成し、そのポートをベアメタルノード上の NIC の MAC アドレスに関連付けます。

   $ openstack baremetal port create --pxe-enabled True --node $UUID $MAC_ADDRESS

   • $UUID はベアメタルノードの UUID に、$MAC_ADDRESS はベアメタルノード上の NIC の MAC アドレスに、それぞれ置き換えてください。

手順

1. 各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドを実行して、ノードのディスク情報を表示します。

   (undercloud)$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

   たとえば、1 つのノードのデータで 3 つのディスクが表示される場合があります。

   [
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sda",
       "wwn_vendor_extension": "0x1ea4dcc412a9632b",
       "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f380700",
       "serial": "61866da04f3807001ea4dcc412a9632b"
     }
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sdb",
       "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
       "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f380d00",
       "serial": "61866da04f380d001ea4e13c12e36ad6"
     }
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sdc",
       "wwn_vendor_extension": "0x1ea4e31e121cfb45",
       "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f37fc00",
       "serial": "61866da04f37fc001ea4e31e121cfb45"
     }
   ]

2. アンダークラウドで、ノードのルートディスクを設定します。ルートディスクを定義するのに最も適切なハードウェア属性値を指定します。

   (undercloud)$ openstack baremetal node set --property root_device='{"serial":"<serial_number>"}' <node-uuid>

   たとえば、ルートデバイスをシリアル番号が 61866da04f380d001ea4e13c12e36ad6 の disk 2 に設定するには、以下のコマンドを実行します。

   (undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

   注記

   選択したルートディスクから起動するように各ノードの BIOS を設定します。最初にネットワークからのブートを試み、次にルートディスクからのブートを試みるように、ブート順序を設定します。

手順

1. overcloud-minimal イメージを使用するように director を設定するには、以下のイメージ定義を含む環境ファイルを作成します。

   parameter_defaults:
     <roleName>Image: overcloud-minimal

2. <roleName> をロール名に置き換え、ロール名に Image を追加します。Ceph Storage ノードの overcloud-minimal イメージの例を以下に示します。

   parameter_defaults:
     CephStorageImage: overcloud-minimal

3. roles_data.yaml ロール定義ファイルで、rhsm_enforce パラメーターを False に設定します。

   rhsm_enforce: False

4. この環境ファイルを openstack overcloud deploy コマンドに渡します。

手順

1. /home/stack/templates/ ディレクトリーに node-info.yaml ファイルを作成します。

   (undercloud) $ touch /home/stack/templates/node-info.yaml

2. ファイルを編集し、必要なノード数およびフレーバーを設定します。以下の例には、3 台のコントローラーノードおよび 3 台のコンピュートノードが含まれます。

   parameter_defaults:
     OvercloudControllerFlavor: control
     OvercloudComputeFlavor: compute
     ControllerCount: 3
     ComputeCount: 3

手順

1. 証明書ファイルを開き、証明書部分だけをコピーします。鍵を含めないでください。

   $ vi /home/stack/ca.crt.pem

   必要となる証明書部分の例を、以下に示します。

   -----BEGIN CERTIFICATE-----
   MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
   BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
   UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
   -----END CERTIFICATE-----

2. 以下に示す内容で /home/stack/inject-trust-anchor-hiera.yaml という名称の新たな YAML ファイルを作成し、PEM ファイルからコピーした証明書を追加します。

   parameter_defaults:
     CAMap:
       undercloud-ca:
         content: |
           -----BEGIN CERTIFICATE-----
           MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
           BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
           UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
           -----END CERTIFICATE-----

1. カスタムの環境ファイルおよび heat テンプレートのパラメーターを変更します。
2. 同じ環境ファイルを指定して openstack overcloud deploy コマンドを再度実行します。

手順

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

   $ source ~/stackrc

2. この検証には、オーバークラウドプランのコピーが必要です。必要なすべての環境ファイルと共に、オーバークラウドプランをアップロードします。プランのみをアップロードするには、--update-plan-only オプションを指定して openstack overcloud deploy コマンドを実行します。

   $ openstack overcloud deploy --templates \
       -e environment-file1.yaml \
       -e environment-file2.yaml \
       ...
       --update-plan-only

3. --group pre-deployment オプションを指定して、openstack tripleo validator run コマンドを実行します。

   $ openstack tripleo validator run --group pre-deployment

4. オーバークラウドにデフォルトのプラン名 overcloud 以外の名前を使用する場合は、--plan オプションでプラン名を設定します。

   $ openstack tripleo validator run --group pre-deployment \
       --plan myovercloud

5. 検証レポートの結果を確認します。特定の検証からの詳細出力を表示するには、レポートからの特定検証の UUID を指定して openstack tripleo validator show run --full コマンドを実行します。

   $ openstack tripleo validator show run --full <UUID>

手順

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

   $ source ~/stackrc

2. --group post-deployment オプションを指定して、openstack tripleo validator run コマンドを実行します。

   $ openstack tripleo validator run --group post-deployment

3. オーバークラウドにデフォルトのプラン名 overcloud 以外の名前を使用する場合は、--plan オプションでプラン名を設定します。

   $ openstack tripleo validator run --group post-deployment \
       --plan myovercloud

4. 検証レポートの結果を確認します。特定の検証からの詳細出力を表示するには、レポートからの特定検証の UUID を指定して openstack tripleo validator show run --full コマンドを実行します。

   $ openstack tripleo validator show run --full <UUID>

手順

1. ノードをリスト表示する nodes.json または nodes.yaml という名前のテンプレートを作成します。以下の例に示す JSON および YAML テンプレートを使用して、ノード定義のテンプレートを設定する方法を説明します。

   JSON テンプレートの例

   {
   	"nodes": [{
   			"ports": [{
   				"address": "aa:aa:aa:aa:aa:aa",
   				"physical_network": "ctlplane",
   				"local_link_connection": {
   					"switch_id": "52:54:00:00:00:00",
   					"port_id": "p0"
   				}
   			}],
   			"name": "node01",
   			"cpu": "4",
   			"memory": "6144",
   			"disk": "40",
   			"arch": "x86_64",
   			"pm_type": "ipmi",
   			"pm_user": "admin",
   			"pm_password": "p@55w0rd!",
   			"pm_addr": "192.168.24.205"
   		},
   		{
   			"ports": [{
   				"address": "bb:bb:bb:bb:bb:bb",
   				"physical_network": "ctlplane",
   				"local_link_connection": {
   					"switch_id": "52:54:00:00:00:00",
   					"port_id": "p0"
   				}
   			}],
   			"name": "node02",
   			"cpu": "4",
   			"memory": "6144",
   			"disk": "40",
   			"arch": "x86_64",
   			"pm_type": "ipmi",
   			"pm_user": "admin",
   			"pm_password": "p@55w0rd!",
   			"pm_addr": "192.168.24.206"
   		}
   	]
   }

   YAML テンプレートの例

   nodes:
     - ports:
         - address: aa:aa:aa:aa:aa:aa
           physical_network: ctlplane
           local_link_connection:
             switch_id: 52:54:00:00:00:00
             port_id: p0
       name: "node01"
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.205"
     - ports:
         - address: bb:bb:bb:bb:bb:bb
           physical_network: ctlplane
           local_link_connection:
             switch_id: 52:54:00:00:00:00
             port_id: p0
       name: "node02"
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.206"

   このテンプレートには、以下の属性が含まれます。

   name

   ノードの論理名

   pm_type

   使用する電源管理ドライバー。この例では IPMI ドライバー (ipmi) を使用しています。

   注記

   IPMI が推奨されるサポート対象電源管理ドライバーです。サポート対象電源管理ドライバーの種別およびそのオプションに関する詳細は、30章電源管理ドライバー を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。

   pm_user、pm_password

   IPMI のユーザー名およびパスワード

   pm_addr

   IPMI デバイスの IP アドレス

   pm_port (オプション)

   特定の IPMI デバイスにアクセスするためのポート

   address

   (オプション) ノード上のネットワークインターフェイスの MAC アドレスリスト。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。

   physical_network

   (オプション) プロビジョニング NIC に接続される物理ネットワーク

   local_link_connection

   (オプション) IPv6 プロビジョニングを使用し、イントロスペクション中に LLDP がローカルリンク接続を正しく反映しない場合は、local_link_connection パラメーターの switch_id および port_id フィールドにダミーのデータを含める必要があります。偽のデータを含める方法の詳細は、Using director introspection to collect bare metal node hardware information を参照してください。

   cpu

   (オプション) ノード上の CPU 数

   memory

   (オプション) メモリーサイズ (MB 単位)

   disk

   (オプション) ハードディスクのサイズ (GB 単位)

   arch

   (オプション) システムアーキテクチャー

   重要

   マルチアーキテクチャークラウドをビルドする場合には、x86_64 アーキテクチャーを使用するノードと ppc64le アーキテクチャーを使用するノードを区別するために arch キーが必須です。

2. テンプレートを作成したら、以下のコマンドを実行してフォーマットおよび構文を検証します。

   $ source ~/stackrc
   (undercloud)$ openstack overcloud node import --validate-only ~/nodes.json

   重要

   マルチアーキテクチャーノードの場合は、--http-boot /var/lib/ironic/tftpboot/ オプションも追加する必要があります。

3. stack ユーザーのホームディレクトリーにファイルを保存し (/home/stack/nodes.json)、続いて以下のコマンドを実行してテンプレートを director にインポートします。

   (undercloud)$ openstack overcloud node import ~/nodes.json

   このコマンドにより、それぞれのノードがテンプレートから director に登録されます。UEFI ブートモードを使用する場合は、各ノードでブートモードも設定する必要があります。UEFI ブートモードを設定せずにノードをイントロスペクトすると、ノードはレガシーモードでブートします。詳細は、Setting the boot mode to UEFI boot mode を参照してください。

4. ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。

   (undercloud)$ openstack baremetal node list

手順

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

   $ source ~/stackrc

2. 新しい ~/overcloud-baremetal-deploy.yaml ファイルを作成し、プロビジョニングする各ロールのノード数を定義します。たとえば、コントローラーノード 3 つとコンピュートノード 3 つをプロビジョニングするには、以下の構文を使用します。

   - name: Controller
     count: 3
   - name: Compute
     count: 3

3. ~/overcloud-baremetal-deploy.yaml ファイルで、予測可能なノード配置、カスタムイメージ、カスタム NIC、またはノードに割り当てるその他の属性を定義します。たとえば、以下の例の構文を使用すると、3 つのコントローラーノードがノード node00、node01、および node02 に、3 つのコンピュートノードがノード node04、node05、および node06 に、それぞれプロビジョニングされます。

   - name: Controller
     count: 3
     instances:
     - hostname: overcloud-controller-0
       name: node00
     - hostname: overcloud-controller-1
       name: node01
     - hostname: overcloud-controller-2
       name: node02
   - name: Compute
     count: 3
     instances:
     - hostname: overcloud-novacompute-0
       name: node04
     - hostname: overcloud-novacompute-1
       name: node05
     - hostname: overcloud-novacompute-2
       name: node06

   デフォルトでは、プロビジョニングプロセスには overcloud-full イメージが使用されます。instances パラメーターで image 属性を使用して、カスタムイメージを定義することができます。

   - name: Controller
     count: 3
     instances:
     - hostname: overcloud-controller-0
       name: node00
       image:
         href: overcloud-custom

   ノードエントリーごとに手動でノードを定義するのを避けるために、defaults パラメーターでデフォルトのパラメーター値を上書きすることもできます。

   - name: Controller
     count: 3
     defaults:
       image:
         href: overcloud-custom
     instances:
     - hostname :overcloud-controller-0
       name: node00
     - hostname: overcloud-controller-1
       name: node01
     - hostname: overcloud-controller-2
       name: node02

   ノード定義ファイルで使用できるパラメーター、属性、および値の詳細は、Bare metal node provisioning attributes を参照してください。

4. ~/overcloud-baremetal-deploy.yaml ファイルを指定し、--output オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。

   (undercloud)$ openstack overcloud node provision \
   --stack stack \
   --output ~/overcloud-baremetal-deployed.yaml \
   ~/overcloud-baremetal-deploy.yaml

   プロビジョニングプロセスにより、--output オプションで指定する名前の heat 環境ファイルが生成されます。このファイルには、ノード定義が含まれます。オーバークラウドをデプロイする際に、このファイルをデプロイメントコマンドに追加します。

5. 別のターミナルでノードをモニタリングし、プロビジョニングが正常に行われていることを確認します。プロビジョニングプロセスでは、ノードの状態が available から active に変わります。

   (undercloud)$ watch openstack baremetal node list

   metalsmith ツールを使用して、割り当てや neutron ポートなどを含むノードの統合ビューを取得します。

   (undercloud)$ metalsmith list

   openstack baremetal allocation コマンドを使用して、ノードのホスト名への関連付けを確認することもできます。

   (undercloud)$ openstack baremetal allocation list

手順

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

   $ source ~/stackrc

2. ベアメタルノードのプロビジョニングに使用した ~/overcloud-baremetal-deploy.yaml ファイルを編集し、スケールアップするロールの count パラメーターを増やします。たとえば、オーバークラウドにコンピュートノードが 3 つある場合に、以下のスニペットを使用してコンピュートノード数を 10 に増やします。

   - name: Controller
     count: 3
   - name: Compute
     count: 10

   instances パラメーターを使用して、予測可能なノード配置を追加することもできます。使用可能なパラメーターと属性の詳細は、Bare metal node provisioning attributes を参照してください。

3. ~/overcloud-baremetal-deploy.yaml ファイルを指定し、--output オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。

   (undercloud)$ openstack overcloud node provision \
   --stack stack \
   --output ~/overcloud-baremetal-deployed.yaml \
   ~/overcloud-baremetal-deploy.yaml

4. openstack baremetal node list コマンドを使用して、プロビジョニングの進捗をモニタリングします。

5. デプロイメントに該当するその他の環境ファイルと共に、プロビジョニングコマンドによって生成される ~/overcloud-baremetal-deployed.yaml ファイルを指定して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy \
     ...
     -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
     -e ~/overcloud-baremetal-deployed.yaml \
     --deployed-server \
     --disable-validations \
     ...

手順

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

   $ source ~/stackrc

2. ベアメタルノードのプロビジョニングに使用した ~/overcloud-baremetal-deploy.yaml ファイルを編集し、スケールダウンするロールの count パラメーターを減らします。また、スタックから削除するノードごとに以下の属性を定義する必要もあります。

   • ノードの名前
   • ノードに関連付けられたホスト名

   • provisioned: false 属性

     たとえば、スタックからノード overcloud-controller-1 を削除するには、~/overcloud-baremetal-deploy.yaml ファイルに以下のスニペットを追加します。

     - name: Controller
       count: 2
       instances:
       - hostname: overcloud-controller-0
         name: node00
       - hostname: overcloud-controller-1
         name: node01
         # Removed from cluster due to disk failure
         provisioned: false
       - hostname: overcloud-controller-2
         name: node02

3. ~/overcloud-baremetal-deploy.yaml ファイルを指定し、--output オプションで出力ファイルを定義して、プロビジョニングコマンドを実行します。

   (undercloud)$ openstack overcloud node provision \
   --stack stack \
   --output ~/overcloud-baremetal-deployed.yaml \
   ~/overcloud-baremetal-deploy.yaml

4. デプロイメントに該当するその他の環境ファイルと共に、プロビジョニングコマンドによって生成される ~/overcloud-baremetal-deployed.yaml ファイルを指定して、オーバークラウドを再デプロイします。

   (undercloud)$ openstack overcloud deploy \
     ...
     -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
     -e ~/overcloud-baremetal-deployed.yaml \
     --deployed-server \
     --disable-validations \
     ...

   オーバークラウドの再デプロイ後、provisioned: false 属性で定義したノードがスタックには存在しなくなります。ただし、これらのノードは provisioned の状態で稼働したままです。

   注記

   スタックから一時的にノードを削除する場合は、オーバークラウドを属性 provisioned: false でデプロイしてから属性 provisioned: true で再デプロイすることで、ノードをスタックに戻すことができます。

5. --baremetal-deployment オプションで ~/overcloud-baremetal-deploy.yaml ファイルを指定して、openstack overcloud node delete コマンドを実行します。

   (undercloud)$ openstack overcloud node delete \
   --stack stack \
   --baremetal-deployment ~/overcloud-baremetal-deploy.yaml

   注記

   スタックから削除するノードを、openstack overcloud node delete コマンドのコマンド引数に含めないでください。

手順

1. 各オーバークラウドノードで、stack ユーザーを作成して、それぞれにパスワードを設定します。コントローラーノードで、以下の例に示すコマンドを実行します。

   [root@controller-0 ~]# useradd stack
   [root@controller-0 ~]# passwd stack  # specify a password

2. sudo を使用する際に、このユーザーがパスワードを要求されないようにします。

   [root@controller-0 ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
   [root@controller-0 ~]# chmod 0440 /etc/sudoers.d/stack

3. 事前にプロビジョニングされた全ノードで stack ユーザーの作成と設定を行った後に、director ノードから各オーバークラウドノードに stack ユーザーの公開 SSH 鍵をコピーします。director の公開 SSH 鍵をコントローラーノードにコピーするには、以下の例に示すコマンドを実行します。

   [stack@director ~]$ ssh-copy-id stack@192.168.24.2

手順

1. 登録コマンドを実行して、プロンプトが表示されたらカスタマーポータルのユーザー名とパスワードを入力します。

   [heat-admin@controller-0 ~]$ sudo subscription-manager register

2. Red Hat OpenStack Platform 16.1 のエンタイトルメントプールを検索します。

   [heat-admin@controller-0 ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"

3. 上記のステップで特定したプール ID を使用して、Red Hat OpenStack Platform 16 のエンタイトルメントをアタッチします。

   [heat-admin@controller-0 ~]$ sudo subscription-manager attach --pool=pool_id

4. デフォルトのリポジトリーをすべて無効にします。

   [heat-admin@controller-0 ~]$ sudo subscription-manager repos --disable=*

5. 必要な Red Hat Enterprise Linux リポジトリーを有効にします。

   1. x86_64 システムの場合は、以下のコマンドを実行します。

      [heat-admin@controller-0 ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms --enable=advanced-virt-for-rhel-8-x86_64-rpms

   2. POWER システムの場合は、以下のコマンドを実行します。

      [heat-admin@controller-0 ~]$ sudo subscription-manager repos --enable=rhel-8-for-ppc64le-baseos-rpms --enable=rhel-8-for-ppc64le-appstream-rpms --enable=rhel-8-for-ppc64le-highavailability-rpms --enable=ansible-2.8-for-rhel-8-ppc64le-rpms --enable=openstack-16-for-rhel-8-ppc64le-rpms --enable=fast-datapath-for-rhel-8-ppc64le-rpms

6. container-tools リポジトリーモジュールをバージョン 2.0 に設定します。

   [heat-admin@controller-0 ~]$ sudo dnf module disable -y container-tools:rhel8
   [heat-admin@controller-0 ~]$ sudo dnf module enable -y container-tools:2.0

7. オーバークラウドで Ceph Storage ノードを使用する場合は、該当する Ceph Storage リポジトリーを有効にします。

   [heat-admin@cephstorage-0 ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-highavailability-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.1-deployment-tools-for-rhel-8-x86_64-rpms

8. dnf update を実行する前に、各ノードを Red Hat Enterprise Linux 8.2 にロックします。

   [heat-admin@controller-0 ~]$ sudo subscription-manager release --set=8.2

9. システムを更新して、ベースシステムパッケージが最新の状態になるようにします。

   [heat-admin@controller-0 ~]$ sudo dnf update -y
   [heat-admin@controller-0 ~]$ sudo reboot

手順

1. 事前にプロビジョニングされた各ノードの /etc/pki/ca-trust/source/anchors/ ディレクトリーに認証局ファイルをコピーします。

2. 各オーバークラウドノード上で以下のコマンドを実行します。

   [root@controller-0 ~]#  sudo update-ca-trust extract

1. 割り当ての名前。形式は <node_hostname>-<network> です。ここで、<node_hostname> の値はノードの短縮ホスト名で、<network> はネットワークの小文字を使用した名前です。たとえば、controller-0.example.com であれば controller-0-ctlplane となり、compute-0.example.com の場合は compute-0-ctlplane となります。

2. 以下のパラメーターパターンを使用する IP 割り当て

   • fixed_ips/ip_address: コントロールプレーンの固定 IP アドレスを定義します。複数の IP アドレスを定義する場合には、複数の ip_address パラメーターをリストで指定してください。
   • subnets/cidr: サブネットの CIDR 値を定義します。

手順

1. 環境ファイル (たとえば hostname-map.yaml) を作成して、HostnameMap パラメーターとホスト名のマッピングを指定します。以下の構文を使用してください。

   parameter_defaults:
     HostnameMap:
       [HEAT HOSTNAME]: [ACTUAL HOSTNAME]
       [HEAT HOSTNAME]: [ACTUAL HOSTNAME]

   [HEAT HOSTNAME] は通常 [STACK NAME]-[ROLE]-[INDEX] の表記法に従います。

   parameter_defaults:
     HostnameMap:
       overcloud-controller-0: controller-00-rack01
       overcloud-controller-1: controller-01-rack02
       overcloud-controller-2: controller-02-rack03
       overcloud-novacompute-0: compute-00-rack01
       overcloud-novacompute-1: compute-01-rack01
       overcloud-novacompute-2: compute-02-rack01

2. hostname-map.yaml ファイルを保存します。

手順

1. 事前にプロビジョニングされた各ノードにログインします。

2. /etc/os-net-config/mapping.yaml ファイルを作成し、インターフェイスマッピングの詳細を含めます。

   interface_mapping:
     nic1: em1
     nic2: em2

1. アンダークラウドホストで環境変数 OVERCLOUD_HOSTS を作成し、変数に Ceph クライアントとして使用するオーバークラウドホストの IP アドレスのスペース区切りリストを設定します。

   export OVERCLOUD_HOSTS="192.168.1.8 192.168.1.42"

2. デフォルトのオーバークラウドプランの名前は overcloud です。別の名前を使用する場合は、環境変数 OVERCLOUD_PLAN を作成してカスタムの名前を保存します。

   export OVERCLOUD_PLAN="<custom-stack-name>"

   • <custom-stack-name> を実際のスタックの名前に置き換えます。

3. enable-ssh-admin.sh スクリプトを実行して、Ansible が Ceph クライアントの設定に使用することのできるオーバークラウドノードのユーザーを設定します。

   bash /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh

1. 「事前にプロビジョニングされたノードの要件」の説明に従って、事前にプロビジョニングされたノードを新たに準備します。
2. ノードをスケールアップします。詳細は、16章オーバークラウドノードのスケーリング を参照してください。
3. デプロイメントコマンドを実行した後に、director が新しいノードリソースを作成して設定を開始するまで待ちます。

1. 削除するノードの名前を特定します。

   $ openstack stack resource list overcloud -n5 --filter type=OS::TripleO::ComputeDeployedServerServer

2. 対応するノード名を stack_name 列から openstack overcloud node delete コマンドに渡します。

   $ openstack overcloud node delete --stack <overcloud> <stack>

   • <overcloud> は、オーバークラウドスタックの名前または UUID に置き換えてください。
   • <stack_name> を削除するノードの名前に置き換えます。openstack overcloud node delete コマンドに複数のノード名を含めることができます。

3. openstack overcloud node delete コマンドが完全に終了したことを確認します。

   $ openstack stack list

   削除の操作が完了すると、オーバークラウド スタックのステータスは UPDATE_COMPLETE と表示されます。

手順

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

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. デプロイする追加のオーバークラウド用に、新たなディレクトリーを作成します。

   (undercloud)$ mkdir ~/overcloud-two

4. network_data.yaml ファイルを既存のオーバークラウドから追加のオーバークラウド用の新しいディレクトリーにコピーします。

   (undercloud)$ cp network_data.yaml ~/overcloud-two/network_data.yaml

5. ~/overcloud-two/network_data.yaml ファイルを開き、name_lower を追加のオーバークラウドネットワークの一意の名前に更新します。

   - name: InternalApi
     name_lower: internal_api_cloud_2
     ...

6. まだ存在しない場合は service_net_map_replace を追加し、値を追加のオーバークラウドネットワークのデフォルト値に設定します。

   - name: InternalApi
     name_lower: internal_api_cloud_2
     service_net_map_replace: internal_api

7. 追加のオーバークラウドの各サブネットに VLAN ID を指定します。

   - name: InternalApi
     ...
     vip: true
     vlan: 21
     ip_subnet: '172.21.0.0/24'
     allocation_pools: [{'start': '172.21.0.4', 'end': '172.21.0.250'}]
     ipv6_subnet: 'fd00:fd00:fd00:2001::/64'
     ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2001::10', 'end': 'fd00:fd00:fd00:2001:ffff:ffff:ffff:fffe'}]
     mtu: 1500
   - name: Storage
     ...

8. overcloud-two 外部ネットワークのゲートウェイの IP アドレスを指定します。

   - name: External
     ...
     gateway_ip: <ip_address>
     ...

   • <ip_address> を overcloud-two 外部ネットワークのゲートウェイの IP アドレス (例: 10.0.10.1) に置き換えます。
9. /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml ファイル (例: network_overrides.yaml) で提供されるデフォルトの隔離されたネットワーク設定をオーバーライドする、追加のオーバークラウド用のネットワーク設定ファイルを作成します。

10. ~/overcloud-two/network_overrides.yaml ファイルを開き、overcloud-two DNS サーバーの IP アドレスを追加します。

    parameter_defaults:
      ...
      DnsServers:
        - <ip_address>
      ...

    • <ip_address> を overcloud-two DNS サーバーの IP アドレス (例: 10.0.10.2) に置き換えます。

11. デプロイメントで予測可能な IP アドレスを使用する場合は、新しいネットワーク IP アドレスマッピングファイル ips-from-pool-overcloud-two.yaml で overcloud-two ノードの IP アドレスを設定します。

    parameter_defaults:
      ControllerIPs:
      ...
        internal_api_cloud_2:
        - 192.168.1.10
        - 192.168.1.11
        - 192.168.1.12
        ...
        external_cloud_2:
        - 10.0.1.41
        ...

12. overcloud-two 環境ファイルを他の環境ファイルと一緒にスタックに追加し、追加のオーバークラウドをデプロイします。

    (undercloud)$ openstack overcloud deploy --templates \
      --stack overcloud-two \
      -n ~/overcloud-two/network_data.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
      -e ~/overcloud-two/network_overrides.yaml \
      -e [your environment files] \
      ...

    デプロイメントプロセスにより、overcloud-two とやり取りして管理するための overcloud-tworc が作成されます。

13. 追加のオーバークラウドと対話するには、オーバークラウド認証情報ファイルを入手します。

    $ source overcloud-tworc

手順

1. stackrc ファイルを取得します。

   $ source ~/stackrc

2. デプロイメントステータスの確認コマンドを実行します。

   $ openstack overcloud status

   このコマンドの出力に、オーバークラウドのステータスが表示されます。

   +-----------+---------------------+---------------------+-------------------+
   | Plan Name |       Created       |       Updated       | Deployment Status |
   +-----------+---------------------+---------------------+-------------------+
   | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 |   DEPLOY_SUCCESS  |
   +-----------+---------------------+---------------------+-------------------+

   実際のオーバークラウドに別の名前が使用されている場合には、--plan 引数を使用してその名前のオーバークラウドを選択します。

   $ openstack overcloud status --plan my-deployment

手順

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

   $ source ~/overcloudrc

2. openstack flavor create コマンドを実行してフレーバーを作成します。以下のオプションを使用して、各フレーバーのハードウェア要件を指定します。

   --disk

   仮想マシンのボリュームのハードディスク容量を定義します。

   --ram

   仮想マシンに必要な RAM を定義します。

   --vcpus

   仮想マシンの仮想 CPU 数を定義します。

3. デフォルトのオーバークラウドフレーバー作成の例を以下に示します。

   $ openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1
   $ openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1
   $ openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1
   $ openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2
   $ openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4
   $ openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8

手順

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

   $ source ~/overcloudrc

2. デフォルトの Tenant ネットワークを作成します。

   (overcloud) $ openstack network create default

3. ネットワーク上にサブネットを作成します。

   (overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16

4. 作成したネットワークを確認します。

   (overcloud) $ openstack network list
   +-----------------------+-------------+--------------------------------------+
   | id                    | name        | subnets                              |
   +-----------------------+-------------+--------------------------------------+
   | 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
   +-----------------------+-------------+--------------------------------------+

手順

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

   $ source ~/overcloudrc

2. public ネットワークを作成します。

   • ネイティブ VLAN 接続用に flat ネットワークを作成します。

     (overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre

   • 非ネイティブ VLAN 接続用に vlan ネットワークを作成します。

     (overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201

     --provider-segment オプションを使用して、使用する VLAN を定義します。この例では、VLAN は 201 です。

3. Floating IP アドレスの割り当てプールを使用してサブネットを作成します。以下の例では、IP 範囲は 10.1.1.51 から 10.1.1.250 までです。

   (overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

   この範囲が、External ネットワークの他の IP アドレスと競合しないようにしてください。

手順

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

   $ source ~/overcloudrc

2. provider ネットワークを作成します。

   • ネイティブ VLAN 接続用に flat ネットワークを作成します。

     (overcloud) $ openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --share

   • 非ネイティブ VLAN 接続用に vlan ネットワークを作成します。

     (overcloud) $ openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --share

     --provider-segment オプションを使用して、使用する VLAN を定義します。この例では、VLAN は 201 です。

   例に示すこれらのコマンドにより、共有ネットワークが作成されます。テナントだけが新しいネットワークにアクセスするように、--share を指定する代わりにテナントを指定することも可能です。

   プロバイダーネットワークを外部としてマークした場合には、そのネットワークでポートを作成できるのはオペレーターのみとなります。

3. provider ネットワークにサブネットを追加して、DHCP サービスを提供します。

   (overcloud) $ openstack subnet create provider-subnet --network  provider --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24

4. 他のネットワークがプロバイダーネットワークを通じてトラフィックをルーティングできるように、ルーターを作成します。

   (overcloud) $ openstack router create external

5. ルーターの外部ゲートウェイを provider ネットワークに設定します。

   (overcloud) $ openstack router set --external-gateway provider external

6. このルーターに他のネットワークを接続します。たとえば、以下のコマンドを実行してサブネット subnet1 をルーターに割り当てます。

   (overcloud) $ openstack router add subnet external subnet1

   このコマンドにより、subnet1 がルーティングテーブルに追加され、subnet1 を使用する仮想マシンからのトラフィックをプロバイダーネットワークにルーティングできるようになります。

手順

1. アンダークラウドからこのテストを実行する場合は、アンダークラウドのホストがオーバークラウドの Internal API ネットワークにアクセスできるようにします。たとえば、172.16.0.201/24 のアドレスを使用して Internal API ネットワーク (ID: 201) にアクセスするにはアンダークラウドホストに一時的な VLAN を追加します。

   $ source ~/stackrc
   (undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
   (undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201

2. OpenStack Integration Test Suite Guide の説明に従って、統合テストを実施します。

3. 検証が完了したら、オーバークラウドの Internal API への一時接続を削除します。この例では、以下のコマンドを使用して、以前にアンダークラウドで作成した VLAN を削除します。

   $ source ~/stackrc
   (undercloud) $ sudo ovs-vsctl del-port vlan201

手順

1. prevent-stack-delete.yaml という名前の環境ファイルを作成します。

2. HeatApiPolicies パラメーターを設定します。

   parameter_defaults:
     HeatApiPolicies:
       heat-deny-action:
         key: 'actions:action'
         value: 'rule:deny_everybody'
       heat-protect-overcloud:
         key: 'stacks:delete'
         value: 'rule:deny_everybody'

   重要

   heat-deny-action は、アンダークラウドのインストールに追加する必要のあるデフォルトポリシーです。

3. undercloud.conf ファイルの custom_env_files パラメーターに、prevent-stack-delete.yaml 環境ファイルを追加します。

   custom_env_files = prevent-stack-delete.yaml

4. アンダークラウドのインストールコマンドを実行して設定をリフレッシュします。

   $ openstack undercloud install

手順

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

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

   $ source ~/stackrc

3. アクセスするノードの名前を確認します。

   (undercloud) $ openstack server list

4. ノードに heat-admin ユーザーとして接続し、ノードの短縮ホスト名を使用します。

   (undercloud) $ ssh heat-admin@overcloud-controller-0.ctlplane

手順

1. 既存の OpenStack 環境において、実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。

   $ openstack server image create instance_name --name image_name
   $ openstack image save image_name --file exported_vm.qcow2

2. エクスポートしたイメージをアンダークラウドノードにコピーします。

   $ scp exported_vm.qcow2 stack@192.168.0.2:~/.

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

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

   $ source ~/overcloudrc

5. エクスポートしたイメージをオーバークラウドにアップロードします。

   (overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare

6. 新規インスタンスを起動します。

   (overcloud) $ openstack server create  imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id

手順

1. ノードの動的インベントリーを表示するには、stackrc を読み込んだ後に tripleo-ansible-inventory コマンドを実行します。

   $ source ~/stackrc
   (undercloud) $ tripleo-ansible-inventory --list

   --list オプションを使用すると、全ホストの詳細が返されます。このコマンドにより、動的インベントリーが JSON 形式で出力されます。

   {"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.168.24.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.168.24.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.168.24.3"]}

2. お使いの環境で Ansible のPlaybookを実行するには、ansible コマンドを実行し、-i オプションを使用して動的インベントリーツールの完全パスを追加します。以下に例を示します。

   (undercloud) $ ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]

   • [HOSTS] を使用するホストの種別に置き換えてください。

     • 全コントローラーノードの場合には controller
     • 全コンピュートノードの場合には compute
     • オーバークラウドの全子ノードの場合には overcloud(たとえば、コントローラー ノードおよび コンピュート ノードの場合)
     • アンダークラウドの場合には undercloud
     • 全ノードの場合には "*"

   • [OTHER OPTIONS] を追加の Ansible オプションに置き換えてください。

     • ホストキーの確認を省略するには、--ssh-extra-args='-o StrictHostKeyChecking=no' オプションを使用します。
     • Ansible の自動化を実行する SSH ユーザーを変更するには、-u [USER] オプションを使用します。オーバークラウドのデフォルトの SSH ユーザーは、動的インベントリーの ansible_ssh_user パラメーターで自動的に定義されます。-u オプションは、このパラメーターより優先されます。
     • 特定の Ansible モジュールを使用するには、-m [MODULE] オプションを使用します。デフォルトは command で Linux コマンドを実行します。
     • 選択したモジュールの引数を定義するには、-a [MODULE_ARGS] オプションを使用します。

手順

1. 既存のオーバークラウドを削除します。

   $ source ~/stackrc
   (undercloud) $ openstack overcloud delete overcloud

2. openstack stack list コマンドの出力にオーバークラウドが表示されなくなったことを確認します。

   (undercloud) $ openstack stack list

   削除には、数分かかります。

3. 削除が完了したら、デプロイメントシナリオの標準ステップに従って、オーバークラウドを再度作成します。

手順

1. アンダークラウドの stack ユーザーに /var/lib/mistral ディレクトリーのファイルへのアクセス権限を付与するには、setfacl コマンドを使用します。

   $ sudo setfacl -R -m u:stack:rwx /var/lib/mistral
   $ sudo chmod -R og-rwx /var/lib/mistral/.ssh

   このコマンドを実行しても、mistral ユーザーのディレクトリーへのアクセス権限は維持されます。

手順

1. less コマンドを使用して、config-download の作業ディレクトリー内のログを表示します。以下の例では、overcloud 作業ディレクトリーが使われています。

   $ less /var/lib/mistral/overcloud/ansible.log

手順

1. オーバークラウドに関する config-download の作業ディレクトリーに移動します。この例の作業ディレクトリーは、overcloud という名前のオーバークラウド用です。

   $ cd /var/lib/mistral/overcloud

2. git log コマンドを実行して、作業ディレクトリー内のコミットのリストを表示します。ログの出力に日付が表示されるようにフォーマットを設定することもできます。

   $ git log --format=format:"%h%x09%cd%x09"
   a7e9063 Mon Oct 8 21:17:52 2018 +1000
   dfb9d12 Fri Oct 5 20:23:44 2018 +1000
   d0a910b Wed Oct 3 19:30:16 2018 +1000
   ...

   デフォルトでは、最新のコミットから順に表示されます。

3. 2 つのコミットのハッシュに対して git diff コマンドを実行し、デプロイメント間の違いをすべて表示します。

   $ git diff a7e9063 dfb9d12

手順

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

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. デプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...

4. デプロイメントプロセスが完了するまで待ちます。

手順

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

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. --stack-only オプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --stack-only

4. プロビジョニングプロセスが完了するまで待ちます。

5. tripleo-admin ユーザーによるアンダークラウドからオーバークラウドへの SSH アクセスを有効にします。config-download プロセスでは、tripleo-admin ユーザーを使用して Ansible ベースの設定を実施します。

   $ openstack overcloud admin authorize

6. ノードで手動の事前設定タスクを実行します。設定に Ansible を使用する場合は、tripleo-admin ユーザーを使用してノードにアクセスします。

7. --config-download-only オプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --config-download-only

8. 設定プロセスが完了するまで待ちます。

手順

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

2. Ansible Playbook のディレクトリーに移動します。

   $ cd /var/lib/mistral/overcloud/

3. /var/lib/mistral/.ssh ディレクトリーの所有者を stack ユーザーに変更します。

   $ sudo chown stack. -R /var/lib/mistral/.ssh/

4. ansible-playbook-command.sh コマンドを実行して、オーバークラウドの設定を実行します。

   $ sudo ./ansible-playbook-command.sh

5. /var/lib/mistral/.ssh ディレクトリーの所有者を mistral ユーザーに変更します。これは、mistral_executor コンテナー内で実行されている ansible-playbook コマンドが正常に実行されるようにするために必要です。

   $ sudo chown 42430:42430 -R /var/lib/mistral/.ssh/

6. mistral ユーザーとしてスクリプトを再実行します。

   このスクリプトには追加の Ansible 引数を渡すことができ、それらの引数は、そのまま ansible-playbook コマンドに渡されます。つまり、チェックモード (--check)、ホストの限定 (--limit)、変数のオーバーライド (-e) など、他の Ansible 機能を使用することができます。以下に例を示します。

   $ ./ansible-playbook-command.sh --limit Controller

   警告

   --limit を使用して大規模にデプロイする場合、実行に含まれるホストのみがノード全体の SSH known_hosts ファイルに追加されます。したがって、ライブマイグレーションなどの一部の操作は、known_hosts ファイルにないノード間では機能しない場合があります。

7. 設定プロセスが完了するまで待ちます。

手順

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

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. --stack-only オプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。

   $ openstack overcloud deploy \
     --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --stack-only

4. プロビジョニングプロセスが完了するまで待ちます。

5. tripleo-admin ユーザーによるアンダークラウドからオーバークラウドへの SSH アクセスを有効にします。config-download プロセスでは、tripleo-admin ユーザーを使用して Ansible ベースの設定を実施します。

   $ openstack overcloud admin authorize

6. config-download ファイルを生成します。

   $ openstack overcloud config download \
     --name overcloud \
     --config-dir ~/config-download

   • --name は、Ansible ファイルのエクスポートに使用するオーバークラウドの名前です。
   • --config-dir は、config-download ファイルを保存する場所です。

7. config-download ファイルが含まれるディレクトリーに移動します。

   $ cd ~/config-download

8. 静的なインベントリーファイルを生成します。

   $ tripleo-ansible-inventory \
     --stack <overcloud> \
     --ansible_ssh_user heat-admin \
     --static-yaml-inventory inventory.yaml

   • <overcloud> を実際のオーバークラウドの名前に置き換えてください。

9. config-download ファイルおよび静的なインベントリーファイルを使用して、設定を実施します。デプロイメント用の Playbook を実行するには、ansible-playbook コマンドを実行します。

   $ ansible-playbook \
     -i inventory.yaml \
     -e gather_facts=true \
     -e @global_vars.yaml \
     --private-key ~/.ssh/id_rsa \
     --become \
     ~/config-download/deploy_steps_playbook.yaml

10. 設定プロセスが完了するまで待ちます。

11. この設定から手動で overcloudrc ファイルを生成するには、以下のコマンドを実行します。

    $ openstack action execution run \
      --save-result \
      --run-sync \
      tripleo.deployment.overcloudrc \
      '{"container":"overcloud"}' \
      | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3

12. デプロイメントステータスを手動で success に設定します。

    $ openstack workflow execution create tripleo.deployment.v1.set_deployment_status_success '{"plan": "<OVERCLOUD>"}'

    • <OVERCLOUD> を実際のオーバークラウドの名前に置き換えてください。