2.9. WildcardRouter から Zync Route Management への移行
3scale 2.6 では、WildcardRouter コンポーネントとワイルドカード OpenShift ルートが削除され、Zync サブシステムによって管理される個別の OpenShift ルートとして作成されるようになりました。この手順では、WildcardRouter から Zync へのルート管理の移行について詳しく説明します。
この時点で、すべての 3scale イメージが 3scale 2.6 にアップグレードされています。3scale サービスとテナントに対応する OpenShift ルートの作成と削除は、Zync サブシステムによって自動的に管理されます。さらに、そのために必要なすべての新しい Zync インフラストラクチャーは、前のセクション新しく OpenShift 要素を追加することで利用可能になります。
OpenShift ルート管理を WildcardRouter から Zync に移行するには、OpenShift ルートとワイルドカードルートに関連する古い 3scale テナントとサービスを削除してから、Zync による既存のサービスとテナントの強制的な再評価を実行する必要があります。これにより、Zync は現在持っているものと同等のルートを作成します。
パブリックベース URL が変更されると、system-app
でイベントがトリガーされ、system-redis
に保存されているジョブキューを介して system-sidekiq
に通知されます。ジョブはバックグラウンドで処理され、zync に送信され、データが zync-db
にすでに存在するかどうかがチェックされます。変更を検出すると、zync-que
で処理されたジョブを介して新しいルートを作成します。
SSL 証明書をいくつかのルートに手動でインストールした場合は、操作を行う前に、ルートに割り当てられた証明書をコピーし、各証明書が割り当てられたルートをメモしておく必要があります。証明書の機能を維持する場合は、Zync で作成される同等の新規ルートに証明書をインストールする必要があります。
- サービスはデフォルトで、hosted オプションを使用して移行されます。
- パブリックベース URL は自動的に入力され、ルートは Zync によって作成されます。
- ステップ 1 は、オプション self_managed を使用して外部 APIcast ゲートウェイを設定する場合にのみ必要です。
- 3scale_managed オプションを選択すると、ルートは Zync によって自動的に管理されます。
手順
Zync が外部ゲートウェイのルートを管理しない場合、提案された代替案のいずれかの手順に従って、Zync で管理されない各サービスのデプロイメントオプションを変更できます。
3scale で以下の操作を行います。
- Integration ページに移動し、edit integration settings をクリックします。
- 適切なデプロイメントオプションを選択し、変更があれば保存します。
API の使用
サービス識別子 (
ID
) とアクセストークン (ACCESS_TOKEN
) およびテナントエンドポイント (TENANT_URL
) でサービスを更新します。$ curl -XPUT "${TENANT_URL}/admin/api/services/${ID}.json" -d deployment_option=self_managed -d access_token="${ACCESS_TOKEN}"
または、ホストされている APIcast を使用している場合は、次のコマンドを使用できます。
$ curl -XPUT "${TENANT_URL}/admin/api/services/${ID}.json" -d deployment_option=hosted -d access_token="${ACCESS_TOKEN}"
各テナントのサービスごとに、3scale または API を介して
deployment_option
フィールドを変更します。deployment_option
をself_managed
に設定できるケースは次のとおりです。- APIcast は、OpenShift のカスタムルートにリンクされています。
- APIcast は OpenShift の外部でホストされます。
-
APICAST_PATH_ROUTING
がtrue
に設定されています。
-
それ以外の場合は、
deployment_option
をhosts
に設定します。
存在する可能性のあるルートの中で、デフォルトのルートの中で 3scale が 2.5 で自動的に作成したものがあります。それらを削除することから始めます。
$ oc delete route system-master $ oc delete route system-provider-admin $ oc delete route system-developer $ oc delete route api-apicast-production $ oc delete route api-apicast-staging
WILDCARD_POLICY=
Subdomain を指定して 3scale 2.5 をデプロイした場合は、以下を使用してワイルドカードルートを削除する必要があります。$ oc delete route apicast-wildcard-router
-
それ以外の場合、
WILDCARD_POLICY=
Subdomain を指定せずに 3scale 2.5 をデプロイした場合は、Zync が作成するルートの重複を避けるために、3scale テナントおよびサービス用に手動で作成したルートを削除する必要があります。
この時点で、サービスとテナントに関連するすべてのルートが削除されている必要があります。ここで、Zync による同等のルートの作成を実行します。
Zync を使用して、すべての 3scale サービスとテナント OpenShift ルートを強制的に再度同期します。
$ SYSTEM_SIDEKIQ_POD=$(oc get pods | grep sidekiq | awk '{print $1}')
SYSTEM_SIDEKIQ_POD 環境変数の結果が空でないことを確認します。
$ echo ${SYSTEM_SIDEKIQ_POD}
最後に、再同期を実行します。
$ oc exec -it ${SYSTEM_SIDEKIQ_POD} -- bash -c 'bundle exec rake zync:resync:domains'
システムへの通知に関する情報を含むこのスタイルの出力が表示されます。
No valid API key has been set, notifications will not be sent ActiveMerchant MODE set to 'production' [Core] Using http://backend-listener:3000/internal/ as URL OpenIdAuthentication.store is nil. Using in-memory store. [EventBroker] notifying subscribers of Domains::ProviderDomainsChangedEvent 59a554f6-7b3f-4246-9c36-24da988ca800 [EventBroker] notifying subscribers of ZyncEvent caa8e941-b734-4192-acb0-0b12cbaab9ca Enqueued ZyncWorker#d92db46bdba7a299f3e88f14 with args: ["caa8e941-b734-4192-acb0-0b12cbaab9ca", {:type=>"Provider", :id=>1, :parent_event_id=>"59a554f6-7b3f-4246-9c36-24da988ca800", :parent_event_type=>"Domains::ProviderDomainsChangedEvent", :tenant_id=>1}] [EventBroker] notifying subscribers of Domains::ProviderDomainsChangedEvent 9010a199-2af1-4023-9b8d-297bd618096f …
強制的に Zync による再評価を行った後に、すべての既存テナントおよびサービスに対して新規ルートが作成されます。サービスおよびテナントの数によっては、ルートの作成に数分かかる場合があります。
プロセスが完了するまでに、以下が作成されたことが分かります。
1 つのマスター管理ポータルルート。
3scale テナントごとに、以下の 2 つのルートが作成されます。
- テナントの管理ポータルルート。
テナントの開発者ポータルルート。
3scale サービスごとに 2 つのルートが作成されます。
- サービスに対応する APIcast staging Route。
- サービスに対応する APIcast production Route。
上記で説明した予想されるすべてのルートが、既存のすべてのサービスとテナントに対して作成されていることを確認します。次のコマンドを実行すると、すべてのルートを表示できます。
$ oc get routes
前のコマンドの出力として表示されるホスト/ポートフィールドは、ルートの URL である必要があります。
-
WILDCARD_POLICY を Subdomain に設定して
3scale
2.5 をデプロイした場合には、新しいルートはすべて、古い OpenShift ワイルドカードルートと同じベースの WildcardDomain を指定する必要があります。 - それ以外の場合、WILDCARD_POLICY=Subdomain なしで 3scale 2.5 をデプロイした場合に、新しいルートは、2.5 リリースで 3scale によって自動的に作成されたものを含め、削除した古いルートと同じホストを指定する必要があります。
-
WILDCARD_POLICY を Subdomain に設定して
- 最後に、古いワイルドカードルート、または手動で作成された古いルートにカスタム SSL 証明書を使用していた場合は、その証明書を Zync で作成された新しいルートにインストールします。これには、OpenShift Web パネルでルートを編集し、証明書をルートに追加します。
この移行の前に存在していたサービスとテナントが、新しいルートを使用して引き続き解決できることを確認します。このタスクを実行するには、以下のテストを実行します。
- この移行の前にすでに存在していた 3scale サービスに関連付けられた既存の APIcast 実稼働 URL のルートを解決します。
- この移行の前にすでに存在していた 3scale サービスに関連付けられた既存の APIcast ステージング URL のルートを解決します。
- この移行の前にすでに存在していた既存のテナントのルートを解決します。
新しい Zync 機能が動作していることを確認するときに、新しいテナントとサービスの作成時に新しいルートが生成されることを確認します。このタスクを実行するには、以下のテストを実行します。
- マスターパネルから新しいテナントを作成し、数秒後にそれに関連付けられた新しいルートが OpenShift に表示されることを確認します。
- 既存のテナントの 1 つで新しいサービスを作成し、数秒後にそれに関連付けられた新しいルートが OpenShift に表示されることを確認します。
apicast-wildcard-router サービスを削除します。
$ oc delete service apicast-wildcard-router
非推奨の WildcardRouter サブシステムを削除します。
$ oc delete ImageStream amp-wildcard-router $ oc delete DeploymentConfig apicast-wildcard-router
リストされたすべてのステップを実行すると、2.5 から 2.6 への 3scale のアップグレードが完了します。