Esta página foi traduzida pela API Cloud Translation.

Atualizar o Apigee Hybrid

Atualizar para a versão 1.2.0

Siga estes passos para atualizar o Apigee hybrid para a versão 1.2.0:

Passo 1: atualize o Kubernetes e transfira o pacote de lançamento

Atualize a sua plataforma Kubernetes da seguinte forma. Siga a documentação da sua plataforma se precisar de ajuda:

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

Transfira o pacote de lançamento para o seu sistema operativo:

Mac 64 bits:

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 de 32 bits:

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

Linux de 32 bits

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

Passo 2: reconfigure o diretório de instalação

Identifique o diretório de instalação base que foi criado quando o Apigee Hybrid foi instalado originalmente. O diretório base é o diretório no qual reside o diretório $APIGEEGTL_HOME. No exemplo seguinte, o diretório base é /Users/myhome/hybrid:
```
echo $APIGEECTL_HOME
/Users/myhome/hybrid/apigeectl
```
Extraia o conteúdo do ficheiro gzip transferido para o diretório base do Apigee Hybrid:
```
tar xvzf filename.tar.gz -C path-to-base-directory
```
cd para o diretório base.
Por predefinição, o conteúdo do ficheiro TAR é expandido para um diretório com a versão e a plataforma no nome. Por exemplo: ./apigeectl_1.2.0-f7b96a8_linux_64.
Mude o nome do diretório apigeectl atual. Por exemplo, se a versão atual for 1.1.1, mude o nome do diretório apigeectl para apigeectl_1.1.1.
Mude o nome do diretório de instalação recém-extraído para apigeectl. Agora, é aqui que o ambiente $APIGEECTL_HOME aponta.

Passo 3: atualize o ficheiro de substituições

Faça uma cópia do ficheiro de substituições e tenha cuidado para guardar o ficheiro antigo caso precise de o reverter. Nos passos seguintes, vai fazer as alterações necessárias ao ficheiro de substituições antes de o aplicar ao cluster.
NOTA: para atualizar para a versão 1.2.0, tem de fazer alterações no ficheiro de substituições que são incompatíveis com as versões anteriores. As alterações ao ficheiro de substituição descritas no passo seguinte são obrigatórias.

Atualize o ficheiro de substituições com as alterações descritas abaixo:

Segue-se um resumo das alterações de configuração que tem de fazer ao ficheiro de substituições. É apresentado um exemplo completo na tabela que se segue ao resumo. Como pode 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[].
NOTA: se usou um único caráter universal "*" para o alias do anfitrião do ambiente numa versão anterior, na versão 1.2.0 TEM de usar um nome DNS totalmente qualificado ou um caráter universal de subdomínio na configuração do alias do anfitrião virtual. Por exemplo: *.mydomain.com. A configuração de um único caráter universal hostAliases['*'] já não é suportada.
Tem de adicionar a nova propriedade de configuração obrigatória virtualhosts.
Tem de mover as propriedades envs[].sslCertPath e envs[].sslKeyPath de envs para virtualhosts.
Tem de adicionar a secção de configuração virtualhosts.routingRules. A propriedade virtualhosts.routingRules substitui a propriedade envs[].paths anterior. Se tiver envs[].paths no ficheiro de substituições, tem de o remover. Para mais informações sobre a configuração do anfitrião virtual, consulte o artigo Configure anfitriões virtuais.

A tabela abaixo ilustra as diferenças entre um ficheiro de substituições 1.1.1 e um ficheiro 1.2.0. O exemplo destina-se a realçar os tipos de alterações que tem de fazer para a versão 1.2.0:

Configuração v1.1.x	Configuração 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 v1.1.x

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

NOTA: se não especificar envs[].paths (conforme mostrado na tabela acima), pode omitir a propriedade virtualhosts[].routingRules.paths[] na atualização. Por predefinição, o caminho é "/". Por exemplo, se quiser usar o caminho predefinido de "/", pode configurar o virtualhosts[].routingRules da seguinte forma:

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

Passo 4: aplique a atualização ao cluster

Se ativou o Apigee Connect na instalação da versão 1.1.1, tem de remover a implementação:
1. Primeiro, liste as implementações do Apigee:
```
kubectl -n namespace get ad
```
2. Elimine a implementação do Apigee Connect:
```
kubectl -n namespace delete ad apigee-connect-name
```
Indique os pods:
```
kubectl get pods -n namespace
```
Elimine o pod apigee-cps-setup do cluster. Use o nome completo do pod, que inclui o nome da sua organização, conforme devolvido no comando anterior. Por exemplo:
```
kubectl -n namespace delete pod apigee-cps-setup-org
```
Elimine o pod apigee-cps-create-user no mesmo espaço de nomes:
```
kubectl -n namespace delete pod apigee-cps-create-user
```
Limpe as tarefas concluídas para o espaço de nomes de tempo de execução híbrido, em que namespace é o espaço de nomes especificado no ficheiro de substituições, se tiver especificado um espaço de nomes. Caso contrário, o espaço de nomes predefinido é apigee:
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Limpe as tarefas concluídas para o espaço de nomes apigee-system:

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

Limpe as tarefas concluídas para o espaço de nomes 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 o apigeectl para a nova versão:

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

Verifique para determinar quando a inicialização está concluída:

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

Quando o check-ready responder com "Todos os contentores estão prontos", pode experimentar uma instalação "de teste". Execute o comando apply com a flag --dry-run=true. A execução de um teste permite-lhe verificar se existem erros antes de serem feitas alterações ao cluster:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
```
Se não existirem erros, pode aplicar os componentes de tempo de execução específicos do Apigee ao cluster:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml
```
Execute novamente check-ready para determinar quando a atualização está concluída.

Reverter uma atualização

Siga estes passos para reverter uma atualização anterior:

Limpe as tarefas concluídas para o espaço de nomes de tempo de execução híbrido, em que namespace é o espaço de nomes especificado no ficheiro de substituições, se tiver especificado um espaço de nomes. Caso contrário, o espaço de nomes predefinido é apigee:
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```