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órioapigeectl
paraapigeectl_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.
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 propriedadevirtualhosts.hostAliases[]
. - Adicione a nova propriedade de configuração obrigatória
virtualhosts
. - Você precisa mover as propriedades
envs[].sslCertPath
eenvs[].sslKeyPath
deenvs
paravirtualhosts
. - Adicione a estrofe de configuração
virtualhosts.routingRules
. A propriedadevirtualhosts.routingRules
substitui a propriedadeenvs[].paths
anterior. Se você tiverenvs[].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
- A propriedade
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:
- Primeiro, liste as implantações da Apigee:
kubectl -n namespace get ad
- Exclua a implantação do Apigee Connect:
kubectl -n namespace delete ad apigee-connect-name
- Primeiro, liste as implantações da Apigee:
- 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 comandoapply
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, 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
- 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 deapigeectl
. 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, executeapigeectl 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