2.4. WildcardRouter에서 Zync 경로 관리로 마이그레이션
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가 현재 가지고 있는 것과 동등한 경로를 만듭니다.
Public Base URL이 수정되면 system-app
에서 이벤트가 트리거되고 system-redis
에 저장된 작업 대기열을 통해 system-sidekiq
에 알립니다. 그러면 작업이 백그라운드에서 처리되고 zync-db
에 데이터가 있는지 여부를 확인하는 zync로 전송됩니다. 변경 사항을 감지하면 zync-que
에서 처리된 작업을 통해 새 경로를 생성합니다.
작업을 수행하기 전에 일부 경로에 SSL 인증서를 수동으로 설치한 경우 경로에 할당된 인증서를 복사하고 각 인증서가 할당된 경로를 기록해야 합니다. 인증서 기능을 유지하려면 Zync에서 생성할 새로운 동등한 경로에 설치해야 합니다.
- 서비스는 기본적으로 호스팅된 옵션과 함께 마이그레이션됩니다.
- Public Base URL은 자동으로 입력되고 경로가 Zync에 의해 생성됩니다.
- 1단계는 옵션 self_managed 를 사용하여 외부 APIcast 게이트웨이를 구성하는 경우에만 필요합니다.
- 3scale_managed 옵션을 선택하면 Zync에서 경로가 자동으로 관리됩니다.
절차
Zync가 외부 게이트웨이의 경로를 관리하지 않으므로 제안된 대안 중 하나의 단계에 따라 Zync에서 관리하지 않는 각 서비스의 배포 옵션을 수정할 수 있습니다.
3scale에서 다음을 수행합니다.
- 통합 페이지로 이동하여 통합 설정 편집 을 클릭합니다.
- 올바른 배포 옵션을 선택하고 변경 사항을 해당하는 경우 저장합니다.
API 사용:
액세스 토큰(
ACCESS_TOKEN
)과 테넌트 엔드포인트(TENANT_URL
)를 사용하여 서비스ID
(ID)로 서비스를 업데이트합니다.$ 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
을호스팅
하도록 설정합니다.
잠재적으로 존재하는 경로 중 일부 기본 경로는 2.5에서 3scale로 자동 생성되었습니다. 이를 제거하려면 다음을 실행합니다.
$ 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에 의해 동등한 경로 생성을 수행합니다.
3scale 서비스 및 테넌트 OpenShift 경로를 모두 Zync로 강제로 다시 동기화합니다.
$ 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 테넌트마다 두 개의 경로가 생성됩니다.
- 테넌트의 관리 포털 경로.
테넌트의 개발자 포털 경로.
3scale 서비스마다 두 개의 경로가 생성됩니다.
- 서비스에 해당하는 APIcast 스테이징 경로
- 서비스에 해당하는 APIcast 프로덕션 경로입니다.
위에서 설명한 모든 예상 경로가 기존 서비스 및 테넌트에 대해 생성되었는지 확인합니다. 다음을 실행하여 모든 경로를 볼 수 있습니다.
$ oc get routes
이전 명령의 출력으로 표시된 host/port 필드는 경로의 URL이어야 합니다.
-
WILDCARD_POLICY를
Subdomain
으로 설정하여 3scale 2.5를 배포한 경우 모든 새 경로에 이전 OpenShift 와일드카드 경로와 동일한 기본 WildcardDomain이 있어야 합니다. - 그렇지 않으면 WILDCARD_POLICY=Subdomain 없이 3scale 2.5를 배포한 경우 2.5 릴리스에서 3scale에 의해 자동으로 생성된 경로를 포함하여 새 경로가 제거된 이전 경로와 동일한 호스트를 보유해야 합니다.
-
WILDCARD_POLICY를
- 마지막으로 이전 와일드카드 경로 또는 수동으로 생성한 경로에 사용자 정의 SSL 인증서를 사용하는 경우 Zync에서 생성한 새 경로에 설치합니다. OpenShift 웹 패널을 통해 경로를 편집하고 인증서/s를 여기에 추가하여 이를 수행할 수 있습니다.
이 마이그레이션 이전에 존재하는 서비스 및 테넌트는 새 경로를 사용하여 여전히 확인할 수 있는지 확인합니다. 이 작업을 수행하려면 다음 테스트를 수행합니다.
- 이 마이그레이션 전에 이미 존재하는 3scale 서비스와 관련된 기존 APIcast 프로덕션 URL의 경로를 해결합니다.
- 이 마이그레이션 전에 이미 존재하는 3scale 서비스와 연결된 기존 APIcast 스테이징 URL의 경로를 해결합니다.
- 이 마이그레이션 전에 이미 존재하는 기존 테넌트의 경로를 해결합니다.
새 Zync 기능이 작동하는지 확인할 때 새 테넌트 및 서비스를 생성할 때 새 경로가 생성되었는지 확인합니다. 이 작업을 수행하려면 다음 테스트를 수행합니다.
- '마스터' 패널에서 새 테넌트를 생성하고 몇 초 후에 OpenShift에 연결된 새 경로가 표시되는지 확인합니다.
- 기존 테넌트 중 하나에서 새 서비스를 생성하고 몇 초 후에 OpenShift에 연결된 새 경로가 표시되는지 확인합니다.
apicast-wildcard-router 서비스를 제거합니다.
$ oc delete service apicast-wildcard-router
더 이상 사용되지 않는 WildcardRouter 하위 시스템을 제거합니다.
$ oc delete ImageStream amp-wildcard-router $ oc delete DeploymentConfig apicast-wildcard-router
나열된 모든 단계를 수행한 후 템플릿 기반 배포에서 2.6에서 2.7로 3scale 업그레이드가 완료되었습니다.
2.4.1. 기존 DeploymentConfigs를 사용하는 추가 단계
2.4.1.1. backend-redis
DeploymentConfig
현재 3scale 설치에 backend-redis
DeploymentConfig가 있는 경우 backend-redis
이미지 스트림을 패치합니다.
$ oc patch imagestream/backend-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Backend 2.7 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-32-rhel7:3.2"}, "name": "2.7", "referencePolicy": {"type": "Source"}}}]' $ oc patch imagestream/backend-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Backend Redis (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.7"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
-
이 패치는
2.7
태그를 포함하도록backend-redis
이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에2.7
이 표시되면 태그가 생성되었는지 확인할 수 있습니다.
$ oc get is backend-redis
-
이 패치는 이미지에 새 업데이트가 있는 경우
backend-redis
DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비될 때까지 기다린 후 이전 Pod가 종료됩니다.
3scale 이미지 업그레이드 를 계속합니다.
2.4.1.2. system-redis
DeploymentConfig
현재 3scale 설치에 system-redis
DeploymentConfig가 있는 경우 system-redis
이미지 스트림을 패치합니다.
$ oc patch imagestream/system-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.7 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-32-rhel7:3.2"}, "name": "2.7", "referencePolicy": {"type": "Source"}}}]' $ oc patch imagestream/system-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System Redis (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.7"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
-
이 패치는
2.7
태그를 포함하도록system-redis
이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에2.7
이 표시되면 태그가 생성되었는지 확인할 수 있습니다.
$ oc get is system-redis
-
이 패치는 이미지에 새 업데이트가 있는 경우
system-redis
DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비될 때까지 기다린 후 이전 Pod가 종료됩니다.
3scale 이미지 업그레이드 를 계속합니다.
2.4.1.3. system-mysql
DeploymentConfig
현재 3scale 설치에 system-mysql
DeploymentConfig가 있는 경우 system-mysql
이미지 스트림을 패치합니다.
$ oc patch imagestream/system-mysql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.7 MySQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/mysql-57-rhel7:5.7"}, "name": "2.7", "referencePolicy": {"type": "Source"}}}]' $ oc patch imagestream/system-mysql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System MySQL (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.7"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
-
이 패치는
2.7
태그를 포함하도록system-mysql
이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에2.7
이 표시되면 태그가 생성되었는지 확인할 수 있습니다.
$ oc get is system-mysql
-
이 패치는 이미지에 새 업데이트가 있는 경우
system-mysql
DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비될 때까지 기다린 후 이전 Pod가 종료됩니다.
3scale 이미지 업그레이드 를 계속합니다.
2.4.1.4. system-postgresql
DeploymentConfig
현재 3scale 설치에 system-postgresql
DeploymentConfig가 있는 경우 system-postgresql
이미지 스트림을 패치합니다.
$ oc patch imagestream/system-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.7 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7"}, "name": "2.7", "referencePolicy": {"type": "Source"}}}]' $ oc patch imagestream/system-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System PostgreSQL (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.7"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
-
이 패치는
2.7
태그를 포함하도록system-postgresql
이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에2.7
이 표시되면 태그가 생성되었는지 확인할 수 있습니다.
$ oc get is system-postgresql
-
이 패치는 이미지에 새 업데이트가 있는 경우
system-postgresql
DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비될 때까지 기다린 후 이전 Pod가 종료됩니다.
3scale 이미지 업그레이드 를 계속합니다.