Como fazer upgrade do Apigee híbrido

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.
  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[].
    • 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:

    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

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, será possível 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