3scale 마이그레이션

Red Hat 3scale API Management 2.10

3scale API Management 및 해당 구성 요소를 마이그레이션 또는 업그레이드

초록

템플릿에서 Operator 기반 설치로 3scale을 마이그레이션합니다. 또한 3scale 및 해당 구성 요소를 최신 버전으로 업그레이드하는 정보를 찾습니다.

머리말

이 가이드에서는 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.comocp3.example.com

Red Hat OpenShift 3.11을 사용하여 템플릿 기반 배포에서 Red Hat OpenShift 4.1을 사용하여 Operator 기반 배포로 3scale을 마이그레이션하려면 다음 단계를 따르십시오.

  1. 템플릿 기반 배포에서 3scale 백업을 생성합니다.
  2. Operator를 사용하여 3scale을 배포합니다.
  3. Operator 기반 배포에서 백업을 복원합니다.
  4. 3scale WILDCARD_DOMAIN을 가리키며 이 경우 3scale.example.comocp4.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 프로젝트의 백업을 생성하는 데 필요한 작업이 나열됩니다.

  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. 생성된 모든 파일이 비어 있지 않으며 모든 파일에 필요한 콘텐츠가 있는지 확인합니다.

2.2.2. 3scale 버전 번호 업데이트

현재 단계

이 단계에서는 system-environment ConfigMap에서 3scale 릴리스 버전 번호를 2.9 에서 2.10 으로 업데이트합니다. AMP_RELEASE는 일부 DeploymentConfig 컨테이너 환경에서 참조되는 ConfigMap 항목입니다.

  1. AMP_RELEASE를 패치하려면 다음 명령을 실행합니다.

    $ oc patch cm system-environment --patch '{"data": {"AMP_RELEASE": "2.10"}}'
  2. 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 이미지 패치

  1. 새 이미지 스트림 태그를 생성합니다.

    $ 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"}}}]'
  2. 이 절차를 계속하려면 3scale 배포와 함께 사용되는 데이터베이스를 고려하십시오.

2.2.3.1.1. Oracle Database를 사용하여 3scale 시스템 이미지 패치하기
  1. Oracle Database로 3scale의 시스템 이미지 패치를 시작하려면 Oracle 19c를 사용하여 3scale 2.9에서 2.10으로 다음 절차를 수행합니다.
  2. system-app ImageChangeTrigger를 패치합니다.

    1. 이전 2.9-oracle 트리거를 제거합니다.

      $ oc set triggers dc/system-app --from-image=amp-system:2.9-oracle --containers=system-master,system-developer,system-provider --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이렇게 하면 system-app 이 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  3. system-sidekiq ImageChange 트리거를 패치합니다.

    1. 이전 2.9-oracle 트리거를 제거합니다.

      $ oc set triggers dc/system-sidekiq --from-image=amp-system:2.9-oracle --containers=system-sidekiq,check-svc --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이렇게 하면 system-sidekiq가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  4. system-sphinx ImageChange 트리거를 패치합니다.

    1. 이전 2.9-oracle 트리거를 제거합니다.

      $ oc set triggers dc/system-sphinx --from-image=amp-system:2.9-oracle --containers=system-sphinx,system-master-svc --remove
    2. 새 버전별 트리거를 추가합니다.

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

      그러면 system-sphinx가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  5. 축소하려는 경우 3scale을 축소하면 됩니다.
2.2.3.1.2. 다른 데이터베이스를 사용하여 3scale 시스템 이미지 패치하기
  1. system-app ImageChange 트리거에 패치를 적용합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/system-app --from-image=amp-system:2.9 --containers=system-master,system-developer,system-provider --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이렇게 하면 system-app 이 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  2. system-sidekiq ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/system-sidekiq --from-image=amp-system:2.9 --containers=system-sidekiq,check-svc --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이렇게 하면 system-sidekiq가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  3. system-sphinx ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/system-sphinx --from-image=amp-system:2.9 --containers=system-sphinx,system-master-svc --remove
    2. 새 버전별 트리거를 추가합니다.

      $ 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 이미지 패치

  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.10"}, "from": {"kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'
  2. apicast-staging ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/apicast-staging --from-image=amp-apicast:2.9 --containers=apicast-staging --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이렇게 하면 apicast-staging 이 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  3. apicast-production ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/apicast-production --from-image=amp-apicast:2.9 --containers=apicast-production,system-master-svc --remove
    2. 새 버전별 트리거를 추가합니다.

      $ 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. 백엔드 이미지 패치

  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.10"}, "from": {"kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/backend-rhel7:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'
  2. backend-listener ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/backend-listener --from-image=amp-backend:2.9 --containers=backend-listener --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이렇게 하면 backend-listener 가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  3. backend-worker ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/backend-worker --from-image=amp-backend:2.9 --containers=backend-worker,backend-redis-svc --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이렇게 하면 backend-worker 가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  4. backend-cron ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/backend-cron --from-image=amp-backend:2.9 --containers=backend-cron,backend-redis-svc --remove
    2. 새 버전별 트리거를 추가합니다.

      $ 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 이미지 패치

  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.10"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/zync-rhel7:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'
  2. zync ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/zync --from-image=amp-zync:2.9 --containers=zync,zync-db-svc --remove
    2. 새 버전별 트리거를 추가합니다.

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

      그러면 zync 가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  3. zync-que ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/zync-que --from-image=amp-zync:2.9 --containers=que --remove
    2. 새 버전별 트리거를 추가합니다.

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

      그러면 zync-que 가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

2.2.3.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.10 Memcached"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/memcached-rhel7:3scale2.10"}, "name": "2.10", "referencePolicy": {"type": "Source"}}}]'
  2. system-memcache ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/system-memcache --from-image=system-memcached:2.9 --containers=memcache --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이렇게 하면 system-memcache DeploymentConfig가 다시 배포됩니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

2.2.3.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.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 태그가 생성되었는지 확인할 수 있습니다.

      1. 다음 명령을 실행하십시오.

        $ oc get is zync-database-postgresql
      2. Tags 열에 2.10 태그가 표시되는지 확인합니다.
  2. zync-database ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/zync-database --from-image=zync-database-postgresql:2.9 --containers=postgresql --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이미지에 새 업데이트가 있는 경우 이 패치에서 zync-database DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비되고 이전 Pod가 종료될 때까지 기다립니다.

2.2.3.7. 추가 이미지 변경

3scale 2.10 설치에서 다음 DeploymentConfigs 중 하나 이상을 사용할 수 있는 경우, 적용되는 링크를 클릭하여 진행 방법에 대한 자세한 정보를 가져옵니다.

backend-redis DeploymentConfig

현재 3scale 설치에 backend-redis DeploymentConfig가 있는 경우 backend-redisredis 이미지를 패치합니다.

  1. 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
  2. backend-redis ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/backend-redis --from-image=backend-redis:2.9 --containers=backend-redis --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이미지에 새 업데이트가 있는 경우 이 패치에서 backend-redis DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비되고 이전 Pod가 종료될 때까지 기다립니다.

system-redis DeploymentConfig

현재 3scale 설치에 system-redis DeploymentConfig가 있는 경우 system-redisredis 이미지를 패치합니다.

  1. 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
  2. system-redis ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/system-redis --from-image=system-redis:2.9 --containers=system-redis --remove
    2. 새 버전별 트리거를 추가합니다.

      $ oc set triggers dc/system-redis --from-image=system-redis:2.10 --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.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
  2. system-mysql ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/system-mysql --from-image=system-mysql:2.9 --containers=system-mysql --remove
    2. 새 버전별 트리거를 추가합니다.

      $ oc set triggers dc/system-mysql --from-image=system-mysql:2.10 --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.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
  2. system-postgresql ImageChange 트리거를 패치합니다.

    1. 이전 2.9 트리거를 제거합니다.

      $ oc set triggers dc/system-postgresql --from-image=system-postgresql:2.9 --containers=system-postgresql --remove
    2. 새 버전별 트리거를 추가합니다.

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

      이미지에 새 업데이트가 있는 경우 이 패치도 system-postgresql DeploymentConfig의 재배포를 트리거할 수 있습니다. 이 경우 새 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 설치

절차

  1. 3scale 2.10용 OpenShift 템플릿복제

    $ git clone --branch 3scale-2.10.0-GA https://github.com/3scale/3scale-amp-openshift-templates.git
  2. Oracle Database Instant Client Package 파일을 3scale-amp-openshift-templates/amp/system-oracle/oracle-client-files 디렉터리에 배치합니다.
  3. -f 옵션과 함께 oc process 명령을 실행하고 build.yml OpenShift 템플릿을 지정합니다.

    $ oc process -f build.yml | oc apply -f -
  4. oc new-app 명령을 -f 옵션과 함께 실행하여 amp.yml OpenShift 템플릿을 표시하고 -p 옵션을 사용하여 OpenShift 클러스터 도메인으로 WILDCARD_DOMAIN 매개변수를 지정합니다.

    $ oc new-app -f amp.yml -p WILDCARD_DOMAIN=mydomain.com
    참고

    다음 단계는 선택 사항입니다. 설치 또는 시스템 업그레이드 후 ORACLE_SYSTEM_PASSWORD 를 제거하는 경우 사용합니다.

  5. 다음 oc patch 명령을 입력하고 SYSTEM_PASSWORDOracle 데이터베이스 준비에 설정한 Oracle Database system 암호로 바꿉니다.

    $ 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. Oracle 데이터베이스 준비에 지정된 DATABASE_URL을 입력하여 Oracle 데이터베이스를 가리키도록 다음 명령을 입력합니다.

    $ oc patch secret/system-database -p '{"stringData": {"URL": "DATABASE_URL"}}'
  7. oc start-build 명령을 입력하여 새 시스템 이미지를 빌드합니다.

    $ oc start-build 3scale-amp-system-oracle --from-dir=.
  8. 빌드가 완료될 때까지 기다립니다. 빌드 상태를 확인하려면 다음 명령을 실행합니다.

    $ oc get build <build-name> -o jsonpath="{.status.phase}"
    1. 빌드가 완료 (Complete) 상태가 될 때까지 기다립니다.
  9. Oracle Database로 3scale 시스템 이미지를 설정한 경우 system-app DeploymentConfig에서 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을 업그레이드하려면 다음을 수행합니다.

  1. 관리자 권한이 있는 계정을 사용하여 OCP 콘솔에 로그인합니다.
  2. 3scale-operator 가 배포된 프로젝트를 선택합니다.
  3. Operators > 설치된 Operators를 클릭합니다.
  4. Red Hat Integration - 3scale > Subscription > Channel 을 선택합니다.
  5. 3scale-2.10 을 선택하여 서브스크립션 채널을 편집하고 변경 사항을 저장합니다.

    • 그러면 업그레이드 프로세스가 시작됩니다.
    • 업그레이드 프로세스가 APIManager 에 대해 완료될 때까지 기다립니다.
  6. 프로젝트의 Pod 상태를 쿼리합니다.

    oc get pods
    • 새 버전이 모두 실행되고 오류 없이 준비될 때까지 기다립니다.
    • 업그레이드 프로세스 중에 일시적인 오류가 발생할 수 있습니다.

      참고

      시간은 약 5-10 분에서 다를 수 있습니다. 모든 Pod가 실행 중이고, 준비되고, 오류 없이 계속 실행될 때까지 Pod 상태를 계속 확인해야 합니다.

  7. 3scale 관리 포털에 로그인하고 예상대로 작동하는지 확인하여 업그레이드 프로세스가 성공했는지 확인합니다.
  8. 다음 명령을 실행하여 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를 업그레이드하려면 다음을 수행합니다.

  1. 관리자 권한이 있는 계정을 사용하여 OCP 콘솔에 로그인합니다.
  2. APIcast Operator 가 배포된 프로젝트를 선택합니다.
  3. Operators > 설치된 Operators를 클릭합니다.
  4. 서브스크립션 > 채널에서 Red Hat Integration - 3scale APIcast 게이트웨이를 선택합니다.
  5. 3scale-2.10 채널을 선택하여 서브스크립션 채널을 편집하고 변경 사항을 저장합니다.

    • 그러면 업그레이드 프로세스가 시작됩니다.
    • 업그레이드 프로세스가 APIcast 를 위해 완료될 때까지 기다립니다.
  6. 프로젝트의 Pod 상태를 쿼리합니다.

    oc get pods
    • 새 버전이 모두 실행되고 오류 없이 준비될 때까지 기다립니다.
    • 업그레이드 프로세스 중에 일시적인 오류가 발생할 수 있습니다.

      참고

      시간은 약 5-10 분에서 다를 수 있습니다. 모든 Pod가 실행 중이고, 준비되고, 오류 없이 계속 실행될 때까지 Pod 상태를 계속 확인해야 합니다.

  7. 다음 명령을 실행하여 APIcast 오브젝트의 상태를 확인하고 YAML 콘텐츠를 가져옵니다.

    oc get apicast <myapicast> -o yaml
    • 값이 포함된 새 주석은 다음과 같아야 합니다.

      apicast.apps.3scale.net/operator-version: “0.4.0”

나열된 모든 단계를 수행한 후 Operator 기반 배포에서 APIcast가 2.9에서 2.10으로 업그레이드됩니다.