手順

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

2. データベースをバックアップします。

   # mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

3. データベースのバックアップと設定ファイルをアーカイブします。

   # sudo tar --xattrs --ignore-failed-read -cf \
       undercloud-backup-`date +%F`.tar \
       /root/undercloud-all-databases.sql \
       /etc \
       /var/log \
       /var/lib/glance \
       /var/lib/certmonger \
       /var/lib/docker \
       /var/lib/registry \
       /srv/node \
       /root \
       /home/stack

   これで、undercloud-backup-<date>.tar.gz という名前のファイルが作成されます。<date> はシステムの日付です。この tar ファイルをセキュアな場所にコピーします。

手順

1. データベースのバックアップを実行します。

   1. コントロールノードにログインします。オーバークラウドには、アンダークラウドからアクセスできます。

      $ ssh heat-admin@192.0.2.100

   2. root ユーザーに変更します。

      $ sudo -i

   3. バックアップを保管するための一時ディレクトリーを作成します。

      # mkdir -p /var/tmp/mysql_backup/

   4. データベースのパスワードを取得して、MYSQLDBPASS の環境変数に保存します。このパスワードは、 /etc/puppet/hieradata/service_configs.json ファイルの mysql::server::root_password の変数に保管されています。以下のコマンドを使用してパスワードを保管します。

      # MYSQLDBPASS=$(sudo hiera mysql::server::root_password)

   5. データベースをバックアップします。

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "select distinct table_schema from information_schema.tables where engine='innodb' and table_schema != 'mysql';" | xargs mysqldump -uroot -p$MYSQLDBPASS --single-transaction --databases > /var/tmp/mysql_backup/openstack_databases-`date +%F`-`date +%T`.sql

      このコマンドにより、/var/tmp/mysql_backup/openstack_databases-<date>.sql という名前のデータベースバックアップがダンプされます。<date> はシステムの日付と時刻です。このデータベースダンプを安全な場所にコピーします。

   6. ユーザーおよびパーミッションに関する全情報をバックアップします。

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "SELECT CONCAT('\"SHOW GRANTS FOR ''',user,'''@''',host,''';\"') FROM mysql.user where (length(user) > 0 and user NOT LIKE 'root')" | xargs -n1 mysql -uroot -p$MYSQLDBPASS -s -N -e | sed 's/$/;/' > /var/tmp/mysql_backup/openstack_databases_grants-`date +%F`-`date +%T`.sql

      このコマンドにより、/var/tmp/mysql_backup/openstack_databases_grants-<date>.sql という名前のデータベースバックアップがダンプされます。<date> はシステムの日付と時刻です。このデータベースダンプを安全な場所にコピーします。

2. OpenStack Telemetry データベースをバックアップします。

   1. 任意のコントローラーに接続して、MongoDB のプライマリーインスタンスの IP を取得します。

      # MONGOIP=$(sudo hiera mongodb::server::bind_ip)

   2. バックアップを作成します。

      # mkdir -p /var/tmp/mongo_backup/
      # mongodump --oplog --host $MONGOIP --out /var/tmp/mongo_backup/

   3. /var/tmp/mongo_backup/ 内のデータベースダンプを安全な場所にコピーします。

3. Redis クラスターをバックアップします。

   1. HAProxy から Redis のエンドポイントを取得します。

      # REDISIP=$(sudo hiera redis_vip)

   2. Redis クラスターのマスターパスワードを取得します。

      # REDISPASS=$(sudo hiera redis::masterauth)

   3. Redis クラスターの接続をチェックします。

      # redis-cli -a $REDISPASS -h $REDISIP ping

   4. Redis データベースをダンプします。

      # redis-cli -a $REDISPASS -h $REDISIP bgsave

      このコマンドにより、データベースのバックアップがデフォルトの /var/lib/redis/ ディレクトリーに保管されます。このデータベースダンプを安全な場所にコピーします。

4. 各コントローラーノードのファイルシステムをバックアップします。

   1. バックアップ用のディレクトリーを作成します。

      # mkdir -p /var/tmp/filesystem_backup/

   2. 以下の tar コマンドを実行します。

      # tar --ignore-failed-read --xattrs \
          -zcvf /var/tmp/filesystem_backup/fs_backup-`date '+%Y-%m-%d-%H-%M-%S'`.tar.gz \
          /var/lib/config-data \
          /var/log/containers \
          /etc/corosync \
          /etc/logrotate.d \
          /etc/openvswitch \
          /var/log/openvswitch \
          /srv/node \
          /home/heat-admin

      --ignore-failed-read オプションを使用すると、見つからないディレクトリーは無視されます。これは、特定のサービスが使用されていない場合や、独自のカスタムロール上に分離されている場合に役立ちます。

5. 作成された tar ファイルを安全な場所にコピーします。

手順

1. director に stack ユーザーとしてログインします。

2. python-tripleoclient パッケージと依存関係を更新し、マイナーバージョンの更新向けの最新のスクリプトを使用できるようにします。

   $ sudo yum update -y python-tripleoclient

3. director は openstack undercloud upgrade コマンドを使用して、アンダークラウドの環境を更新します。以下のコマンドを実行します。

   $ openstack undercloud upgrade

4. アンダークラウドのアップグレードプロセスが完了するまで待ちます。

5. アンダークラウドを再起動して、オペレーティングシステムのカーネルとその他のシステムパッケージを更新します。

   $ sudo reboot

6. ノードが起動するまで待ちます。

手順

1. コンテナー化されたサービスのイメージの最新タグを確認します。

   $ openstack overcloud container image tag discover \
     --image registry.access.redhat.com/rhosp12/openstack-base:latest \
     --tag-from-label version-release

   最も新しいタグを書き留めておきます。

2. openstack overcloud container image prepare コマンドで、コンテナーイメージのソース用の更新された環境ファイルを作成します。たとえば、 registry.access.redhat.com からのイメージを使用する場合は、以下のコマンドを実行します。

   $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp12 \
     --prefix=openstack- \
     --tag [TAG] \ 1
     --set ceph_namespace=registry.access.redhat.com/rhceph \
     --set ceph_image=rhceph-2-rhel7 \
     --set ceph_tag=latest \
     --env-file=/home/stack/templates/overcloud_images.yaml \
     -e /home/stack/templates/custom_environment_file.yaml 2

   1

   [TAG] の箇所は、前のステップで取得したタグに置き換えます。

   2

   -e パラメーターで追加の環境ファイルをすべて指定します。director は指定されているすべての環境ファイルでカスタムリソースを確認して、コンテナー化されたサービスに必要なコンテナーイメージを特定します。

   この環境ファイルを異なるソース種別用に生成する方法についての詳しい情報は、『director のインストールと使用方法』ガイドの「コンテナーイメージのソースの設定」を参照してください。

3. openstack overcloud update stack コマンドを実行して、オーバークラウド内のコンテナーイメージの場所を更新します。

   $ openstack overcloud update stack --init-minor-update \
     --container-registry-file /home/stack/templates/overcloud_images.yaml

   --init-minor-update はオーバークラウドスタック内のパラメーターの更新のみを実行します。実際のパッケージやコンテナーの更新は行いません。このコマンドが完了するまで待ちます。

4. openstack overcloud update コマンドを使用してパッケージとコンテナーの更新を実行します。--nodes オプションを使用して、各ロールのノードをアップグレードします。たとえば、以下のコマンドは、Controller ロールのノードを更新します。

   $ openstack overcloud update stack --nodes Controller

   以下の順序で、各ロールグループにこのコマンドを実行します。

   • Controller
   • CephStorage
   • Compute
   • ObjectStorage
   • Database、MessageBus、Networker などのカスタムロール
5. 選択したロールの更新プロセスが開始します。director は Ansible playbook を使用して更新を実行し、各タスクの出力を表示します。
6. 次のロールグループを更新します。全ノードの更新が完了するまで作業を繰り返してください。

手順

1. ノードを選択してログインします。

2. ノードを再起動します。

   [heat-admin@overcloud-controller-0 ~]$ sudo reboot

3. ノードが起動するまで待ちます。

4. ノードにログインしてサービスをチェックします。以下に例を示します。

   1. ノードが Pacemaker サービスを使用している場合には、ノードがクラスターに再度参加したかどうかを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status

   2. ノードが Systemd サービスを使用している場合には、全サービスが有効化されているかどうかを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status

手順

1. Ceph MON またはコントローラーノードにログインして、Ceph Storage クラスターのリバランスを一時的に無効にします。

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

2. 再起動する最初の Ceph Storage ノードを選択して、ログインします。

3. ノードを再起動します。

   $ sudo reboot

4. ノードが起動するまで待ちます。

5. ノードにログインして、クラスターのステータスを確認します。

   $ sudo ceph -s

   pgmap により、すべての pgs が正常な状態 (active+clean) として報告されることを確認します。

6. ノードからログアウトして、次のノードを再起動し、ステータスを確認します。全 Ceph Storage ノードが再起動されるまで、このプロセスを繰り返します。

7. 完了したら、Ceph MON またはコントローラーノードにログインして、クラスターのリバランスを再度有効にします。

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

8. 最終のステータスチェックを実行して、クラスターがHEALTH_OK を報告していることを確認します。

   $ sudo ceph status

手順

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

2. 全コンピュートノードとその UUID を一覧表示します。

   $ source ~/stackrc
   (undercloud) $ openstack server list --name compute

   再起動するコンピュートノードの UUID を特定します。

3. アンダークラウドから、コンピュートノードを選択し、そのノードを無効にします。

   $ source ~/overcloudrc
   (overcloud) $ openstack compute service list
   (overcloud) $ openstack compute service set [hostname] nova-compute --disable

4. コンピュートノード上の全インスタンスを一覧表示します。

   (overcloud) $ openstack server list --host [hostname] --all-projects

5. 以下のコマンドの 1 つを使用して、インスタンスを移行します。

   1. 選択した特定のホストにインスタンスを移行します。

      (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait

   2. nova-scheduler により対象のホストが自動的に選択されるようにします。

      (overcloud) $ nova live-migration [instance-id]

   3. 一度にすべてのインスタンスのライブマイグレーションを行います。

      $ nova host-evacuate-live [hostname]

      注記

      nova コマンドで非推奨の警告が表示される可能性がありますが、安全に無視することができます。

6. 移行が完了するまで待ちます。

7. 正常に移行したことを確認します。

   (overcloud) $ openstack server list --host [hostname] --all-projects

8. 選択したコンピュートノードのインスタンスがなくなるまで、移行を続けます。

9. コンピュートノードのログインしてリブートします。

   [heat-admin@overcloud-compute-0 ~]$ sudo reboot

10. ノードが起動するまで待ちます。

11. コンピュートノードを再度有効化します。

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service set [hostname] nova-compute --enable

12. コンピュートノードが有効化されているかどうかを確認します。

    (overcloud) $ openstack compute service list

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. エラーが発生している Systemd サービスがあるかどうかを確認します。

   (undercloud) $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. アンダークラウドの空き領域を確認します。

   (undercloud) $ df -h

4. アンダークラウド上に NTP をインストールしている場合にはクロックが同期されていることを確認します。

   (undercloud) $ sudo ntpstat

5. アンダークラウドのネットワークサービスを確認します。

   (undercloud) $ openstack network agent list

   全エージェントが Alive で、それらの状態が UP である必要があります。

6. アンダークラウドの Compute サービスを確認します。

   (undercloud) $ openstack compute service list

   全エージェントのステータスが enabled で、状態が up である必要があります。

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. ベアメタルノードのステータスを確認します。

   (undercloud) $ openstack baremetal node list

   全ノードの電源状態が有効で (on)、かつメンテナンスモードが falseである必要があります。

3. エラーが発生している Systemd サービスがあるかどうかを確認します。

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. エラーが発生しているコンテナー化されたサービスがあるかどうかを確認します。

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'exited=1' --all" ; done
   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'status=dead' -f 'status=restarting'" ; done

5. 全サービスへの HAProxy 接続をチェックします。コントロールプレーンの仮想 IP アドレスとhaproxy.stats サービスの認証情報を取得します。

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg'

   以下の cURL 要求でそれらの情報を使用します。

   (undercloud) $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   <PASSWORD> と <IP ADDRESS> は、haproxy.stats サービスからのそれぞれの情報に置き換えます。その結果表示される一覧には、各ノード上の OpenStackPlatform サービスとそれらの接続ステータスが表示されます。

6. オーバークラウドデータベースのレプリケーションの正常性をチェックします。

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec clustercheck clustercheck" ; done

7. RabbitMQ クラスターの正常性を確認します。

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec $(ssh heat-admin@$NODE "sudo docker ps -f 'name=.*rabbitmq.*' -q") rabbitmqctl node_health_check" ; done

8. Pacemaker リソースの正常性を確認します。

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   以下の点を確認します。

   • 全クラスタノードが online であること
   • いずれのクラスターノード上でも stopped のリソースがないこと
   • pacemaker で failed のアクションがないこと

9. 各オーバークラウドノードでディスク領域を確認します。

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

10. オーバークラウドの Ceph Storage クラスターの正常性を確認します。以下のコマンドを使用すると、コントローラーノード上で ceph ツールが実行されて、クラスターをチェックします。

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

11. Ceph Storage OSD に空き領域があるかどうかを確認します。以下のコマンドを使用すると、コントローラーノード上で ceph ツールが実行され、空き領域をチェックします。

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

12. オーバークラウドノードでクロックが同期されていることを確認します。

    (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

13. オーバークラウドのアクセス情報を読み込みます。

    (undercloud) $ source ~/overcloudrc

14. オーバークラウドのネットワークサービスを確認します。

    (overcloud) $ openstack network agent list

    全エージェントが Alive で、それらの状態が UP である必要があります。

15. オーバークラウドの Compute サービスを確認します。

    (overcloud) $ openstack compute service list

    全エージェントのステータスが enabled で、状態が up である必要があります。

16. オーバークラウドのボリュームサービスを確認します。

    (overcloud) $ openstack volume service list

    全エージェントのステータスが enabled で、状態が up である必要があります。

手順

1. director に stack ユーザーとしてログインします。

2. 現在設定されている OpenStack Platform リポジトリーを無効にします。

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-12-rpms

3. 新しい OpenStack Platform リポジトリーを有効にします。

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-13-rpms

4. yum コマンドを実行して、director の主要なパッケージをアップグレードします。

   $ sudo yum update -y python-tripleoclient

5. 以下のコマンドを実行してアンダークラウドをアップグレードします。

   $ openstack undercloud upgrade

6. アンダークラウドのアップグレードプロセスが完了するまで待ちます。

7. アンダークラウドを再起動して、オペレーティングシステムのカーネルとその他のシステムパッケージを更新します。

   $ sudo reboot

8. ノードが起動するまで待ちます。

手順

1. stack ユーザーのホーム (/home/stack/images) にある images ディレクトリーから既存のイメージをすべて削除します。

   $ rm -rf ~/images/*

2. アーカイブを展開します。

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

3. director に最新のイメージをインポートします。

   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/

4. ノードが新しいイメージを使用するように設定します。

   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)

5. 新規イメージが存在することを確認します。

   $ openstack image list
   $ ls -l /httpboot

手順

1. openstack-tripleo-heat-templates-compat パッケージをインストールします。

   $ sudo yum install openstack-tripleo-heat-templates-compat

   これにより、Heat テンプレートコレクションの compat ディレクトリー (/usr/share/openstack-tripleo-heat-templates/compat) に以前のテンプレートがインストールされ、以前のバージョン (ocata) から命名された compat へのリンクが作成されます。これらのテンプレートは、アップグレードされた director との後方互換性があるので、最新バージョンの director を使用して以前のバージョンのオーバークラウドをインストールすることができます。

2. コア Heat テンプレートの一時的なコピーを作成します。

   $ cp -a /usr/share/openstack-tripleo-heat-templates /tmp/osp13

3. 以前のバージョンをそれ独自のディレクトリーに移動します。

   $ mv /tmp/osp12/compat /tmp/osp12

4. 両ディレクトリーのコンテンツに対して diff を実行します。

   $ diff -urN /tmp/osp12 /tmp/osp13

   このコマンドにより、バージョン間におけるコアテンプレートの変更が表示されます。この内容を確認すると、オーバークラウドのアップグレード中にどのような動作が行われるかがわかります。

手順

1. イメージを直接 registry.access.redhat.com からオーバークラウドデプロイメントにプルするには、イメージパラメーターを指定するための環境ファイルが必要となります。以下のコマンドにより、この環境ファイルが自動的に作成されます。

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp13 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml

   • -e: オプションのサービスの環境ファイルを指定します。
   • Ceph Storage を使用している場合は、Ceph Storage コンテナーイメージの場所を定義するための追加のパラメーターを含めます: --set ceph_namespace、--set ceph_image、--set ceph_tag
2. これで、イメージの場所が記載された overcloud_images.yaml 環境ファイルがアンダークラウド上に作成されます。このファイルをデプロイメントで指定します。

手順

1. ローカルアンダークラウドレジストリーのアドレスを特定します。アドレスは、以下のパターンを使用します。

   <REGISTRY IP ADDRESS>:8787

   アンダークラウドの IP アドレスを使用します。これは、以前に undercloud.conf ファイルの local_ip パラメーターで設定されています。以下のコマンドでは、このアドレスが 192.168.24.1:8787 であると仮定しています。

2. イメージをローカルレジストリーにアップロードするためのテンプレートと、それらのイメージを参照する環境ファイルを作成します。

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp13 \
     --push-destination=192.168.24.1:8787 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml \
     --output-images-file /home/stack/local_registry_images.yaml

   • -e: オプションのサービスの環境ファイルを指定します。
   • Ceph Storage を使用している場合は、Ceph Storage コンテナーイメージの場所を定義するための追加のパラメーターを含めます: --set ceph_namespace、--set ceph_image、--set ceph_tag

3. これで 2 つのファイルが作成されます。

   • リモートソースからのコンテナーイメージの情報が含まれている local_registry_images.yaml。このファイルを使用して、Red Hat Container Registry (registry.access.redhat.com) からイメージをアンダークラウドにプルします。

   • アンダークラウド上の最終的なイメージの場所が記載されている overcloud_images.yaml。このファイルはデプロイメントで指定します。

     両方のファイルが存在することを確認します。

4. コンテナーイメージを registry.access.redhat.com からアンダークラウドにプルします。

   (undercloud) $ sudo openstack overcloud container image upload \
     --config-file  /home/stack/local_registry_images.yaml \
     --verbose

   ネットワークおよびアンダークラウドディスクの速度によっては、必要なイメージをプルするのに時間がかかる場合があります。

   注記

   コンテナーイメージは、およそ 10 GB のディスク領域を使用します。

手順

1. イメージをローカルレジストリーにプルするためのテンプレートを作成します。

   $ source ~/stackrc
   (undercloud) $ openstack overcloud container image prepare \
     --namespace=rhosp13 \
     --prefix=openstack- \
     --output-images-file /home/stack/satellite_images \

   • -e: オプションのサービスの環境ファイルを指定します。
   • Ceph Storage を使用している場合は、Ceph Storage コンテナーイメージの場所を定義するための追加のパラメーターを含めます: --set ceph_namespace、--set ceph_image、--set ceph_tag
   注記

   上記の openstack overcloud container image prepare コマンドは、 registry.access.redhat.com のレジストリーをターゲットにしてイメージの一覧を生成します。この後のステップでは、openstack overcloud container image prepare コマンドで別の値を使用します。

2. これで、コンテナーイメージの情報が含まれた satellite_images という名前のファイルが作成されます。このファイルを使用して、コンテナーイメージを Satellite 6 サーバーに同期します。

3. satellite_images ファイルから YAML 固有の情報を削除して、イメージ一覧のみが記載されたフラットファイルに変換します。この操作は、以下の sed コマンドで実行します。

   (undercloud) $ awk -F ':' '{if (NR!=1) {gsub("[[:space:]]", ""); print $2}}' ~/satellite_images > ~/satellite_images_names

   これにより、Satellite サーバーにプルするイメージのリストが提供されます。

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

5. 以下の hammer コマンドを実行して、新しい製品 (OSP13 Containers) を Satellite の組織に作成します。

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

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

6. 製品にベースコンテナーイメージを追加します。

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.access.redhat.com \
     --docker-upstream-name rhosp13/openstack-base \
     --name base

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

   $ while read IMAGE; do \
     IMAGENAME=$(echo $IMAGE | cut -d"/" -f2 | sed "s/openstack-//g" | sed "s/:.*//g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.access.redhat.com \
     --docker-upstream-name $IMAGE \
     --name $IMAGENAME ; done < satellite_images_names

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

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

   Satellite サーバーが同期を完了するまで待ちます。

   注記

   設定によっては、 hammer が Satellite サーバーのユーザー名とパスワードを要求する場合があります。設定ファイルを使用して、hammer が自動ログインするように設定することができます。『Hammer CLI ガイド』の「認証」 の項を参照してください。

9. Satellite 6 サーバーでコンテンツビューを使用している場合には、新規コンテンツビューを作成して、イメージを取り入れます。

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

    $ hammer docker tag list --repository "base" \
      --organization "ACME" \
      --product "OSP13 Containers"

    これにより、OpenStack Platform コンテナーイメージのタグが表示されます。

11. アンダークラウドに戻り、Satellite サーバー上のイメージ用に環境ファイルを生成します。環境ファイルを生成するコマンドの例を以下に示します。

    (undercloud) $ openstack overcloud container image prepare \
      --namespace=satellite6.example.com:5000 \
      --prefix=acme-osp13_containers- \
      --tag-from-label {version}-{release} \
      --output-env-file=/home/stack/templates/overcloud_images.yaml

    注記

    上記の openstack overcloud container image prepare コマンドはSatelliteサーバーをターゲットにします。これは、前のステップで使用した openstack overcloud container image prepare コマンドとは異なる値を使用します。

    このコマンドを実行する際には、以下の情報を含めてください。

    • --namespace: Satellite サーバー上のレジストリーの URL およびポート。Red Hat Satellite のデフォルトのレジストリーポートは 5000 です。例: --namespace=satellite6.example.com:5000

    • --prefix=: プレフィックスは Satellite 6 の命名規則に基づきます。これは、コンテンツビューを使用するかどうかによって異なります。

      • コンテンツビューを使用する場合、構造は [org]-[environment]-[content view]-[product]- となります (例: acme-production-myosp13-osp13_containers-)。
      • コンテンツビューを使用しない場合、構造は [org]-[product]- となります (例: acme-osp13_containers-)。
    • --tag-from-label {version}-{release}: 各イメージの最新のタグを識別します。
    • -e: オプションのサービスの環境ファイルを指定します。

    • --set ceph_namespace、--set ceph_image、--set ceph_tag: Ceph Storageを使用する場合は、Ceph Storageコンテナーのイメージの場所を定義するための追加パラメーターを含めます。ceph_image には現在 Satellite 固有のプレフィックスが付いている点に注意してください。このプレフィックスは、 --prefix オプションと同じ値です。以下に例を示します。

      --set ceph_image=acme-osp13_containers-rhceph-3-rhel7

      これにより、オーバークラウドは Satelite の命名規則の Ceph コンテナーイメージを使用することができます。

12. これで、Satellite サーバー上のイメージの場所が記載された overcloud_images.yaml 環境ファイルが作成されます。このファイルをデプロイメントで指定します。

手順

1. 登録情報が記載された環境ファイルを編集します。以下に例を示します。

   $ vi ~/templates/rhel-registration/environment-rhel-registration.yaml

2. 以下のパラメーター値を編集します。

   rhel_reg_repos

   Red Hat OpenStack Platform 13 の新しいリポジトリーを追加するように更新します。

   rhel_reg_activation_key

   Red Hat OpenStack Platform 13 のリポジトリーにアクセスするためのアクティベーションキーを更新します。

   rhel_reg_sat_repo

   Red Hat Satellite 6 のより新しいバージョンを使用する場合には、Satellite 6 の管理ツールが含まれているリポジトリーを更新します。

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

手順

1. 環境ファイルを選択し、ExtraConfig パラメーターがあるかどうかをチェックします。

   $ grep ExtraConfig ~/templates/custom-config.yaml

2. このコマンドの結果に、選択したファイル内のいずれかのロールの ExtraConfig パラメーター (例: ControllerExtraConfig) が表示された場合には、そのファイルの完全なパラメーター構造を確認してください。

3. SECTION/parameter 構文で valueが続くいずれかの puppet Hierdata がパラメーターに含まれている場合には、実際の Puppet クラスに置き換えられている可能性があります。以下に例を示します。

   parameter_defaults:
     ExtraConfig:
       neutron::config::dhcp_agent_config:
         'DEFAULT/dnsmasq_local_resolv':
           value: 'true'

4. director の Puppet モジュールを確認して、パラメーターが Puppet クラス内に存在しているかどうかを確認します。以下に例を示します。

   $ grep dnsmasq_local_resolv

   その場合には、新規インターフェースに変更します。

5. 構文の変更の実例を以下に示します。

   • 例 1:

     parameter_defaults:
       ExtraConfig:
         neutron::config::dhcp_agent_config:
           'DEFAULT/dnsmasq_local_resolv':
             value: 'true'

     変更後

     parameter_defaults:
       ExtraConfig:
         neutron::agents::dhcp::dnsmasq_local_resolv: true

   • 例 1:

     parameter_defaults:
       ExtraConfig:
         ceilometer::config::ceilometer_config:
           'oslo_messaging_rabbit/rabbit_qos_prefetch_count':
             value: '32'

     変更後

     parameter_defaults:
       ExtraConfig:
         oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. upgrade prepare コマンドを実行します。

   $ openstack overcloud upgrade prepare \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定環境ファイル（-e)
   • 新しいコンテナーイメージの場所が記載された環境ファイル (-e)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e を使用するのが推奨されるようになっているので、警告は無視して問題ありません。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) のファイルを指定します。
3. upgrade prepare が完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --roles Controller

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. コントローラーノードのアップグレードが完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --roles Compute

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. コンピュートノードのアップグレードが完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --roles CephStorage

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. ノードのアップグレードが完了するまで待ちます。

4. Ceph Storage のアップグレードコマンドを実行します。以下に例を示します。

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定環境ファイル (-e)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e を使用するのが推奨されるようになっているので、警告は無視して問題ありません。
     • Ceph Storage ノード用の関連する環境ファイル
     • お使いの環境に関連する追加の環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) のファイルを指定します。
5. Ceph Storage ノードのアップグレードが完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. アップグレードの最終処理のコマンドを実行します。

   $ openstack overcloud upgrade converge \
       --templates \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定環境ファイル (-e)
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合は、--roles-file でカスタムロール (roles_data) のファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) のファイルを指定します。
3. アップグレードの最終処理が完了するまで待ちます。