Esta página foi traduzida pela API Cloud Translation.

Atualizar o Apigee Hybrid para a versão 1.13

Este procedimento abrange a atualização da versão 1.12.x do Apigee Hybrid para a versão 1.13.4 do Apigee Hybrid e das versões anteriores do Hybrid 1.13.x para a versão 1.13.4.

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

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

Alterações do Apigee Hybrid v1.12

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

apigee-operator no espaço de nomes do Apigee: a partir da versão 1.13, o apigee-operator é executado no mesmo espaço de nomes do Kubernetes que os outros componentes híbridos do Apigee, apigee por predefinição. Pode fornecer qualquer nome para o espaço de nomes. Nas versões anteriores, o apigee-operator era obrigatório para ser executado no seu próprio espaço de nomes, apigee-system.
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.13.3, o 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 descrito no artigo Valide as políticas após a atualização para a versão 1.13.3 ou posterior para validar o comportamento das políticas.

Pré-requisitos

Antes de atualizar para a versão híbrida 1.13, 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.12, tem de fazer a atualização para a versão 1.12 antes de fazer a atualização para a v1.13. Consulte o artigo Atualizar o Apigee Hybrid para a versão 1.12.
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 a atualização para a versão 1.13 abaixo.

Vista geral da atualização para a versão 1.13.4

A atualização para a versão 1.13 do Apigee Hybrid pode exigir tempo de inatividade.

Quando atualizar o controlador do Apigee para a versão 1.13.4, todas as implementações do Apigee são reiniciadas de forma contínua. 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 atualize todos os clusters assim que 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.12 para restaurar uma instância da versão híbrida 1.13.

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.13.4 do tempo de execução híbrido.

Prepare-se para atualizar para a versão 1.13

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.12 $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.12-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.

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.12 e pelo Hybrid 1.13. Siga a documentação da sua plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas suportadas

	1.10 ⁽²⁾	1.11	1.12	1.13
GKE no Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x 1.30.x
GKE no AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)} 1.30.x
GKE no Azure	1.13.x 1.14.x 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)} 1.30.x
Google Distributed Cloud (apenas software) no VMware ⁽⁵⁾	1.13.x ⁽¹⁾ 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)}	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x
Google Distributed Cloud (apenas software) em bare metal	1.13.x ⁽¹⁾ 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x⁽⁴⁾^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)}	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x
EKS	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.26.x 1.27.x 1.28.x 1.29.x
AKS	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.26.x 1.27.x 1.28.x 1.29.x
OpenShift	4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}	4.12 4.13 4.14 4.15 4.16
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x
VMware Tanzu	N/A	N/A	v1.26.x	v1.26.x
Componentes	1.10	1.11	1.12	1.13
Cloud Service Mesh	1.17.x⁽³⁾	1.17.x^{(v1.11.0 - v1.11.1)}⁽³⁾ 1.18.x^{(≥ 1.11.2)}⁽³⁾	1.18.x⁽³⁾	1.19.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x	1.13.x 1.14.x 1.15.x
Cassandra	3.11	3.11	4,0	4,0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x 1.29.x	1.27.x 1.28.x 1.29.x 1.30.x
kubectl	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x 1.29.x	1.27.x 1.28.x 1.29.x 1.30.x
Leme	3.10+	3.10+	3.14.2+	3.14.2+
Controlador CSI da Secret Store		1.3.4	1.4.1	1.4.1
Vault		1.13.x	1.15.2	1.15.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.10 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.

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

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.13.4
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.15.5/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 da versão 1.15.5 ou superior 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

Migre apigee-operator do espaço de nomes apigee-system para APIGEE_NAMESPACE.
Nota: este passo só é necessário para atualizações a partir da versão 1.12.x. Se estiver a atualizar a partir de uma versão anterior à 1.13, pode ignorar este passo.
1. Anote o clusterIssuer com o novo espaço de nomes
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='APIGEE_NAMESPACE'
```
2. Se estiver a alterar o nome do lançamento de apigee-operator, anote o ficheiro clusterIssuer com o novo nome do lançamento.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='APIGEE_OPERATOR_RELEASE_NAME'
```
3. Atualize as réplicas da sua implementação do Apigee Operator existente no espaço de nomes apigee-system para 0 (zero) para evitar a conciliação dos dois controladores.
```
kubectl scale deployment apigee-controller-manager -n apigee-system --replicas=0
```
4. Elimine o apigee-mutating-webhook-configuration e o apigee-validating-webhook-configuration.
```
kubectl delete mutatingwebhookconfiguration apigee-mutating-webhook-configuration
kubectl delete validatingwebhookconfiguration apigee-validating-webhook-configuration
```
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.

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.13.4   1.13.4

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
```
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.13.4
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.
Nota: este passo só é necessário para atualizações a partir da versão 1.12.x. Se estiver a atualizar a partir de uma versão anterior à 1.13, pode ignorar este passo.
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:
Nota: este passo só é necessário para atualizações a partir da versão 1.12.x. Se estiver a atualizar a partir de uma versão anterior à 1.13, pode ignorar este passo.
```
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.13.3 ou posterior

Use este procedimento para validar o comportamento da política JavaCallout após a atualização da versão 1.13.2 ou anterior para a versão 1.13.3 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.

Devido à alteração no espaço de nomes para apigee-operator, tem de realizar passos adicionais para eliminar os hooks de admissão de validação e mutação. Deste modo, quando reinstalar o apigee-operator no espaço de nomes apigee-system, estes são recriados para apontar para o ponto final correto do operador do Apigee.

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.

Atualize as réplicas da implementação do Apigee Operator existente no Apigee para 0 (zero) para evitar que os dois controladores reconciliem os recursos personalizados e evitem conflitos quando revertê-los no espaço de nomes apigee-system.

kubectl scale deployment apigee-controller-manager -n APIGEE_NAMESPACE --replicas=0

kubectl delete mutatingwebhookconfiguration \
  apigee-mutating-webhook-configuration-APIGEE_NAMESPACE

kubectl delete validatingwebhookconfiguration \
  apigee-validating-webhook-configuration-APIGEE_NAMESPACE

Reverta todos os gráficos de apigee-virtualhost para apigee-datastore. Os comandos seguintes partem do princípio de que está a usar os gráficos da versão anterior (v1.12.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.12_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.12_OVERRIDES_FILE

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

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

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

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

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

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.12_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.12_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.12_OVERRIDES_FILE
```

Atualizar o Apigee Hybrid para a versão 1.13 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.12

Pré-requisitos

Vista geral da atualização para a versão 1.13.4

Prepare-se para atualizar para a versão 1.13

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.13.4

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.13.3 ou posterior

Reverter para uma versão anterior

Atualizar o Apigee Hybrid para a versão 1.13