Apigee Hybrid 업그레이드

현재 1.2 버전의 Apigee Hybrid 문서를 보고 있습니다. 이 버전은 지원 종료됩니다. 최신 버전으로 업그레이드해야 합니다. 자세한 내용은 지원되는 버전을 참조하세요.

Version 1.2 (unsupported)

지원되는 버전:

• v1.12(최신 버전)                        
• v1.11                         
• v1.10                                        
• 지원되는 버전 목록

지원되지 않는 버전:

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

버전 1.0.0과 하위 호환되지 않으므로 1.0.0에서 이후 버전으로 업그레이드할 수 없습니다. 버전 1.0.0을 사용하고 있으며 업그레이드하려면 새로 설치해야 합니다.

버전 1.2.0으로 업그레이드

다음 단계에 따라 Apigee Hybrid를 버전 1.2.0으로 업그레이드합니다.

1단계: Kubernetes 업그레이드 및 출시 패키지 다운로드

1. Kubernetes 플랫폼을 다음과 같이 업그레이드합니다. 도움이 필요하면 플랫폼 문서를 참조하세요.

   플랫폼	업그레이드할 버전
   GKE	1.14.x
   Anthos	1.2
   AKS	1.14.x

2. 사용 중인 운영체제에 해당하는 출시 패키지를 다운로드합니다.

   Mac 64비트:

   curl -LO \
       https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_mac_64.tar.gz

   Linux 64비트

   curl -LO \
       https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_linux_64.tar.gz

   Mac 32비트:

   curl -LO \
       https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_mac_32.tar.gz

   Linux 32비트

   curl -LO \
       https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_linux_32.tar.gz

2단계: 설치 디렉터리 재구성

1. Apigee Hybrid를 처음 설치할 때 생성된 기본 설치 디렉터리를 확인합니다. 기본 디렉터리는 $APIGEEGTL_HOME 디렉터리가 있는 디렉터리입니다. 다음 예시에서 기본 디렉터리는 /Users/myhome/hybrid입니다.

   echo $APIGEECTL_HOME
   /Users/myhome/hybrid/apigeectl

2. 다운로드한 gzip 파일 콘텐츠를 Apigee Hybrid 기본 디렉터리에 추출합니다.

   tar xvzf filename.tar.gz -C path-to-base-directory

3. cd 명령어를 사용하여 기본 디렉터리로 이동합니다.

4. 기본적으로 tar 콘텐츠는 이름에 버전과 플랫폼이 있는 디렉터리로 확장됩니다. 예를 들면 ./apigeectl_1.2.0-f7b96a8_linux_64입니다.

5. 현재 apigeectl 디렉터리의 이름을 바꿉니다. 예를 들어 현재 버전이 1.1.1인 경우 apigeectl 디렉터리의 이름을 apigeectl_1.1.1로 바꿉니다.
6. 새로 추출된 설치 디렉터리 이름을 apigeectl로 바꿉니다. 이제 $APIGEECTL_HOME 환경이 이 디렉터리로 연결됩니다.

3단계: 재정의 파일 업데이트

1. 재정의 파일의 사본을 만들고 나중에 롤백할 때를 대비해서 이전 파일을 보관해둡니다. 다음 단계에서는 재정의 파일을 원하는 대로 변경한 후 이를 클러스터에 적용합니다.
   참고: 버전 1.2.0으로 업그레이드하려면 이전 버전과 호환되지 않는 변경 작업을 재정의 파일에서 수행해야 합니다. 다음 단계에서 설명하는 재정의 파일 변경사항이 필요합니다.

2. 아래 설명된 변경사항에 따라 재정의 파일을 업데이트합니다.

   다음은 재정의 파일에서 수행해야 하는 구성 변경사항을 요약해서 보여줍니다. 전체 예시는 요약 다음의 테이블을 참조하세요. 보시는 것처럼 envs[] 속성이 이전 버전과 크게 달라졌습니다.

   • envs[].hostAlias 속성이 삭제되었고 새로운 virtualhosts.hostAliases[] 속성으로 대체되었습니다.
     참고: 이전 버전에서 환경 호스트 별칭에 단일 와일드 카드 '*'를 사용한 경우, 버전 1.2.0에서는 가상 호스트 별칭 구성의 하위 도메인 와일드 카드 또는 정규화된 DNS 이름을 사용해야 합니다. 예를 들면 *.mydomain.com입니다. 단일 와일드 카드 문자 구성 hostAliases['*']는 더 이상 지원되지 않습니다.
   • 새로운 필수 구성 속성 virtualhosts를 추가해야 합니다.
   • envs[].sslCertPath 및 envs[].sslKeyPath 속성을 envs에서 virtualhosts로 이동해야 합니다.
   • virtualhosts.routingRules 구성 스탠자를 추가해야 합니다. virtualhosts.routingRules 속성은 이전 envs[].paths 속성을 대체합니다. 재정의 파일에 envs[].paths가 있으면 이를 삭제해야 합니다. 가상 호스트 구성에 대한 자세한 내용은 가상 호스트 구성을 참조하세요.

   아래 테이블은 1.1.1 재정의 파일과 버전 1.2.0 파일 간의 차이점을 보여줍니다. 이 예시는 버전 1.2.0에 대해 수행해야 하는 변경사항의 종류를 보여주기 위한 것입니다.

   참고: 표시된 코드는 예시 목적으로만 사용됩니다.

   v1.1.x 구성

   v1.2.0 구성

   envs: - name: test1 hostAlias: "api.example.com" sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.pem serviceAccountPaths: synchronizer: ./sa/sync.json udca: ./sa/udca.json paths: uri: prefixes: - /orders - /items - name: test2 hostAlias: "api.example.com" sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.pem serviceAccountPaths: synchronizer: ./sa/sync.json udca: ./sa/udca.json paths: uri: prefixes: - /v0/hello - /httpbin

   virtualhosts: - name: default hostAliases: ["api.example.com"] sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.pem routingRules: - paths: - /orders - /items env: test1 - paths: - /v0/hello - /httpbin env: test2 envs: - name: test1 serviceAccountPaths: synchronizer: ./sa/synchronizer.json udca: ./sa/udca.json - name: test2 serviceAccountPaths: synchronizer: ./sa/synchronizer.json udca: ./sa/udca.json

   참고: 위 테이블에 표시된 것처럼 envs[].paths를 지정하지 않을 경우, 업그레이드할 때 virtualhosts[].routingRules.paths[] 속성을 생략할 수 있습니다. 기본적으로 경로는 '/'입니다. 예를 들어 기본 경로 '/'를 사용하려면 다음과 같이 virtualhosts[].routingRules를 구성할 수 있습니다.

   virtualhosts:
     - name: default
       hostAliases: ["api.example.com"]
       sslCertPath: ./certs/fullchain.pem
       sslKeyPath: ./certs/privkey.pem
       routingRules:
         - env: test1
     - name: prod
       hostAliases: ["api.example.com"]
       sslCertPath: ./certs/fullchain.pem
       sslKeyPath: ./certs/privkey.pem
       routingRules:
         - env: test2

4단계: 클러스터에 업그레이드 적용

1. 버전 1.1.1 설치에 Apigee Connect를 사용 설정한 경우 배포를 삭제해야 합니다.
   1. 먼저 Apigee 배포를 나열합니다.

      kubectl -n namespace get ad

   2. Apigee Connect 배포를 삭제합니다.

      kubectl -n namespace delete ad apigee-connect-name

2. pod를 나열합니다.

   kubectl get pods -n namespace

3. 클러스터에서 apigee-cps-setup pod를 삭제합니다. 이전 명령어로 반환된 것처럼 조직 이름이 포함된 pod의 전체 이름을 사용합니다. 예를 들면 다음과 같습니다.

   kubectl -n namespace delete pod apigee-cps-setup-org

4. 동일한 네임스페이스에서 apigee-cps-create-user pod를 삭제합니다.

   kubectl -n namespace delete pod apigee-cps-create-user

5. 하이브리드 런타임 네임스페이스에 대해 완료된 작업을 삭제합니다. 여기서 namespace는 재정의 파일에 지정된 네임스페이스(네임스페이스가 있는 경우)입니다. 그렇지 않은 경우 기본 네임스페이스는 apigee입니다.

   kubectl delete job -n namespace \
     $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

6. apigee-system 네임스페이스에 대해 완료된 작업을 삭제합니다.

   kubectl delete job -n apigee-system \
     $(kubectl get job -n apigee-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

7. istio-system 네임스페이스에 대해 완료된 작업을 삭제합니다.

   kubectl delete job -n istio-system \
     $(kubectl get job -n istio-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

8. cd를 ./hybrid-files 디렉터리에 추가합니다.
9. 새 버전에 대해 apigeectl을 초기화합니다.

   $APIGEECTL_HOME/apigeectl init -f overrides/overrides-file.yaml

10. 초기화가 완료되었는지 확인하려면 다음을 확인하세요.

    $APIGEECTL_HOME/apigeectl check-ready -f overrides/overrides-file.yaml

11. check-ready가 '모든 컨테이너 준비 완료'로 응답하면 '테스트 실행' 설치를 시도할 수 있습니다. --dry-run=true 플래그를 사용하여 apply 명령어를 실행합니다. 테스트 실행을 수행하면 클러스터를 실제로 변경하기 전에 오류를 확인할 수 있습니다.

    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true

12. 오류가 없으면 클러스터에 Apigee 관련 런타임 구성요소를 적용할 수 있습니다.

    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml

13. check-ready를 다시 실행하여 업그레이드가 완료되는 시점을 확인합니다.

업그레이드 롤백

이전 업그레이드를 롤백하려면 다음 단계를 따르세요.

1. 하이브리드 런타임 네임스페이스에 대해 완료된 작업을 삭제합니다. 여기서 namespace는 재정의 파일에 지정된 네임스페이스(네임스페이스가 있는 경우)입니다. 그렇지 않은 경우 기본 네임스페이스는 apigee입니다.

   kubectl delete job -n namespace \
     $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

2. apigee-system 네임스페이스에 대해 완료된 작업을 삭제합니다.

   kubectl delete job -n apigee-system \
     $(kubectl get job -n apigee-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

3. istio-system 네임스페이스에 대해 완료된 작업을 삭제합니다.

   kubectl delete job -n istio-system \
     $(kubectl get job -n istio-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

4. Apigee 연산자 배포를 삭제합니다. 이 작업은 런타임 트래픽에 영향을 주지 않습니다.

   kubectl -n apigee-system delete deployment apigee-controller-manager

5. apigeectl의 원본 버전이 포함된 디렉터리를 가리키도록 $APIGEECTL_HOME 변수를 변경합니다. 예를 들면 다음과 같습니다.

   export APIGEECTL_HOME=path-to-original-apigeectl-directory

6. 롤백할 설치의 루트 디렉터리에서 apigeectl init을 실행한 다음 apigeectl apply를 실행합니다. 롤백하려는 버전에 원래 재정의 파일을 사용해야 합니다.

     $APIGEECTL_HOME/apigeectl init -f overrides/original-overrides.yaml
     $APIGEECTL_HOME/apigeectl apply -f overrides/original-overrides.yaml