Como fazer upgrade do Apigee híbrido

Você está visualizando a versão 1.2 da documentação da Apigee híbrida. This version is end of life. You should upgrade to a newer version. Para mais informações, consulte Versões compatíveis.

Version 1.2 (unsupported)

Versões com suporte:

• v1.13 (mais recente)                        
• v1.12                         
• v1.11
• Lista de versões com suporte

Versões sem suporte:

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

Não é possível fazer upgrade da versão 1.0.0 para versões posteriores porque elas não são compatíveis com a versão 1.0.0. Caso esteja usando a versão 1.0.0 e queira fazer o upgrade, instale novamente.

Como fazer upgrade para a versão 1.2.0

Siga estas etapas para fazer upgrade do Apigee híbrido para a versão 1.2.0:

Etapa 1: fazer upgrade do Kubernetes e fazer o download do pacote da versão

1. Faça o upgrade da plataforma do Kubernetes da seguinte maneira. Siga a documentação da plataforma se precisar de ajuda:

   Plataforma	Fazer upgrade para a versão
   GKE	1.14.x
   Anthos	1.2
   AKS	1.14.x

2. Faça o download do pacote de lançamento para seu sistema operacional:

   Mac 64 bit:

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

   Linux de 64 bits

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

   Mac 32 bits:

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

   Linux 32 bit

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

Etapa 2: configure novamente o diretório de instalação

1. Identifique o diretório de instalação base que foi criado quando o Apigee híbrido foi instalado originalmente. O diretório base é o diretório em que o diretório $APIGEEGTL_HOME reside. No exemplo a seguir, o diretório base é /Users/myhome/hybrid:

   echo $APIGEECTL_HOME
   /Users/myhome/hybrid/apigeectl

2. Extraia o conteúdo do arquivo gzip transferido por download no diretório base do Apigee híbrido:

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

3. cd ao diretório base.

4. O conteúdo dos arquivos tar é, por padrão, expandido em um diretório com a versão e a plataforma no nome. Por exemplo, ./apigeectl_1.2.0-f7b96a8_linux_64.

5. Renomeie o diretório apigeectl atual. Por exemplo, se a versão atual for 1.1.1, renomeie o diretório apigeectl para apigeectl_1.1.1.
6. Renomeie o diretório de instalação recém-criado para apigeectl. É para ele que o ambiente $APIGEECTL_HOME aponta agora.

Etapa 3: atualizar o arquivo de modificação

1. Faça uma cópia do arquivo de modificações. Lembre-se de salvar o arquivo antigo caso precise reverter a alteração. Nas etapas a seguir, você fará as alterações necessárias no arquivo de modificação antes de aplicá-lo ao cluster.
   OBSERVAÇÃO: para fazer upgrade para a versão 1.2.0, é necessário fazer alterações no arquivo de modificações incompatíveis com versões anteriores. As alterações no arquivo de modificação descritas na próxima etapa são obrigatórias.

2. Atualize o arquivo de modificação com as alterações descritas abaixo:

   Veja a seguir um resumo das alterações de configuração que você precisa fazer no arquivo de modificações. Veja um exemplo completo na tabela após o resumo. Como você verá, a propriedade envs[] mudou significativamente em relação às versões anteriores:

   • A propriedade envs[].hostAlias foi removida e substituída pela nova propriedade virtualhosts.hostAliases[].
     OBSERVAÇÃO: se você usou um único caractere curinga "*" para o alias de host de ambiente em uma versão anterior, na versão 1.2.0 será obrigatório usar um nome de DNS totalmente qualificado ou um caractere curinga de subdomínio na configuração de alias de host virtual. Por exemplo: *.mydomain.com. A configuração de caractere curinga único hostAliases['*'] não é mais compatível.
   • Adicione a nova propriedade de configuração obrigatória virtualhosts.
   • Você precisa mover as propriedades envs[].sslCertPath e envs[].sslKeyPath de envs para virtualhosts.
   • Adicione a estrofe de configuração virtualhosts.routingRules. A propriedade virtualhosts.routingRules substitui a propriedade envs[].paths anterior. Se você tiver envs[].paths no arquivo de modificações, será necessário removê-la. Para mais informações sobre a configuração do host virtual, consulte Configurar hosts virtuais.

   A tabela abaixo ilustra as diferenças entre um arquivo de modificações 1.1.1 e um arquivo de versão 1.2.0. O exemplo serve para destacar os tipos de alterações que você precisa fazer para a versão 1.2.0:

   OBSERVAÇÃO: o código mostrado é apenas para fins de exemplo.

   Configuração da v1.1.x

   Configuração da 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

   OBSERVAÇÃO: se você não especificar envs[].paths (como mostrado na tabela acima), poderá omitir a propriedade virtualhosts[].routingRules.paths[] no upgrade. Por padrão, o caminho é "/". Por exemplo, se você quiser usar o caminho padrão "/", configure virtualhosts[].routingRules desta maneira:

   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

Etapa 4: aplicar o upgrade ao cluster

1. Se você ativou o Apigee Connect na instalação da versão 1.1.1, será necessário remover a implantação:
   1. Primeiro, liste as implantações da Apigee:

      kubectl -n namespace get ad

   2. Exclua a implantação do Apigee Connect:

      kubectl -n namespace delete ad apigee-connect-name

2. Liste os pods:

   kubectl get pods -n namespace

3. Exclua o pod apigee-cps-setup do cluster. Use o nome completo do pod, que inclui o nome da organização, conforme retornado no comando anterior. Exemplo:

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

4. Exclua o pod apigee-cps-create-user no mesmo namespace:

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

5. Limpe os jobs concluídos do namespace do ambiente de execução híbrido, em que namespace é o namespace especificado no arquivo de modificações, se você especificou um namespace. Caso contrário, o namespace padrão é apigee:

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

6. Limpe jobs concluídos do namespace apigee-system:

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

7. Limpe jobs concluídos do namespace istio-system:

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

8. cd para o diretório ./hybrid-files:
9. Inicialize apigeectl para a nova versão:

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

10. Verifique se a inicialização foi concluída:

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

11. Quando check-ready responder com "Todos os contêineres estão prontos", tente uma instalação simulada. Execute o comando apply com a sinalização --dry-run=true. Uma simulação permite verificar se há erros antes de fazer alteração no cluster.

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

12. Se não houver erros, você poderá aplicar os componentes de ambiente de execução específicos da Apigee ao cluster:

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

13. Execute check-ready novamente para determinar quando o upgrade será concluído.

Como reverter um upgrade

Siga estas etapas para reverter um upgrade anterior:

1. Limpe os jobs concluídos do namespace do ambiente de execução híbrido, em que namespace é o namespace especificado no arquivo de modificações, se você especificou um namespace. Caso contrário, o namespace padrão é apigee:

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

2. Limpe jobs concluídos do namespace apigee-system:

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

3. Limpe jobs concluídos do namespace istio-system:

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

4. Exclua a implantação do Apigee Operators. Essa operação não terá efeito no tráfego do ambiente de execução

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

5. Altere a variável $APIGEECTL_HOME para apontar para o diretório que contém a versão original de apigeectl. Exemplo:

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

6. No diretório raiz da instalação para a qual você quer reverter, execute apigeectl init e, em seguida, execute apigeectl apply. Use o arquivo de modificações original da versão para a qual você quer reverter:

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