3scale 마이그레이션
3scale API Management 및 해당 구성 요소를 마이그레이션 또는 업그레이드
초록
머리말
이 가이드에서는 Red Hat 3scale API Management를 템플릿에서 Operator 기반 설치로 마이그레이션하는 방법, 3scale 설치를 2.9에서 2.10으로 업그레이드하는 데 필요한 세부 정보, 운영자 기반 배포에서 APIcast를 업그레이드하는 단계를 설명합니다.
템플릿 기반 배포에서 운영자 기반 배포로 마이그레이션하려면 3scale 마이그레이션 가이드에 나열된 절차를 참조하십시오.
3scale 온-프레미스 배포를 2.9에서 2.10으로 업그레이드하려면 설치 유형에 따라 다음 가이드 중 하나를 참조하십시오.
Operator 기반 배포의 APIcast를 업그레이드하려면 APIcast 업그레이드 가이드에 나열된 절차를 참조하십시오.
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지에서 참조하십시오.
1장. 3scale 마이그레이션 가이드: 템플릿에서 Operator 기반 배포로
이 섹션에서는 Red Hat OpenShift 3.11을 사용하여 템플릿 기반 배포에서 Red Hat OpenShift 4.x를 사용하는 operator 기반 배포로 Red Hat 3scale API Management를 마이그레이션하는 방법에 대해 설명합니다.
필요한 조건 및 절차를 이해하려면 나열된 단계를 적용하기 전에 전체 마이그레이션 가이드를 살펴보십시오. 마이그레이션 프로세스에서 절차가 완료될 때까지 서비스 프로비저닝을 중단합니다. 이러한 중단으로 인해 유지 관리 기간이 있는지 확인하십시오.
1.1. 마이그레이션을 수행하기 위한 사전 요구 사항
3scale 설치를 템플릿에서 operator 기반 배포로 마이그레이션하기 전에 다음 가이드를 참조하여 배포를 지원하는지 확인합니다.
1.2. 3scale 템플릿을 Operator 기반 배포로 마이그레이션
마이그레이션 전 기본 설정은 3scale이 OCP3 도메인을 가리키는 것입니다: 3scale.example.com → ocp3.example.com
Red Hat OpenShift 3.11을 사용하여 템플릿 기반 배포에서 Red Hat OpenShift 4.1을 사용하여 Operator 기반 배포로 3scale을 마이그레이션하려면 다음 단계를 따르십시오.
- 템플릿 기반 배포에서 3scale 백업을 생성합니다.
- Operator를 사용하여 3scale을 배포합니다.
- Operator 기반 배포에서 백업을 복원합니다.
-
3scale WILDCARD_DOMAIN을 가리키며 이 경우
3scale.example.com을ocp4.example.com으로 지정합니다.
나열된 모든 단계를 수행한 후 템플릿에서 operator 기반 배포로 3scale 마이그레이션을 완료했습니다.
2장. 3scale 템플릿 기반 업그레이드 가이드: 2.9에서 2.10으로
이 섹션에서는 템플릿 기반 배포에서 Red Hat 3scale API Management를 버전 2.9에서 2.10으로 업그레이드하는 방법에 대해 설명합니다.
필요한 조건 및 절차를 이해하려면 나열된 단계를 적용하기 전에 전체 업그레이드 가이드를 읽으십시오. 업그레이드 프로세스에서 절차가 완료될 때까지 서비스 프로비저닝을 중단합니다. 이러한 중단으로 인해 유지 관리 기간이 있는지 확인하십시오.
2.1. 업그레이드를 수행하기 위한 사전 요구 사항
이 섹션에서는 템플릿 기반 설치에서 3scale을 2.9에서 2.10으로 업그레이드하는 데 필요한 구성, 작업 및 도구에 대해 설명합니다.
2.1.1. 구성
- 3scale은 OpenShift 3.11의 템플릿을 사용하여 2.9에서 2.10으로 업그레이드 경로를 지원합니다.
2.1.2. 사전 작업
- 3scale이 배포된 프로젝트와 동일한 프로젝트에서 OpenShift CLI 도구가 구성되었는지 확인합니다.
- 3scale과 함께 사용하는 데이터베이스 백업을 수행합니다. 백업 절차는 각 데이터베이스 유형 및 설정에 따라 다릅니다.
2.1.3. 툴
업그레이드를 수행하려면 다음 툴이 필요합니다.
- 3scale 2.9는 OpenShift 3.11 프로젝트의 템플릿과 함께 배포됩니다.
- bash shell: 업그레이드 절차에 자세히 설명된 명령을 실행합니다.
- base64: 시크릿 정보를 인코딩 및 디코딩합니다.
- jq: JSON 변환의 경우 필요합니다.
2.2. 템플릿 기반 설치에서 2.9에서 2.10으로 업그레이드
이 섹션에 설명된 절차에 따라 템플릿 기반 설치에서 3scale 2.9를 2.10으로 업그레이드하십시오.
업그레이드를 시작하려면 3scale이 배포된 프로젝트로 이동합니다.
$ oc project <3scale-project>
다음 단계를 순서대로 수행합니다.
2.2.1. 3scale 프로젝트의 백업 생성
이전 단계
없음.
현재 단계
이 단계에서는 3scale 프로젝트의 백업을 생성하는 데 필요한 작업이 나열됩니다.
3scale과 함께 사용되는 데이터베이스에 따라 다음 값 중 하나를 사용하여 ${SYSTEM_DB}를 설정합니다.
-
데이터베이스가 MySQL인 경우
SYSTEM_DB=system-mysql. -
데이터베이스가 PostgreSQL인 경우
SYSTEM_DB=system-postgresql.
-
데이터베이스가 MySQL인 경우
기존 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 ; doneexport all명령을 통해 내보낸 프로젝트에서 기존 OpenShift 리소스를 모두 백업합니다.$ oc get -o yaml --export all > threescale-project-elements.yaml
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
- 생성된 모든 파일이 비어 있지 않으며 모든 파일에 필요한 콘텐츠가 있는지 확인합니다.
2.2.2. 3scale 버전 번호 업데이트
현재 단계
이 단계에서는 system-environment ConfigMap에서 3scale 릴리스 버전 번호를 2.9 에서 2.10 으로 업데이트합니다. AMP_RELEASE는 일부 DeploymentConfig 컨테이너 환경에서 참조되는 ConfigMap 항목입니다.
AMP_RELEASE를 패치하려면 다음 명령을 실행합니다.
$ oc patch cm system-environment --patch '{"data": {"AMP_RELEASE": "2.10"}}'system-environment ConfigMap의 AMP_RELEASE 키의
2.10값이 있는지 확인합니다.$ oc get cm system-environment -o json | jq '.data["AMP_RELEASE"]'
2.2.3. 3scale 이미지 업그레이드
현재 단계
이 단계에서는 업그레이드 프로세스에 필요한 3scale 이미지를 업데이트합니다.
2.2.3.1. system 이미지 패치
새 이미지 스트림 태그를 생성합니다.
$ oc patch imagestream/amp-system --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP system 2.10"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/system-rhel7:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'이 절차를 계속하려면 3scale 배포와 함께 사용되는 데이터베이스를 고려하십시오.
- 데이터베이스가 Oracle DB인 경우 다음에 설명된 단계를 따르십시오. 2.2.3.1.1절. “Oracle Database를 사용하여 3scale 시스템 이미지 패치하기”
- 데이터베이스가 Oracle DB와 다른 경우 다음에 설명된 단계를 따르십시오. 2.2.3.1.2절. “다른 데이터베이스를 사용하여 3scale 시스템 이미지 패치하기”
2.2.3.1.1. Oracle Database를 사용하여 3scale 시스템 이미지 패치하기
- Oracle Database로 3scale의 시스템 이미지 패치를 시작하려면 Oracle 19c를 사용하여 3scale 2.9에서 2.10으로 다음 절차를 수행합니다.
system-app ImageChangeTrigger를 패치합니다.
이전
2.9-oracle트리거를 제거합니다.$ oc set triggers dc/system-app --from-image=amp-system:2.9-oracle --containers=system-master,system-developer,system-provider --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-app --from-image=amp-system:2.10-oracle --containers=system-master,system-developer,system-provider
이렇게 하면
system-app이 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
system-sidekiqImageChange 트리거를 패치합니다.이전
2.9-oracle트리거를 제거합니다.$ oc set triggers dc/system-sidekiq --from-image=amp-system:2.9-oracle --containers=system-sidekiq,check-svc --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-sidekiq --from-image=amp-system:2.10-oracle --containers=system-sidekiq,check-svc
이렇게 하면
system-sidekiq가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
system-sphinxImageChange 트리거를 패치합니다.이전
2.9-oracle트리거를 제거합니다.$ oc set triggers dc/system-sphinx --from-image=amp-system:2.9-oracle --containers=system-sphinx,system-master-svc --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-sphinx --from-image=amp-system:2.10-oracle --containers=system-sphinx,system-master-svc
그러면
system-sphinx가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
- 축소하려는 경우 3scale을 축소하면 됩니다.
2.2.3.1.2. 다른 데이터베이스를 사용하여 3scale 시스템 이미지 패치하기
system-appImageChange 트리거에 패치를 적용합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/system-app --from-image=amp-system:2.9 --containers=system-master,system-developer,system-provider --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-app --from-image=amp-system:2.10 --containers=system-master,system-developer,system-provider
이렇게 하면
system-app이 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
system-sidekiqImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/system-sidekiq --from-image=amp-system:2.9 --containers=system-sidekiq,check-svc --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-sidekiq --from-image=amp-system:2.10 --containers=system-sidekiq,check-svc
이렇게 하면
system-sidekiq가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
system-sphinxImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/system-sphinx --from-image=amp-system:2.9 --containers=system-sphinx,system-master-svc --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-sphinx --from-image=amp-system:2.10 --containers=system-sphinx,system-master-svc
그러면
system-sphinx가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
2.2.3.2. apicast 이미지 패치
amp-apicast이미지 스트림을 패치합니다.$ oc patch imagestream/amp-apicast --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP APIcast 2.10"}, "from": {"kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'apicast-stagingImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/apicast-staging --from-image=amp-apicast:2.9 --containers=apicast-staging --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/apicast-staging --from-image=amp-apicast:2.10 --containers=apicast-staging
이렇게 하면
apicast-staging이 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
apicast-productionImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/apicast-production --from-image=amp-apicast:2.9 --containers=apicast-production,system-master-svc --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/apicast-production --from-image=amp-apicast:2.10 --containers=apicast-production,system-master-svc
이렇게 하면
apicast-production이 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
2.2.3.3. 백엔드 이미지 패치
amp-backend이미지 스트림을 패치합니다.$ oc patch imagestream/amp-backend --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Backend 2.10"}, "from": {"kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/backend-rhel7:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'backend-listenerImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/backend-listener --from-image=amp-backend:2.9 --containers=backend-listener --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/backend-listener --from-image=amp-backend:2.10 --containers=backend-listener
이렇게 하면
backend-listener가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
backend-workerImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/backend-worker --from-image=amp-backend:2.9 --containers=backend-worker,backend-redis-svc --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/backend-worker --from-image=amp-backend:2.10 --containers=backend-worker,backend-redis-svc
이렇게 하면
backend-worker가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
backend-cronImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/backend-cron --from-image=amp-backend:2.9 --containers=backend-cron,backend-redis-svc --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/backend-cron --from-image=amp-backend:2.10 --containers=backend-cron,backend-redis-svc
이로 인해
backend-cron의 재배포가 트리거됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
2.2.3.4. zync 이미지 패치
amp-zync이미지 스트림을 패치합니다.$ oc patch imagestream/amp-zync --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Zync 2.10"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/zync-rhel7:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'zyncImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/zync --from-image=amp-zync:2.9 --containers=zync,zync-db-svc --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/zync --from-image=amp-zync:2.10 --containers=zync,zync-db-svc
그러면
zync가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
zync-queImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/zync-que --from-image=amp-zync:2.9 --containers=que --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/zync-que --from-image=amp-zync:2.10 --containers=que
그러면
zync-que가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
2.2.3.5. system-memcached 이미지 패치
system-memcached이미지 스트림을 패치합니다.$ oc patch imagestream/system-memcached --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.10 Memcached"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/memcached-rhel7:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'system-memcacheImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/system-memcache --from-image=system-memcached:2.9 --containers=memcache --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-memcache --from-image=system-memcached:2.10 --containers=memcache
이렇게 하면
system-memcacheDeploymentConfig가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.
2.2.3.6. zync-database-postgresql 이미지 패치
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.10 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'이 patch 명령은 2.10 태그를 포함하도록
zync-database-postgresql이미지 스트림을 업데이트합니다. 다음 단계를 사용하여 2.10 태그가 생성되었는지 확인할 수 있습니다.다음 명령을 실행하십시오.
$ oc get is zync-database-postgresql
- Tags 열에 2.10 태그가 표시되는지 확인합니다.
zync-databaseImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/zync-database --from-image=zync-database-postgresql:2.9 --containers=postgresql --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/zync-database --from-image=zync-database-postgresql:2.10 --containers=postgresql
이미지에 새 업데이트가 있는 경우 이 패치에서
zync-databaseDeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비되고 이전 Pod가 종료될 때까지 기다립니다.
2.2.3.7. 추가 이미지 변경
3scale 2.10 설치에서 다음 DeploymentConfigs 중 하나 이상을 사용할 수 있는 경우, 적용되는 링크를 클릭하여 진행 방법에 대한 자세한 정보를 가져옵니다.
backend-redis DeploymentConfig
현재 3scale 설치에 backend-redis DeploymentConfig가 있는 경우 backend-redis 의 redis 이미지를 패치합니다.
backend-redis이미지 스트림을 패치합니다.$ oc patch imagestream/backend-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Backend 2.10 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-32-rhel7:3.2"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'이 패치는 2.10 태그를 포함하도록 backend-redis 이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에 2.10 이 표시되면 태그가 생성되었는지 확인할 수 있습니다.
$ oc get is backend-redis
backend-redisImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/backend-redis --from-image=backend-redis:2.9 --containers=backend-redis --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/backend-redis --from-image=backend-redis:2.10 --containers=backend-redis
이미지에 새 업데이트가 있는 경우 이 패치에서
backend-redisDeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비되고 이전 Pod가 종료될 때까지 기다립니다.
system-redis DeploymentConfig
현재 3scale 설치에 system-redis DeploymentConfig가 있는 경우 system-redis 의 redis 이미지를 패치합니다.
system-redis이미지 스트림을 패치합니다.$ oc patch imagestream/system-redis --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.10 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-32-rhel7:3.2"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'이 패치는 2.10 태그를 포함하도록
system-redis이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에 2.10 이 표시되면 태그가 생성되었는지 확인할 수 있습니다.$ oc get is system-redis
system-redisImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/system-redis --from-image=system-redis:2.9 --containers=system-redis --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-redis --from-image=system-redis:2.10 --containers=system-redis
이미지에 새 업데이트가 있는 경우 이 패치로 인해
system-redisDeploymentConfig가 다시 배포될 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비되고 이전 Pod가 종료될 때까지 기다립니다.
system-mysql DeploymentConfig
현재 3scale 설치에 system-mysql DeploymentConfig가 있는 경우 system-mysql 의 MySQL 이미지를 패치합니다.
system-mysql이미지 스트림을 패치합니다.$ oc patch imagestream/system-mysql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.10 MySQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/mysql-57-rhel7:5.7"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'이 패치는 2.10 태그를 포함하도록
system-mysql이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에 2.10 이 표시되면 태그가 생성되었는지 확인할 수 있습니다.$ oc get is system-mysql
system-mysqlImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/system-mysql --from-image=system-mysql:2.9 --containers=system-mysql --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-mysql --from-image=system-mysql:2.10 --containers=system-mysql
이미지에 새 업데이트가 있는 경우 이 패치도
system-mysqlDeploymentConfig의 재배포를 트리거할 수 있습니다. 이 경우 새 Pod가 재배포되고 준비되고 이전 Pod가 종료될 때까지 기다립니다.
system-postgresql DeploymentConfig
현재 3scale 설치에 system-postgresql DeploymentConfig가 있는 경우 system-postgresql 의 PostgreSQL 이미지를 패치합니다.
system-postgresql이미지 스트림을 패치합니다.$ oc patch imagestream/system-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.10 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'이 패치는 2.10 태그를 포함하도록
system-postgresql이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에 2.10 이 표시되면 태그가 생성되었는지 확인할 수 있습니다.$ oc get is system-postgresql
system-postgresqlImageChange 트리거를 패치합니다.이전
2.9트리거를 제거합니다.$ oc set triggers dc/system-postgresql --from-image=system-postgresql:2.9 --containers=system-postgresql --remove
새 버전별 트리거를 추가합니다.
$ oc set triggers dc/system-postgresql --from-image=system-postgresql:2.10 --containers=system-postgresql
이미지에 새 업데이트가 있는 경우 이 패치도
system-postgresqlDeploymentConfig의 재배포를 트리거할 수 있습니다. 이 경우 새 Pod가 재배포되고 준비되고 이전 Pod가 종료될 때까지 기다립니다.
2.2.3.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다음 단계
없음. 나열된 모든 단계를 수행한 후 템플릿 기반 배포에서 3scale 업그레이드를 2.9에서 2.10으로 업그레이드합니다.
2.3. 템플릿 기반 설치의 Oracle Database로 3scale 업그레이드
이 섹션에서는 OpenShift 3.11을 사용한 템플릿 기반 설치에서 Oracle Database와 함께 3scale 시스템 이미지를 사용할 때 Red Hat 3scale API Management를 업그레이드하는 방법을 설명합니다.
사전 요구 사항
Oracle Database를 사용한 3scale 설치 Oracle Database를 사용하여 3scale 시스템 이미지 설정을 참조하십시오.
템플릿 기반 설치의 Oracle 데이터베이스를 사용하여 3scale 시스템 이미지를 업그레이드하려면 다음 절차를 수행하십시오.
2.3.1. Oracle 19c로 3scale 업그레이드
이 절차에서는 기존 3scale 2.9 설치에서 3scale 2.10용 Oracle Database 19c 업데이트를 안내합니다.
중요: 데이터베이스 연결 손실로 인해 3scale이 손상될 수 있습니다. 업그레이드를 진행하기 전에 백업을 만듭니다. 공식 Oracle Database 설명서: Oracle Database Backup andECDHE User's Guide.
사전 요구 사항
- 3scale 2.9 설치
Oracle Database 19c 설치
- Oracle을 사용한 3scale 구성에 대한 자세한 내용은 Oracle 데이터베이스 준비를참조하십시오.
절차
$ git clone --branch 3scale-2.10.0-GA https://github.com/3scale/3scale-amp-openshift-templates.git
-
Oracle Database Instant Client Package 파일을
3scale-amp-openshift-templates/amp/system-oracle/oracle-client-files디렉터리에 배치합니다. -f옵션과 함께oc process명령을 실행하고build.ymlOpenShift 템플릿을 지정합니다.$ oc process -f build.yml | oc apply -f -
oc new-app명령을-f옵션과 함께 실행하여amp.ymlOpenShift 템플릿을 표시하고-p옵션을 사용하여 OpenShift 클러스터 도메인으로WILDCARD_DOMAIN매개변수를 지정합니다.$ oc new-app -f amp.yml -p WILDCARD_DOMAIN=mydomain.com
참고다음 단계는 선택 사항입니다. 설치 또는 시스템 업그레이드 후
ORACLE_SYSTEM_PASSWORD를 제거하는 경우 사용합니다.다음
oc patch명령을 입력하고SYSTEM_PASSWORD를 Oracle 데이터베이스 준비에 설정한 Oracle Databasesystem암호로 바꿉니다.$ 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"}]}}}}}}'Oracle 데이터베이스 준비에 지정된
DATABASE_URL을 입력하여 Oracle 데이터베이스를 가리키도록 다음 명령을 입력합니다.$ oc patch secret/system-database -p '{"stringData": {"URL": "DATABASE_URL"}}'oc start-build명령을 입력하여 새 시스템 이미지를 빌드합니다.$ oc start-build 3scale-amp-system-oracle --from-dir=.
빌드가 완료될 때까지 기다립니다. 빌드 상태를 확인하려면 다음 명령을 실행합니다.
$ oc get build <build-name> -o jsonpath="{.status.phase}"- 빌드가 완료 (Complete) 상태가 될 때까지 기다립니다.
Oracle Database로 3scale 시스템 이미지를 설정한 경우
system-appDeploymentConfig에서ORACLE_SYSTEM_PASSWORD를 제거합니다. 3scale의 새 버전으로 업그레이드할 때까지 다시 필요하지 않습니다.$ oc set env dc/system-app ORACLE_SYSTEM_PASSWORD-
추가 리소스
3scale 및 Oracle Database 지원에 대한 자세한 내용은 Red Hat 3scale API Management 지원 구성을 참조하십시오.
3장. 3scale Operator 기반 업그레이드 가이드: 2.9에서 2.10으로
이 섹션에서는 Operator 기반 배포에서 Red Hat 3scale API Management를 버전 2.9에서 2.10으로 업그레이드하는 방법에 대해 설명합니다.
3scale의 마이크로 출시를 자동으로 얻으려면 자동 업데이트가 있는지 확인하십시오. 이를 확인하려면 마이크로 릴리스의 3scale Operator 설정을 참조하십시오.
필요한 조건 및 절차를 이해하려면 나열된 단계를 적용하기 전에 전체 업그레이드 가이드를 읽으십시오. 업그레이드 프로세스에서 절차가 완료될 때까지 서비스 프로비저닝을 중단합니다. 이러한 중단으로 인해 유지 관리 기간이 있는지 확인하십시오.
3.1. 업그레이드를 수행하기 위한 사전 요구 사항
이 섹션에서는 Operator 기반 설치에서 3scale을 2.9에서 2.10으로 업그레이드하는 데 필요한 구성에 대해 설명합니다.
- 3scale 2.9는 이전에 3scale Operator를 통해 배포되었습니다.
- 관리자 액세스 권한이 있는 OpenShift Container Platform (OCP) 4.x 클러스터.
3.2. Operator 기반 설치에서 2.9에서 2.10으로 업그레이드
Operator 기반 배포에서 버전 2.9에서 2.10으로 3scale을 업그레이드하려면 다음을 수행합니다.
- 관리자 권한이 있는 계정을 사용하여 OCP 콘솔에 로그인합니다.
- 3scale-operator 가 배포된 프로젝트를 선택합니다.
- Operators > 설치된 Operators를 클릭합니다.
- Red Hat Integration - 3scale > Subscription > Channel 을 선택합니다.
3scale-2.10 을 선택하여 서브스크립션 채널을 편집하고 변경 사항을 저장합니다.
- 그러면 업그레이드 프로세스가 시작됩니다.
- 업그레이드 프로세스가 APIManager 에 대해 완료될 때까지 기다립니다.
프로젝트의 Pod 상태를 쿼리합니다.
oc get pods
- 새 버전이 모두 실행되고 오류 없이 준비될 때까지 기다립니다.
업그레이드 프로세스 중에 일시적인 오류가 발생할 수 있습니다.
참고시간은 약 5-10 분에서 다를 수 있습니다. 모든 Pod가 실행 중이고, 준비되고, 오류 없이 계속 실행될 때까지 Pod 상태를 계속 확인해야 합니다.
- 3scale 관리 포털에 로그인하고 예상대로 작동하는지 확인하여 업그레이드 프로세스가 성공했는지 확인합니다.
다음 명령을 실행하여 APIManager 오브젝트의 상태를 확인하고 YAML 콘텐츠를 가져옵니다.
oc get apimanager <myapimanager> -o yaml
값이 포함된 새 주석은 다음과 같아야 합니다.
apps.3scale.net/apimanager-threescale-version: "2.10" apps.3scale.net/threescale-operator-version: "0.7.0"
나열된 모든 단계를 수행한 후 Operator 기반 배포에서 2.9에서 2.10으로 3scale 업그레이드가 완료됩니다.
4장. APIcast Operator 기반 업그레이드 가이드: 2.9에서 2.10
이 섹션에서는 Operator 기반 배포의 버전 2.9에서 2.10으로 APIcast를 업그레이드하는 방법에 대해 설명합니다.
필요한 조건 및 절차를 이해하려면 나열된 단계를 적용하기 전에 전체 업그레이드 가이드를 읽으십시오. 업그레이드 프로세스에서 절차가 완료될 때까지 서비스 프로비저닝을 중단합니다. 이러한 중단으로 인해 유지 관리 기간이 있는지 확인하십시오.
4.1. 업그레이드를 수행하기 위한 사전 요구 사항
이 섹션에서는 Operator 기반 설치에서 APIcast를 2.9에서 2.10으로 업그레이드하는 데 필요한 구성에 대해 설명합니다.
- APIcast 2.9는 이전에 APIcast Operator를 통해 배포되었습니다.
- 관리자 액세스 권한이 있는 OpenShift Container Platform (OCP) 4.x 클러스터.
4.2. Operator 기반 설치에서 APIcast를 2.9에서 2.10으로 업그레이드
Operator 기반 배포에서 버전 2.9에서 2.10으로 APIcast를 업그레이드하려면 다음을 수행합니다.
- 관리자 권한이 있는 계정을 사용하여 OCP 콘솔에 로그인합니다.
- APIcast Operator 가 배포된 프로젝트를 선택합니다.
- Operators > 설치된 Operators를 클릭합니다.
- 서브스크립션 > 채널에서 Red Hat Integration - 3scale APIcast 게이트웨이를 선택합니다.
3scale-2.10 채널을 선택하여 서브스크립션 채널을 편집하고 변경 사항을 저장합니다.
- 그러면 업그레이드 프로세스가 시작됩니다.
- 업그레이드 프로세스가 APIcast 를 위해 완료될 때까지 기다립니다.
프로젝트의 Pod 상태를 쿼리합니다.
oc get pods
- 새 버전이 모두 실행되고 오류 없이 준비될 때까지 기다립니다.
업그레이드 프로세스 중에 일시적인 오류가 발생할 수 있습니다.
참고시간은 약 5-10 분에서 다를 수 있습니다. 모든 Pod가 실행 중이고, 준비되고, 오류 없이 계속 실행될 때까지 Pod 상태를 계속 확인해야 합니다.
다음 명령을 실행하여 APIcast 오브젝트의 상태를 확인하고 YAML 콘텐츠를 가져옵니다.
oc get apicast <myapicast> -o yaml
값이 포함된 새 주석은 다음과 같아야 합니다.
apicast.apps.3scale.net/operator-version: “0.4.0”
나열된 모든 단계를 수행한 후 Operator 기반 배포에서 APIcast가 2.9에서 2.10으로 업그레이드됩니다.