Como fazer upgrade da Apigee híbrida para a versão 1.10

Este procedimento abrange o upgrade da versão híbrida 1.9.x da Apigee para a versão híbrida 1.10.5 da Apigee e de versões anteriores da versão híbrida 1.10.x para a versão 1.10.5.

Use os mesmos procedimentos para upgrades de versão secundária (por exemplo, 1.9 para 1.10) e para upgrades de versão de patch (por exemplo, 1.10.0 para 1.10.5).

Como fazer upgrade para a versão 1.10.5

Os procedimentos para fazer upgrade da Apigee híbrida são organizados nas seguintes seções:

  1. Prepare-se para o upgrade.
  2. Instale o ambiente de execução híbrido versão 1.10.5.

Pré-requisitos

Estas instruções de upgrade presumem que você tenha a Apigee híbrida versão 1.9.x instalada e queira fazer upgrade para a versão 1.10.5. Se você estiver atualizando de uma versão anterior, consulte as instruções sobre Como fazer upgrade da Apigee híbrida para a versão 1.9.

Preparar para fazer upgrade para a versão 1.10

  1. Estas instruções usam a variável de ambiente APIGEECTL_HOME para o diretório no seu sistema de arquivos em que você instalou apigeectl. Se necessário, mude o diretório para seu diretório apigeectl e defina a variável com o seguinte comando:
    Linux Mac OS Windows 
    export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
     
    export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
     
    set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
  2. Faça uma cópia de backup do diretório $APIGEECTL_HOME/ da versão 1.9. Por exemplo: 
    tar -czvf $APIGEECTL_HOME/../apigeectl-v1.9-backup.tar.gz $APIGEECTL_HOME
  3. Faça o backup do banco de dados Cassandra seguindo as instruções em Backup e recuperação do Cassandra.

Fazer upgrade da versão do Kubernetes

Verifique a versão da plataforma do Kubernetes e, se necessário, faça upgrade para uma versão compatível com as versões híbridas 1.9 e 1.10. Siga a documentação da plataforma se precisar de ajuda.

1.10 sem suporte (3) 1.11 1.12
GKE no Google Cloud 1.24.x
1.25.x
1.26.x
1.27.x(≥ 1.10.5)
1.28.x(≥ 1.10.5) 		1.25.x
1.26.x
1.27.x
1.28.x(≥ 1.11.2)
1.29.x(≥ 1.11.2) 		1.26.x
1.27.x
1.28.x
1.29.x(≥ 1.12.1)
GKE na AWS 1.13.x (K8s v1.24.x)
1.14.x (K8s v1.25.x)
1.26.x(12)
1.27.x(≥ 1.10.5)
1.28.x(≥ 1.10.5) 		1.14.x (K8s v1.25.x)
1.26.x(12)
1.27.x
1.28.x(≥ 1.11.2)
1.29.x(≥ 1.11.2) 		1.26.x(12)
1.27.x
1.28.x
1.29.x(≥ 1.12.1)
GKE no Azure 1.13.x
1.14.x
1.26.x(12)
1.27.x(≥ 1.10.5)
1.28.x(≥ 1.10.5) 		1.14.x
1.26.x(12)
1.27.x
1.28.x(≥ 1.11.2)
1.29.x(≥ 1.11.2) 		1.26.x(12)
1.27.x
1.28.x
1.29.x(≥ 1.12.1)
Google Distributed Cloud (somente software) no VMware (1) (13) 1.13.x
1.14.x
1.15.x (K8s v1.26.x)
1.16.x (K8s v1.27.x)
1.27.x(≥ 1.10.5)
1.28.x(≥ 1.10.5) 		1.14.x
1.15.x (K8s v1.26.x)
1.16.x (K8s v1.27.x)
1.28.x(≥ 1.11.2)
1.29.x(≥ 1.11.2) 		1.15.x (K8s v1.26.x)
1.16.x (K8s v1.27.x)
1.28.x(12)
1.29.x(≥ 1.12.1)
Google Distributed Cloud (somente software) em bare metal (1) 1.13.x
1.14.x (K8s v1.25.x)
1.15.x (K8s v1.26.x)
1.16.x (K8s v1.27.x)
1.27.x(12)(≥ 1.10.5)
1.28.x(≥ 1.10.5) 		1.14.x
1.15.x (K8s v1.26.x)
1.16.x (K8s v1.27.x)
1.28.x(12)(≥ 1.11.2)
1.29.x(≥ 1.11.2) 		1.15.x (K8s v1.26.x)
1.16.x (K8s v1.27.x)
1.28.x(12)
1.29.x(≥ 1.12.1)
EKS(7) 1.24.x
1.25.x
1.26.x
1.27.x(≥ 1.10.5)
1.28.x(≥ 1.10.5) 		1.25.x
1.26.x
1.27.x
1.28.x(≥ 1.11.2)
1.29.x(≥ 1.11.2) 		1.26.x
1.27.x
1.28.x
1.29.x(≥ 1.12.1)
AKS(7) 1.24.x
1.25.x
1.26.x
1.27.x(≥ 1.10.5)
1.28.x(≥ 1.10.5) 		1.25.x
1.26.x
1.27.x
1.28.x(≥ 1.11.2)
1.29.x(≥ 1.11.2) 		1.26.x
1.27.x
1.28.x
1.29.x(≥ 1.12.1)
OpenShift(7) 4.11
4.12
4.14(≥ 1.10.5)
4.15(≥ 1.10.5) 		4.12
4.13
4.14
4.15(≥ 1.11.2)
4.16(≥ 1.11.2) 		4.12
4.13
4.14
4.15
4.16(≥ 1.12.1)
Rancher Kubernetes Engine (RKE) v1.26.2+rke2r1
1.27.x(≥ 1.10.5)
1.28.x(≥ 1.10.5) 		v1.26.2+rke2r1
v1.27.x
1.28.x(≥ 1.11.2)
1.29.x(≥ 1.11.2) 		v1.26.2+rke2r1
v1.27.x

1.28.x
1.29.x(≥ 1.12.1)
VMware Tanzu N/A N/A v1.26.x

Componentes

 1.10 1.11 1.12
Anthos Service Mesh 1.17.x(10) 1.18.x(10) 1.19.x(10)
JDK JDK 11 JDK 11 JDK 11
cert-manager. 1.10.x
1.11.x
1.12.x 		1.11.x
1.12.x
1.13.x 		1.11.x
1.12.x
1.13.x
Cassandra 3.11 3.11 4.0
Kubernetes 1.24.x
1.25.x
1.26.x
 1.25.x
1.26.x
1.27.x
 1.26.x
1.27.x
1.28.x
kubectl 1.27.x
1.28.x
1.29.x
Helm 3.10+ 3.10+ 3.14.2+
Driver CSI do Secret Store 1.3.4 1.4.1
Vault 1.13.x 1.15.2

(1) No Anthos local (Google Distributed Cloud) versão 1.13, siga estas instruções para evitar conflitos com o cert-manager: Instalação conflitante do cert-manager

(2) Suporte disponível para a Apigee híbrida versão 1.8.4 e mais recentes.

(3) As datas de EOL oficiais da Apigee híbrida versões 1.10 e anteriores foram atingidas. Os patches mensais regulares não estão mais disponíveis. Essas versões não têm mais suporte oficial, exceto para clientes com exceções explícitas e oficiais para suporte contínuo. Outros clientes precisam fazer o upgrade.

(4)O Anthos no local (Google Distributed Cloud) nas versões 1.12 e anteriores não tem suporte. Consulte a Política de suporte de versões do Distributed Cloud em Bare Metal e a lista de versões compatíveis do Distributed Cloud on VMware.

(5)O Google Distributed Cloud em bare metal ou VMware requer o Anthos Service Mesh 1.14 ou mais recente. Recomendamos que você faça upgrade para a versão híbrida v1.8 e mude para o gateway de entrada da Apigee, que não requer mais a instalação do Anthos Service Mesh no cluster híbrido.

(6) Suporte disponível para a versão híbrida da Apigee 1.8.4 e mais recentes.

(7) Não há suporte na Apigee híbrida 1.8.4 e mais recentes.

(8) Suporte disponível para a Apigee híbrida versão 1.7.6 e mais recentes.

(9) Não há suporte na Apigee híbrida versão 1.8.5 e mais recentes.

(10) O Anthos Service Mesh é instalado automaticamente com a Apigee híbrida 1.9 e mais recentes.

(11) Suporte disponível para a Apigee híbrida versão 1.9.2 e mais recentes.

(12) Agora os números de versão do GKE na AWS refletem as versões do Kubernetes. Consulte Suporte a versões e upgrades do GKE Enterprise para conferir detalhes da versão e os patches recomendados.

(13) O Vault não é certificado em Google Distributed Cloud for VMware.

(14) Suporte disponível para a Apigee híbrida versão 1.10.5 e mais recentes.

(15) Suporte disponível para a Apigee híbrida versão 1.11.2 e mais recentes.

(16) Suporte disponível para a Apigee híbrida versão 1.12.1 e mais recentes.

Sobre os clusters anexados

Para a Apigee híbrida versão 1.7.x e anteriores, é necessário usar os clusters anexados do GKE quando você quer executar a Apigee híbrida em um contexto multicloud no Elastic Kubernetes Service (EKS), no Azure Kubernetes Service (AKS) ou em outro provedor de serviços de terceiros do Kubernetes com suporte. O anexo do cluster permite que o Google meça o uso do Anthos Service Mesh.

Para a versão híbrida da Apigee 1.8.x, os clusters anexados ao GKE são obrigatórios se você estiver usando o Anthos Service Mesh no seu gateway de entrada. Se você estiver usando o gateway de entrada da Apigee, os clusters anexados serão opcionais.

Instalar o ambiente de execução híbrido 1.10.5

  1. Verifique se você está no diretório base híbrido (o pai do diretório em que o arquivo executável apigeectl está localizado): 
    cd $APIGEECTL_HOME/..

  2. Faça o download do pacote de lançamento do seu sistema operacional usando o seguinte comando. Selecione sua plataforma na tabela a seguir:

    Linux Mac OS Windows

    Linux de 64 bits:

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

    Mac 64 bits:

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

    Windows 64 bit:

    curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.10.5/apigeectl_windows_64.zip
  3. Renomeie o diretório apigeectl/ atual para um nome de diretório de backup. Exemplo:
    Linux Mac OS Windows 
    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.9/
     
    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.9/ 
    rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.9

  4. Extraia o conteúdo do arquivo gzip baixado para seu diretório base híbrido. O diretório base híbrido é aquele em que o diretório renomeado apigeectl-v1.9 está localizado:

    Linux Mac OS Windows 
    tar xvzf filename.tar.gz -C ./
     
    tar xvzf filename.tar.gz -C ./
     
    tar xvzf filename.zip -C ./

  5. O conteúdo de tar é, por padrão, expandido em um diretório com a versão e a plataforma no nome. Por exemplo, ./apigeectl_1.10.5-xxxxxxx_linux_64. Renomeie esse diretório para apigeectl usando o seguinte comando:

    Linux Mac OS Windows 
    mv apigeectl_1.10.5-xxxxxxx_linux_64 apigeectl
     
    mv apigeectl_1.10.5-xxxxxxx_mac_64 apigeectl
     
    rename apigeectl_1.10.5-xxxxxxx_windows_64 apigeectl
  6. Altere para o diretório apigeectl: 
    cd ./apigeectl

    Esse diretório é o diretório inicial apigeectl. É lá que o comando executável apigeectl está localizado.

  7. Estas instruções usam a variável de ambiente $APIGEECTL_HOME para o diretório no seu sistema de arquivos em que o utilitário apigeectl está instalado. Se necessário, mude o diretório para seu diretório apigeectl e defina a variável com o seguinte comando:
    Linux Mac OS Windows 
    export APIGEECTL_HOME=$PWD
     
    echo $APIGEECTL_HOME
     
    export APIGEECTL_HOME=$PWD
     
    echo $APIGEECTL_HOME
     
    set APIGEECTL_HOME=%CD%
     
    echo %APIGEECTL_HOME%
  8. Verifique a versão de apigeectl com o comando version: 
    ./apigeectl version
     
    Version: 1.10.5
  9. Crie um diretório hybrid-base-directory/hybrid-files e acesse-o. O diretório hybrid-files é onde estão localizados os arquivos de configuração, como os arquivos de substituição, certificados e contas de serviço. Por exemplo:
    Linux Mac OS Windows 
    mkdir $APIGEECTL_HOME/../hybrid-files
     
    cd $APIGEECTL_HOME/../hybrid-files
     
    mkdir $APIGEECTL_HOME/../hybrid-files
     
    cd $APIGEECTL_HOME/../hybrid-files
     
    mkdir %APIGEECTL_HOME%/../hybrid-files
     
    cd %APIGEECTL_HOME%/../hybrid-files
  10. Verifique se kubectl está definido para o contexto correto usando o seguinte comando. O contexto atual precisa ser definido como o cluster em que você está fazendo upgrade da Apigee híbrida. 
    kubectl config get-contexts | grep \*
  11. No diretório hybrid-files:
    1. Atualize os seguintes links simbólicos para $APIGEECTL_HOME. Com esses links, você pode executar o comando apigeectl recém-instalado no diretório hybrid-files: 
      ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
    2. Para verificar se os links simbólicos foram criados corretamente, execute este comando e certifique-se de que os caminhos do link apontam para os locais corretos: 
      ls -l | grep ^l
  12. Faça a seguinte mudança no arquivo overrides.yaml para ativar o gráfico apigee-operator usando a tag correta, 1.10.5-hotfix.1: 
      ao:
    image:
      url: "gcr.io/apigee-release/hybrid/apigee-operators"
      tag: "1.10.5-hotfix.1"
  13. Faça uma inicialização a seco para verificar se há erros: 
    ${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client

    Em que OVERRIDES_FILE é o nome do arquivo de substituições, por exemplo, ./overrides/overrides.yaml.

  14. Se não houver erros, inicialize o híbrido 1.10.5: 
    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
  15. Verifique o status da inicialização: 
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Em caso de sucesso, a saída vai ser: All containers ready. 

    kubectl describe apigeeds -n apigee

    Na saída, procure State: running.

  16. Verifique se há erros com uma simulação do comando apply usando a sinalização --dry-run: 
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
  17. Se não houver erros, aplique as substituições. Selecione e siga as instruções para ambientes de produção ou ambientes sem produção, dependendo da sua instalação.
    ProduçãoSem produção

    Para ambientes de produção, você precisa fazer upgrade de cada componente híbrido individualmente e verificar o status do componente atualizado antes de seguir para o próximo componente.

    1. Verifique se você está no diretório hybrid-files.
    2. Aplique as modificações para fazer upgrade do Cassandra: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
    3. Verifique a conclusão: 
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

      Passe para a próxima etapa somente quando os pods estiverem prontos.

    4. Aplique as modificações para fazer upgrade dos componentes de telemetria e verificar a conclusão: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
       
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    5. Acesse os componentes do Redis: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
    6. Aplique as modificações para fazer upgrade dos componentes no nível da organização (MART, Watcher e Apigee Connect) e verifique a conclusão: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
       
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    7. Aplique as modificações para fazer upgrade dos seus ambientes. Você tem duas opções:
      • Ambiente por ambiente: aplique suas modificações em um ambiente por vez e verifique a conclusão. Repita esta etapa para cada ambiente: 
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
         
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

        Em que ENV_NAME é o nome do ambiente que você está atualizando.

      • Todos os ambientes de uma só vez: aplique suas modificações a todos os ambientes de uma só vez e verifique a conclusão: 
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
         
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    8. Aplique as modificações para fazer upgrade dos componentes virtualhosts de telemetria e verificar a conclusão: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
       
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Na maioria dos ambientes de produção, de demonstração ou experimental, é possível aplicar as substituições a todos os componentes de uma só vez. Se o ambiente de não produção for grande e complexo, ou imita frequentemente um ambiente de produção, use as instruções para fazer upgrade dos ambientes de produção.

    1. Verifique se você está no diretório hybrid-files.
    2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
    3. Verifique o status: 
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

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. Altere a variável APIGEECTL_HOME para apontar para o diretório que contém a versão original de apigeectl. Por exemplo: 
    export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
  4. No diretório raiz da instalação para a qual você quer reverter, execute apigeectl apply, verifique o status dos pods e execute apigeectl init. Use o arquivo de modificações original da versão para a qual você quer reverter:
    1. No diretório de arquivos híbridos, execute apigeectl apply: 
      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

      Em que ORIGINAL_OVERRIDES_FILE é o caminho relativo e o nome do arquivo de substituições para a instalação híbrida da versão anterior, por exemplo, ./overrides/overrides1.9.yaml.

    2. Verifique o status dos seus pods. 
      kubectl -n NAMESPACE get pods

      Em que NAMESPACE é seu namespace da Apigee híbrida.

    3. Verifique o status de apigeeds: 
      kubectl describe apigeeds -n apigee

      A saída será semelhante a esta: 

      Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running

      Siga para a próxima etapa somente quando o pod apigeeds estiver em execução.

    4. Execute o comando a seguir para anotar quais serão os novos valores de contagem da réplica para o processador de mensagens após o upgrade. Se esses valores não corresponderem ao que você definiu anteriormente, altere os valores no arquivo de substituições para corresponder à configuração anterior. 
      apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2

      A saída será semelhante a esta: 

            autoScaler:
        minReplicas: 2
        maxReplicas: 10
    5. Execute apigeectl init: 
      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE