3scale 마이그레이션

Red Hat 3scale API Management 2.8

3scale API Management 설치를 업그레이드합니다.

Red Hat Customer Content Services

초록

이 가이드에서는 3scale API Management 설치를 최신 버전으로 업그레이드하는 방법을 설명합니다.

머리말

이 가이드를 통해 Red Hat 3scale API Management를 마이그레이션 및 업그레이드할 수 있습니다.

3scale 설치를 2.7에서 2.8로 업그레이드하려면 설치 유형에 따라 두 가지 가이드가 있습니다.

개발자 포털에서 API 프로비저닝을 위한 업그레이드 후 단계

  • 3scale을 성공적으로 업그레이드한 후 개발자 포털에서 OpenAPI Specification 3.0(OAS 3.0)을 구성하려면 다음을 참조하십시오. OAS 3.0으로 개발자 포털 구성.

템플릿 기반에서 Operator 기반 배포로 마이그레이션하려면 3장. 3scale API Management 마이그레이션 가이드: 템플릿에서 Operator 기반 배포로 에 나열된 절차를 따르십시오.

1장. 3scale 템플릿 기반 업그레이드 가이드: 2.7에서 2.8까지

이 섹션에서는 템플릿 기반 배포에서 Red Hat 3scale API Management를 버전 2.7에서 2.8로 업그레이드하는 방법에 대해 설명합니다.

중요

필요한 조건 및 절차를 이해하려면 나열된 단계를 적용하기 전에 전체 업그레이드 가이드를 읽으십시오. 업그레이드 프로세스에서 절차가 완료될 때까지 서비스 프로비저닝을 중단합니다. 이러한 중단으로 인해 유지 관리 기간이 있는지 확인하십시오.

1.1. 업그레이드를 위한 준비

이 장에서는 3scale 업그레이드 전에 충족해야 하는 조건을 설명합니다. 또한 업그레이드를 수행하는 데 필요한 사전 요구 사항으로 필요한 작업 및 도구가 나열됩니다.

1.1.1. 업그레이드 조건

업그레이드를 진행하려면 다음 사항을 고려해야 합니다.

  • 3scale은 OpenShift 3.11에서 템플릿을 사용하여 2.7에서 2.8로의 업그레이드 경로를 지원합니다.
  • 3scale이 배포된 프로젝트와 동일한 프로젝트에서 OpenShift CLI 도구가 구성되었는지 확인합니다.

1.1.2. 업그레이드를 수행하기 위한 사전 요구 사항

이 섹션에서는 템플릿 기반 설치에서 3scale을 2.7에서 2.8으로 업그레이드하는 데 필요한 작업과 도구에 대해 설명합니다.

사전 작업

  • 3scale과 함께 사용하는 데이터베이스 백업을 수행합니다. 백업 절차는 각 데이터베이스 유형 및 설정에 따라 다릅니다.

툴

업그레이드를 수행하려면 다음 툴이 필요합니다.

  • 3scale 2.7은 OpenShift 3.11 프로젝트의 템플릿과 함께 배포됩니다.
  • bash shell: 업그레이드 절차에 자세히 설명된 명령을 실행합니다.
  • base64: 시크릿 정보를 인코딩 및 디코딩합니다.
  • jq: JSON 변환의 경우 필요합니다.

1.2. 템플릿 기반 설치에서 2.7에서 2.8으로 업그레이드

이 섹션에 설명된 절차에 따라 템플릿 기반 설치에서 3scale 2.7을 2.8로 업그레이드하십시오.

업그레이드를 시작하려면 3scale이 배포된 프로젝트로 이동합니다. 

$ oc project <3scale-project>

다음 단계를 순서대로 수행합니다.

  1. 1.2.1절. “3scale 프로젝트의 백업 생성”
  2. 1.2.2절. “smtp ConfigMap을 system-smtp 시크릿으로 마이그레이션”
  3. 1.2.3절. “system-app DeploymentConfig의 pre-hook pod 명령 업데이트”
  4. 1.2.4절. “system -app DeploymentConfig의 pre-hook Pod 환경 패치”
  5. 1.2.5절. “system-app DeploymentConfig 컨테이너의 환경 패치”
  6. 1.2.6절. “system-sidekiq DeploymentConfig 컨테이너의 환경 패치”
  7. 1.2.7절. “S3 특정 구성 마이그레이션”
  8. 1.2.8절. “3scale 버전 번호 업데이트”
  9. 1.2.9절. “3scale 이미지 업그레이드”
  10. 1.2.10절. “smtp ConfigMap 삭제”

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

다음 단계

1.2.2절. “smtp ConfigMap을 system-smtp 시크릿으로 마이그레이션”

1.2.2. smtp ConfigMap을 system-smtp 시크릿으로 마이그레이션

이전 단계

1.2.1절. “3scale 프로젝트의 백업 생성”

현재 단계

이 단계의 목표는 시스템의 SMTP 구성을 ConfigMap에서 Secret으로 마이그레이션하는 것입니다. 이 마이그레이션에는 메일링 관련 측면이 포함됩니다. SMTP 구성에 중요한 정보가 포함되어 있기 때문입니다. 이 정보를 보호하기 위해 보안은 ConfigMaps보다 더 안전합니다.

  1. app 레이블의 현재 값을 수집합니다. 

    $ DEPLOYED_APP_LABEL=$(oc get dc backend-listener -o json | jq .spec.template.metadata.labels.app -r)

    • 다음 명령을 실행하여 DEPLOYED_APP_LABEL이 비어 있지 않은지 확인할 수 있습니다. 

      $ echo  ${DEPLOYED_APP_LABEL}

  2. smtp ConfigMap의 현재 콘텐츠를 수집합니다. 

    $ CFGMAP_DATA_CONTENTS=$(oc get configmap smtp -o json | jq -r .data)

    • 다음 명령을 실행하여 CFGMAP_DATA_CONTENTS가 비어 있지 않은지 확인할 수 있습니다. 

      $ echo  ${CFGMAP_DATA_CONTENTS}

    • 다음 명령을 실행하여 CFGMAP_DATA_CONTENTS 값을 확인할 수 있습니다. 

      $ oc get configmap smtp -o json | jq -r .data

  3. smtp ConfigMap의 콘텐츠를 사용하여 system-smtp 보안을 생성합니다. 

    $ cat <<EOF | oc create -f -
{
  "apiVersion": "v1",
  "kind": "Secret",
  "metadata": {
    "creationTimestamp": null,
    "labels": {
      "app": "${DEPLOYED_APP_LABEL}",
      "threescale_component": "system",
      "threescale_component_element": "smtp"
    },
    "name": "system-smtp"
  },
  "stringData": ${CFGMAP_DATA_CONTENTS}
}
EOF

  4. 다음을 실행하여 system-smtp 시크릿이 생성되었는지 확인합니다. 

    $ oc get secret system-smtp -o yaml

    모든 데이터 키와 관련 값이 system-smtp secret 및 smtp ConfigMap 모두에서 동일한지 확인합니다. system-smtp 시크릿의 데이터 값은 base64로 인코딩되므로 실제 값을 보기 위해 디코딩해야 합니다. 예를 들어 시크릿 데이터의 키 이름이 mykey 인 경우 해당 키에 연결된 값을 복사하고 다음 명령으로 디코딩하여 실제 값을 확인할 수 있습니다. 

    $ oc get secret system-smtp -o json | jq -r .data.mykey | base64 -d

    키와 연결된 값이 빈 문자열인 경우 이전 명령의 결과에 출력이 없습니다.

다음 단계

1.2.3절. “system-app DeploymentConfig의 pre-hook pod 명령 업데이트”

1.2.3. system-app DeploymentConfig의 pre-hook pod 명령 업데이트

이전 단계

1.2.2절. “smtp ConfigMap을 system-smtp 시크릿으로 마이그레이션”

현재 단계

3scale의 최신 기능을 가져오기 위해 이 단계에서는 system-app DeploymentConfig에서 pre-hook pod 명령을 업데이트하는 방법을 설명합니다.

  1. system-app DeploymentConfig에서 pre-hook pod 명령을 이 릴리스에 필요한 새 Pod 명령으로 업데이트합니다. 

    oc patch dc/system-app -p '{"spec":{"strategy":{"rollingParams":{"pre":{"execNewPod":{"command":["bash","-c","bundle exec rake boot openshift:deploy"]}}}}}}'

  2. pre-hook pod 명령이 새 값으로 변경되었는지 확인합니다. 

    oc get dc system-app -o json | jq .spec.strategy.rollingParams.pre.execNewPod.command

    • 이전 명령의 결과는 다음과 같아야 합니다. 

      [
  "bash",
  "-c",
  "bundle exec rake boot openshift:deploy"
]

다음 단계

1.2.4절. “system -app DeploymentConfig의 pre-hook Pod 환경 패치”

1.2.4. system -app DeploymentConfig의 pre-hook Pod 환경 패치

이전 단계

1.2.3절. “system-app DeploymentConfig의 pre-hook pod 명령 업데이트”

현재 단계

이 단계에서는 pre-hook Pod 환경에서 system-app DeploymentConfig에 환경 변수를 추가합니다. 또한 SMTP 관련 환경 변수가 새로 생성된 system-smtp 시크릿 을 가리키도록 합니다. 또한 pre-hook pod 명령 수정과 관련된 변수가 올바르게 구성됩니다.

  1. system-app DeploymentConfig에서 pre-hook pod 환경 변수를 패치합니다. 

    oc get dc system-app -o json | jq 'del(.spec.strategy.rollingParams.pre.execNewPod.env[] | select(.name == "SMTP_ADDRESS" // .name == "SMTP_USER_NAME" // .name == "SMTP_PASSWORD" // .name == "SMTP_DOMAIN" // .name == "SMTP_PORT" // .name == "SMTP_AUTHENTICATION" // .name == "SMTP_OPENSSL_VERIFY_MODE")) | .spec.strategy.rollingParams.pre.execNewPod.env += [{"name":"SMTP_ADDRESS","valueFrom":{"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}},{"name":"MASTER_ACCESS_TOKEN","valueFrom":{"secretKeyRef":{"key":"MASTER_ACCESS_TOKEN","name":"system-seed"}}}]' | oc apply -f -

  2. 다음 작업 포인트를 따라 pre-hook Pod 환경이 패치되었는지 확인합니다.

    1. ECDHETER_ACCESS_TOKEN이 system-app pre-hook Pod에서 시크릿 참조로 설정되어 있는지 확인합니다. 

      oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(select(.name == "MASTER_ACCESS_TOKEN")) | length'

      예상 출력: 1

      • ECDHETER_ACCESS_TOKEN이 시스템이 적용된 시크릿을 올바르게 가리키는지 확인할 수 있습니다. 

        oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(select(.name == "MASTER_ACCESS_TOKEN"))'

        예상 출력: 

        [
  {
    "name": "MASTER_ACCESS_TOKEN",
    "valueFrom": {
          "secretKeyRef": {
                "key": "MASTER_ACCESS_TOKEN",
                "name": "system-seed"
          }
    }
  }
]

    2. 모든 SMTP_* env vars가 system-app pre-hook Pod에서 시크릿 참조로 설정되어 있는지 확인합니다. 

      oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(select(.name | contains("SMTP")))'

      • 아래 출력 목록의 각 환경 변수는 system-smtp 보안 키에 대한 참조여야 합니다.

        • SMTP_ADDRESS
        • SMTP_USER_NAME
        • SMTP_PASSWORD
        • SMTP_DOMAIN
        • SMTP_PORT
        • SMTP_AUTHENTICATION
        • SMTP_OPENSSL_VERIFY_MODE

다음 단계

1.2.5절. “system-app DeploymentConfig 컨테이너의 환경 패치”

1.2.5. system-app DeploymentConfig 컨테이너의 환경 패치

이전 단계

1.2.4절. “system -app DeploymentConfig의 pre-hook Pod 환경 패치”

현재 단계

이 절차에서는 system-app 컨테이너 환경에 환경 변수를 추가하고 수정합니다. 이를 통해 SMTP 관련 환경 변수가 새로 생성된 system-smtp 시크릿을 가리키도록 합니다.

  1. system-app DeploymentConfig에 컨테이너 환경 변수를 패치합니다. 

    oc patch dc/system-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"system-master","env":[{"name":"SMTP_ADDRESS","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}}]},{"name":"system-provider","env":[{"name":"SMTP_ADDRESS","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}}]},{"name":"system-developer","env":[{"name":"SMTP_ADDRESS","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}}]}]}}}}'

  2. 여기에 나열된 system-app 컨테이너에서 모든 SMTP_* env vars가 시크릿 참조로 설정되어 있는지 확인합니다.

    • system-developer 

      oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-developer"))[].env | map(select(.name | contains("SMTP")))'

    • system-provider 

      oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-provider"))[].env | map(select(.name | contains("SMTP")))'

    • system-master 

      oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-master"))[].env | map(select(.name | contains("SMTP")))'

      이러한 컨테이너에서 아래 출력 목록의 환경 변수는 system-smtp 보안 키에 대한 참조여야 합니다.

      • SMTP_ADDRESS
      • SMTP_USER_NAME
      • SMTP_PASSWORD
      • SMTP_DOMAIN
      • SMTP_PORT
      • SMTP_AUTHENTICATION
      • SMTP_OPENSSL_VERIFY_MODE

다음 단계

1.2.6절. “system-sidekiq DeploymentConfig 컨테이너의 환경 패치”

1.2.6. system-sidekiq DeploymentConfig 컨테이너의 환경 패치

이전 단계

1.2.5절. “system-app DeploymentConfig 컨테이너의 환경 패치”

현재 단계

이 절차에서는 system-sidekiq pod 환경에 환경 변수를 추가하고 수정합니다. 여기에 나열된 단계를 통해 SMTP 관련 환경 변수가 새로 생성된 system-smtp 시크릿을 가리키도록 합니다.

  1. system-sidekiq DeploymentConfig의 환경 변수를 패치합니다. 

    oc patch dc/system-sidekiq -p '{"spec":{"template":{"spec":{"containers":[{"name":"system-sidekiq","env":[{"name":"SMTP_ADDRESS","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"address","name":"system-smtp"}}},{"name":"SMTP_USER_NAME","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"username","name":"system-smtp"}}},{"name":"SMTP_PASSWORD","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"password","name":"system-smtp"}}},{"name":"SMTP_DOMAIN","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"domain","name":"system-smtp"}}},{"name":"SMTP_PORT","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"port","name":"system-smtp"}}},{"name":"SMTP_AUTHENTICATION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"authentication","name":"system-smtp"}}},{"name":"SMTP_OPENSSL_VERIFY_MODE","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"openssl.verify.mode","name":"system-smtp"}}}]}]}}}}'

  2. 모든 SMTP_* 환경 변수가 시크릿 참조로 설정되어 있는지 확인합니다. 

    oc get dc system-sidekiq -o json | jq '.spec.template.spec.containers | map(select(.name == "system-sidekiq"))[].env | map(select(.name | contains("SMTP")))'

    아래 출력 목록의 각 환경 변수는 system-smtp 보안 키에 대한 참조여야 합니다.

    • SMTP_ADDRESS
    • SMTP_USER_NAME
    • SMTP_PASSWORD
    • SMTP_DOMAIN
    • SMTP_PORT
    • SMTP_AUTHENTICATION
    • SMTP_OPENSSL_VERIFY_MODE

다음 단계

1.2.7. S3 특정 구성 마이그레이션

참고

3scale 2.7에 amp-s3 템플릿을 설치한 경우 이 단계의 지침을 따르십시오. 그렇지 않으면 다음 단계를 통해 업그레이드를 계속합니다. 1.2.8절. “3scale 버전 번호 업데이트”

이전 단계

1.2.6절. “system-sidekiq DeploymentConfig 컨테이너의 환경 패치”

현재 단계

이 단계에서는 system-environment ConfigMap에서 aws-auth secret으로 구성을 S3와 관련된 구성을 마이그레이션하는 작업이 나열됩니다.

  1. 기존 aws-auth 보안에 값을 추가합니다. 

    oc patch secret aws-auth --patch "{\"stringData\": $(oc get configmap system-environment -o json | jq '.data | {"AWS_BUCKET": .AWS_BUCKET, "AWS_REGION": .AWS_REGION } ')}"

    • 키와 해당 값이 aws-auth 보안에 추가되었는지 확인합니다. 이러한 값은 base64로 인코딩됩니다. 

      oc get secret aws-auth -o yaml

  2. system-app DeploymentConfig의 pre-hook Pod 환경 변수를 패치합니다. 

    oc get dc system-app -o json | jq 'del(.spec.strategy.rollingParams.pre.execNewPod.env[] | select(.name == "AWS_BUCKET" // .name == "AWS_REGION")) | .spec.strategy.rollingParams.pre.execNewPod.env += [{"name":"AWS_BUCKET","valueFrom":{"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]' | oc apply -f -

    • 모든 AWS_* 환경 변수가 system-app pre-hook Pod에서 시크릿 참조로 설정되어 있는지 확인합니다. 

      oc get dc system-app -o json | jq '.spec.strategy.rollingParams.pre.execNewPod.env | map(select(.name | contains("AWS")))'

    • 아래 출력 목록의 각 환경 변수는 aws-auth secret 키에 대한 참조여야 합니다.

      • AWS_ACCESS_KEY_ID
      • AWS_SECRET_ACCESS_KEY
      • AWS_BUCKET
      • AWS_REGION
      • AWS_PROTOCOL
      • AWS_HOSTNAME
      • AWS_PATH_STYLE

  3. system-app DeploymentConfig에 컨테이너 환경 변수를 패치합니다. 

    oc patch dc/system-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"system-master","env":[{"name":"AWS_BUCKET","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]},{"name":"system-provider","env":[{"name":"AWS_BUCKET","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]},{"name":"system-developer","env":[{"name":"AWS_BUCKET","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]}]}}}}'

    system-app 의 세 컨테이너에서 모든 AWS_* 환경 변수가 시크릿 참조로 설정되어 있는지 확인합니다.

    • system-developer: 

      oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-developer"))[].env | map(select(.name | contains("AWS")))'

    • system-master: 

      oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-master"))[].env | map(select(.name | contains("AWS")))'

    • system-provider 

      oc get dc system-app -o json | jq '.spec.template.spec.containers | map(select(.name == "system-provider"))[].env | map(select(.name | contains("AWS")))'

      세 가지 컨테이너 모두에서 아래 출력 목록의 각 환경 변수는 aws-auth secret 키에 대한 참조여야 합니다.

      • AWS_ACCESS_KEY_ID
      • AWS_SECRET_ACCESS_KEY
      • AWS_BUCKET
      • AWS_REGION
      • AWS_PROTOCOL
      • AWS_HOSTNAME
      • AWS_PATH_STYLE

  4. system-sidekiq DeploymentConfig에 컨테이너 환경 변수를 패치합니다. 

    oc patch dc/system-sidekiq -p '{"spec":{"template":{"spec":{"containers":[{"name":"system-sidekiq","env":[{"name":"AWS_BUCKET","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_BUCKET","name":"aws-auth"}}},{"name":"AWS_REGION","valueFrom":{"configMapKeyRef":null,"secretKeyRef":{"key":"AWS_REGION","name":"aws-auth"}}},{"name":"AWS_PROTOCOL","valueFrom":{"secretKeyRef":{"key":"AWS_PROTOCOL","name":"aws-auth", "optional": true}}},{"name":"AWS_HOSTNAME","valueFrom":{"secretKeyRef":{"key":"AWS_HOSTNAME","name":"aws-auth", "optional": true}}},{"name":"AWS_PATH_STYLE","valueFrom":{"secretKeyRef":{"key":"AWS_PATH_STYLE","name":"aws-auth", "optional": true}}}]}]}}}}'

    • 모든 AWS_* 환경 변수가 시크릿 참조로 설정되어 있는지 확인합니다. 

      oc get dc system-sidekiq -o json | jq '.spec.template.spec.containers | map(select(.name == "system-sidekiq"))[].env | map(select(.name | contains("AWS")))'

      아래 출력 목록의 각 환경 변수는 aws-auth secret 키에 대한 참조여야 합니다.

      • AWS_ACCESS_KEY_ID
      • AWS_SECRET_ACCESS_KEY
      • AWS_BUCKET
      • AWS_REGION
      • AWS_PROTOCOL
      • AWS_HOSTNAME
      • AWS_PATH_STYLE

  5. 사용되지 않은 system-environment ConfigMap 키를 삭제합니다. 

    oc patch configmap system-environment --patch '{"data": {"AWS_BUCKET": null, "AWS_REGION": null}}'

다음 단계

1.2.8절. “3scale 버전 번호 업데이트”

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

이전 단계

현재 단계

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

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

    oc patch cm system-environment --patch '{"data": {"AMP_RELEASE": "2.8"}}'

  2. system-environment ConfigMap의 AMP_RELEASE 키의 2.8 값이 있는지 확인합니다. 

    oc get cm system-environment -o json | jq .data.AMP_RELEASE

다음 단계

1.2.9절. “3scale 이미지 업그레이드”

1.2.9. 3scale 이미지 업그레이드

이전 단계

1.2.8절. “3scale 버전 번호 업데이트”

현재 단계

이 단계에서는 업그레이드 프로세스에 필요한 3scale 이미지를 업데이트합니다.

  1. amp-system 이미지 스트림을 패치합니다.

    amp-system 이미지 스트림을 패치하려면 3scale 배포에 사용된 데이터베이스를 고려해야 합니다.

    • 3scale을 Oracle Database와 함께 배포하는 경우 다음 단계를 수행하여 Oracle Database : 1, 2, 4, 8 및 9로 시스템 이미지를 빌드 합니다.

    • 데이터베이스가 Oracle DB와 다른 경우 다음 명령을 사용하십시오. 

      oc patch imagestream/amp-system --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP system 2.8"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/system-rhel7:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/amp-system --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP system (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

      이 트리거는 system-app,system-sphinx 및 system-sidekiq DeploymentConfigs의 재배포를 트리거합니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료됩니다.

  2. amp-apicast 이미지 스트림을 패치합니다. 

    oc patch imagestream/amp-apicast --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP APIcast 2.8"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/amp-apicast --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP APIcast (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

    이 트리거는 apicast-production 및 apicast-staging DeploymentConfigs의 재배포를 트리거합니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료됩니다.

  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.8"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/backend-rhel7:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/amp-backend --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Backend (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

    이 트리거는 backend-listener,backend-worker, backend-cron DeploymentConfigs의 재배포를 트리거합니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료됩니다.

  4. amp-zync 이미지 스트림을 패치합니다. 

    oc patch imagestream/amp-zync --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Zync 2.8"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/zync-rhel7:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/amp-zync --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "AMP Zync (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

    이 트리거는 zync 및 zync-que DeploymentConfigs의 재배포를 트리거합니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료됩니다.

  5. system-memcached ImageStream을 패치합니다. 

    oc patch imagestream/system-memcached --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System 2.8 Memcached"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/3scale-amp2/memcached-rhel7:3scale2.8"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/system-memcached --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "System Memcached (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

    이 트리거는 system-memcache DeploymentConfig의 재배포를 트리거합니다. 재배포될 때까지 기다린 후 해당 새 Pod가 준비되고 이전 Pod가 종료될 때까지 기다립니다.

  6. 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.8 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7"}, "name": "2.8", "referencePolicy": {"type": "Source"}}}]'
oc patch imagestream/zync-database-postgresql --type=json -p '[{"op": "add", "path": "/spec/tags/-", "value": {"annotations": {"openshift.io/display-name": "Zync PostgreSQL (latest)"}, "from": { "kind": "ImageStreamTag", "name": "2.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'

    • 이 patch 명령은 2.8 태그를 포함하도록 zync-database-postgresql 이미지 스트림을 업데이트합니다. 다음을 실행하여 2.8 태그가 생성되었는지 확인할 수 있습니다. 

      oc get is/zync-database-postgresql

      그런 다음 태그 열에 2.8 태그가 표시되는지 확인합니다.

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

  7. 3scale 2.7 설치에 다음 DeploymentConfig 중 하나 이상이 있는 경우 적용되는 DeploymentConfig 링크를 클릭하여 진행 방법에 대한 자세한 정보를 가져옵니다.

  8. DeploymentConfigs의 모든 이미지 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

다음 단계

1.2.10절. “smtp ConfigMap 삭제”

1.2.9.1. 기존 DeploymentConfigs를 사용하는 추가 단계

1.2.9.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.8 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-32-rhel7:3.2"}, "name": "2.8", "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.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
  • 이 패치는 2.8 태그를 포함하도록 backend-redis 이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에 2.8 이 표시되는 경우 태그가 생성되었는지 확인할 수 있습니다. 
oc get is/backend-redis
  • 이 패치는 이미지에 새 업데이트가 있는 경우 backend-redis DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비될 때까지 기다린 후 이전 Pod가 종료됩니다.

3scale 이미지 업그레이드 를 계속합니다.

1.2.9.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.8 Redis"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/redis-32-rhel7:3.2"}, "name": "2.8", "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.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
  • 이 패치는 2.8 태그를 포함하도록 system-redis 이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에 2.8 이 표시되는 경우 태그가 생성되었는지 확인할 수 있습니다. 
oc get is/system-redis
  • 이 패치는 이미지에 새 업데이트가 있는 경우 system-redis DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비될 때까지 기다린 후 이전 Pod가 종료됩니다.

3scale 이미지 업그레이드 를 계속합니다.

1.2.9.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.8 MySQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/mysql-57-rhel7:5.7"}, "name": "2.8", "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.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
  • 이 패치는 2.8 태그를 포함하도록 system-mysql 이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에 2.8 이 표시되는 경우 태그가 생성되었는지 확인할 수 있습니다. 
oc get is/system-mysql
  • 이 패치는 이미지에 새 업데이트가 있는 경우 system-mysql DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비될 때까지 기다린 후 이전 Pod가 종료됩니다.

3scale 이미지 업그레이드 를 계속합니다.

1.2.9.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.8 PostgreSQL"}, "from": { "kind": "DockerImage", "name": "registry.redhat.io/rhscl/postgresql-10-rhel7
"}, "name": "2.8", "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.8"}, "name": "latest", "referencePolicy": {"type": "Source"}}}]'
  • 이 패치는 2.8 태그를 포함하도록 system-postgresql 이미지 스트림을 업데이트합니다. 아래 명령을 사용하면 태그 열에 2.8 이 표시되는 경우 태그가 생성되었는지 확인할 수 있습니다. 
oc get is/system-postgresql
  • 이 패치는 이미지에 새 업데이트가 있는 경우 system-postgresql DeploymentConfig의 재배포를 트리거할 수도 있습니다. 이 경우 새 Pod가 재배포되고 준비될 때까지 기다린 후 이전 Pod가 종료됩니다.

3scale 이미지 업그레이드 를 계속합니다.

1.2.10. smtp ConfigMap 삭제

이전 단계

1.2.9절. “3scale 이미지 업그레이드”

현재 단계

이 단계에서는 이 ConfigMap이 system- smtp 시크릿으로 마이그레이션되었기 때문에 smtp ConfigMap을 제거합니다.

smtp ConfigMap을 제거하려면 다음 명령을 실행합니다. 

$ oc delete cm smtp

명령에서 오류를 반환하지 않으면 올바르게 작동했습니다.

다음 단계

없음. 나열된 모든 단계를 수행한 후 템플릿 기반 배포에서 2.7에서 2.8로 3scale 업그레이드가 완료되었습니다.

2장. 3scale Operator 기반 업그레이드 가이드: 2.7에서 2.8까지

이 섹션에서는 Operator 기반 배포에서 Red Hat 3scale API Management를 버전 2.7에서 2.8로 업그레이드하는 방법에 대해 설명합니다.

중요

필요한 조건 및 절차를 이해하려면 나열된 단계를 적용하기 전에 전체 업그레이드 가이드를 읽으십시오. 업그레이드 프로세스에서 절차가 완료될 때까지 서비스 프로비저닝을 중단합니다. 이러한 중단으로 인해 유지 관리 기간이 있는지 확인하십시오.

사전 요구 사항

  • 3scale 2.7은 이전에 3scale Operator를 통해 배포되었습니다.
  • 관리자 액세스 권한이 있는 OpenShift Container Platform (OCP) 4.x 클러스터.

2.1. 3scale 2.7을 2.8로 업그레이드

Operator 기반 배포에서 버전 2.7에서 2.8으로 3scale을 업그레이드하려면 다음 절차를 사용하십시오.

절차

  1. 관리자 권한이 있는 계정을 사용하여 OCP 콘솔에 로그인합니다.
  2. 3scale-operator 가 배포된 프로젝트를 선택합니다.
  3. Operators > 설치된 Operators를 클릭합니다.
  4. 3scale Operator 서브스크립션 > 채널을 선택합니다.

  5. 3scale-2.8 을 선택하여 서브스크립션 채널을 편집하고 변경 사항을 저장합니다.

    • 그러면 업그레이드 프로세스가 시작됩니다.
    • 업그레이드 프로세스가 APIManager 에 대해 완료될 때까지 기다립니다.

  6. 프로젝트의 Pod 상태를 쿼리합니다. 

    oc get pods
    • 새 버전이 모두 실행되고 오류 없이 준비될 때까지 기다립니다.

    • 업그레이드 프로세스 중에 일시적인 오류가 발생할 수 있습니다.

      참고

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

  7. 3scale 관리 포털에 로그인하고 예상대로 작동하는지 확인하여 업그레이드 프로세스가 성공했는지 확인합니다.

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

    oc get apimanager <myapimanager> -o yaml

    1. 값이 있는 새 주석은 다음과 같이 표시됩니다. 

      apps.3scale.net/apimanager-threescale-version: "2.8"
apps.3scale.net/threescale-operator-version: "0.5.0"

      나열된 모든 단계를 수행한 후 Operator 기반 배포에서 2.7에서 2.8로 3scale 업그레이드가 완료됩니다.

3장. 3scale API Management 마이그레이션 가이드: 템플릿에서 Operator 기반 배포로

이 섹션에서는 Red Hat OpenShift 3.11을 사용하여 템플릿 기반 배포에서 Red Hat OpenShift 4.x를 사용하는 operator 기반 배포로 Red Hat 3scale API Management를 마이그레이션하는 방법에 대해 설명합니다.

주의

필요한 조건 및 절차를 이해하려면 나열된 단계를 적용하기 전에 전체 마이그레이션 가이드를 살펴보십시오. 마이그레이션 프로세스에서 절차가 완료될 때까지 서비스 프로비저닝을 중단합니다. 이러한 중단으로 인해 유지 관리 기간이 있는지 확인하십시오.

3.1. 마이그레이션을 위한 준비

3scale 설치를 템플릿에서 operator 기반 배포로 마이그레이션하기 전에 다음 가이드를 참조하여 배포를 지원하는지 확인합니다.

3.2. 3scale 템플릿을 Operator 기반 배포로 마이그레이션

사전 요구 사항

  • 두 환경 모두에 배포된 Red Hat 3scale API Management 2.8.

  • 각 OpenShift 클러스터의 도메인과 3scale의 경우 다른 WILDCARD_DOMAIN입니다. 예:

    • Red Hat OpenShift 3.11 (OCP3): ocp3.example.com
    • Red Hat OpenShift 4.x (OCP4): ocp4.example.com
    • 3scale: 3scale.example.com

절차

마이그레이션 전 기본 설정은 3scale이 OCP3 도메인을 가리키는 것입니다: 3scale.example.com → ocp3.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.com을 ocp4.example.com으로 지정합니다.

나열된 모든 단계를 수행한 후 템플릿에서 operator 기반 배포로 3scale 마이그레이션을 완료했습니다.

법적 공지

Copyright © 2023 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.