Esta página foi traduzida pela API Cloud Translation.

Atualizar o Apigee Hybrid para a versão 1.14

Este procedimento abrange a atualização da versão 1.13.x do Apigee Hybrid para a versão 1.14.2 do Apigee Hybrid e de versões anteriores do Hybrid 1.14.x para a versão 1.14.2.

Use os mesmos procedimentos para atualizações de versões secundárias (por exemplo, da versão 1.13 para a 1.14) e para atualizações de lançamentos de patches (por exemplo, da versão 1.14.1 para a 1.14.2).

Se estiver a atualizar a partir da versão 1.12 ou anterior do Apigee Hybrid, tem de atualizar primeiro para a versão 1.13 antes de atualizar para a versão 1.14.2. Consulte as instruções para atualizar o Apigee Hybrid para a versão 1.13.

Alterações do Apigee Hybrid v1.13

Tenha em atenção as seguintes alterações:

A partir da versão 1.14, os componentes do plano de dados escrevem dados diretamente no plano de controlo por predefinição. Isto oferece maior fiabilidade e conformidade para os dados de depuração e de estatísticas. Consulte o artigo Configure o modo híbrido para usar o novo pipeline de dados.
O Anthos (em bare metal ou VMware) é agora o Google Distributed Cloud (para bare metal ou VMware): para mais informações, consulte as descrições gerais dos produtos Google Distributed Cloud para bare metal e Google Distributed Cloud para VMware.
Verificações de instanciação de classes mais rigorosas: a partir da versão 1.14.1 do Apigee Hybrid, a política JavaCallout inclui agora segurança adicional durante a instanciação de classes Java. A medida de segurança melhorada impede a implementação de políticas que tentam direta ou indiretamente ações que requerem autorizações não permitidas.
Na maioria dos casos, as políticas existentes continuam a funcionar como esperado, sem problemas. No entanto, existe a possibilidade de as políticas que dependem de bibliotecas de terceiros ou que têm código personalizado que aciona indiretamente operações que requerem autorizações elevadas serem afetadas.

Importante: para testar a instalação, siga o procedimento em Valide as políticas após a atualização para a versão 1.14.1 para validar o comportamento das políticas.

Para mais informações acerca das funcionalidades na versão híbrida 1.14, consulte as notas de lançamento do Apigee hybrid v1.14.0.

Pré-requisitos

Antes de atualizar para a versão híbrida 1.14, certifique-se de que a sua instalação cumpre os seguintes requisitos:

Se a sua instalação híbrida estiver a executar uma versão anterior à v1.13, tem de fazer a atualização para a versão 1.13 antes de atualizar para a v1.14. Consulte o artigo Atualizar o Apigee Hybrid para a versão 1.13.
Versão do Helm v3.14.2 ou superior.
kubectl: uma versão suportada do kubectl adequada para a versão da sua plataforma Kubernetes. Consulte o artigo Plataformas e versões suportadas: kubectl.
cert-manager: uma versão suportada do cert-manager. Consulte o artigo Plataformas e versões suportadas: cert-manager. Se necessário, atualize o cert-manager na secção Prepare-se para atualizar para a versão 1.14 abaixo.

Antes de atualizar para a versão 1.14.2: limitações e notas importantes

O Apigee Hybrid 1.14.2 apresenta um novo limite de proxy melhorado por ambiente que lhe permite implementar mais proxies e fluxos partilhados num único ambiente. Consulte o artigo Limites: proxies de API para compreender os limites do número de proxies e fluxos partilhados que pode implementar por ambiente. Esta funcionalidade só está disponível em organizações híbridas criadas recentemente e não pode ser aplicada a organizações atualizadas. Para usar esta funcionalidade, faça uma nova instalação do Hybrid 1.14.2 e crie uma nova organização.

Esta funcionalidade está disponível exclusivamente como parte do plano de subscrição de 2024 e está sujeita às concessões concedidas ao abrigo dessa subscrição. Consulte os Limites de proxy melhorados por ambiente para saber mais acerca desta funcionalidade.
A atualização para a versão 1.14 do Apigee Hybrid pode exigir tempo de inatividade.

Quando atualizar o controlador do Apigee para a versão 1.14.2, todas as implementações do Apigee são reiniciadas de forma gradual. Para minimizar o tempo de inatividade em ambientes híbridos de produção durante um reinício contínuo, certifique-se de que está a executar, pelo menos, dois clusters (na mesma região ou num centro de dados diferente). Desvie todo o tráfego de produção para um único cluster e coloque o cluster que está prestes a atualizar offline. Em seguida, avance com o processo de atualização. Repita o processo para cada cluster.

A Apigee recomenda que, assim que iniciar a atualização, atualize todos os clusters o mais rapidamente possível para reduzir as probabilidades de impacto na produção. Não existe um limite de tempo para a atualização de todos os clusters restantes depois de o primeiro ser atualizado. No entanto, até que todos os clusters restantes sejam atualizados, a cópia de segurança e o restauro do Cassandra não podem funcionar com versões mistas. Por exemplo, não é possível usar uma cópia de segurança da versão híbrida 1.13 para restaurar uma instância da versão híbrida 1.14.
Não é necessário suspender totalmente as alterações do plano de gestão durante uma atualização. Quaisquer suspensões temporárias necessárias às alterações do plano de gestão são indicadas nas instruções de atualização abaixo.

Atualização para a versão 1.14.2: vista geral

Os procedimentos para atualizar o Apigee hybrid estão organizados nas seguintes secções:

Prepare-se para a atualização.
Instale a versão 1.14.2 do tempo de execução híbrido.

Prepare-se para atualizar para a versão 1.14

Faça uma cópia de segurança da sua instalação híbrida

Estas instruções usam a variável de ambiente APIGEE_HELM_CHARTS_HOME para o diretório no seu sistema de ficheiros onde instalou os gráficos Helm. Se necessário, altere o diretório para este diretório e defina a variável com o seguinte comando:
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Mac OS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
Faça uma cópia de segurança do diretório 1.13 $APIGEE_HELM_CHARTS_HOME/. Pode usar qualquer processo de cópia de segurança. Por exemplo, pode criar um ficheiro tar de todo o diretório com:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.13-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Faça uma cópia de segurança da base de dados Cassandra seguindo as instruções em Cópia de segurança e recuperação do Cassandra.
Importante: a partir da versão 1.14, as restrições incluem as seguintes verificações relacionadas com cópias de segurança aplicadas durante a atualização do Apigee hybrid.
1. A cópia de segurança tem de estar ativada para suportar o restauro para a versão anterior, se necessário.
2. Tem de fazer uma cópia de segurança nas últimas 24 horas antes da atualização se a cópia de segurança do CSI estiver ativada. Isto minimiza a potencial perda de dados se for necessária uma restauração para a versão anterior.
Para mais informações sobre as verificações de restrições, consulte o artigo Restrições.

Se estiver a usar ficheiros de certificado de serviço (.json) nas suas substituições para autenticar contas de serviço, certifique-se de que os ficheiros de certificado de serviço residem no diretório do gráfico Helm correto. Os gráficos Helm não podem ler ficheiros fora do diretório de cada gráfico.

Este passo não é obrigatório se estiver a usar segredos do Kubernetes ou a identidade de carga de trabalho para autenticar contas de serviço.

A tabela seguinte mostra o destino de cada ficheiro de conta de serviço, consoante o seu tipo de instalação:

Prod

Conta de serviço	Nome do ficheiro predefinido	Diretório de gráficos Helm
`apigee-cassandra`	`PROJECT_ID-apigee-cassandra.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/`
`apigee-logger`	`PROJECT_ID-apigee-logger.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-mart`	`PROJECT_ID-apigee-mart.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-metrics`	`PROJECT_ID-apigee-metrics.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-runtime`	`PROJECT_ID-apigee-runtime.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env`
`apigee-synchronizer`	`PROJECT_ID-apigee-synchronizer.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env/`
`apigee-udca`	`PROJECT_ID-apigee-udca.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-watcher`	`PROJECT_ID-apigee-watcher.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`

Não prod

Faça uma cópia do ficheiro de conta de serviço apigee-non-prod em cada um dos seguintes diretórios:

Conta de serviço	Nome do ficheiro predefinido	Diretórios de gráficos Helm
`apigee-non-prod`	`PROJECT_ID-apigee-non-prod.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/` `$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/` `$APIGEE_HELM_CHARTS_HOME/apigee-org/` `$APIGEE_HELM_CHARTS_HOME/apigee-env/`

Certifique-se de que os ficheiros de chave e certificado TLS (.crt, .key e/ou .pem) residem no diretório $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Atualize a versão do Kubernetes

Verifique a versão da sua plataforma Kubernetes e, se necessário, atualize-a para uma versão suportada pelo Hybrid 1.13 e pelo Hybrid 1.14. Siga a documentação da sua plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas suportadas

	1,12 ⁽²⁾	1.13	1.14
GKE no Google Cloud	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x
GKE no AWS	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x
GKE no Azure	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x
Google Distributed Cloud (apenas software) no VMware ⁽⁵⁾	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)(8)}	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x	1.28.x⁽⁴⁾ 1.29.x 1.30.x 1.31.x
Google Distributed Cloud (apenas software) em bare metal	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)(8)}	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x	1.28.x⁽⁴⁾ 1.29.x 1.30.x 1.31.x
EKS	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x
AKS	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x
OpenShift⁽⁹⁾	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)(8)}	4.12 4.13 4.14 4.15 4.16	4.13 4.14 4.15 4.16 4.17
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x	v1.27.x 1.28.x 1.29.x 1.30.x 1.31.x
VMware Tanzu	v1.26.x	v1.26.x	v1.26.x
Componentes	1,12 ⁽²⁾	1.13	1.14
Cloud Service Mesh	1.18.x⁽³⁾	1.19.x⁽³⁾	1.22.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.11.x 1.12.x 1.13.x	1.13.x 1.14.x 1.15.x⁽¹⁰⁾	1.14.x 1.15.x⁽¹⁰⁾ 1.16.x⁽¹⁰⁾
Cassandra	4,0	4,0	4,0
Kubernetes	1.26.x 1.27.x 1.28.x 1.29.x	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x
kubectl	1.26.x 1.27.x 1.28.x 1.29.x	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x
Leme	3.14.2+	3.14.2+	3.14.2+
Controlador CSI da Secret Store	1.4.1	1.4.1	1.4.6
Vault	1.15.2	1.15.2	1.17.2
⁽¹⁾ No Anthos on-premises (Google Distributed Cloud) versão 1.13, siga estas instruções para evitar conflitos com `cert-manager`: Instalação do cert-manager em conflito ⁽²⁾ As datas oficiais de FdV para as versões 1.12 e anteriores do Apigee Hybrid foram atingidas. Os patches mensais normais já não estão disponíveis. Estas versões já não são oficialmente suportadas, exceto para clientes com exceções explícitas e oficiais para apoio técnico contínuo. Os outros clientes têm de fazer a atualização. ⁽³⁾ O Cloud Service Mesh é instalado automaticamente com o Apigee Hybrid 1.9 e mais recente. ⁽⁴⁾ Os números das versões do GKE no AWS refletem agora as versões do Kubernetes. Consulte o artigo GKE Enterprise versão e suporte de atualizações para ver detalhes da versão e patches recomendados. ⁽⁵⁾ O Vault não está certificado no Google Distributed Cloud para VMware. ⁽⁶⁾ Suporte disponível com a versão 1.10.5 e mais recentes do Apigee Hybrid. ⁽⁷⁾ Apoio técnico disponível com a versão 1.11.2 e mais recentes do Apigee Hybrid. ⁽⁸⁾ Apoio técnico disponível com a versão 1.12.1 e mais recentes do Apigee Hybrid. ⁽⁹⁾ O Apigee hybrid é testado e certificado no OpenShift através da versão do Kubernetes incluída em cada versão específica do OCP. ⁽¹⁰⁾ Algumas versões do cert-manager têm um problema em que o servidor TLS do webhook pode não renovar automaticamente o respetivo certificado da AC. Para evitar esta situação, a Apigee recomenda: Híbrida v1.13: use a versão 1.15.5+ do cert-manager. Híbrida v1.14: use as versões 1.15.5+ ou 1.16.3+ do cert-manager.

Instale o tempo de execução híbrido 1.14.2

Configure o pipeline de recolha de dados.

A partir da versão híbrida 1.14, o novo pipeline de dados de estatísticas e depuração é ativado por predefinição para todas as organizações híbridas do Apigee. Tem de seguir os passos para ativar o acesso do publicador do Analytics para configurar o fluxo de autorização.

Prepare-se para a atualização dos gráficos Helm

Extraia os gráficos Helm do Apigee.

Os gráficos do Apigee Hybrid estão alojados no Google Artifact Registry:

oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

Usando o comando pull, copie todos os gráficos Helm do Apigee hybrid para o seu armazenamento local com o seguinte comando:

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.14.2-hotfix.1
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

Atualize o cert-manager, se necessário.
Se precisar de atualizar a versão do cert-manager, instale a nova versão com o seguinte comando:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.3/cert-manager.yaml
```
Consulte o artigo Plataformas e versões suportadas: cert-manager para ver uma lista das versões suportadas.

Nota: algumas versões do cert-manager têm um problema em que o servidor TLS do webhook pode não renovar automaticamente o respetivo certificado da CA. Para evitar esta situação, a Apigee recomenda a utilização das versões 1.15.5+ ou 1.16.3+ do cert-manager.
Se o seu espaço de nomes do Apigee não for apigee, edite o ficheiro apigee-operator/etc/crds/default/kustomization.yaml e substitua o valor namespace pelo seu espaço de nomes do Apigee.
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE
```
Se estiver a usar apigee como espaço de nomes, não precisa de editar o ficheiro.

Instale as CRDs do Apigee atualizadas:

Nota: este é o único método suportado para instalar CRDs do Apigee. Não use kubectl apply sem -k, não omita --server-side.

Use a funcionalidade de teste de execução kubectl executando o seguinte comando:

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server

Depois de fazer a validação com o comando de teste, execute o seguinte comando:

kubectl apply -k  apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false

Valide a instalação com o comando kubectl get crds:

kubectl get crds | grep apigee

O resultado deve ter um aspeto semelhante ao seguinte:

apigeedatastores.apigee.cloud.google.com                    2024-08-21T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2024-08-21T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2024-08-21T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2024-08-21T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2024-08-21T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2024-08-21T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2024-08-21T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2024-08-21T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2024-08-21T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2024-08-21T14:48:35Z

Verifique as etiquetas nos nós do cluster. Por predefinição, o Apigee agenda pods de dados em nós com a etiqueta cloud.google.com/gke-nodepool=apigee-data e os pods de tempo de execução são agendados em nós com a etiqueta cloud.google.com/gke-nodepool=apigee-runtime. Pode personalizar as etiquetas do conjunto de nós no ficheiro overrides.yaml.

Para mais informações, consulte o artigo Configurar pools de nós dedicados.
Opcional: execute este passo se precisar de permitir a utilização do combinador allOf juntamente com a definição de :additionalProperties: true na sua especificação OAS. No ficheiro de substituições, adicione ou atualize a secção runtime para ativar a utilização do combinador allOf na sua especificação OAS. Para mais informações, consulte as notas de lançamento do Apigee hybrid v1.14.2-hotfix.1.
```
runtime:
  cwcAppend:
    conf_message-processor-communication_oas.disable.resolve.combinator: true
```

Instale os gráficos Helm do Apigee Hybrid

Nota: antes de executar qualquer um dos comandos de instalação/atualização do Helm, use a funcionalidade de teste do Helm adicionando --dry-run no final do comando. Consulte helm -h para ver uma lista dos comandos, das opções e da utilização suportados.

Caso contrário, navegue para o diretório APIGEE_HELM_CHARTS_HOME. Execute os seguintes comandos a partir desse diretório.

Atualize o operador/controlador do Apigee:

Nota: este passo requer autorizações de cluster elevadas. Execute helm -h ou helm upgrade -h para ver detalhes.

Execução de ensaio:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Valide a instalação do operador do Apigee:

helm ls -n APIGEE_NAMESPACE

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee   3          2024-08-21 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.14.2   1.14.2

Verifique se está em funcionamento, verificando a respetiva disponibilidade:

kubectl -n APIGEE_NAMESPACE get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Atualize o repositório de dados do Apigee:

Execução de ensaio:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Verifique se o apigeedatastore está em funcionamento verificando o respetivo estado:

kubectl -n APIGEE_NAMESPACE get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Atualize a telemetria do Apigee:

Execução de ensaio:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Verifique se está a funcionar corretamente verificando o respetivo estado:

kubectl -n APIGEE_NAMESPACE get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Atualize o Redis do Apigee:

Execução de ensaio:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Verifique se está a funcionar corretamente verificando o respetivo estado:

kubectl -n APIGEE_NAMESPACE get apigeeredis default

NAME      STATE     AGE
default   running   2d

Atualize o gestor de entrada do Apigee:

Execução de ensaio:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Verifique se está em funcionamento, verificando a respetiva disponibilidade:

kubectl -n APIGEE_NAMESPACE get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Atualize a organização do Apigee:
Execução de ensaio:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
```
Atualize o gráfico:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE
```
Verifique se está em funcionamento consultando o estado da organização respetiva:
```
kubectl -n APIGEE_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d
```
Nota: se o comando de atualização falhar com o erro Forbidden: state: releasing, os componentes existentes continuam no estado de lançamento. Pode aguardar a conclusão da atualização atual e, em seguida, tentar novamente. Verifique o estado do lançamento com o seguinte comando:
```
kubectl get org -n APIGEE_NAMESPACE
```
Nota: durante a atualização do Apigee Hybrid de versões mais antigas para a versão 1.14.2 ou posterior, a presença de CRDs istio.io existentes pode causar falhas nas sondagens de prontidão nos contentores discovery dos pods apigee-ingressgateway-manager. Este é um problema conhecido que será corrigido em lançamentos futuros. Para uma solução alternativa, consulte o Problema conhecido 416634326 nas notas de lançamento do Apigee.
Atualize o ambiente.
Tem de instalar um ambiente de cada vez. Especifique o ambiente com --set env=ENV_NAME.

Execução de ensaio:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
```
- ENV_RELEASE_NAME é um nome usado para monitorizar a instalação e as atualizações do gráfico apigee-env. Este nome tem de ser exclusivo dos outros nomes de lançamentos do Helm na sua instalação. Normalmente, este valor é igual a ENV_NAME. No entanto, se o seu ambiente tiver o mesmo nome que o seu grupo de ambientes, tem de usar nomes de lançamentos diferentes para o ambiente e o grupo de ambientes, por exemplo, dev-env-release e dev-envgroup-release. Para mais informações sobre lançamentos no Helm, consulte o artigo Três grandes conceitos class="external" na documentação do Helm.
- ENV_NAME é o nome do ambiente que está a atualizar.
- OVERRIDES_FILE é o seu novo ficheiro de substituições para a versão 1.14.2
Atualize o gráfico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Verifique se está em funcionamento consultando o estado do ambiente respetivo:
```
kubectl -n APIGEE_NAMESPACE get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```

Nota: se o comando de atualização falhar com o erro Forbidden: state: releasing, os componentes existentes continuam no estado de lançamento. Pode aguardar a conclusão da atualização atual e, em seguida, tentar novamente. Verifique o estado do lançamento com o seguinte comando:

kubectl get env -n APIGEE_NAMESPACE

Atualize os grupos de ambientes (virtualhosts).
1. Tem de atualizar um grupo de ambientes (virtualhost) de cada vez. Especifique o grupo do ambiente com --set envgroup=ENV_GROUP_NAME. Repita os seguintes comandos para cada grupo de ambientes mencionado no ficheiro overrides.yaml:
  Execução de ensaio:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
```
  ENV_GROUP_RELEASE_NAME é o nome com o qual instalou anteriormente o gráfico apigee-virtualhost. Normalmente, é ENV_GROUP_NAME.
  
  Atualize o gráfico:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  Nota: ENV_GROUP_RELEASE_NAME tem de ser exclusivo no espaço de nomes apigee.
  Por exemplo, se tiver um ambiente denominado prod e um grupo de ambientes denominado prod, defina o valor de ENV_GROUP_RELEASE_NAME para algo único, como prod-envgroup.
2. Verifique o estado do ApigeeRoute (AR).
  A instalação do virtualhosts cria o ApigeeRouteConfig (ARC), que cria internamente o ApigeeRoute (AR) assim que o monitor do Apigee extrai detalhes relacionados com o grupo de ambientes do plano de controlo. Por conseguinte, verifique se o estado do AR correspondente está em execução:
```
kubectl -n APIGEE_NAMESPACE get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n APIGEE_NAMESPACE get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```
Depois de verificar que todas as instalações foram atualizadas com êxito, elimine a versão apigee-operator mais antiga do espaço de nomes apigee-system.
1. Desinstale a versão operator antiga:
```
helm delete operator -n apigee-system
```
2. Elimine o espaço de nomes apigee-system:
```
kubectl delete namespace apigee-system
```

Atualize novamente o operator no seu espaço de nomes do Apigee para reinstalar os recursos com âmbito de cluster eliminados:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

Valide as políticas após a atualização para a versão 1.14.1

Use este procedimento para validar o comportamento da política JavaCallout após a atualização da versão 1.14.0 ou anterior para a versão 1.14.1 ou posterior.

Verifique se os ficheiros JAR Java pedem autorizações desnecessárias.
Após a implementação da política, verifique os registos de tempo de execução para ver se a seguinte mensagem de registo está presente: "Failed to load and initialize class ...". Se observar esta mensagem, sugere que o JAR implementado pediu autorizações desnecessárias. Para resolver este problema, investigue o código Java e atualize o ficheiro JAR.
Investigue e atualize o código Java.
Reveja qualquer código Java (incluindo dependências) para identificar a causa de operações potencialmente não permitidas. Quando o encontrar, modifique o código-fonte conforme necessário.
Teste as políticas com a verificação de segurança ativada.
Num ambiente de não produção, ative a flag de verificação de segurança e volte a implementar as suas políticas com um JAR atualizado. Para definir a flag:
- No ficheiro apigee-env/values.yaml, defina conf_security-secure.constructor.only como true em runtime:cwcAppend:. Por exemplo:
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- Atualize o gráfico apigee-env para que a alteração seja aplicada ao ambiente. Por exemplo:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Se a mensagem de registo "Failed to load and initialize class ..." ainda estiver presente, continue a modificar e testar o JAR até que a mensagem de registo deixe de aparecer.
Ative a verificação de segurança no ambiente de produção.
Depois de testar e validar exaustivamente o ficheiro JAR no ambiente de não produção, ative a verificação de segurança no seu ambiente de produção definindo a flag conf_security-secure.constructor.only como true e atualizando o gráfico apigee-env para o ambiente de produção para aplicar a alteração.

Reverter para uma versão anterior

Para reverter para a versão anterior, use a versão mais antiga do gráfico para reverter o processo de atualização na ordem inversa. Comece por apigee-virtualhost e avance até apigee-operator e, em seguida, reverta os CRDs.

Sugestão: se souber a última versão de lançamento, pode usar o comando helm rollback em vez do comando helm upgrade descrito abaixo.

Reverta todos os gráficos de apigee-virtualhost para apigee-datastore. Os comandos seguintes pressupõem que está a usar os gráficos da versão anterior (v1.13.x).

Execute o seguinte comando para cada grupo de ambientes:

helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.13_OVERRIDES_FILE

Execute o seguinte comando para cada ambiente:

helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f 1.13_OVERRIDES_FILE

Reverta os restantes gráficos, exceto o apigee-operator.

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

Crie o espaço de nomes apigee-system.
```
kubectl create namespace apigee-system
```

Corrija a anotação de recursos de volta para o espaço de nomes apigee-system.

kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='apigee-system'

Se também tiver alterado o nome de lançamento, atualize a anotação com o nome de lançamento operator.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
```

Instale apigee-operator novamente no espaço de nomes apigee-system.

helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.13_OVERRIDES_FILE

Reverta os CRDs reinstalando os CRDs mais antigos.

kubectl apply -k apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false

Limpe a versão apigee-operator do espaço de nomes APIGEE_NAMESPACE para concluir o processo de reversão.
```
helm uninstall operator -n APIGEE_NAMESPACE
```
Alguns recursos com âmbito de cluster, como clusterIssuer, são eliminados quando operator é desinstalado. Reinstale-as com o seguinte comando:
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.13_OVERRIDES_FILE
```

Atualizar o Apigee Hybrid para a versão 1.14 Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Alterações do Apigee Hybrid v1.13

Pré-requisitos

Antes de atualizar para a versão 1.14.2: limitações e notas importantes

Atualização para a versão 1.14.2: vista geral

Prepare-se para atualizar para a versão 1.14

Faça uma cópia de segurança da sua instalação híbrida

Linux

Mac OS

Windows

Prod

Não prod

Atualize a versão do Kubernetes

Clique para expandir uma lista de plataformas suportadas

Componentes

Instale o tempo de execução híbrido 1.14.2

Configure o pipeline de recolha de dados.

Prepare-se para a atualização dos gráficos Helm

Instale os gráficos Helm do Apigee Hybrid

Valide as políticas após a atualização para a versão 1.14.1

Reverter para uma versão anterior

Atualizar o Apigee Hybrid para a versão 1.14