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

2.2. テンプレートベースのインストール環境における 2.11 から 2.12 へのアップグレード

テンプレートベースのインストール環境において、3scale 2.11 を 2.12 にアップグレードするには、本セクションに記載の手順に従います。

アップグレードを開始するには、3scale がデプロイされているプロジェクトに移動します。 

$ oc project <3scale-project>

続いて、以下の順序で手順を実行します。

  1. 3scale プロジェクトのバックアップの作成
  2. 未使用の AMP_RELEASE 変数の削除
  3. MySQL 設定のアップグレード
  4. 3scale イメージのアップグレード
  5. その他のイメージの変更
  6. イメージの URL の確認
  7. 未使用の MessageBus 変数の削除

2.2.1. 3scale プロジェクトのバックアップの作成
リンクのコピー

前の手順

なし

現在の手順

3scale プロジェクトのバックアップを作成するのに必要なアクションを以下のリストに示します。

手順

  1. 3scale で使用するデータベースに応じて、${SYSTEM_DB} を以下のいずれかの値に設定します。

    • データベースが MySQL の場合: SYSTEM_DB=system-mysql
    • データベースが PostgreSQL の場合: SYSTEM_DB=system-postgresql

  2. 既存の DeploymentConfigs でバックアップファイルを作成します。 

    $ THREESCALE_DC_NAMES="apicast-production apicast-staging backend-cron backend-listener backend-redis backend-worker system-app system-memcache ${SYSTEM_DB} system-redis system-sidekiq system-sphinx zync zync-database zync-que"

for component in ${THREESCALE_DC_NAMES}; do oc get --export -o yaml dc ${component} > ${component}_dc.yml ; done

  3. export all コマンドでエクスポートされるプロジェクト内のすべての既存 OpenShift リソースをバックアップします。 

    $ oc get -o yaml --export all > threescale-project-elements.yaml

  4. export all コマンドでエクスポートされない追加の要素でバックアップファイルを作成します。 

    $ for object in rolebindings serviceaccounts secrets imagestreamtags cm rolebindingrestrictions limitranges resourcequotas pvc templates cronjobs statefulsets hpa deployments replicasets poddisruptionbudget endpoints
do
  oc get -o yaml --export $object > $object.yaml
done
  5. 生成されたすべてのファイルが空ではないこと、およびそれらすべての内容が予想どおりであることを確認します。

次のステップ

未使用の AMP_RELEASE 変数の削除

2.2.2. 未使用の AMP_RELEASE 変数の削除
リンクのコピー

前の手順

3scale プロジェクトのバックアップの作成

現在の手順

この手順では、未使用の AMP_RELEASE 変数を system-app コンテナー、system-app pre hook から削除し、AMP_RELEASE が存在しないことを確認します。

手順

  1. system-app コンテナーから変数を削除します。

    • 変数名の後ろにあるダッシュ文字に注意してください。 

      $ oc set env dc/system-app AMP_RELEASE-

  2. system-app pre hook から変数を削除します。 

    $ INDEX=$(oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(.name == "AMP_RELEASE") | index(true)')
oc patch dc/system-app --type=json -p "[{'op': 'remove', 'path': '/spec/strategy/rollingParams/pre/execNewPod/env/$INDEX'}]"

  3. AMP_RELEASE が存在しないことを確認します。 

    $ oc get dc system-app -o yaml | grep AMP_RELEASE

次のステップ

MySQL 設定のアップグレード

2.2.3. MySQL 設定のアップグレード
リンクのコピー

注記

3scale デプロイメントで外部データベースモードが有効になっていて、MySQL 8.0 を使用している場合は、3scale 2.12 の認証プラグインを mysql_native_password に設定します。

MySQL 設定ファイルに以下を追加します。 

[mysqld]
default_authentication_plugin=mysql_native_password

前の手順

未使用の AMP_RELEASE 変数の削除

現在の手順

この手順では MySQL 設定 configmap にパッチを適用し、MySQL 8.0 へのアップグレードを有効にします。

注記

現在の 3scale インストールに system-mysql デプロイメントが存在する場合に限り、この手順を実行します。

手順

  1. configmap にパッチを適用します。 

    $ oc patch configmap/mysql-extra-conf --type merge -p '{"data": {"mysql-default-authentication-plugin.cnf": "[mysqld]\ndefault_authentication_plugin=mysql_native_password"}}'

  2. configmap が更新されていることを確認します。 

    $ oc get cm mysql-extra-conf -o jsonpath='{.data.mysql-default-authentication-plugin\.cnf}'

    • 以下が返されるはずです。 

      [mysqld]
default_authentication_plugin=mysql_native_password

次のステップ

3scale イメージのアップグレード

2.2.4. 3scale イメージのアップグレード
リンクのコピー

前の手順

MySQL 設定のアップグレード

現在の手順

この手順では、アップグレードプロセスに必要な 3scale イメージを更新します。

2.2.4.1. system イメージのパッチ
リンクのコピー

  1. 新しいイメージストリームタグを作成します。 

    $ oc patch imagestream/amp-system --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP system 2.12"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/system-rhel7:3scale2.12"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

  2. 手順を進めるには、ご自分の 3scale デプロイメントで使用しているデータベースを考慮してください。

2.2.4.1.1. システムイメージのパッチ適用: Oracle データベースを使用する 3Scale
リンクのコピー

  1. Oracle Database を使用して 3scale のシステムイメージのパッチ適用を開始するには、システムイメージをビルドする必要があります。

    • GitHub リポジトリーから 3scale OpenShift テンプレートをダウンロードし、アーカイブをデプロイメントします。 

      tar -xzf 3scale-amp-openshift-templates-3scale-2.12.0-GA.tar.gz
    • Oracle Database の Instant Client パッケージファイルを 3scale-amp-openshift-templates-3scale-2.12.0-GA/amp/system-oracle/oracle-client-files ディレクトリーに配置します。

    • -f オプションを使用して oc process コマンドを実行し、oc apply コマンドで build.yml OpenShift テンプレートを指定し、-f オプションを使用して既存のビルドをオーバーライドします。 

      $ oc process -f build.yml | oc apply -f -

    • oc start-build コマンドを入力し、新しいシステムイメージをビルドします。 

      $ oc start-build 3scale-amp-system-oracle --from-dir=.

  2. system-app ImageChange トリガーにパッチを適用します。

    1. 古い 2.11-oracle トリガーを削除します。 

      $ oc set triggers dc/system-app --from-image=amp-system:2.11-oracle --containers=system-master,system-developer,system-provider --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-app --from-image=amp-system:2.12-oracle --containers=system-master,system-developer,system-provider

      これがトリガーとなり system-app が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  3. system-sidekiq ImageChange トリガーにパッチを適用します。

    1. 古い 2.11-oracle トリガーを削除します。 

      $ oc set triggers dc/system-sidekiq --from-image=amp-system:2.11-oracle --containers=system-sidekiq,check-svc --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-sidekiq --from-image=amp-system:2.12-oracle --containers=system-sidekiq,check-svc

      これがトリガーとなり system-sidekiq が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  4. system-sphinx ImageChange トリガーにパッチを適用します。

    1. 古い 2.11-oracle トリガーを削除します。 

      $ oc set triggers dc/system-sphinx --from-image=amp-system:2.11-oracle --containers=system-sphinx,system-master-svc --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-sphinx --from-image=amp-system:2.12-oracle --containers=system-sphinx,system-master-svc

      これがトリガーとなり system-sphinx が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  5. 3scale をスケールダウンした場合は、元に戻します。
2.2.4.1.2. システムイメージのパッチ適用: 他のデータベースを使用する 3scale
リンクのコピー

  1. system-app ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/system-app --from-image=amp-system:2.11 --containers=system-master,system-developer,system-provider --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-app --from-image=amp-system:2.12 --containers=system-master,system-developer,system-provider

      これがトリガーとなり system-app が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  2. system-sidekiq ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/system-sidekiq --from-image=amp-system:2.11 --containers=system-sidekiq,check-svc --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-sidekiq --from-image=amp-system:2.12 --containers=system-sidekiq,check-svc

      これがトリガーとなり system-sidekiq が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  3. system-sphinx ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/system-sphinx --from-image=amp-system:2.11 --containers=system-sphinx,system-master-svc --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-sphinx --from-image=amp-system:2.12 --containers=system-sphinx,system-master-svc

      これがトリガーとなり system-sphinx が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

2.2.4.2. apicast イメージのパッチ
リンクのコピー

  1. amp-apicast イメージストリームにパッチを適用します。 

    $ oc patch imagestream/amp-apicast --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP APIcast 2.12"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.12"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

  2. apicast-staging ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/apicast-staging --from-image=amp-apicast:2.11 --containers=apicast-staging --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/apicast-staging --from-image=amp-apicast:2.12 --containers=apicast-staging

      これがトリガーとなり apicast-staging が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  3. apicast-production ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/apicast-production --from-image=amp-apicast:2.11 --containers=apicast-production,system-master-svc --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/apicast-production --from-image=amp-apicast:2.12 --containers=apicast-production,system-master-svc

      これがトリガーとなり apicast-production が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

2.2.4.3. backend イメージのパッチ
リンクのコピー

  1. amp-backend イメージストリームにパッチを適用します。 

    $ oc patch imagestream/amp-backend --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Backend 2.12"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/backend-rhel8:3scale2.12"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

  2. backend-listener ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/backend-listener --from-image=amp-backend:2.11 --containers=backend-listener --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/backend-listener --from-image=amp-backend:2.12 --containers=backend-listener

      これがトリガーとなり backend-listener が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  3. backend-worker ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/backend-worker --from-image=amp-backend:2.11 --containers=backend-worker,backend-redis-svc --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/backend-worker --from-image=amp-backend:2.12 --containers=backend-worker,backend-redis-svc

      これがトリガーとなり backend-worker が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  4. backend-cron ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/backend-cron --from-image=amp-backend:2.11 --containers=backend-cron,backend-redis-svc --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/backend-cron --from-image=amp-backend:2.12 --containers=backend-cron,backend-redis-svc

      このコマンドがトリガーとなり backend-cron が再デプロイされます。再デプロイされ、対応する新しい Pod の準備が整い、以前の Pod が終了するまで待ちます。

2.2.4.4. zync イメージへのパッチ適用
リンクのコピー

  1. amp-zync イメージストリームにパッチを適用します。 

    $ oc patch imagestream/amp-zync --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Zync 2.12"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/zync-rhel8:3scale2.12"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

  2. zync ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/zync --from-image=amp-zync:2.11 --containers=zync,zync-db-svc --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/zync --from-image=amp-zync:2.12 --containers=zync,zync-db-svc

      これがトリガーとなり zync が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

  3. zync-que ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/zync-que --from-image=amp-zync:2.11 --containers=que --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/zync-que --from-image=amp-zync:2.12 --containers=que

      これがトリガーとなり zync-que が再デプロイされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

2.2.4.5. system-memcached イメージのパッチ
リンクのコピー

  1. system-memcached イメージストリームにパッチを適用します。 

    $ oc patch imagestream/system-memcached --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.12 Memcached"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/memcached-rhel7:3scale2.12"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

  2. system-memcache ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/system-memcache --from-image=system-memcached:2.11 --containers=memcache --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-memcache --from-image=system-memcached:2.12 --containers=memcache

      これにより、system-memcache DeploymentConfig の再デプロイメントがトリガーされます。再デプロイが完了し、対応する新規 Pod が使用できる状態になり、古い Pod が終了するまで待ちます。

2.2.4.6. zync-database-postgresql イメージのパッチ
リンクのコピー

  1. zync-database-postgresql イメージストリームにパッチを適用します。 

    $ oc patch imagestream/zync-database-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Zync 2.12 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

    • このパッチコマンドにより zync-database-postgresql イメージストリームが更新され、2.12 タグが含まれるようになります。以下の手順により、2.12 タグが作成されていることを確認することができます。

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

        $ oc get is zync-database-postgresql
      2. Tags 欄に 2.12 タグが表示されていることを確認します。

  2. zync-database ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/zync-database --from-image=zync-database-postgresql:2.11 --containers=postgresql --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/zync-database --from-image=zync-database-postgresql:2.12 --containers=postgresql

      イメージに新しい更新があれば、このパッチがトリガーとなり zync-database DeploymentConfig も再デプロイされます。その場合は、新規 Pod の再デプロイが完了して使用できる状態になり、古い Pod が終了するまで待ちます。

2.2.4.7. その他のイメージの変更
リンクのコピー

3scale 2.11 のインストール環境で以下の DeploymentConfig の 1 つまたは複数が利用可能な場合は、該当するリンクをクリックして詳細な操作手順を確認してください。

backend-redis DeploymentConfig

現在の 3scale インストール環境に backend-redis DeploymentConfig が存在する場合は、backend-redis 用の redis イメージにパッチを適用します。

  1. backend-redis イメージストリームにパッチを適用します。 

    $ oc patch imagestream/backend-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Backend 2.12 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-5-rhel7:5"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

    このパッチにより backend-redis イメージストリームが更新され、2.12 タグが含まれるようになります。以下のコマンドにより Tags 欄に 2.12 が表示されれば、タグが作成されていることを確認することができます。 

    $ oc get is backend-redis

  2. backend-redis ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/backend-redis --from-image=backend-redis:2.11 --containers=backend-redis --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/backend-redis --from-image=backend-redis:2.12 --containers=backend-redis

      イメージに新しい更新があれば、このパッチがトリガーとなり backend-redis DeploymentConfig も再デプロイされます。その場合は、新規 Pod の再デプロイが完了して使用できる状態になり、古い Pod が終了するまで待ちます。

system-redis DeploymentConfig

現在の 3scale インストール環境に system-redis DeploymentConfig が存在する場合は、system-redis 用の redis イメージにパッチを適用します。

  1. system-redis イメージストリームにパッチを適用します。 

    $ oc patch imagestream/system-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.12 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-5-rhel7:5"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

    このパッチにより system-redis イメージストリームが更新され、2.12 タグが含まれるようになります。以下のコマンドにより Tags 欄に 2.12 が表示されれば、タグが作成されていることを確認することができます。 

    $ oc get is system-redis

  2. system-redis ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/system-redis --from-image=system-redis:2.11 --containers=system-redis --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-redis --from-image=system-redis:2.12 --containers=system-redis

      イメージに新しい更新があれば、このパッチがトリガーとなり system-redis DeploymentConfig も再デプロイされます。その場合は、新規 Pod の再デプロイが完了して使用できる状態になり、古い Pod が終了するまで待ちます。

system-mysql DeploymentConfig

現在の 3scale インストール環境に system-mysql DeploymentConfig が存在する場合は、system-mysql 用の MySQL イメージにパッチを適用します。

  1. system-mysql イメージストリームにパッチを適用します。 

    $ oc patch imagestream/system-mysql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.12 MySQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhel8/mysql-80:1"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

    このパッチにより system-mysql イメージストリームが更新され、2.12 タグが含まれるようになります。以下のコマンドにより Tags 欄に 2.12 が表示されれば、タグが作成されていることを確認することができます。 

    $ oc get is system-mysql

  2. system-mysql ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/system-mysql --from-image=system-mysql:2.11 --containers=system-mysql --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-mysql --from-image=system-mysql:2.12 --containers=system-mysql

      イメージに新しい更新があれば、このパッチがトリガーとなり system-mysql DeploymentConfig も再デプロイされます。その場合は、新規 Pod の再デプロイが完了して使用できる状態になり、古い Pod が終了するまで待ちます。

system-postgresql DeploymentConfig

現在の 3scale インストール環境に system-postgresql DeploymentConfig が存在する場合は、system-postgresql 用の PostgreSQL イメージにパッチを適用します。

  1. system-postgresql イメージストリームにパッチを適用します。 

    $ oc patch imagestream/system-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.12 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7"}, "name": "2.12", "referencePolicy": {"type": "Source"}}}]'

    このパッチにより system-postgresql イメージストリームが更新され、2.12 タグが含まれるようになります。以下のコマンドにより Tags 欄に 2.12 が表示されれば、タグが作成されていることを確認することができます。 

    $ oc get is system-postgresql

  2. system-postgresql ImageChange トリガーにパッチを適用します。

    1. 古い 2.11 トリガーを削除します。 

      $ oc set triggers dc/system-postgresql --from-image=system-postgresql:2.11 --containers=system-postgresql --remove

    2. 新しいバージョン固有のトリガーを追加します。 

      $ oc set triggers dc/system-postgresql --from-image=system-postgresql:2.12 --containers=system-postgresql

      イメージに新しい更新があれば、このパッチがトリガーとなり system-postgresql DeploymentConfig も再デプロイされます。その場合は、新規 Pod の再デプロイが完了して使用できる状態になり、古い Pod が終了するまで待ちます。

2.2.4.8. イメージの URL の確認
リンクのコピー

DeploymentConfig のすべてのイメージ URL に、各 URL アドレスの最後に追加されたハッシュと共に新しいイメージレジストリーの URL が含まれていることを確認します。 

THREESCALE_DC_NAMES="apicast-production apicast-staging backend-cron backend-listener backend-redis backend-worker system-app system-memcache system-mysql system-redis system-sidekiq system-sphinx zync zync-database zync-que"
for component in ${THREESCALE_DC_NAMES}; do echo -n "${component} image: " && oc get dc $component -o json | jq .spec.template.spec.containers[0].image ; done

次のステップ

未使用の MessageBus 変数の削除

2.2.5. 未使用の MessageBus 変数の削除
リンクのコピー

前の手順

3scale イメージのアップグレード

現在の手順

この手順では、未使用の MESSAGE_BUS_REDIS_* 変数を削除します。

2.2.5.1. system-app deploymentconfig からの MESSAGE_BUS_REDIS_* 変数の削除
リンクのコピー

  1. system-app コンテナーから MESSAGE_BUS_REDIS_* 変数を削除します。

    • 変数名の後ろにあるダッシュ文字に注意してください。 

      $ oc set env dc/system-app MESSAGE_BUS_REDIS_URL-
$ oc set env dc/system-app MESSAGE_BUS_REDIS_NAMESPACE-
$ oc set env dc/system-app MESSAGE_BUS_REDIS_SENTINEL_HOSTS-
$ oc set env dc/system-app MESSAGE_BUS_REDIS_SENTINEL_ROLE-

  2. system-app pre hook から MESSAGE_BUS_REDIS_* 変数を削除します。 

    $ INDEX=$(oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(.name == "MESSAGE_BUS_REDIS_URL") | index(true)')
oc patch dc/system-app --type=json -p "[{'op': 'remove', 'path': '/spec/strategy/rollingParams/pre/execNewPod/env/$INDEX'}]"

$ INDEX=$(oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(.name == "MESSAGE_BUS_REDIS_NAMESPACE") | index(true)')
oc patch dc/system-app --type=json -p "[{'op': 'remove', 'path': '/spec/strategy/rollingParams/pre/execNewPod/env/$INDEX'}]"

$ INDEX=$(oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(.name == "MESSAGE_BUS_REDIS_SENTINEL_HOSTS") | index(true)')
oc patch dc/system-app --type=json -p "[{'op': 'remove', 'path': '/spec/strategy/rollingParams/pre/execNewPod/env/$INDEX'}]"

$ INDEX=$(oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(.name == "MESSAGE_BUS_REDIS_SENTINEL_ROLE") | index(true)')
oc patch dc/system-app --type=json -p "[{'op': 'remove', 'path': '/spec/strategy/rollingParams/pre/execNewPod/env/$INDEX'}]"

  3. MESSAGE_BUS_REDIS_* 環境変数が存在しないことを確認します。 

    $ oc get dc system-app -o yaml | grep MESSAGE_BUS_REDIS

2.2.5.2. system-sidekiq deploymentconfig からの MESSAGE_BUS_REDIS_* 変数の削除
リンクのコピー

  1. system-sidekiq コンテナーから MESSAGE_BUS_REDIS_* 変数を削除します。

    • 変数名の後ろにあるダッシュ文字に注意してください。 

      $ oc set env dc/system-sidekiq MESSAGE_BUS_REDIS_URL-
$ oc set env dc/system-sidekiq MESSAGE_BUS_REDIS_NAMESPACE-
$ oc set env dc/system-sidekiq MESSAGE_BUS_REDIS_SENTINEL_HOSTS-
$ oc set env dc/system-sidekiq MESSAGE_BUS_REDIS_SENTINEL_ROLE-

  2. system-sidekiq init-container から MESSAGE_BUS_REDIS_* 変数を削除します。 

    $ INDEX=$(oc get dc system-sidekiq -o json | jq '.spec.template.spec.initContainers[].env | map(.name == "MESSAGE_BUS_REDIS_URL") | index(true)')
oc patch dc/system-sidekiq --type=json -p "[{'op': 'remove', 'path': '/spec/template/spec/initContainers/0/env/$INDEX'}]"

$ INDEX=$(oc get dc system-sidekiq -o json | jq '.spec.template.spec.initContainers[].env | map(.name == "MESSAGE_BUS_REDIS_NAMESPACE") | index(true)')
oc patch dc/system-sidekiq --type=json -p "[{'op': 'remove', 'path': '/spec/template/spec/initContainers/0/env/$INDEX'}]"

$ INDEX=$(oc get dc system-sidekiq -o json | jq '.spec.template.spec.initContainers[].env | map(.name == "MESSAGE_BUS_REDIS_SENTINEL_HOSTS") | index(true)')
oc patch dc/system-sidekiq --type=json -p "[{'op': 'remove', 'path': '/spec/template/spec/initContainers/0/env/$INDEX'}]"

$ INDEX=$(oc get dc system-sidekiq -o json | jq '.spec.template.spec.initContainers[].env | map(.name == "MESSAGE_BUS_REDIS_SENTINEL_ROLE") | index(true)')
oc patch dc/system-sidekiq --type=json -p "[{'op': 'remove', 'path': '/spec/template/spec/initContainers/0/env/$INDEX'}]"

  3. MESSAGE_BUS_REDIS_* 環境変数が存在しないことを確認します。 

    $ oc get dc system-sidekiq -o yaml | grep MESSAGE_BUS_REDIS

2.2.5.3. system-sphinx deploymentconfig から MESSAGE_BUS_REDIS_* 変数を削除
リンクのコピー

  1. system-sphinx コンテナーから MESSAGE_BUS_REDIS_* 変数を削除します。

    • 変数名の後ろにあるダッシュ文字に注意してください。 

      $ oc set env dc/system-sphinx MESSAGE_BUS_REDIS_URL-
$ oc set env dc/system-sphinx MESSAGE_BUS_REDIS_NAMESPACE-
$ oc set env dc/system-sphinx MESSAGE_BUS_REDIS_SENTINEL_HOSTS-
$ oc set env dc/system-sphinx MESSAGE_BUS_REDIS_SENTINEL_ROLE-

  2. MESSAGE_BUS_REDIS_* 環境変数が存在しないことを確認します。 

    $ oc get dc system-sphinx -o yaml | grep MESSAGE_BUS_REDIS

2.2.5.4. system-redis シークレットからの MESSAGE_BUS_REDIS_* 変数の削除
リンクのコピー

  1. system-redis シークレットから MESSAGE_BUS_REDIS_* 変数を削除します。 

    $ oc patch secret/system-redis --type=json -p "[{'op': 'remove', 'path': '/data/MESSAGE_BUS_URL'}]"
$ oc patch secret/system-redis --type=json -p "[{'op': 'remove', 'path': '/data/MESSAGE_BUS_NAMESPACE'}]"
$ oc patch secret/system-redis --type=json -p "[{'op': 'remove', 'path': '/data/MESSAGE_BUS_SENTINEL_HOSTS'}]"
$ oc patch secret/system-redis --type=json -p "[{'op': 'remove', 'path': '/data/MESSAGE_BUS_SENTINEL_ROLE'}]"

  2. MESSAGE_BUS_REDIS_* 環境変数が存在しないことを確認します。 

    $ oc get secret system-redis -o yaml | grep MESSAGE_BUS

このアップグレードは、PostgreSQL 10 を使用する外部 システムデータベース をサポートします。最初に 3scale のアップグレードを完了してから、PostgreSQL 13 にアップグレードする必要があります。

次のステップ

なし上記の手順をすべて実施すると、テンプレートベースのデプロイメントにおける 3scale 2.11 から 2.12 へのアップグレードが完了します。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る