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

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

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

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
```
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
```
cd ao diretório base.
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.
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.
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

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.

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:

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

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

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
```
Liste os pods:
```
kubectl get pods -n namespace
```
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
```

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

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

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}')
```

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}')

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}')

cd para o diretório ./hybrid-files:

Inicialize apigeectl para a nova versão:

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

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

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

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
```
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
```
Execute check-ready novamente para determinar quando o upgrade será concluído.

Como reverter um upgrade

Siga estas etapas para reverter um upgrade anterior:

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}')
```

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}')

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}')

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
```
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
```
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
```