手順

1. openstack namespace を作成します。

   $ oc new-project openstack

2. https://catalog.redhat.com/software/containers/search から最新の osp-director-operator-bundle イメージを取得します。
3. Operator Package Manager (opm) ツールを https://console.redhat.com/openshift/downloads からダウンロードします。

4. opm ツールを使用してインデックスイメージを作成します。

   $ BUNDLE_IMG="registry.redhat.io/rhosp-rhel8/osp-director-operator-bundle@sha256:c19099ac3340d364307a43e0ae2be949a588fefe8fcb17663049342e7587f055"
   $ INDEX_IMG="quay.io/<account>/osp-director-operator-index:x.y.z-a"
   $ opm index add --bundles ${BUNDLE_IMG} --tag ${INDEX_IMG} -u podman --pull-tool podman

5. インデックスイメージをレジストリーにプッシュします。

   $ podman push ${INDEX_IMG}

6. osp-director-operator.yaml という名前のファイルを作成し、3 つのリソースを設定して director Operator をインストールするように設定するための以下の YAML コンテンツを追加します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: osp-director-operator-index
     namespace: openstack
   spec:
     sourceType: grpc
     image: quay.io/<account>/osp-director-operator-index:x.y.z-a 1
   ---
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: "osp-director-operator-group"
     namespace: openstack
   spec:
     targetNamespaces:
     - openstack
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: osp-director-operator-subscription
     namespace: openstack
   spec:
     config:
       env:
       - name: WATCH_NAMESPACE
         value: openstack,openshift-machine-api,openshift-sriov-network-operator
     source: osp-director-operator-index
     sourceNamespace: openstack
     name: osp-director-operator

   1

   Operator デプロイメントがイメージをプルできるように Quay 認証を適用する方法の詳細は、プライベートレジストリーから Operator のイメージにアクセスする を参照してください。

7. openstack namespace 内に 3 つの新規リソースを作成します。

   $ oc apply -f osp-director-operator.yaml

検証

1. director Operator が正常にインストールされていることを確認します。

   $ oc get operators
   NAME                                     AGE
   osp-director-operator.openstack          5m

1. openstacknetconfig CRD を使用して、コントロールプレーンと分離されたネットワークを含むオーバークラウドネットワークを作成します。
2. ConfigMap を作成して、オーバークラウド用のカスタム heat テンプレートおよび環境ファイルを保存します。
3. コントローラーノード用の 3 つの仮想マシンと、クライアント操作を実行するための Pod を含むコントロールプレーンを作成します。
4. ベアメタルの Compute ノードを作成します。
5. オーバークラウド設定用の Ansible Playbook をレンダリングするための openstackconfiggenerator を作成します。
6. openstackdeploy を使用して、Ansible Playbook 設定をオーバークラウドノードに適用します。

手順

1. access.redhat.com からダウンロードしたデフォルトの QCOW2 イメージでは、biosdev の予測可能なネットワークインターフェイス名は使用されません。biosdev の予測可能なネットワークインターフェイス名を使用するように、virt-customize でイメージを変更します。

   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(kernelopts=.*\)net.ifnames=0 \(.*\)/\1\2/" /boot/grub2/grubenv'
   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(GRUB_CMDLINE_LINUX=.*\)net.ifnames=0 \(.*\)/\1\2/" /etc/default/grub' --truncate /etc/machine-id

2. virtctl でイメージを OpenShift Virtualization にアップロードします。

   $ virtctl image-upload dv <datavolume_name> -n openstack \
    --size=<size> --image-path=<local_path_to_image> \
    --storage-class <storage_class> --access-mode <access_mode> --insecure

   • <datavolume_name> をデータボリュームの名前 (例: openstack-base-img) に置き換えます。
   • <size> を、環境に必要なデータボリュームのサイズ (たとえば、50Gi) に置き換えます。最小サイズは 50GB です。

   • <storage_class> をクラスターの必要なストレージクラスに置き換えます。次のコマンドを使用して、利用可能なストレージクラスを取得します。

     $ oc get storageclass

   • <access_mode> を、PVC のアクセスモードに置き換えます。デフォルト値は ReadWriteOnce です。

3. OpenStackControlPlane リソースおよび個別の OpenStackVmSet リソースの作成時に、baseImageVolumeName パラメーターをデータボリューム名に設定します。

   ...
   spec:
     ...
     baseImageVolumeName: openstack-base-img
   ...

手順

1. Secret リソースを作成します。

   $ oc create secret generic git-secret -n openstack --from-file=git_ssh_identity=<path_to_private_SSH_key> --from-literal=git_url=<git_server_URL>

   git-secret Secret リソースには、2 つのキーと値のペアが含まれます。

   git_ssh_identity

   Git リポジトリーにアクセスするための秘密鍵--from-file オプションは、SSH 秘密鍵ファイルの内容を保存します。

   git_url

   設定を保存する git リポジトリーの SSH URL。--from-literal オプションは、このキーに入力した URL を保存します。

検証

1. Secret リソースを表示します。

   $ oc get secret/git-secret -n openstack

手順

1. 選択したパスワードを base64 値に変換します。

   $ echo -n "p@ssw0rd!" | base64
   cEBzc3cwcmQh

   注記

   -n オプションは、echo 出力から末尾の改行を削除します。

2. ワークステーションに openstack-userpassword.yaml という名前のファイルを作成します。ファイルに、Secret の以下のリソース仕様を追加します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: userpassword
     namespace: openstack
   data:
     NodeRootPassword: "cEBzc3cwcmQh"

   NodeRootPassword パラメーターを base64 でエンコードされたパスワードに設定します。

3. userpassword シークレットを作成します。

   $ oc create -f openstack-userpassword.yaml -n openstack

手順

1. ワークステーション上に osnetconfig.yaml という名前のファイルを作成します。ctlplane という名前のコントロールプレーンネットワークのリソース仕様を含めます。たとえば、各ワーカーノードの enp6s0 イーサネットデバイスに接続された Linux ブリッジを使用するコントロールプレーンの仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.100
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     # optional: configure static mapping for the networks per nodes. If there is none, a random gets created
     reservations:
       controller-0:
         ipReservations:
           ctlplane: 172.22.0.120
       compute-0:
         ipReservations:
           ctlplane: 172.22.0.140

   ネットワーク仕様で次の値を設定します。

   name

   コントロールプレーンネットワークの名 (Control) を設定します。

   nameLower

   コントロールプレーンネットワークの下位の名前 (ctlplane) を設定します。

   subnets

   サブネットの仕様を設定します。

   subnets.name

   コントロールプレーンサブネットの名前 (ctlplane) を設定します。

   subnets.attachConfiguration

   どのアタッチ設定を使用するかの参照を設定します。

   subnets.ipv4

   allocationStart、allocationEnd、cidr、ゲートウェイ、オプションのルートリスト (宛先と nexthop を含む) を含む ipv4 サブネットの詳細

   このセクションで使用できる値の詳細は、openstacknetconfig CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstacknetconfig

   ネットワーク仕様の設定が完了したら、ファイルを保存します。

2. コントロールプレーンネットワークを作成します。

   $ oc create -f osnetconfig.yaml -n openstack

検証

1. コントロールプレーンネットワークのリソースを表示します。

   $ oc get openstacknetconfig/openstacknetconfig

手順

1. ネットワーク設定用のファイルを作成します。VLAN ネットワークのリソース仕様を含めます。たとえば、各ワーカーノードの enp6s0 および enp7s0 イーサネットデバイスに接続された Linux ブリッジ br-ex および br-osp を介して VLAN タグ付きトラフィックを管理する内部 API、ストレージ、ストレージ管理、テナント、および外部ネットワークの仕様は次のとおりです。:

   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 172.22.0.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.10
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         attachConfiguration: br-osp
         vlan: 20
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1500
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
         vlan: 30
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1500
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
         vlan: 40
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1500
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
         vlan: 50
         attachConfiguration: br-osp

   linux-bridge でネットワーク分離に VLAN を使用する場合に、以下のような処理が行われます。

   • director Operator は、リソースに指定されたブリッジインターフェイスの Node Network Configuration Policy を作成します。このポリシーは、nmstate を使用してワーカーノードにブリッジを設定します。
   • director Operator は、Multus CNI プラグイン設定を定義するネットワークごとにネットワーク接続定義を作成します。ネットワーク接続定義で VLAN ID を指定する場合には、Multus CNI プラグインはブリッジで vlan-filtering を有効にします。
   • director Operator は、仮想マシン上の各ネットワーク専用のインターフェイスを割り当てます。これは、OpenStackVMSet のネットワークテンプレートがマルチ NIC ネットワークテンプレートであることを意味します。

   リソース仕様に以下の値を設定します。

   metadata.name

   OpenStackNetConfig の名前に設定します。

   spec

   ネットワークを接続するためのネットワーク設定とネットワークの詳細を設定します。このセクションで使用できる値の詳細は、openstacknetconfig CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstacknetconfig

   ネットワーク仕様の設定が完了したら、ファイルを保存します。

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

   $ oc apply -f openstacknetconfig.yaml -n openstack

検証

1. OpenStackNetConfig API と作成された子リソースを表示します。

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

   エラーが表示された場合は、基礎となる network-attach-definition とノードのネットワーク設定ポリシーを確認してください。

   $ oc get network-attachment-definitions -n openstack
   $ oc get nncp

手順

1. カスタムテンプレートの場所に移動します。

   $ cd ~/custom_templates

2. テンプレートを tarball にアーカイブします。

   $ tar -cvzf custom-config.tar.gz *.yaml

3. tripleo-tarball-config ConfigMap を作成し、tarball をデータとして使用します。

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

検証

1. ConfigMap を表示します。

   $ oc get configmap/tripleo-tarball-config -n openstack

手順

1. heat-env-config ConfigMap を作成し、環境ファイルが含まれるディレクトリーをデータとして使用します。

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

検証

1. ConfigMap を表示します。

   $ oc get configmap/heat-env-config -n openstack

手順

1. ワークステーションに openstack-controller.yaml という名前のファイルを作成します。コントローラーノードのリソース仕様を含めます。たとえば、3 つのコントローラーノードで設定されるコントロールプレーンの仕様は以下のとおりです。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: overcloud
     namespace: openstack
   spec:
     openStackClientNetworks:
           - ctlplane
           - internal_api
           - external
     openStackClientStorageClass: host-nfs-storageclass
     passwordSecret: userpassword
     virtualMachineRoles:
       Controller:
         roleName: Controller
         roleCount: 3
         networks:
           - ctlplane
           - internal_api
           - external
           - tenant
           - storage
           - storage_mgmt
         cores: 12
         memory: 64
         rootDisk:
           diskSize: 100
           baseImageVolumeName: openstack-base-img
           # storageClass must support RWX to be able to live migrate VMs
           storageClass: host-nfs-storageclass
           storageAccessMode:  ReadWriteMany
           # When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
           # specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks.
           # With virtual machine disks, RBD block mode volumes are more efficient and provide better
           # performance than Ceph FS or RBD filesystem-mode PVCs.
           # To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and
           # VolumeMode: Block.
           storageVolumeMode: Filesystem
         # optional configure additional discs to be attached to the VMs,
         # need to be configured manually inside the VMs where to be used.
         additionalDisks:
           - name: datadisk
             diskSize: 500
             storageClass: host-nfs-storageclass
             storageAccessMode:  ReadWriteMany
             storageVolumeMode: Filesystem
     openStackRelease: "16.2"

   リソース仕様に以下の値を設定します。

   metadata.name

   オーバークラウドコントロールプレーンの名前を overcloud に設定します。

   metadata.namespace

   director Operator namespace を openstack に設定します。

   spec

   コントロールプレーンの設定を指定します。このセクションで使用できる値の詳細は、openstackcontrolplane CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackcontrolplane

   コントロールプレーンの仕様の設定が完了したら、ファイルを保存します。

2. コントロールプレーンを作成します。

   $ oc create -f openstack-controller.yaml -n openstack

   OCP が OpenStackControlPlane リソースに関連するリソースを作成するまで待機します。

   director Operator は、OpenStackControlPlane リソースの一部として、リモートシェルからアクセスして RHOSP コマンドを実行できる OpenStackClient Pod も作成します。

検証

1. コントロールプレーンのリソースを表示します。

   $ oc get openstackcontrolplane/overcloud -n openstack

2. OpenStackVMSet リソースを表示して、コントロールプレーンの仮想マシンセットの作成を確認します。

   $ oc get openstackvmsets -n openstack

3. 仮想マシンリソースを表示し、OpenShift Virtualization でのコントロールプレーンの仮想マシンの作成を確認します。

   $ oc get virtualmachines

4. openstackclient リモートシェルにアクセスできるかをテストします。

   $ oc rsh -n openstack openstackclient

手順

1. ワークステーションに openstack-provision.yaml という名前のファイルを作成します。プロビジョニングサーバーのリソース仕様を含めます。たとえば、特定の RHEL 8.4 QCOW2 イメージを使用する Provisioing サーバーの仕様は次のとおりです。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackProvisionServer
   metadata:
     name: openstack-provision-server
     namespace: openstack
   spec:
     baseImageUrl: http://<source_host>/rhel-guest-image-8.4-992.x86_64.qcow2
     port: 8080

   リソース仕様に以下の値を設定します。

   metadata.name

   OpenStackProvisionServer を識別する名前を設定します。

   metadata.namespace

   director Operator namespace を openstack に設定します。

   spec

   baseImageURL

   Provisioing サーバーの RHEL QCOW2 イメージの初期ソースを設定します。イメージは、サーバーの作成時にこのリモートソースからダウンロードされます。

   port

   デフォルトでは、8080 に設定されています。特定のポート設定に合わせて変更できます。

   このセクションで使用できる値の詳細は、OpenStackProvisionServer CRD のカスタムリソース定義の仕様スキーマを参照してください。

   $ oc describe crd openstackprovisionserver

   Provisioning サーバー仕様の設定が完了したら、ファイルを保存します。

2. Provisioning サーバーを作成します。

   $ oc create -f openstack-provision-server.yaml -n openstack

検証

1. Provisioning サーバーのリソースを表示します。

   $ oc get openstackprovisionserver/openstack-provision-server -n openstack

手順

1. ワークステーションに openstack-compute.yaml という名前のファイルを作成します。Compute ノードのリソース仕様を含めます。たとえば、Compute ノード 1 つの仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: compute
     namespace: openstack
   spec:
     count: 1
     baseImageUrl: http://host/images/rhel-image-8.4.x86_64.qcow2
     deploymentSSHSecret: osp-controlplane-ssh-keys
     # If you manually created an OpenStackProvisionServer, you can use it here,
     # otherwise the director Operator will create one for you (with `baseImageUrl` as the image that it server)
     # to use with this OpenStackBaremetalSet
     # provisionServerName: openstack-provision-server
     ctlplaneInterface: enp2s0
     networks:
       - ctlplane
       - internal_api
       - tenant
       - storage
     roleName: Compute
     passwordSecret: userpassword

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前を overcloud に設定します。

   metadata.namespace

   director Operator namespace を openstack に設定します。

   spec

   Compute ノードの設定を定義します。このセクションで使用できる値の詳細は、openstackbaremetalset CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackbaremetalset

   Compute ノードの仕様の設定が完了したら、ファイルを保存します。

2. Compute ノードを作成します。

   $ oc create -f openstack-compute.yaml -n openstack

検証

1. Compute ノードのリソースを表示します。

   $ oc get openstackbaremetalset/compute -n openstack

2. OpenShift が管理するベアメタルマシンを表示し、Compute ノードの作成を確認します。

   $ oc get baremetalhosts -n openshift-machine-api

手順

1. ワークステーションに openstack-config-generator.yaml という名前のファイルを作成します。リソース仕様を追加して Ansible Playbook を生成します。たとえば、Playbook を生成する仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: default
     namespace: openstack
   spec:
     enableFencing: true
     gitSecret: git-secret
     imageURL: registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
     heatEnvConfigMap: heat-env-config
     # List of heat environment files to include from tripleo-heat-templates/environments
     heatEnvs:
     - ssl/tls-endpoints-public-dns.yaml
     - ssl/enable-tls.yaml
     tarballConfigMap: tripleo-tarball-config

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前に設定します。デフォルトは default です。

   metadata.namespace

   director の Operator の namespace (デフォルトでは openstack) に設定します。

   spec.enableFencing

   フェンシングを有効にするために必要な heat 環境ファイルの自動作成を有効にします。

   注記

   本番 OSP 環境では、フェンシングを有効にする必要があります。pacemaker を実行する仮想マシンには、fence-agents-kubevirt パッケージが必要です。

   spec.gitSecret

   Git 認証の認証情報を含む ConfigMap に設定します (デフォルトでは git-secret)。

   spec.heatEnvs

   Playbook の生成に使用されるデフォルトの Tripleo 環境ファイルのリスト。

   spec.heatEnvConfigMap

   カスタム環境ファイルを含む ConfigMap に設定します (デフォルトは heat-env-config)。

   spec.tarballConfigMap

   カスタムの heat テンプレートを使用して tarball が含まれる ConfigMap (tripleo-tarball-config) に設定します。

   spec セクションで使用できる値の詳細は、openstackconfiggenerator CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackconfiggenerator

   Ansible 設定ジェネレーター仕様の設定が完了したら、ファイルを保存します。

2. Ansible 設定ジェネレーターを作成します。

   $ oc create -f openstack-config-generator.yaml -n openstack

検証

1. 設定ジェネレーターのリソースを表示します。

   $ oc get openstackconfiggenerator/default -n openstack

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. cloud-admin ホームディレクトリーに移動します。

   $ cd /home/cloud-admin

3. ノードを登録する 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-16.2-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 変数でリストされます。

4. 必要なリポジトリーにオーバークラウドノードを登録します。

   ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml

手順

1. 最新の OpenStackConfigVersion の hash/digest を選択します。

   $ oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o json

手順

1. ワークステーションに openstack-deployment.yaml という名前のファイルを作成します。リソース仕様を Ansible Playbook に含めます。以下に例を示します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: default
   spec:
     configVersion: n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h…
     configGenerator: default

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前を設定します。デフォルトは default です。

   metadata.namespace

   デフォルトの openstack で、diretor Operator namespace に設定します。

   spec.configVersion

   デプロイする Playbook の設定バージョン/git ハッシュ。

   spec.configGenerator

   configGenerator の名前。

   spec セクションで使用できる値の詳細は、openstackdeploy CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackdeploy

   OpenStackDeploy 仕様の設定が完了したら、ファイルを保存します。

2. OpenStackDeploy リソースを作成します。

   $ oc create -f openstack-deployment.yaml -n openstack

   デプロイメントが実行すると、Ansible Playbook を実行するための Kubernetes ジョブが作成されます。ジョブのログを追跡して、実行中の Ansible Playbook を確認できます。

   $ oc logs -f jobs/deploy-openstack-default

   さらに、openstackclient Pod にログインすることで、実行された Ansible Playbook に手動でアクセスできます。/home/cloud-admin/work/directory には、現在のデプロイメントの ansible Playbook と ansible.log ファイルがあります。

手順

1. access.redhat.com からダウンロードしたデフォルトの QCOW2 イメージでは、biosdev の予測可能なネットワークインターフェイス名は使用されません。biosdev の予測可能なネットワークインターフェイス名を使用するように、virt-customize でイメージを変更します。

   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(kernelopts=.*\)net.ifnames=0 \(.*\)/\1\2/" /boot/grub2/grubenv'
   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(GRUB_CMDLINE_LINUX=.*\)net.ifnames=0 \(.*\)/\1\2/" /etc/default/grub' --truncate /etc/machine-id

2. virtctl でイメージを OpenShift Virtualization にアップロードします。

   $ virtctl image-upload dv <datavolume_name> -n openstack \
    --size=<size> --image-path=<local_path_to_image> \
    --storage-class <storage_class> --access-mode <access_mode> --insecure

   • <datavolume_name> をデータボリュームの名前 (例: openstack-base-img) に置き換えます。
   • <size> を、環境に必要なデータボリュームのサイズ (たとえば、50Gi) に置き換えます。最小サイズは 50GB です。

   • <storage_class> をクラスターの必要なストレージクラスに置き換えます。次のコマンドを使用して、利用可能なストレージクラスを取得します。

     $ oc get storageclass

   • <access_mode> を、PVC のアクセスモードに置き換えます。デフォルト値は ReadWriteOnce です。

3. OpenStackControlPlane リソースおよび個別の OpenStackVmSet リソースの作成時に、baseImageVolumeName パラメーターをデータボリューム名に設定します。

   ...
   spec:
     ...
     baseImageVolumeName: openstack-base-img
   ...

手順

1. Secret リソースを作成します。

   $ oc create secret generic git-secret -n openstack --from-file=git_ssh_identity=<path_to_private_SSH_key> --from-literal=git_url=<git_server_URL>

   git-secret Secret リソースには、2 つのキーと値のペアが含まれます。

   git_ssh_identity

   Git リポジトリーにアクセスするための秘密鍵--from-file オプションは、SSH 秘密鍵ファイルの内容を保存します。

   git_url

   設定を保存する git リポジトリーの SSH URL。--from-literal オプションは、このキーに入力した URL を保存します。

検証

1. Secret リソースを表示します。

   $ oc get secret/git-secret -n openstack

手順

1. 選択したパスワードを base64 値に変換します。

   $ echo -n "p@ssw0rd!" | base64
   cEBzc3cwcmQh

   注記

   -n オプションは、echo 出力から末尾の改行を削除します。

2. ワークステーションに openstack-userpassword.yaml という名前のファイルを作成します。ファイルに、Secret の以下のリソース仕様を追加します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: userpassword
     namespace: openstack
   data:
     NodeRootPassword: "cEBzc3cwcmQh"

   NodeRootPassword パラメーターを base64 でエンコードされたパスワードに設定します。

3. userpassword シークレットを作成します。

   $ oc create -f openstack-userpassword.yaml -n openstack

手順

1. ワークステーション上に osnetconfig.yaml という名前のファイルを作成します。ctlplane という名前のコントロールプレーンネットワークのリソース仕様を含めます。たとえば、各ワーカーノードの enp6s0 イーサネットデバイスに接続された Linux ブリッジを使用するコントロールプレーンの仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.100
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     # optional: configure static mapping for the networks per nodes. If there is none, a random gets created
     reservations:
       controller-0:
         ipReservations:
           ctlplane: 172.22.0.120
       compute-0:
         ipReservations:
           ctlplane: 172.22.0.140

   ネットワーク仕様で次の値を設定します。

   name

   コントロールプレーンネットワークの名 (Control) を設定します。

   nameLower

   コントロールプレーンネットワークの下位の名前 (ctlplane) を設定します。

   subnets

   サブネットの仕様を設定します。

   subnets.name

   コントロールプレーンサブネットの名前 (ctlplane) を設定します。

   subnets.attachConfiguration

   どのアタッチ設定を使用するかの参照を設定します。

   subnets.ipv4

   allocationStart、allocationEnd、cidr、ゲートウェイ、オプションのルートリスト (宛先と nexthop を含む) を含む ipv4 サブネットの詳細

   このセクションで使用できる値の詳細は、openstacknetconfig CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstacknetconfig

   ネットワーク仕様の設定が完了したら、ファイルを保存します。

2. コントロールプレーンネットワークを作成します。

   $ oc create -f osnetconfig.yaml -n openstack

検証

1. コントロールプレーンネットワークのリソースを表示します。

   $ oc get openstacknetconfig/openstacknetconfig

手順

1. ネットワーク設定用のファイルを作成します。VLAN ネットワークのリソース仕様を含めます。たとえば、各ワーカーノードの enp6s0 および enp7s0 イーサネットデバイスに接続された Linux ブリッジ br-ex および br-osp を介して VLAN タグ付きトラフィックを管理する内部 API、ストレージ、ストレージ管理、テナント、および外部ネットワークの仕様は次のとおりです。:

   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 172.22.0.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.10
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         attachConfiguration: br-osp
         vlan: 20
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1500
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
         vlan: 30
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1500
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
         vlan: 40
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1500
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
         vlan: 50
         attachConfiguration: br-osp

   linux-bridge でネットワーク分離に VLAN を使用する場合に、以下のような処理が行われます。

   • director Operator は、リソースに指定されたブリッジインターフェイスの Node Network Configuration Policy を作成します。このポリシーは、nmstate を使用してワーカーノードにブリッジを設定します。
   • director Operator は、Multus CNI プラグイン設定を定義するネットワークごとにネットワーク接続定義を作成します。ネットワーク接続定義で VLAN ID を指定する場合には、Multus CNI プラグインはブリッジで vlan-filtering を有効にします。
   • director Operator は、仮想マシン上の各ネットワーク専用のインターフェイスを割り当てます。これは、OpenStackVMSet のネットワークテンプレートがマルチ NIC ネットワークテンプレートであることを意味します。

   リソース仕様に以下の値を設定します。

   metadata.name

   OpenStackNetConfig の名前に設定します。

   spec

   ネットワークを接続するためのネットワーク設定とネットワークの詳細を設定します。このセクションで使用できる値の詳細は、openstacknetconfig CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstacknetconfig

   ネットワーク仕様の設定が完了したら、ファイルを保存します。

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

   $ oc apply -f openstacknetconfig.yaml -n openstack

検証

1. OpenStackNetConfig API と作成された子リソースを表示します。

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

   エラーが表示された場合は、基礎となる network-attach-definition とノードのネットワーク設定ポリシーを確認してください。

   $ oc get network-attachment-definitions -n openstack
   $ oc get nncp

手順

1. ワークステーションに openstack-controller.yaml という名前のファイルを作成します。コントローラーノードのリソース仕様を含めます。たとえば、3 つのコントローラーノードで設定されるコントロールプレーンの仕様は以下のとおりです。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: overcloud
     namespace: openstack
   spec:
     openStackClientNetworks:
           - ctlplane
           - internal_api
           - external
     openStackClientStorageClass: host-nfs-storageclass
     passwordSecret: userpassword
     virtualMachineRoles:
       Controller:
         roleName: Controller
         roleCount: 3
         networks:
           - ctlplane
           - internal_api
           - external
           - tenant
           - storage
           - storage_mgmt
         cores: 12
         memory: 64
         rootDisk:
           diskSize: 100
           baseImageVolumeName: openstack-base-img
           # storageClass must support RWX to be able to live migrate VMs
           storageClass: host-nfs-storageclass
           storageAccessMode:  ReadWriteMany
           # When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
           # specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks.
           # With virtual machine disks, RBD block mode volumes are more efficient and provide better
           # performance than Ceph FS or RBD filesystem-mode PVCs.
           # To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and
           # VolumeMode: Block.
           storageVolumeMode: Filesystem
         # optional configure additional discs to be attached to the VMs,
         # need to be configured manually inside the VMs where to be used.
         additionalDisks:
           - name: datadisk
             diskSize: 500
             storageClass: host-nfs-storageclass
             storageAccessMode:  ReadWriteMany
             storageVolumeMode: Filesystem
     openStackRelease: "16.2"

   リソース仕様に以下の値を設定します。

   metadata.name

   オーバークラウドコントロールプレーンの名前を overcloud に設定します。

   metadata.namespace

   director Operator namespace を openstack に設定します。

   spec

   コントロールプレーンの設定を指定します。このセクションで使用できる値の詳細は、openstackcontrolplane CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackcontrolplane

   コントロールプレーンの仕様の設定が完了したら、ファイルを保存します。

2. コントロールプレーンを作成します。

   $ oc create -f openstack-controller.yaml -n openstack

   OCP が OpenStackControlPlane リソースに関連するリソースを作成するまで待機します。

   director Operator は、OpenStackControlPlane リソースの一部として、リモートシェルからアクセスして RHOSP コマンドを実行できる OpenStackClient Pod も作成します。

検証

1. コントロールプレーンのリソースを表示します。

   $ oc get openstackcontrolplane/overcloud -n openstack

2. OpenStackVMSet リソースを表示して、コントロールプレーンの仮想マシンセットの作成を確認します。

   $ oc get openstackvmsets -n openstack

3. 仮想マシンリソースを表示し、OpenShift Virtualization でのコントロールプレーンの仮想マシンの作成を確認します。

   $ oc get virtualmachines

4. openstackclient リモートシェルにアクセスできるかをテストします。

   $ oc rsh -n openstack openstackclient

手順

1. カスタムテンプレートのディレクトリーを作成します。

   $ mkdir custom_templates

2. カスタム環境ファイルのディレクトリーを作成します。

   $ mkdir custom_environment_files

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. OS_CLOUD 環境変数の設定を解除します。

   $ unset OS_CLOUD

3. cloud-admin ディレクトリーに移動します。

   $ cd /home/cloud-admin/

4. Controller ロールおよび ComputeHCI ロールを設定して、新しい roles_data.yaml ファイルを生成します。

   $ openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml

5. openstackclient Pod を終了します。

   $ exit

6. カスタムの roles_data.yaml ファイルを openstackclient Pod からカスタムテンプレートディレクトリーにコピーします。

   $ oc cp openstackclient:/home/cloud-admin/roles_data.yaml custom_templates/roles_data.yaml -n openstack

手順

1. カスタムテンプレートの場所に移動します。

   $ cd ~/custom_templates

2. テンプレートを tarball にアーカイブします。

   $ tar -cvzf custom-config.tar.gz *.yaml

3. tripleo-tarball-config ConfigMap を作成し、tarball をデータとして使用します。

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

検証

1. ConfigMap を表示します。

   $ oc get configmap/tripleo-tarball-config -n openstack

手順

1. heat-env-config ConfigMap を作成し、環境ファイルが含まれるディレクトリーをデータとして使用します。

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

検証

1. ConfigMap を表示します。

   $ oc get configmap/heat-env-config -n openstack

手順

1. ワークステーションに openstack-hcicompute.yaml という名前のファイルを作成します。Compute ノードのリソース仕様を含めます。たとえば、Compute ノード 1 つの仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: computehci
     namespace: openstack
   spec:
     count: 3
     baseImageUrl: http://host/images/rhel-image-8.4.x86_64.qcow2
     deploymentSSHSecret: osp-controlplane-ssh-keys
     ctlplaneInterface: enp8s0
     networks:
       - ctlplane
       - internal_api
       - tenant
       - storage
       - storage_mgmt
     roleName: ComputeHCI
     passwordSecret: userpassword

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前を overcloud に設定します。

   metadata.namespace

   director Operator namespace を openstack に設定します。

   spec

   Compute ノードの設定を定義します。このセクションで使用できる値の詳細は、openstackbaremetalset CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackbaremetalset

   Compute ノードの仕様の設定が完了したら、ファイルを保存します。

2. Compute ノードを作成します。

   $ oc create -f openstack-hcicompute.yaml -n openstack

検証

1. コンピュート HCI ノードのリソースを表示します。

   $ oc get openstackbaremetalset/computehci -n openstack

2. OpenShift が管理するベアメタルマシンを表示して、コンピュート HCI ノードの作成を確認します。

   $ oc get baremetalhosts -n openshift-machine-api

手順

1. ワークステーションに openstack-config-generator.yaml という名前のファイルを作成します。リソース仕様を追加して Ansible Playbook を生成します。たとえば、Playbook を生成する仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: default
     namespace: openstack
   spec:
     enableFencing: true
     gitSecret: git-secret
     imageURL: registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
     heatEnvConfigMap: heat-env-config
     # List of heat environment files to include from tripleo-heat-templates/environments
     heatEnvs:
     - ssl/tls-endpoints-public-dns.yaml
     - ssl/enable-tls.yaml
     tarballConfigMap: tripleo-tarball-config

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前に設定します。デフォルトは default です。

   metadata.namespace

   director の Operator の namespace (デフォルトでは openstack) に設定します。

   spec.enableFencing

   フェンシングを有効にするために必要な heat 環境ファイルの自動作成を有効にします。

   注記

   本番 OSP 環境では、フェンシングを有効にする必要があります。pacemaker を実行する仮想マシンには、fence-agents-kubevirt パッケージが必要です。

   spec.gitSecret

   Git 認証の認証情報を含む ConfigMap に設定します (デフォルトでは git-secret)。

   spec.heatEnvs

   Playbook の生成に使用されるデフォルトの Tripleo 環境ファイルのリスト。

   spec.heatEnvConfigMap

   カスタム環境ファイルを含む ConfigMap に設定します (デフォルトは heat-env-config)。

   spec.tarballConfigMap

   カスタムの heat テンプレートを使用して tarball が含まれる ConfigMap (tripleo-tarball-config) に設定します。

   spec セクションで使用できる値の詳細は、openstackconfiggenerator CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackconfiggenerator

   Ansible 設定ジェネレーター仕様の設定が完了したら、ファイルを保存します。

2. Ansible 設定ジェネレーターを作成します。

   $ oc create -f openstack-config-generator.yaml -n openstack

検証

1. 設定ジェネレーターのリソースを表示します。

   $ oc get openstackconfiggenerator/default -n openstack

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. cloud-admin ホームディレクトリーに移動します。

   $ cd /home/cloud-admin

3. ノードを登録する 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-16.2-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 変数でリストされます。

4. 必要なリポジトリーにオーバークラウドノードを登録します。

   ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml

手順

1. ワークステーションに openstack-deployment.yaml という名前のファイルを作成します。リソース仕様を Ansible Playbook に含めます。以下に例を示します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: default
   spec:
     configVersion: n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h…
     configGenerator: default

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前を設定します。デフォルトは default です。

   metadata.namespace

   デフォルトの openstack で、diretor Operator namespace に設定します。

   spec.configVersion

   デプロイする Playbook の設定バージョン/git ハッシュ。

   spec.configGenerator

   configGenerator の名前。

   spec セクションで使用できる値の詳細は、openstackdeploy CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackdeploy

   OpenStackDeploy 仕様の設定が完了したら、ファイルを保存します。

2. OpenStackDeploy リソースを作成します。

   $ oc create -f openstack-deployment.yaml -n openstack

   デプロイメントが実行すると、Ansible Playbook を実行するための Kubernetes ジョブが作成されます。ジョブのログを追跡して、実行中の Ansible Playbook を確認できます。

   $ oc logs -f jobs/deploy-openstack-default

   さらに、openstackclient Pod にログインすることで、実行された Ansible Playbook に手動でアクセスできます。/home/cloud-admin/work/directory には、現在のデプロイメントの ansible Playbook と ansible.log ファイルがあります。

手順

1. access.redhat.com からダウンロードしたデフォルトの QCOW2 イメージでは、biosdev の予測可能なネットワークインターフェイス名は使用されません。biosdev の予測可能なネットワークインターフェイス名を使用するように、virt-customize でイメージを変更します。

   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(kernelopts=.*\)net.ifnames=0 \(.*\)/\1\2/" /boot/grub2/grubenv'
   $ sudo virt-customize -a <local path to image> --run-command 'sed -i -e "s/^\(GRUB_CMDLINE_LINUX=.*\)net.ifnames=0 \(.*\)/\1\2/" /etc/default/grub' --truncate /etc/machine-id

2. virtctl でイメージを OpenShift Virtualization にアップロードします。

   $ virtctl image-upload dv <datavolume_name> -n openstack \
    --size=<size> --image-path=<local_path_to_image> \
    --storage-class <storage_class> --access-mode <access_mode> --insecure

   • <datavolume_name> をデータボリュームの名前 (例: openstack-base-img) に置き換えます。
   • <size> を、環境に必要なデータボリュームのサイズ (たとえば、50Gi) に置き換えます。最小サイズは 50GB です。

   • <storage_class> をクラスターの必要なストレージクラスに置き換えます。次のコマンドを使用して、利用可能なストレージクラスを取得します。

     $ oc get storageclass

   • <access_mode> を、PVC のアクセスモードに置き換えます。デフォルト値は ReadWriteOnce です。

3. OpenStackControlPlane リソースおよび個別の OpenStackVmSet リソースの作成時に、baseImageVolumeName パラメーターをデータボリューム名に設定します。

   ...
   spec:
     ...
     baseImageVolumeName: openstack-base-img
   ...

手順

1. Secret リソースを作成します。

   $ oc create secret generic git-secret -n openstack --from-file=git_ssh_identity=<path_to_private_SSH_key> --from-literal=git_url=<git_server_URL>

   git-secret Secret リソースには、2 つのキーと値のペアが含まれます。

   git_ssh_identity

   Git リポジトリーにアクセスするための秘密鍵--from-file オプションは、SSH 秘密鍵ファイルの内容を保存します。

   git_url

   設定を保存する git リポジトリーの SSH URL。--from-literal オプションは、このキーに入力した URL を保存します。

検証

1. Secret リソースを表示します。

   $ oc get secret/git-secret -n openstack

手順

1. 選択したパスワードを base64 値に変換します。

   $ echo -n "p@ssw0rd!" | base64
   cEBzc3cwcmQh

   注記

   -n オプションは、echo 出力から末尾の改行を削除します。

2. ワークステーションに openstack-userpassword.yaml という名前のファイルを作成します。ファイルに、Secret の以下のリソース仕様を追加します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: userpassword
     namespace: openstack
   data:
     NodeRootPassword: "cEBzc3cwcmQh"

   NodeRootPassword パラメーターを base64 でエンコードされたパスワードに設定します。

3. userpassword シークレットを作成します。

   $ oc create -f openstack-userpassword.yaml -n openstack

手順

1. ワークステーション上に osnetconfig.yaml という名前のファイルを作成します。ctlplane という名前のコントロールプレーンネットワークのリソース仕様を含めます。たとえば、各ワーカーノードの enp6s0 イーサネットデバイスに接続された Linux ブリッジを使用するコントロールプレーンの仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.100
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     # optional: configure static mapping for the networks per nodes. If there is none, a random gets created
     reservations:
       controller-0:
         ipReservations:
           ctlplane: 172.22.0.120
       compute-0:
         ipReservations:
           ctlplane: 172.22.0.140

   ネットワーク仕様で次の値を設定します。

   name

   コントロールプレーンネットワークの名 (Control) を設定します。

   nameLower

   コントロールプレーンネットワークの下位の名前 (ctlplane) を設定します。

   subnets

   サブネットの仕様を設定します。

   subnets.name

   コントロールプレーンサブネットの名前 (ctlplane) を設定します。

   subnets.attachConfiguration

   どのアタッチ設定を使用するかの参照を設定します。

   subnets.ipv4

   allocationStart、allocationEnd、cidr、ゲートウェイ、オプションのルートリスト (宛先と nexthop を含む) を含む ipv4 サブネットの詳細

   このセクションで使用できる値の詳細は、openstacknetconfig CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstacknetconfig

   ネットワーク仕様の設定が完了したら、ファイルを保存します。

2. コントロールプレーンネットワークを作成します。

   $ oc create -f osnetconfig.yaml -n openstack

検証

1. コントロールプレーンネットワークのリソースを表示します。

   $ oc get openstacknetconfig/openstacknetconfig

手順

1. ネットワーク設定用のファイルを作成します。VLAN ネットワークのリソース仕様を含めます。たとえば、各ワーカーノードの enp6s0 および enp7s0 イーサネットデバイスに接続された Linux ブリッジ br-ex および br-osp を介して VLAN タグ付きトラフィックを管理する内部 API、ストレージ、ストレージ管理、テナント、および外部ネットワークの仕様は次のとおりです。:

   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 172.22.0.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.10
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         attachConfiguration: br-osp
         vlan: 20
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1500
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
         vlan: 30
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1500
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
         vlan: 40
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1500
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
         vlan: 50
         attachConfiguration: br-osp

   linux-bridge でネットワーク分離に VLAN を使用する場合に、以下のような処理が行われます。

   • director Operator は、リソースに指定されたブリッジインターフェイスの Node Network Configuration Policy を作成します。このポリシーは、nmstate を使用してワーカーノードにブリッジを設定します。
   • director Operator は、Multus CNI プラグイン設定を定義するネットワークごとにネットワーク接続定義を作成します。ネットワーク接続定義で VLAN ID を指定する場合には、Multus CNI プラグインはブリッジで vlan-filtering を有効にします。
   • director Operator は、仮想マシン上の各ネットワーク専用のインターフェイスを割り当てます。これは、OpenStackVMSet のネットワークテンプレートがマルチ NIC ネットワークテンプレートであることを意味します。

   リソース仕様に以下の値を設定します。

   metadata.name

   OpenStackNetConfig の名前に設定します。

   spec

   ネットワークを接続するためのネットワーク設定とネットワークの詳細を設定します。このセクションで使用できる値の詳細は、openstacknetconfig CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstacknetconfig

   ネットワーク仕様の設定が完了したら、ファイルを保存します。

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

   $ oc apply -f openstacknetconfig.yaml -n openstack

検証

1. OpenStackNetConfig API と作成された子リソースを表示します。

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

   エラーが表示された場合は、基礎となる network-attach-definition とノードのネットワーク設定ポリシーを確認してください。

   $ oc get network-attachment-definitions -n openstack
   $ oc get nncp

手順

1. ワークステーションに openstack-controller.yaml という名前のファイルを作成します。コントローラーノードのリソース仕様を含めます。たとえば、3 つのコントローラーノードで設定されるコントロールプレーンの仕様は以下のとおりです。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: overcloud
     namespace: openstack
   spec:
     openStackClientNetworks:
           - ctlplane
           - internal_api
           - external
     openStackClientStorageClass: host-nfs-storageclass
     passwordSecret: userpassword
     virtualMachineRoles:
       Controller:
         roleName: Controller
         roleCount: 3
         networks:
           - ctlplane
           - internal_api
           - external
           - tenant
           - storage
           - storage_mgmt
         cores: 12
         memory: 64
         rootDisk:
           diskSize: 100
           baseImageVolumeName: openstack-base-img
           # storageClass must support RWX to be able to live migrate VMs
           storageClass: host-nfs-storageclass
           storageAccessMode:  ReadWriteMany
           # When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
           # specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks.
           # With virtual machine disks, RBD block mode volumes are more efficient and provide better
           # performance than Ceph FS or RBD filesystem-mode PVCs.
           # To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and
           # VolumeMode: Block.
           storageVolumeMode: Filesystem
         # optional configure additional discs to be attached to the VMs,
         # need to be configured manually inside the VMs where to be used.
         additionalDisks:
           - name: datadisk
             diskSize: 500
             storageClass: host-nfs-storageclass
             storageAccessMode:  ReadWriteMany
             storageVolumeMode: Filesystem
     openStackRelease: "16.2"

   リソース仕様に以下の値を設定します。

   metadata.name

   オーバークラウドコントロールプレーンの名前を overcloud に設定します。

   metadata.namespace

   director Operator namespace を openstack に設定します。

   spec

   コントロールプレーンの設定を指定します。このセクションで使用できる値の詳細は、openstackcontrolplane CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackcontrolplane

   コントロールプレーンの仕様の設定が完了したら、ファイルを保存します。

2. コントロールプレーンを作成します。

   $ oc create -f openstack-controller.yaml -n openstack

   OCP が OpenStackControlPlane リソースに関連するリソースを作成するまで待機します。

   director Operator は、OpenStackControlPlane リソースの一部として、リモートシェルからアクセスして RHOSP コマンドを実行できる OpenStackClient Pod も作成します。

検証

1. コントロールプレーンのリソースを表示します。

   $ oc get openstackcontrolplane/overcloud -n openstack

2. OpenStackVMSet リソースを表示して、コントロールプレーンの仮想マシンセットの作成を確認します。

   $ oc get openstackvmsets -n openstack

3. 仮想マシンリソースを表示し、OpenShift Virtualization でのコントロールプレーンの仮想マシンの作成を確認します。

   $ oc get virtualmachines

4. openstackclient リモートシェルにアクセスできるかをテストします。

   $ oc rsh -n openstack openstackclient

手順

1. カスタムテンプレートのディレクトリーを作成します。

   $ mkdir custom_templates

2. カスタム環境ファイルのディレクトリーを作成します。

   $ mkdir custom_environment_files

手順

1. カスタムテンプレートの場所に移動します。

   $ cd ~/custom_templates

2. テンプレートを tarball にアーカイブします。

   $ tar -cvzf custom-config.tar.gz *.yaml

3. tripleo-tarball-config ConfigMap を作成し、tarball をデータとして使用します。

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

検証

1. ConfigMap を表示します。

   $ oc get configmap/tripleo-tarball-config -n openstack

手順

1. heat-env-config ConfigMap を作成し、環境ファイルが含まれるディレクトリーをデータとして使用します。

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

検証

1. ConfigMap を表示します。

   $ oc get configmap/heat-env-config -n openstack

手順

1. ワークステーションに openstack-compute.yaml という名前のファイルを作成します。Compute ノードのリソース仕様を含めます。たとえば、Compute ノード 1 つの仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: compute
     namespace: openstack
   spec:
     count: 1
     baseImageUrl: http://host/images/rhel-image-8.4.x86_64.qcow2
     deploymentSSHSecret: osp-controlplane-ssh-keys
     # If you manually created an OpenStackProvisionServer, you can use it here,
     # otherwise the director Operator will create one for you (with `baseImageUrl` as the image that it server)
     # to use with this OpenStackBaremetalSet
     # provisionServerName: openstack-provision-server
     ctlplaneInterface: enp2s0
     networks:
       - ctlplane
       - internal_api
       - tenant
       - storage
     roleName: Compute
     passwordSecret: userpassword

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前を overcloud に設定します。

   metadata.namespace

   director Operator namespace を openstack に設定します。

   spec

   Compute ノードの設定を定義します。このセクションで使用できる値の詳細は、openstackbaremetalset CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackbaremetalset

   Compute ノードの仕様の設定が完了したら、ファイルを保存します。

2. Compute ノードを作成します。

   $ oc create -f openstack-compute.yaml -n openstack

検証

1. Compute ノードのリソースを表示します。

   $ oc get openstackbaremetalset/compute -n openstack

2. OpenShift が管理するベアメタルマシンを表示し、Compute ノードの作成を確認します。

   $ oc get baremetalhosts -n openshift-machine-api

手順

1. ワークステーションに openstack-config-generator.yaml という名前のファイルを作成します。リソース仕様を追加して Ansible Playbook を生成します。たとえば、Playbook を生成する仕様は以下のようになります。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: default
     namespace: openstack
   spec:
     enableFencing: true
     gitSecret: git-secret
     imageURL: registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
     heatEnvConfigMap: heat-env-config
     # List of heat environment files to include from tripleo-heat-templates/environments
     heatEnvs:
     - ssl/tls-endpoints-public-dns.yaml
     - ssl/enable-tls.yaml
     tarballConfigMap: tripleo-tarball-config

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前に設定します。デフォルトは default です。

   metadata.namespace

   director の Operator の namespace (デフォルトでは openstack) に設定します。

   spec.enableFencing

   フェンシングを有効にするために必要な heat 環境ファイルの自動作成を有効にします。

   注記

   本番 OSP 環境では、フェンシングを有効にする必要があります。pacemaker を実行する仮想マシンには、fence-agents-kubevirt パッケージが必要です。

   spec.gitSecret

   Git 認証の認証情報を含む ConfigMap に設定します (デフォルトでは git-secret)。

   spec.heatEnvs

   Playbook の生成に使用されるデフォルトの Tripleo 環境ファイルのリスト。

   spec.heatEnvConfigMap

   カスタム環境ファイルを含む ConfigMap に設定します (デフォルトは heat-env-config)。

   spec.tarballConfigMap

   カスタムの heat テンプレートを使用して tarball が含まれる ConfigMap (tripleo-tarball-config) に設定します。

   spec セクションで使用できる値の詳細は、openstackconfiggenerator CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackconfiggenerator

   Ansible 設定ジェネレーター仕様の設定が完了したら、ファイルを保存します。

2. Ansible 設定ジェネレーターを作成します。

   $ oc create -f openstack-config-generator.yaml -n openstack

検証

1. 設定ジェネレーターのリソースを表示します。

   $ oc get openstackconfiggenerator/default -n openstack

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. cloud-admin ホームディレクトリーに移動します。

   $ cd /home/cloud-admin

3. ノードを登録する 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-16.2-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 変数でリストされます。

4. 必要なリポジトリーにオーバークラウドノードを登録します。

   ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml

手順

1. ワークステーションに openstack-deployment.yaml という名前のファイルを作成します。リソース仕様を Ansible Playbook に含めます。以下に例を示します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: default
   spec:
     configVersion: n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h…
     configGenerator: default

   リソース仕様に以下の値を設定します。

   metadata.name

   Compute ノードのベアメタルセットの名前を設定します。デフォルトは default です。

   metadata.namespace

   デフォルトの openstack で、diretor Operator namespace に設定します。

   spec.configVersion

   デプロイする Playbook の設定バージョン/git ハッシュ。

   spec.configGenerator

   configGenerator の名前。

   spec セクションで使用できる値の詳細は、openstackdeploy CRD のカスタムリソース定義の仕様スキーマを確認します。

   $ oc describe crd openstackdeploy

   OpenStackDeploy 仕様の設定が完了したら、ファイルを保存します。

2. OpenStackDeploy リソースを作成します。

   $ oc create -f openstack-deployment.yaml -n openstack

   デプロイメントが実行すると、Ansible Playbook を実行するための Kubernetes ジョブが作成されます。ジョブのログを追跡して、実行中の Ansible Playbook を確認できます。

   $ oc logs -f jobs/deploy-openstack-default

   さらに、openstackclient Pod にログインすることで、実行された Ansible Playbook に手動でアクセスできます。/home/cloud-admin/work/directory には、現在のデプロイメントの ansible Playbook と ansible.log ファイルがあります。

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. cloud-admin ホームディレクトリーに移動します。

   $ cd /home/cloud-admin

3. openstack コマンドを実行します。たとえば、以下のコマンドを使用して default ネットワークを作成できます。

   $ openstack network create default

手順

1. オプション: admin ユーザーとしてログインするには、tripleo-passwords シークレットにある AdminPassword パラメーターから admin パスワードを取得します。

   $ oc get secret tripleo-passwords -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' | base64 -d

2. Web ブラウザーを開きます。
3. URL フィールドに、オーバークラウドダッシュボードのホスト名またはパブリック仮想 IP を入力します。
4. 選択したユーザー名とパスワードを使用して Dashboard にログインします。

手順

1. Compute OpenStackBaremetalSet の YAML 設定を変更し、リソースの count パラメーターを増やします。

   $ oc patch osbms compute --type=merge --patch '{"spec":{"count":3}}' -n openstack

2. OpenStackBaremetalSet リソースは、Red Hat Enterprise Linux のベースオペレーティングシステムで新規ノードを自動的にプロビジョニングします。プロビジョニングプロセスが完了するまで待ちます。ノードを定期的にチェックし、ノードの readiness を判別します。

   $ oc get baremetalhosts -n openshift-machine-api
   $ oc get openstackbaremetalset

3. OpenStackConfigGenerator を使用して Ansible Playbook を生成します。director Operator を使用したオーバークラウドソフトウェアの設定 を参照してください。

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. 削除する Compute ノードを特定します。

   $ openstack compute service list

3. ノード上の Compute サービスを無効にして、ノードが新しいインスタンスをスケジュールできないようにします。

   $ openstack compute service set <hostname> nova-compute --disable

4. Metal ³ がノードを起動しないようにベアメタルノードにアノテーションを付けます。

   $ oc annotate baremetalhost <node> baremetalhost.metal3.io/detached=true
   $ oc logs --since=1h <metal3-pod> metal3-baremetal-operator | grep -i detach
   $ oc get baremetalhost <node> -o json | jq .status.operationalStatus
   "detached"

   • <node> を BareMetalHost リソースの名前に置き換えます。
   • <metal3-pod> を metal3 Pod の名前に置き換えます。

5. root ユーザーとして Compute ノードにログインし、ベアメタルノードをシャットダウンします。

   [root@compute-0 ~]# shutdown -h now

   Compute ノードにアクセスできない場合は、次の手順を実行します。

   1. コントローラーノードに root ユーザーとしてログインします。

   2. インスタンス HA が有効になっている場合は、Compute ノードの STONITH デバイスを無効にします。

      [root@controller-0 ~]# pcs stonith disable <stonith_resource_name>

      • <stonith_resource_name> は、ノードに対応する STONITH リソースの名前に置き換えます。リソース名には <resource_agent>-<host_mac> 形式が使用されます。リソースエージェントおよびホストの MAC アドレスは、fencing.yaml ファイルの FencingConfig セクションに記載されています。
   3. IPMI を使用してベアメタルノードの電源をオフにします。詳細は、ハードウェアベンダーのドキュメントを参照してください。

6. 削除するノードに対応する BareMetalHost リソースを取得します。

   $ oc get openstackbaremetalset compute -o json | jq '.status.baremetalHosts | to_entries[] | "\(.key) => \(.value | .hostRef)"'
   "compute-0, openshift-worker-3"
   "compute-1, openshift-worker-4"

7. OpenStackBaremetalSet リソースの annotatedForDeletion パラメーターのステータスを true に変更するには、BareMetalHost リソースに osp-director.openstack.org/delete-host=true のアノテーションを付けます。

   $ oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite

8. オプション: OpenStackBaremetalSet リソースで annotatedForDeletion ステータスが true に変更されたことを確認します。

   $ oc get openstackbaremetalset compute -o json -n openstack | jq .status
   {
     "baremetalHosts": {
       "compute-0": {
         "annotatedForDeletion": true,
         "ctlplaneIP": "192.168.25.105/24",
         "hostRef": "openshift-worker-3",
         "hostname": "compute-0",
         "networkDataSecretName": "compute-cloudinit-networkdata-openshift-worker-3",
         "provisioningState": "provisioned",
         "userDataSecretName": "compute-cloudinit-userdata-openshift-worker-3"
       },
       "compute-1": {
         "annotatedForDeletion": false,
         "ctlplaneIP": "192.168.25.106/24",
         "hostRef": "openshift-worker-4",
         "hostname": "compute-1",
         "networkDataSecretName": "compute-cloudinit-networkdata-openshift-worker-4",
         "provisioningState": "provisioned",
         "userDataSecretName": "compute-cloudinit-userdata-openshift-worker-4"
       }
     },
     "provisioningStatus": {
       "readyCount": 2,
       "reason": "All requested BaremetalHosts have been provisioned",
       "state": "provisioned"
     }
   }

9. compute OpenStackBaremetalSet リソースの count パラメーターを減らします。

   $ oc patch openstackbaremetalset compute --type=merge --patch '{"spec":{"count":1}}' -n openstack

   OpenStackBaremetalSet リソースのリソース数を減らすと、対応するコントローラーがリソースの削除を処理するようトリガーされ、以下のアクションが発生します。

   • director Operator は、ノードの OpenStackIPSet および OpenStackNetConfig から対応する IP 予約を削除します。

   • director Operator は、OpenStackNet リソースの IP 予約エントリーを削除済みとしてフラグします。

     $ oc get osnet ctlplane -o json -n openstack | jq .status.reservations
     {
       "compute-0": {
         "deleted": true,
         "ip": "172.22.0.140"
       },
       "compute-1": {
         "deleted": false,
         "ip": "172.22.0.100"
       },
       "controller-0": {
         "deleted": false,
         "ip": "172.22.0.120"
       },
       "controlplane": {
         "deleted": false,
         "ip": "172.22.0.110"
       },
       "openstackclient-0": {
         "deleted": false,
         "ip": "172.22.0.251"
       }

10. オプション: 削除された OpenStackBaremetalSet リソースの IP 予約を他のロールが使用できるようにするには、OpenStackNetConfig オブジェクトで spec.preserveservations パラメーターの値を false に設定します。

11. openstackclient のリモートシェルにアクセスします。

    $ oc rsh openstackclient -n openstack

12. オーバークラウドから Compute サービスエントリーを削除します。

    $ openstack compute service list
    $ openstack compute service delete <service-id>

13. オーバークラウドの Compute ネットワークエージェントエントリーをチェックして、このようなエントリーが存在する場合は削除します。

    $ openstack network agent list
    $ for AGENT in $(openstack network agent list --host <scaled-down-node> -c ID -f value) ; do openstack network agent delete $AGENT ; done

14. openstackclient を終了します。

    $ exit

手順

1. fencing.yaml という heat パラメーター ConfigMap を変更して、更新中にフェンシングを無効にします。

   parameter_defaults:
     EnableFencing: false

2. osconfiggenerator-update-prepare.yaml という OpenStackConfigGenerator リソースを作成します。

   $ cat <<EOF > osconfiggenerator-update-prepare.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: "update"
     namespace: openstack
   spec:
     gitSecret: git-secret
     heatEnvs:
       - lifecycle/update-prepare.yaml
     heatEnvConfigMap: heat-env-config-update
     tarballConfigMap: tripleo-tarball-config-update
   EOF

3. 設定を適用します。

   $ oc apply -f osconfiggenerator-update-prepare.yaml

4. 更新の準備プロセスが完了するまで待ちます。

手順

1. osdeploy-container-image-prepare.yaml という osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-container-image-prepare.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: container_image_prepare
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - container_image_prepare
   EOF

2. 設定を適用します。

   $ oc apply -f osdeploy-container-image-prepare.yaml

手順

1. osdeploy-ovn-update.yaml という osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-ovn-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ovn-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       tags:
         - ovn
   EOF

2. 設定を適用します。

   $ oc apply -f osdeploy-ovn-update.yaml

3. ovn-controller コンテナーの更新が完了するまで待ちます。

手順

1. osdeploy-controller-update.yaml という osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-controller-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: controller-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: Controller
   EOF

2. 設定を適用します。

   $ oc apply -f osdeploy-controller-update.yaml

3. コントローラーノードの更新が完了するまで待ちます。

手順

1. osdeploy-compute-update.yaml という osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-compute-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: compute-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: Compute
   EOF

2. 設定を適用します。

   $ oc apply -f osdeploy-compute-update.yaml

3. Compute ノードの更新が完了するまで待ちます。

手順

1. osdeploy-computehci-update.yaml という osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-computehci-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: computehci-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: ComputeHCI
   EOF

2. 設定を適用します。

   $ oc apply -f osdeploy-computehci-update.yaml

3. ComputeHCI ノードの更新が完了するまで待ちます。

4. osdeploy-ceph-update.yaml という osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-ceph-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ceph-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - ceph
   EOF

5. 設定を適用します。

   $ oc apply -f osdeploy-ceph-update.yaml

6. Red Hat Ceph Storage ノードの更新が完了するまで待ちます。

手順

1. osdeploy-cephstorage-update.yaml という osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-cephstorage-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: cephstorage-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: CephStorage
   EOF

2. 設定を適用します。

   $ oc apply -f osdeploy-cephstorage-update.yaml

3. Red Hat Ceph Storage ノードの更新が完了するまで待ちます。

4. osdeploy-ceph-update.yaml という osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-ceph-update.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ceph-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - ceph
   EOF

5. 設定を適用します。

   $ oc apply -f osdeploy-ceph-update.yaml

6. Red Hat Ceph Storage ノードの更新が完了するまで待ちます。

手順

1. osdeploy-online-migration.yaml という名前の osdeploy ジョブを作成します。

   $ cat <<EOF > osdeploy-online-migration.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: online-migration
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - online_upgrade
   EOF

2. 設定を適用します。

   $ oc apply -f osdeploy-online-migration.yaml

手順

1. fencing.yaml 環境ファイルでフェンシングを再度有効にします。

   parameter_defaults:
     EnableFencing: true

2. デフォルト設定を再生成して、lifecycle/update-prepare.yaml が heatEnvs に含まれていないことを確認します。詳細は、director Operator を使用したオーバークラウドソフトウェアの設定 を参照してください。

3. OpenStackConfigGenerator、ConfigVersion、および設定デプロイメントリソースを削除します。

   $ oc delete <type> <name>

   • <type> を、削除するリソースのタイプに置き換えます。
   • <name> を、削除するリソースの名前に置き換えます。
4. 更新の最終処理が完了するまで待ちます。

手順

1. CA 証明書を格納するための ConfigMap を作成します。ConfigMap は、OpenStackControlPlane オブジェクトを使用して CA 証明書を openstackclient Pod に追加するために使用されるインターフェイスです。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cacerts
     namespace: openstack
   data:
    local_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----
     another_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----

2. OpenStackControlPlane を作成し、ConfigMap を参照します。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: <overcloud>
     namespace: openstack
   spec:
     caConfigMap: cacerts

   • <overcloud> をスタックの名前に置き換えます。

3. ~/custom_environment_files ディレクトリーで、SSLCertificate、SSLIntermediateCertificate、SSLKey、および CAMap パラメーターを使用して、デプロイ用に生成された証明書を含む tls-certs.yaml というファイルを作成します。

   注記

   証明書ファイルの作成の詳細は、SSL/TLS の有効化 を参照してください。

4. heatEnvConfigMap を更新して tls-certs.yaml ファイルを追加します。

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

5. OpenStackConfigGenerator を作成し、必要な heatEnvs 設定ファイルを追加して、パブリックエンドポイント IP の TLS を設定します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   …
   spec:
     …
     heatEnvs:
       - ssl/tls-endpoints-public-ip.yaml
       - ssl/enable-tls.yaml
     …
     heatEnvConfigMap: heat-env-config
     tarballConfigMap: tripleo-tarball-config

6. OpenStackConfigGenerator と新しい OpenStackConfigVersion が作成され、OpenStackDeploy リソースを使用してオーバークラウドに対して Ansible Playbook を実行します。

   • オーバークラウドのオペレーティングシステムの登録
   • 最新の OpenStackConfig バージョンを入手します。
   • director Operator を使用したオーバークラウドの設定の適用

手順

1. CA 証明書を格納するための ConfigMap を作成します。ConfigMap は、OpenStackControlPlane オブジェクトを使用して、追加の CA 証明書を openstackclient Pod に追加するために使用されるインターフェイスです。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cacerts
     namespace: openstack
   data:
    local_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----
     another_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----

2. OpenStackControlPlane を作成し、ConfigMap を参照します。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: <overcloud>
     namespace: openstack
   spec:
     caConfigMap: cacerts

   • <overcloud> をスタックの名前に置き換えます。

3. ~/custom_environment_files ディレクトリーで、SSLCertificate、SSLIntermediateCertificate、SSLKey、および CAMap パラメーターを使用して、デプロイ用に生成された証明書を含む tls-certs.yaml というファイルを作成します。

   注記

   証明書ファイルの作成の詳細は、SSL/TLS の有効化 を参照してください。

4. heatEnvConfigMap を更新して tls-certs.yaml ファイルを追加します。

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

5. OpenStackConfigGenerator を作成し、必要な heatEnvs 設定ファイルを追加して、パブリックエンドポイント DNS 名の TLS を設定します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   …
   spec:
     …
     heatEnvs:
       - ssl/tls-endpoints-public-dns.yaml
       - ssl/enable-tls.yaml
     …
     heatEnvConfigMap: heat-env-config
     tarballConfigMap: tripleo-tarball-config

6. OpenStackConfigGenerator と新しい OpenStackConfigVersion が作成され、OpenStackDeploy リソースを使用してオーバークラウドに対して Ansible Playbook を実行します。

   • オーバークラウドのオペレーティングシステムの登録
   • 最新の OpenStackConfig バージョンを入手します。
   • director Operator を使用したオーバークラウドの設定の適用

手順

1. 現在の Tripleo-passwords シークレットのバックアップを作成します。

   $ oc get secret tripleo-passwords -n openstack -o yaml > tripleo-passwords_backup.yaml

2. Tripleo-overcloud-passwords_preserve_list という名前のプレインテキストファイルを作成して、次のサービスのパスワードをローテーションしないように指定します。

   parameter_defaults
   BarbicanSimpleCryptoKek
   KeystoneCredential0
   KeystoneCredential1
   KeystoneFernetKey0
   KeystoneFernetKey1
   KeystoneFernetKeys
   CephClientKey
   CephClusterFSID
   CephManilaClientKey
   CephRgwKey
   HeatAuthEncryptionKey
   MysqlClustercheckPassword
   MysqlMariabackupPassword
   PacemakerRemoteAuthkey
   PcsdPassword

   パスワードを保持したいサービスが他にもある場合は、そのサービスをリストに追加できます。

3. 変更すべきでないパスワードをリストするためのパスワードパラメーターファイル (Tripleo-overcloud-passwords.yaml) を作成します。

   $ oc get secret tripleo-passwords -n openstack \
   -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' \
   | base64 -d | grep -f ./tripleo-overcloud-passwords_preserve_list > tripleo-overcloud-passwords.yaml

4. Tripleo-overcloud-passwords.yaml ファイルに、ローテーションしないパスワードが含まれていることを検証します。

5. tripleo-password シークレットを更新します。

   $ oc create secret generic tripleo-passwords -n openstack \
   --from-file=./tripleo-overcloud-passwords.yaml \
   --dry-run=client -o yaml | oc apply -f -

6. Ansible Playbook を作成し、OpenStackConfigGenerator CRD を使用してオーバークラウドを設定します。詳細は、OpenStackConfigGenerator CRD を使用したオーバークラウド設定用の Ansible Playbook の作成 を参照してください。
7. 更新された設定を適用します。詳細は、director Operator を使用したオーバークラウド設定の適用 を参照してください。

1. 更新されたシークレットからパスワードを取得します。

   $ oc get secret tripleo-passwords -n openstack -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' | base64 -d | grep NovaPassword

   出力例:

   NovaPassword: hp4xpt7t2p79ktqjjnxpqwbp6

2. コントローラーノード上で稼働している Compute サービス (nova) のパスワードを取得します。

   1. openstackclient リモートシェルにアクセスします。

      $ oc rsh openstackclient -n openstack

   2. ホームディレクトリーにいることを確認します。

      $ cd

   3. Compute サービスのパスワードを取得します。

      $ ansible -i /home/cloud-admin/ctlplane-ansible-inventory Controller -b -a "grep ^connection /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf"

      出力例:

      172.22.0.120 | CHANGED | rc=0 >> connection=mysql+pymysql://nova_api:hp4xpt7t2p79ktqjjnxpqwbp6@172.17.0.10/nova_api?read_default_file=/etc/my.cnf.d/tripleo.cnf&read_default_group=tripleo connection=mysql+pymysql://nova:hp4xpt7t2p79ktqjjnxpqwbp6@172.17.0.10/nova?read_default_file=/etc/my.cnf.d/tripleo.cnf&read_default_group=tripleo

手順

1. openstacknetconfig.yaml という設定ファイルを作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 192.168.25.250
           allocationStart: 192.168.25.100
           cidr: 192.168.25.0/24
           gateway: 192.168.25.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
           routes:
           - destination: 172.17.1.0/24
             nexthop: 172.17.0.1
           - destination: 172.17.2.0/24
             nexthop: 172.17.0.1
         vlan: 20
         attachConfiguration: br-osp
       - name: internal_api_leaf1
         ipv4:
           allocationEnd: 172.17.1.250
           allocationStart: 172.17.1.10
           cidr: 172.17.1.0/24
           routes:
           - destination: 172.17.0.0/24
             nexthop: 172.17.1.1
           - destination: 172.17.2.0/24
             nexthop: 172.17.1.1
         vlan: 21
         attachConfiguration: br-osp
       - name: internal_api_leaf2
         ipv4:
           allocationEnd: 172.17.2.250
           allocationStart: 172.17.2.10
           cidr: 172.17.2.0/24
           routes:
           - destination: 172.17.1.0/24
             nexthop: 172.17.2.1
           - destination: 172.17.0.0/24
             nexthop: 172.17.2.1
         vlan: 22
         attachConfiguration: br-osp
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1350
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
           routes:
           - destination: 172.18.1.0/24
             nexthop: 172.18.0.1
           - destination: 172.18.2.0/24
             nexthop: 172.18.0.1
         vlan: 30
         attachConfiguration: br-osp
       - name: storage_leaf1
         ipv4:
           allocationEnd: 172.18.1.250
           allocationStart: 172.18.1.10
           cidr: 172.18.1.0/24
           routes:
           - destination: 172.18.0.0/24
             nexthop: 172.18.1.1
           - destination: 172.18.2.0/24
             nexthop: 172.18.1.1
         vlan: 31
         attachConfiguration: br-osp
       - name: storage_leaf2
         ipv4:
           allocationEnd: 172.18.2.250
           allocationStart: 172.18.2.10
           cidr: 172.18.2.0/24
           routes:
           - destination: 172.18.0.0/24
             nexthop: 172.18.2.1
           - destination: 172.18.1.0/24
             nexthop: 172.18.2.1
         vlan: 32
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1350
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
           routes:
           - destination: 172.19.1.0/24
             nexthop: 172.19.0.1
           - destination: 172.19.2.0/24
             nexthop: 172.19.0.1
         vlan: 40
         attachConfiguration: br-osp
       - name: storage_mgmt_leaf1
         ipv4:
           allocationEnd: 172.19.1.250
           allocationStart: 172.19.1.10
           cidr: 172.19.1.0/24
           routes:
           - destination: 172.19.0.0/24
             nexthop: 172.19.1.1
           - destination: 172.19.2.0/24
             nexthop: 172.19.1.1
         vlan: 41
         attachConfiguration: br-osp
       - name: storage_mgmt_leaf2
         ipv4:
           allocationEnd: 172.19.2.250
           allocationStart: 172.19.2.10
           cidr: 172.19.2.0/24
           routes:
           - destination: 172.19.0.0/24
             nexthop: 172.19.2.1
           - destination: 172.19.1.0/24
             nexthop: 172.19.2.1
         vlan: 42
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1350
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
           routes:
           - destination: 172.20.1.0/24
             nexthop: 172.20.0.1
           - destination: 172.20.2.0/24
             nexthop: 172.20.0.1
         vlan: 50
         attachConfiguration: br-osp
       - name: tenant_leaf1
         ipv4:
           allocationEnd: 172.20.1.250
           allocationStart: 172.20.1.10
           cidr: 172.20.1.0/24
           routes:
           - destination: 172.20.0.0/24
             nexthop: 172.20.1.1
           - destination: 172.20.2.0/24
             nexthop: 172.20.1.1
         vlan: 51
         attachConfiguration: br-osp
       - name: tenant_leaf2
         ipv4:
           allocationEnd: 172.20.2.250
           allocationStart: 172.20.2.10
           cidr: 172.20.2.0/24
           routes:
           - destination: 172.20.0.0/24
             nexthop: 172.20.2.1
           - destination: 172.20.1.0/24
             nexthop: 172.20.2.1
         vlan: 52
         attachConfiguration: br-osp

2. 内部 API ネットワークを作成します。

   $ oc create -f openstacknetconfig.yaml -n openstack

検証

1. OpenStackNetConfig のリソースと子リソースを表示します。

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

手順

1. roles_data.yaml ファイルを更新します。

   ...
   ###############################################################################
   # Role: ComputeLeaf1                                                          #
   ###############################################################################
   - name: ComputeLeaf1
     description: |
       Basic ComputeLeaf1 Node role
     # Create external Neutron bridge (unset if using ML2/OVS without DVR)
     tags:
       - external_bridge
     networks:
       InternalApi:
         subnet: internal_api_leaf1
       Tenant:
         subnet: tenant_leaf1
       Storage:
         subnet: storage_leaf1
     HostnameFormatDefault: '%stackname%-novacompute-leaf1-%index%'
   ...
   ###############################################################################
   # Role: ComputeLeaf2                                                          #
   ###############################################################################
   - name: ComputeLeaf2
     description: |
       Basic ComputeLeaf1 Node role
     # Create external Neutron bridge (unset if using ML2/OVS without DVR)
     tags:
       - external_bridge
     networks:
       InternalApi:
         subnet: internal_api_leaf2
       Tenant:
         subnet: tenant_leaf2
       Storage:
         subnet: storage_leaf2
     HostnameFormatDefault: '%stackname%-novacompute-leaf2-%index%'
   ...

2. ~/custom_environment_files ディレクトリーで、テンプレートを tarball にアーカイブします。

   $ tar -cvzf custom-config.tar.gz *.yaml

3. tripleo-tarball-config ConfigMap を作成します。

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

手順

1. OpenStackBackupRequest CRD を作成し、mode を save に設定してバックアップをリクエストします。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBackupRequest
   metadata:
     name: openstackbackupsave
     namespace: openstack
   spec:
     mode: save
     additionalConfigMaps: []
     additionalSecrets: []

2. オプション: additionalConfigMaps および additionalSecrets 仕様を使用して、手動で作成した ConfigMaps またはシークレットを含めます。

3. OpenStackBackupRequest のステータスをモニターします。

   $ oc get -n openstack osbackuprequest openstackbackupsave
   NAME                     OPERATION   SOURCE   STATUS      COMPLETION TIMESTAMP
   openstackbackupsave      save                 Quiescing

   注記

   Quiescing 状態は、director Operator が CR が終了状態に達するのを待っていることを示します。バックアップが完了するまでの時間は、CR の数によって異なります。

4. director Operator ログを調査して、進行状況を確認できます。

   $ oc logs <operator_pod> -c manager -f
   2022-01-11T18:26:15.180Z        INFO    controllers.OpenStackBackupRequest      Quiesce for save for OpenStackBackupRequest openstackbackupsave is waiting for: [OpenStackBaremetalSet: compute, OpenStackControlPlane: overcloud, OpenStackVMSet: controller]

   • <operator_pod> を Operator Pod の名前に置き換えます。

検証

1. OpenStackBackupRequest を表示して、STATUS が Saved であることを確認します。

   $ oc get -n openstack osbackuprequest
   NAME                     OPERATION   SOURCE   STATUS   COMPLETION TIMESTAMP
   openstackbackupsave      save                 Saved    2022-01-11T19:12:58Z

2. OpenStackBackupRequest が Error 状態になった場合は、リクエストの内容を確認してエラーを見つけます。

   $ oc get -n openstack openstackbackuprequest <request_name> -o yaml

   • <request_name> をバックアップ要求の名前に置き換えます。

3. OpenStackBackup を表示して、存在することを確認します。

   $ oc get -n openstack osbackup
   
   NAME                                AGE
   openstackbackupsave-1641928378      6m7s

手順

1. 利用可能なバックアップを一覧表示します。

   $ oc get osbackup

   注記

   特定のバックアップの詳細を調べるには:

   $ oc get backup <name> -o yaml

   • <name> を検査するバックアップの名前に置き換えます。

2. OpenStackBackupRequest CRD を作成し、mode を restore に設定します。以下に例を示します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBackupRequest
   metadata:
     name: openstackbackupsave
     namespace: openstack
   spec:
     mode: <mode>
     restoreSource: <restore_source>

   • <mode> を次のいずれかのオプションに置き換えます。

     • restore - 既存の OpenStackBackup からの復元をリクエストします。
     • cleanRestore - 復元を試みる前に、namespace 内の既存の director Operator リソースを完全に消去します。
   • <restore_source> を復元する OpenStackBackup の ID に置き換えます (例: openstackbackupsave-1641928378)。

3. OpenStackBackupRequest のステータスをモニターします。

   $ oc get -n openstack osbackuprequest openstackbackuprestore
   NAME                     OPERATION  SOURCE                           STATUS     COMPLETION TIMESTAMP
   openstackbackuprestore   restore    openstackbackupsave-1641928378   Loading

   すべてのリソースがロードされた後、director Operator は調整を開始します。

   $ oc get -n openstack osbackuprequest openstackbackuprestore
   NAME                     OPERATION  SOURCE                           STATUS       COMPLETION TIMESTAMP
   openstackbackuprestore   restore    openstackbackupsave-1641928378   Reconciling

   注記

   OpenStackBackupRequest がエラー状態になった場合は、リクエストの内容を表示してエラーを見つけます。

   $ oc get -n openstack openstackbackuprequest <name> -o yaml

検証

1. OpenStackBackupRequest を表示して、STATUS が Restored であることを確認します。

   $ oc get -n openstack osbackuprequest
   NAME                     OPERATION  SOURCE                           STATUS     COMPLETION TIMESTAMP
   openstackbackuprestore   restore    openstackbackupsave-1641928378   Restored   2022-01-12T13:48:57Z

手順

1. Controller virtualMachineRole コアの数を 8 に変更します。

   $ oc patch -n openstack osctlplane overcloud --type='json' -p='[{"op": "add", "path": "/spec/virtualMachineRoles/controller/cores", "value": 8 }]'

2. コントローラーの virtualMachineRole RAM サイズを 22GB に変更します。

   $ oc patch -n openstack osctlplane overcloud --type='json' -p='[{"op": "add", "path": "/spec/virtualMachineRoles/controller/memory", "value": 22 }]'

3. virtualMachineRole リソースを検証します。

   $ oc get osvmset
   NAME         CORES   RAM   DESIRED   READY   STATUS        REASON
   controller   8       22    1         1       Provisioned   All requested VirtualMachines have been provisioned

4. 仮想マシンの内部から、正常なシャットダウンを実行します。更新された各仮想マシンを 1 つずつシャットダウンします。

5. 仮想マシンをパワーオンします。

   $ `virtctl start <VM>` to power on the virtual machine.

   • <VM> を 仮想マシンの名前に置き換えます。

手順

1. OpenStackControlPlane オブジェクトで additionalDisks パラメーターを追加または更新します。

   spec:
     ...
     virtualMachineRoles:
       Controller:
         ...
         additionalDisks:
         - baseImageVolumeName: openstack-base-img
           dedicatedIOThread: false
           diskSize: 10
           name: "data-disk1"
           storageAccessMode: ReadWriteMany
           storageClass: host-nfs-storageclass
           storageVolumeMode: Filesystem

2. パッチを適用します。

   $ oc patch -n openstack osctlplane overcloud --patch-file controller_add_data_disk1.yaml

3. virtualMachineRole リソースを検証します。

   $ oc get osvmset controller -o json | jq .spec.additionalDisks
   [
     {
       "baseImageVolumeName": "openstack-base-img",
       "dedicatedIOThread": false,
       "diskSize": 10,
       "name": "data-disk1",
       "storageAccessMode": "ReadWriteMany",
       "storageClass": "host-nfs-storageclass",
       "storageVolumeMode": "Filesystem"
     }
   ]

4. 仮想マシンの内部から、正常なシャットダウンを実行します。更新された各仮想マシンを 1 つずつシャットダウンします。

5. 仮想マシンをパワーオンします。

   $ `virtctl start <VM>` to power on the virtual machine.

   • <VM> を 仮想マシンの名前に置き換えます。

手順

1. openstack namespace を作成します。

   $ oc new-project openstack

2. インデックスイメージを作成し、レジストリーにプッシュします。

   $ podman login registry.redhat.io
   $ podman login your.registry.local
   $ BUNDLE_IMG="registry.redhat.io/rhosp-rhel8/osp-director-operator-bundle@sha256:c19099ac3340d364307a43e0ae2be949a588fefe8fcb17663049342e7587f055"

   注記

   最新のバンドルイメージは次の場所から取得できます: Certified container images .osp-director-operator-bundle を検索します。

3. オペレータインデックスイメージに基づいて、関連するイメージをミラーリングします。

   $ oc adm catalog mirror ${INDEX_IMG} your.registry.local --insecure --index-filter-by-os='Linux/x86_64'

4. ミラーリングが完了すると、現在のディレクトリーに manifests-osp-director-operator-index-<random_number> という manifests ディレクトリーが生成されます。作成した ImageContentSourcePolicy をクラスターに適用します。

   $ os apply -f manifests-osp-director-operator-index-<random_number>/imageContentSourcePolicy.yaml

   • <random_number> をランダムに生成された数値に置き換えます。

5. osp-director-operator.yaml という名前のファイルを作成し、次の YAML コンテンツを含めて、director Operator のインストールに必要な 3 つのリソースを設定します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: osp-director-operator-index
     namespace: openstack
   spec:
     sourceType: grpc
     image: your.registry.local/osp-director-operator-index:1.3.x-y
   ---
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: "osp-director-operator-group"
     namespace: openstack
   spec:
     targetNamespaces:
     - openstack
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: osp-director-operator-subscription
     namespace: openstack
   spec:
     config:
       env:
       - name: WATCH_NAMESPACE
         value: openstack,openshift-machine-api,openshift-sriov-network-operator
     source: osp-director-operator-index
     sourceNamespace: openstack
     name: osp-director-operator

6. openstack namespace に新しいリソースを作成します。

   $ oc applycreate -f osp-director-operator.yaml

7. 必要なオーバークラウドのイメージをリポジトリーにコピーします。

   $ for i in $(podman search --limit 1000 "registry.redhat.io/rhosp-rhel8/openstack" --format="{{ .Name }}" | awk '{print $1 ":" "16.2.4"}' | awk -F "/" '{print $2 "/" $3}'); do skopeo copy --all docker://registry.redhat.io/$i docker://your.registry.local/$i;done

   注記

   Red Hat Satellite がローカルレジストリーとして使用されている場合は、コンテナーイメージ用の Satellite Server の準備 を参照できます。

8. これで、director Operator を使用したオーバークラウドデプロイメントの準備 に進むことができます。

検証

1. director Operator が正常にインストールされていることを確認します。

   $ oc get operators
   NAME                                     AGE
   osp-director-operator.openstack          5m