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

3scale の移行

Red Hat 3scale API Management 2.12

3scale API Management およびそのコンポーネントの移行またはアップグレード

Red Hat Customer Content Services

概要

3scale をテンプレートベースから operator ベースのインストールに移行する方法を説明します。3scale およびそのコンポーネントを最新バージョンにアップグレードするための情報についても説明します。

前書き

本ガイドでは、Red Hat 3scale API Management をテンプレートベースから operator ベースのインストールに移行するための情報、3scale インストールを 2.10 から 2.11 にアップグレードするのに必要な詳細情報、および operator ベースのデプロイメントで APIcast をアップグレードする手順について説明します。

テンプレートベースから operator ベースのデプロイメントに移行するには、3scale の移行ガイド に記載の手順を参照してください。

オンプレミス型 3scale のデプロイメントを 2.10 から 2.11 にアップグレードするには、インストールのタイプに応じて以下のガイドのいずれかを参照してください。

operator ベースのデプロイメントで APIcast をアップグレードするには、operator ベースの APIcast のアップグレードガイド に記載の手順を参照してください。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、CTO である Chris Wright のメッセージ をご覧ください。

第1章 3scale の移行ガイド: テンプレートベースから operator ベースのデプロイメントへ

本セクションでは、Red Hat 3scale API Management を Red Hat OpenShift 3.11 を使用するテンプレートベースのデプロイメントから Red Hat OpenShift 4.x を使用する operator ベースのデプロイメントに移行する方法について説明します。

警告

必要な条件および手順を理解するために、記載の手順を適用する前に、移行ガイド全体を読んでください。移行プロセスの手順が完了するまで、サービスの提供が中断されます。このサービス中断が生じるため、メンテナンス期間を設けるようにしてください。

1.1. 移行を行うための前提条件

3scale インストールをテンプレートベースから operator ベースのデプロイメントに移行する前に、以下のガイドを参照してデプロイメントがサポートされていることを確認してください。

1.2. 3scale のテンプレートベースから operator ベースのデプロイメントへの移行

移行前の基本セットアップは、3scale が OCP3 ドメインをポイントする設定です。3scale.example.com → ocp3.example.com

3scale を Red Hat OpenShift 3.11 を使用するテンプレートベースのデプロイメントから Red Hat OpenShift 4.1 を使用する operator ベースのデプロイメントに移行するには、以下の手順に従います。

  1. テンプレートベースのデプロイメントから 3scale のバックアップを作成する。
  2. operator を使用して 3scale をデプロイする。
  3. operator ベースのデプロイメントでバックアップを復元する。
  4. 3scale WILDCARD_DOMAIN (ここでは 3scale.example.com) を ocp4.example.com にポイントする。

上記の手順をすべて実施すると、3scale のテンプレートベースから operator ベースのデプロイメントへの移行が完了します。

第2章 テンプレートを使用した 3scale バージョン 2.11 からバージョン 2.12 へのアップグレード

Red Hat 3scale API Management をバージョン 2.11 からバージョン 2.12 にアップグレードするには、Open Shift 3.11 でテンプレートベースのデプロイメントを使用します。

重要

これは、OpenShift 3.11 上のテンプレートを使用してデプロイされた 3scale のアップグレードをサポートする最後のリリースです。今後のリリースで引き続きサポート対象となるには、3scale migration guide: from template to operator-based deployments に従ってください。

重要

必要な条件および手順を理解するために、記載の手順を適用する前に、アップグレードガイド全体を読んでください。アップグレードプロセスの手順が完了するまで、サービスの提供が中断されます。このサービス中断が生じるため、メンテナンス期間を設けるようにしてください。

2.1. アップグレードを行うための前提条件

本セクションでは、テンプレートベースのインストール環境において、3scale を 2.11 から 2.12 にアップグレードするのに必要な設定、タスク、およびツールについて説明します。

2.1.1. 設定

  • OpenShift 3.11 上の 3scale では、テンプレートを使用した 2.11 から 2.12 へのアップグレードパスがサポートされます。

2.1.2. 主要なタスク

  • OpenShift CLI ツールが 3scale をデプロイしたプロジェクトに設定されるようにする。
  • 3scale で使用しているデータベースのバックアップを行う。バックアップの手順は、データベースのタイプや設定により異なります。

2.1.3. ツール

アップグレードを行うには、以下のツールが必要です。

  • テンプレートを使用して OpenShift 3.11 のプロジェクトにデプロイされた 3scale 2.11
  • Bash シェル: アップグレード手順で詳細を説明するコマンドを実行します。
  • base64: シークレットの情報をエンコードおよびデコードします。
  • jq: JSON 変換用です。

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

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

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

Copy to Clipboard Toggle word wrap 
$ 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 でバックアップファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    $ 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 リソースをバックアップします。

    Copy to Clipboard Toggle word wrap 
    $ oc get -o yaml --export all > threescale-project-elements.yaml

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

    Copy to Clipboard Toggle word wrap 
    $ 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 コンテナーから変数を削除します。

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

      Copy to Clipboard Toggle word wrap 
      $ oc set env dc/system-app AMP_RELEASE-

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

    Copy to Clipboard Toggle word wrap 
    $ 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 が存在しないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ 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 設定ファイルに以下を追加します。

Copy to Clipboard Toggle word wrap 
[mysqld]
default_authentication_plugin=mysql_native_password

前の手順

未使用の AMP_RELEASE 変数の削除

現在の手順

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

注記

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

手順

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

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

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

    Copy to Clipboard Toggle word wrap 
    $ oc get cm mysql-extra-conf -o jsonpath='{.data.mysql-default-authentication-plugin\.cnf}'

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

      Copy to Clipboard Toggle word wrap 
      [mysqld]
default_authentication_plugin=mysql_native_password

次のステップ

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

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

前の手順

MySQL 設定のアップグレード

現在の手順

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

2.2.4.1. system イメージのパッチ

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

    Copy to Clipboard Toggle word wrap 
    $ 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 テンプレートをダウンロードし、アーカイブをデプロイメントします。

      Copy to Clipboard Toggle word wrap 
      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 オプションを使用して既存のビルドをオーバーライドします。

      Copy to Clipboard Toggle word wrap 
      $ oc process -f build.yml | oc apply -f -

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

      Copy to Clipboard Toggle word wrap 
      $ oc start-build 3scale-amp-system-oracle --from-dir=.

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

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

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-app --from-image=amp-system:2.11-oracle --containers=system-master,system-developer,system-provider --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-sidekiq --from-image=amp-system:2.11-oracle --containers=system-sidekiq,check-svc --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-sphinx --from-image=amp-system:2.11-oracle --containers=system-sphinx,system-master-svc --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-app --from-image=amp-system:2.11 --containers=system-master,system-developer,system-provider --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-sidekiq --from-image=amp-system:2.11 --containers=system-sidekiq,check-svc --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-sphinx --from-image=amp-system:2.11 --containers=system-sphinx,system-master-svc --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/apicast-staging --from-image=amp-apicast:2.11 --containers=apicast-staging --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/apicast-production --from-image=amp-apicast:2.11 --containers=apicast-production,system-master-svc --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/backend-listener --from-image=amp-backend:2.11 --containers=backend-listener --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/backend-worker --from-image=amp-backend:2.11 --containers=backend-worker,backend-redis-svc --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/backend-cron --from-image=amp-backend:2.11 --containers=backend-cron,backend-redis-svc --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/zync --from-image=amp-zync:2.11 --containers=zync,zync-db-svc --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/zync-que --from-image=amp-zync:2.11 --containers=que --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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 トリガーを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-memcache --from-image=system-memcached:2.11 --containers=memcache --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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. 以下のコマンドを実行します。

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

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

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

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/zync-database --from-image=zync-database-postgresql:2.11 --containers=postgresql --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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 が表示されれば、タグが作成されていることを確認することができます。

    Copy to Clipboard Toggle word wrap 
    $ oc get is backend-redis

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

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

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/backend-redis --from-image=backend-redis:2.11 --containers=backend-redis --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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 が表示されれば、タグが作成されていることを確認することができます。

    Copy to Clipboard Toggle word wrap 
    $ oc get is system-redis

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

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

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-redis --from-image=system-redis:2.11 --containers=system-redis --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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 が表示されれば、タグが作成されていることを確認することができます。

    Copy to Clipboard Toggle word wrap 
    $ oc get is system-mysql

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

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

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-mysql --from-image=system-mysql:2.11 --containers=system-mysql --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 イメージストリームにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ 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 が表示されれば、タグが作成されていることを確認することができます。

    Copy to Clipboard Toggle word wrap 
    $ oc get is system-postgresql

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

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

      Copy to Clipboard Toggle word wrap 
      $ oc set triggers dc/system-postgresql --from-image=system-postgresql:2.11 --containers=system-postgresql --remove

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

      Copy to Clipboard Toggle word wrap 
      $ 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 が含まれていることを確認します。

Copy to Clipboard Toggle word wrap 
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_* 変数を削除します。

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

      Copy to Clipboard Toggle word wrap 
      $ 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_* 変数を削除します。

    Copy to Clipboard Toggle word wrap 
    $ 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_* 環境変数が存在しないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ 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_* 変数を削除します。

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

      Copy to Clipboard Toggle word wrap 
      $ 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_* 変数を削除します。

    Copy to Clipboard Toggle word wrap 
    $ 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_* 環境変数が存在しないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ 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_* 変数を削除します。

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

      Copy to Clipboard Toggle word wrap 
      $ 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_* 環境変数が存在しないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ 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_* 変数を削除します。

    Copy to Clipboard Toggle word wrap 
    $ 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_* 環境変数が存在しないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get secret system-redis -o yaml | grep MESSAGE_BUS
2.2.5.5. PostgreSQL 10 および PostgreSQL 13 を使用した外部システムデータベースによるアップグレード

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

次のステップ

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

2.3. テンプレートベースのインストール環境での Oracle Database を使用した 3scale のアップグレード

本セクションでは、OpenShift 3.11 とテンプレートベースのインストール環境の組み合わせにおいて、Oracle Database で 3scale システムイメージを使用している場合に、Red Hat 3scale API Management をアップグレードする方法について説明します。

前提条件

Oracle Database を使用した 3scale インストール環境。Oracle Database を使用した 3scale システムイメージの設定 を参照してください。

テンプレートベースのインストール環境で Oracle Database を使用して 3scale のシステムイメージをアップグレードするには、以下の手順を実行します。

2.3.1. Oracle 19c を使用した 3scale のアップグレード

以下の手順では、Oracle Database 19c の更新、既存の 3scale 2.11 インストール環境から 3scale 2.12 への変更について説明します。

重要:データベースへの接続が失われると、3scale が破損する可能性があります。アップグレードを進める前にバックアップを作成します。詳細については、Oracle データベースのドキュメントを参照してください。Oracle Database Backup and Recovery User's Guideを参照してください。

前提条件

  • 3scale 2.11 のインストール

  • Oracle Database 19c のインストール

手順

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

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

  3. -f オプションで build.yml OpenShift テンプレートを指定して、oc process コマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc process -f build.yml | oc apply -f -

  4. -f オプションで amp.yml OpenShift テンプレートを指定し、-p オプションで WILDCARD_DOMAIN パラメーターに OpenShift クラスターのドメインを指定して、oc new-app コマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc new-app -f amp.yml -p WILDCARD_DOMAIN=mydomain.com
    注記

    以下の手順は任意です。インストール後やシステムアップグレード後にORACLE_SYSTEM_PASSWORDを削除する場合に使用します。

  5. 以下の oc patch コマンドを入力します。SYSTEM_PASSWORD はOracle Database の準備 で設定した Oracle Database の system パスワードに置き換えます。

    Copy to Clipboard Toggle word wrap 
    $ oc patch dc/system-app -p '[{"op": "add", "path": "/spec/strategy/rollingParams/pre/execNewPod/env/-", "value": {"name": "ORACLE_SYSTEM_PASSWORD", "value": "SYSTEM_PASSWORD"}}]' --type=json

$ oc patch dc/system-app -p '{"spec": {"strategy": {"rollingParams": {"post":{"execNewPod": {"env": [{"name": "ORACLE_SYSTEM_PASSWORD", "value": "SYSTEM_PASSWORD"}]}}}}}}'

  6. 以下のコマンドを入力します。DATABASE_URL はOracle Database の準備で指定した Oracle Database を参照するように置き換えます。

    Copy to Clipboard Toggle word wrap 
    $ oc patch secret/system-database -p '{"stringData": {"URL": "DATABASE_URL"}}'

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

    Copy to Clipboard Toggle word wrap 
    $ oc start-build 3scale-amp-system-oracle --from-dir=.

  8. ビルドが完了するまで待ちます。ビルドの状態を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc get build <build-name> -o jsonpath="{.status.phase}"
    1. ビルドが Complete の状態になるまで待ちます。

  9. Oracle Database で 3scale システムイメージを設定したら、system-app DeploymentConfig から ORACLE_SYSTEM_PASSWORD を削除します。新しいバージョンの 3scale にアップグレードするまで再度削除する必要はありません。

    Copy to Clipboard Toggle word wrap 
    $ oc set env dc/system-app ORACLE_SYSTEM_PASSWORD-

open_cursors パラメーター設定の検証

このデータベースの open_cursors パラメーターが 1000 より大きい値に設定されていることを確認する必要があります。

これを行うには、SYSTEM ユーザーとして Oracle Database にログインし、次のコマンドを実行します。

Copy to Clipboard Toggle word wrap 
show parameter open_cursors;

戻り値は少なくとも 1000 である必要があります。そうでない場合は、open cursors に関する次の Oracle のドキュメントに従って、パラメーターを 1000 より大きい値に変更します。

open_cursors パラメーターが以前に 1000 未満の制限に設定されていて、値を増加させなかった場合は、OpenShift の system-app Pod ログの 1 つに次のエラーが表示される場合があります。

Copy to Clipboard Toggle word wrap 
ORA-01000: maximum open cursors exceeded

関連情報

3scale と Oracle Database のサポートについては、Red Hat 3scale API Management のサポート対象設定 を参照してください。

第3章 operator ベースの 3scale のアップグレードガイド: 2.11 から 2.12 へ

operator ベースのインストールで Red Hat 3scale API Management をバージョン 2.11 から 2.12 にアップグレードして、Open Shift 4.x で 3scale を管理できるようにします。

3scale のマイクロリリースを自動的に取得するには、自動更新が有効であることを確認してください。これを確認するには、Setting up the 3scale operator for micro releases を参照してください。

重要

必要な条件および手順を理解するために、記載の手順を適用する前に、アップグレードガイド全体を読んでください。アップグレードプロセスの手順が完了するまで、サービスの提供が中断されます。このサービス中断が生じるため、メンテナンス期間を設けるようにしてください。

3.1. アップグレードを行うための前提条件

本セクションでは、operator ベースのインストール環境において、3scale を 2.11 から 2.12 にアップグレードするのに必要な設定について説明します。

  • OpenShift Container Platform (OCP) 4.6、4.7、4.8、4.9、または 4.10 クラスターおよびその管理者アクセス
  • 3scale operator によりデプロイされている 3scale 2.11

  • threescale-2.11 チャネルの最新 CSV が使用されていることを確認します。以下を確認してください。

    • サブスクリプションの承認設定が自動の場合は、すでに最新の CSV バージョンのチャンネルになっているはずです。
    • サブスクリプションの承認設定が手動の場合、保留中のすべての Install Plans を承認し、最新の CSV バージョンがあることを確認してください。
    • 保留中のインストールプランがある場合、さらに保留中のインストールプランがある可能性があり、既存の保留中のプランがインストールされた後にのみ表示されることに注意してください。

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

operator ベースのデプロイメントにおいて、3scale をバージョン 2.11 から 2.12 にアップグレードするには、以下の手順を実施します。

  1. 管理者権限を持つアカウントを使用して OCP コンソールにログインします。
  2. 3scale-operator がデプロイされているプロジェクトを選択します。
  3. Operators > Installed Operators の順にクリックします。
  4. Red Hat Integration - 3scale > Subscription > Channel の順に選択します。

  5. threescale-2.12 を選択してサブスクリプションのチャンネルを編集し、変更を保存します。

    これによりアップグレードプロセスが開始されます。

  6. すべての新しいバージョンが実行され、エラーなく準備ができていることを確認するまで、プロジェクトで Pod の状態を照会します。

    Copy to Clipboard Toggle word wrap 
    $ oc get pods
    注記
    • Pod ではアップグレードプロセス中、一時的にエラーが発生する場合があります。
    • Pod のアップグレードに必要な時間は、5～10 分程度です。
  7. 新しい Pod のバージョンの実行後に、3scale Admin Portal にログインして、想定どおりに動作することをチェックし、アップグレードが正常に行われたことを確認します。

  8. 以下のコマンドを実行して、APIManagerオブジェクトのステータスを確認し、YAMLコンテンツを取得します。 <myapimanager> は、APIManagerの名前を表します。

    Copy to Clipboard Toggle word wrap 
    $ oc get apimanager <myapimanager> -o yaml

    • 新しいアノテーションおよび値は以下のようになります。

      Copy to Clipboard Toggle word wrap 
      apps.3scale.net/apimanager-threescale-version: "2.12"
apps.3scale.net/threescale-operator-version: "0.9.0"

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

3.2.1. 外部 MySQL バージョンの 8.0 へのアップグレード

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

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

Copy to Clipboard Toggle word wrap 
[mysqld]
default_authentication_plugin=mysql_native_password

3.2.2. 未使用の MessageBus 変数の削除

3scale デプロイメントで外部データベースモードが有効になっている場合は、system-redis シークレットから MESSAGE_BUS_* フィールドを手動で削除する必要があります。

  1. system-redis シークレットから MESSAGE_BUS_* フィールドを削除します。シークレットが外部コントローラーによって管理されていない場合は、次のコマンドを使用して手動で更新します。

    Copy to Clipboard Toggle word wrap 
    $ 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_* フィールドが存在しないことを確認します。次のコマンドは空を返す必要があります。

    Copy to Clipboard Toggle word wrap 
    $ oc get secret system-redis -o yaml | grep MESSAGE_BUS

3.2.3. PostgreSQL 10 および PostgreSQL 13 を使用した外部システムデータベースによるアップグレード

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

第4章 operator ベースの APIcast のアップグレードガイド: 2.11 から 2.12 へ

オペレータベースのインストールで APIcast を 2.11 から 2.12 にアップグレードすると、APIcast API ゲートウェイを使用して、内部および外部の API サービスを 3scale と統合できます。

重要

必要な条件および手順を理解するために、記載の手順を適用する前に、アップグレードガイド全体を読んでください。アップグレードプロセスの手順が完了するまで、サービスの提供が中断されます。このサービス中断が生じるため、メンテナンス期間を設けるようにしてください。

4.1. アップグレードを行うための前提条件

operator ベースのインストールで APIcast を 2.11 から 2.12 にアップグレードするには、以下の前提条件を満たしている必要があります。

  • OpenShift Container Platform (OCP) 4.6、4.8、4.9、または 4.10 クラスターおよびその管理者アクセス
  • APIcast operator によりデプロイされている APIcast 2.11

  • threescale-2.11 チャネルの最新 CSV が使用されていることを確認します。以下を確認してください。

    • サブスクリプションの承認設定が自動の場合は、すでに最新の CSV バージョンのチャンネルになっているはずです。
    • サブスクリプションの承認設定が手動の場合、保留中のすべての Install Plans を承認し、最新の CSV バージョンがあることを確認してください。
    • 保留中のインストールプランがある場合、さらに保留中のインストールプランがある可能性があり、既存の保留中のプランがインストールされた後にのみ表示されることに注意してください。

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

operator ベースのインストールで、APIcast を 2.11 から 2.12 にアップグレードし、APIcast が 3scale のインストールで API ゲートウェイとして機能するようにします。

手順

  1. 管理者権限を持つアカウントを使用して OCP コンソールにログインします。
  2. APIcast operator がデプロイされているプロジェクトを選択します。
  3. Operators > Installed Operators の順にクリックします。
  4. Subscription > Channel の順に移動し、Red Hat Integration - 3scale APIcast gateway を選択します。

  5. threescale-2.12 チャンネルを選択してサブスクリプションのチャンネルを編集し、変更を保存します。

    これによりアップグレードプロセスが開始されます。

  6. すべての新しいバージョンが実行され、エラーなく準備ができていることを確認するまで、プロジェクトで Pod の状態を照会します。

    Copy to Clipboard Toggle word wrap 
    $ oc get pods
    注記
    • Pod ではアップグレードプロセス中、一時的にエラーが発生する場合があります。
    • Pod のアップグレードに必要な時間は、5～10 分程度です。

  7. APIcast オブジェクトのステータスを確認し、以下のコマンドを実行して YAML のコンテンツを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get apicast <myapicast> -o yaml

    • 新しいアノテーションおよび値は以下のようになります。

      Copy to Clipboard Toggle word wrap 
      apicast.apps.3scale.net/operator-version: “0.6.0”

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

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.