O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Atualizar a Apigee Edge 4.53.00 ou 4.53.01 para 4.54.00

A Apigee oferece suporte ao upgrade do Edge para nuvem privada diretamente da versão 4.53.00 ou 4.53.01 para a versão 4.54.00. Nesta página, descrevemos como realizar esses upgrades.

Para uma visão geral dos caminhos de upgrade compatíveis, consulte a matriz de compatibilidade de upgrade para versões do Edge para nuvem privada.

Quem pode fazer a atualização

A pessoa que executa a atualização precisa ser a mesma que instalou o Edge originalmente ou uma pessoa que executa como raiz.

Depois de instalar os RPMs do Edge, qualquer pessoa pode configurá-los.

Quais componentes você precisa atualizar

É preciso atualizar todos os componentes do Edge. O Edge não é compatível com uma configuração que contenha componentes de várias versões.

Materiais de leitura prévia

Confira nos tópicos a seguir informações importantes sobre as mudanças introduzidas no Edge para nuvem privada 4.54.00:

Mudanças na versão 4.54.00:revise as mudanças na TLS e na chamada de Java que exigem preparação antes do upgrade. Para mais informações, consulte Mudanças na versão 4.54.00.
Arquitetura de ambiente de execução dual-Java (Java 17 e Java 21): a partir da versão 4.54.00, o Edge para nuvem privada remove o suporte ao Java 8 e executa componentes no Java 17 ou no Java 21. Para mais informações, consulte Mudanças na versão 4.54.00.
Sem instalação automática do Java durante o bootstrap:o Edge para nuvem privada 4.54.00 pode descobrir instalações do Java e validar se você tem o Java 17 e o 21 instalados.
Nova interface do Edge na versão 4.54.00:saiba mais sobre a transição para a nova interface do Edge como a interface de gerenciamento padrão e a remoção da interface clássica (edge-ui). Para mais informações, consulte Nova interface do Edge.
SSO da Apigee na versão 4.54.00:entenda a arquitetura de SSO atualizada e as mudanças de configuração para autenticação. Para mais informações, consulte SSO da Apigee.
Nginx 1.30 na versão 4.54.00:confira o upgrade automático do Nginx 1.30.x nos roteadores do Edge, os possíveis impactos no ambiente de execução e as etapas de mitigação. Para mais informações, consulte Mudanças no Nginx 1.30.

Pré-requisitos de upgrade

Verifique os seguintes pré-requisitos antes de fazer upgrade da Apigee Edge:

Analisar as notas da versão e os novos recursos

Analise e entenda todos os novos recursos, mudanças de comportamento e desativações detalhados nas notas da versão do Edge para nuvem privada antes de iniciar o processo de upgrade.
Descoberta e coexistência automáticas de binários Java durante o upgrade:instale o Java usando gerenciadores de pacotes padrão (como yum) ou locais padrão (como /usr/lib/jvm ou update-alternatives). Não é necessário configurar as duas versões no PATH do sistema ao mesmo tempo. Não desinstale o Java 8 antes de fazer upgrade. Mantenha o Java 8 instalado junto com o Java 17 e o Java 21 para que os serviços atuais do Edge para nuvem privada 4.53.xx continuem em execução sem interrupções até serem atualizados.
Fazer backup de todos os nós

Antes de atualizar, recomendamos que você faça um backup completo de todos os nós por motivos de segurança. Use o procedimento da sua versão atual do Edge para realizar o backup. Isso permite que você tenha um plano de backup, caso a atualização para uma nova versão não funcione corretamente. Para mais informações sobre backup, consulte Backup e restauração.
Backup do arquivo de configuração silenciosa

Verifique se as cópias de backup dos arquivos de configuração silenciosa do Edge para nuvem privada 4.53.00 ou 4.53.01 foram mantidas para facilitar uma reversão, se necessário.
Verificar se o Edge está em execução

Verifique se o Edge está em execução durante o processo de atualização usando o comando:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Verificar os pré-requisitos do Cassandra

Se você fez upgrade de uma versão mais antiga do Edge para nuvem privada para a versão 4.53.00 (ou) 4.53.01 e agora planeja fazer upgrade para a versão 4.54.00, verifique se você concluiu as etapas pós-upgrade necessárias para o Cassandra. Essas etapas estão descritas na documentação de upgrade da versão 4.53.00 (ou) 4.53.01 e também são mencionadas em Pré-requisitos para o upgrade do Cassandra. Se você não tiver certeza se essas etapas foram concluídas durante o upgrade anterior, conclua-as novamente antes de prosseguir com o upgrade para a versão 4.54.00.
Interrompa o apigee-monit:se o apigee-monit estiver em execução no nó, interrompa-o com /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop antes de fazer upgrade. Isso impede que o apigee-monit reinicie automaticamente os componentes durante o upgrade. Reative-o com apigee-service apigee-monit start após a conclusão do upgrade.

Propagação automática das configurações de propriedade

Se você tiver definido propriedades editando arquivos .properties em /opt/apigee/customer/application, esses valores serão mantidos pela atualização.

Fazer upgrade do roteador e do processador de mensagens

Faça upgrade de todos os nós de roteadores e processadores de mensagens nos data centers, um por um:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Fazer upgrade do servidor de gerenciamento

Faça upgrade de todos os nós do servidor de gerenciamento nos data centers, um por um:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Fazer upgrade para o OpenLDAP 2.6.10

O Edge para nuvem privada 4.54.00 apresenta o OpenLDAP 2.6.10. Esse upgrade se aplica a todas as topologias de implantação do OpenLDAP da Apigee: servidor único, ativo-passivo e ativo-ativo (multimestre).

Preparação e instalação (todos os servidores LDAP)

Etapas para fazer upgrade do LDAP de 4.53.00 para 4.54.00

Pré-requisitos e considerações

Durante o processo de migração do OpenLDAP 2.4 para o 2.6.10 (ao fazer upgrade da versão 4.53.00), as APIs de gerenciamento e, consequentemente, a interface da Apigee vão ficar indisponíveis em todas as regiões. Todas as tarefas administrativas, como gerenciar usuários, funções, apps e organizações, vão falhar e precisam ser pausadas. Não há impacto no processamento do tráfego do proxy de API. Encerre todas as instâncias de edge-management-server e edge-ui antes de prosseguir com a migração do LDAP.
O backup é essencial (ao fazer upgrade da versão 4.53.00): ao fazer upgrade do Edge para nuvem privada 4.53.00 (OpenLDAP 2.4.46), é obrigatório ter um backup completo e validado dos dados LDAP atuais. Se você continuar sem um backup válido, vai perder dados de forma irreversível. Inicie o backup enquanto o serviço LDAP ainda estiver em execução para capturar um snapshot consistente e pontual dos dados LDAP. Sem um backup, não é possível executar a migração da versão 2.4 para a 2.6.10 nem fazer uma reversão, porque as etapas de migração da versão 4.53.00 limpam os diretórios de dados LDAP legados.

Encerre o servidor de gerenciamento e a interface:encerre todas as instâncias de edge-management-server e edge-ui antes de prosseguir com a migração do LDAP da versão 4.53.00.
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
Faça backup dos dados LDAP atuais : antes de fazer qualquer mudança ao fazer upgrade da versão 4.53.00 (OpenLDAP 2.4.46), faça um backup completo dos dados LDAP atuais de todos os servidores LDAP. Isso cria um ponto de restauração seguro. (Ao fazer upgrade da versão 4.53.01 para a 4.54.00, essa sequência de backup, interrupção e limpeza não é necessária.)
- Execute o comando de backup. Essa ação cria um arquivo de backup com carimbo de data/hora no diretório /opt/apigee/backup/openldap.
```
apigee-service apigee-openldap backup
```
- Verifique o número total de registros:registre o número de registros no seu diretório para validação pós-upgrade. A contagem de registros precisa ser a mesma em todos os servidores LDAP.
```
# Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
```
Interrompa o LDAP e limpe os diretórios de dados: execute esta etapa em todos os servidores LDAP somente se você estiver fazendo upgrade da versão 4.53.00 (OpenLDAP 2.4.46). Não interrompa o LDAP nem exclua /opt/apigee/data/apigee-openldap/* se estiver fazendo upgrade da versão 4.53.01 (OpenLDAP 2.6.7). Para upgrades da versão 4.53.00, essa etapa é obrigatória devido à mudança na versão principal e às diferenças estruturais do banco de dados. Quando todos os servidores LDAP são interrompidos, as APIs de gerenciamento e a interface são interrompidas.
- Interrompa o serviço LDAP.
```
apigee-service apigee-openldap stop
```
- Remova permanentemente os diretórios de dados e configuração antigos do LDAP.
```
rm -rf /opt/apigee/data/apigee-openldap/*
```
Instale e configure a nova versão do LDAP: em todos os servidores LDAP, use os scripts padrão da Apigee para fazer o download e instalar a nova versão do componente.
- Instale o novo componente LDAP:o script de atualização lê o arquivo de configuração e instala o novo pacote apigee-openldap.
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
- Valide a nova versão do LDAP:após a conclusão da instalação, recarregue o perfil e verifique se a nova versão do LDAP (2.6.10) está instalada:
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
  A saída do comando especificado acima precisa verificar a versão 2.6.10 do LDAP, conforme mostrado abaixo:
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```
Interrompa o LDAP em todos os servidores antes da restauração de dados:siga as etapas 5, 6 e 7 somente se você estiver fazendo upgrade da versão 4.53.00 (OpenLDAP 2.4.46). Se você fez o upgrade no local da versão 4.53.01 na etapa 4, os dados LDAP atuais serão preservados e o upgrade será concluído. Antes de restaurar o backup da versão 4.53.00, verifique se o serviço LDAP recém-instalado está interrompido em todos os servidores. Em cada servidor LDAP, execute os seguintes comandos:
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/ldap/*
```
Restaurar dados LDAP:a estratégia é restaurar o backup no primeiro servidor ativo. Esse servidor vai atuar como a fonte de verdade, replicando os dados para os pares em uma configuração de vários servidores.
1. Identifique o primeiro servidor ativo para restauração:
  - Para configuração de servidor único:este é seu único servidor LDAP. Você pode prosseguir diretamente para a próxima etapa.
  - Para configurações ativo-passivo e ativo-ativo:execute o seguinte comando de diagnóstico em cada servidor LDAP:
```
grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
```
    Observação:
    - Se o comando acima retornar uma saída, o servidor é passivo.
    - Se não houver saída, o servidor é o ativo.
2. Restaure os dados de backup:antes de continuar, verifique se a Etapa 5 foi concluída em todos os servidores LDAP.
  - No primeiro servidor ativo identificado acima, navegue até o diretório de backup.
```
cd /opt/apigee/backup/openldap
```
  - Execute o comando de restauração. Especifique o carimbo de data/hora exato do backup da Etapa 2 para evitar a restauração de uma versão não intencional ou mais antiga.
```
# To restore a specific backup (recommended):
apigee-service apigee-openldap restore 2025.08.11,23.34.00

# To restore the latest available backup by default:
apigee-service apigee-openldap restore
```
  - Depois que o processo de restauração for concluído, inicie o serviço LDAP no primeiro servidor ativo.
```
apigee-service apigee-openldap start
```
Inicie os servidores LDAP restantes:se você tiver uma configuração de vários servidores, inicie o serviço em cada um dos servidores LDAP:
```
apigee-service apigee-openldap start
```
Observação:não é necessário restaurar os dados manualmente nesses servidores de peering. Ao iniciar, eles vão se conectar ao primeiro servidor (que agora contém os dados restaurados) e sincronizar automaticamente todo o diretório por replicação.
Validação final: a última etapa é verificar se o upgrade foi bem-sucedido e se os dados são consistentes em todo o cluster LDAP.
- Execute o comando de validação em todos os servidores LDAP. A contagem de registros precisa ser idêntica em todos os servidores e corresponder à contagem capturada na Etapa 2:
```
# Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
```
- Depois de confirmar que os dados estão corretos e consistentes, o upgrade do LDAP estará concluído. Agora é possível iniciar o edge-management-server, a edge-ui e qualquer outro componente dependente de acordo com o procedimento de upgrade padrão da sua organização.

Etapas para fazer upgrade do LDAP de 4.53.01 para 4.54.00

Instale e configure a nova versão do LDAP: em todos os servidores LDAP, use os scripts padrão da Apigee para fazer o download e instalar a nova versão do componente.

Instale o novo componente LDAP:o script de atualização lê o arquivo de configuração e instala o novo pacote apigee-openldap.
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
Valide a nova versão do LDAP:após a conclusão da instalação, recarregue o perfil e verifique se a nova versão do LDAP (2.6.10) está instalada:
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
A saída do comando especificado acima precisa verificar a versão 2.6.10 do LDAP, conforme mostrado abaixo:
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```

Fazer upgrade para a nova IU do Edge e o SSO da Apigee (se instalado)

Na Apigee Edge para nuvem privada 4.54.00, a interface clássica (edge-ui) foi removida e substituída pela nova interface do Edge (edge-management-ui). Dependendo se o Logon único (SSO) da Apigee está instalado e usado na sua configuração, siga uma das duas opções abaixo:

Opção 1: fazer upgrade da IU (sem o SSO da Apigee)

Esta seção se aplica exclusivamente se o SSO da Apigee (apigee-sso) não estiver configurado / instalado na sua instalação atual do Edge para nuvem privada versão 4.53.00 ou 4.53.01.

Como parte do processo de upgrade do Edge para nuvem privada versão 4.54.00, a interface clássica (edge-ui) é removida. A execução do comando de upgrade a seguir faz a transição do nó da IU da IU clássica (edge-ui) para a nova IU do Edge(edge-management-ui).

Etapa 1: fazer backup dos arquivos de configuração

Antes de iniciar, faça backup do arquivo de configuração silenciosa (configFile) e do diretório /opt/apigee/customer/application/ em todos os nós da interface.

Etapa 2: atualizar o arquivo de configuração silenciosa para autenticação básica

Edite o arquivo de configuração silenciosa (por exemplo, /opt/silent.conf) e adicione as seguintes propriedades da nova interface do Edge para autenticação básica:

# Authentication mode for New Edge UI (Basic Authentication - No Apigee SSO)
AUTH_MODE=basic

# Access configuration for the New Edge UI
MANAGEMENT_UI_PORT=3001
MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_SCHEME=http

Etapa 3: fazer upgrade do componente de interface

Execute o script update.sh com o componente -c ue para fazer upgrade da IU clássica (edge-ui) para a nova IU do Edge (edge-management-ui):

/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

Etapa 4: verificar o upgrade da nova interface do Edge

Depois de concluir o processo de upgrade em todos os nós de IU, verifique se a versão 4.54.00 da nova interface do Edge está totalmente operacional e acessível:

Verifique se o serviço edge-management-ui está em execução:
```
apigee-service edge-management-ui status
```
Abra um navegador e acesse:
```
http://MANAGEMENT_UI_NODE_IP:3001
```
Depois de verificar, pule a Opção 2: fazer upgrade da interface (com o SSO da Apigee) e prossiga diretamente para Upgrade obrigatório para o Qpid.

Opção 2: fazer upgrade da interface (com o SSO da Apigee)

Use esta seção se o SSO da Apigee (apigee-sso) estiver configurado / instalado no ambiente do Edge para nuvem privada 4.53.00 ou 4.53.01.

Na Apigee Edge para nuvem privada 4.54.00:

O serviço de SSO da Apigee subjacente faz a transição do componente legado apigee-sso para o SSO da Apigee gerenciado em apigee-openldap. Esse upgrade é obrigatório ao fazer upgrade para a versão 4.54.00 da Apigee Edge para nuvem privada se o SSO estiver ativado na versão 4.53.00 ou 4.53.01 da Apigee Edge para nuvem privada.
A IU clássica 4.53.x (edge-ui) com SSO e a nova IU da Edge 4.53.x (edge-management-ui) com SSO fazem upgrade para a nova IU da Edge 4.54.00 (edge-management-ui) com SSO da Apigee.

Leia os artigos a seguir para entender o novo design do SSO da Apigee e o impacto dele nos utilitários e fluxos de automação com a API Management:
Sobre a nova estrutura de SSO da Apigee
Tarefas automatizadas usando SSO

Siga as etapas consolidadas de ponta a ponta abaixo para fazer upgrade da interface e do SSO da Apigee sem etapas de configuração duplicadas:

Etapa 1: fazer backup dos arquivos de configuração

Faça backup do configFile silencioso atual e do diretório /opt/apigee/customer/application/ em todos os nós de interface e SSO antes de continuar.

Etapa 2: remover as variáveis de IU/SSO descontinuadas e atualizar o arquivo de configuração silenciosa (`configFile`)

Antes de fazer upgrade da nova interface do Edge e configurar o módulo de SSO da Apigee, atualize o arquivo de configuração silenciosa (configFile) em uma etapa com base na configuração atual da interface 4.53.x:

Remova ou comente as variáveis de IU e SSO obsoletas da versão 4.53.x de configFile:

Se você estiver fazendo upgrade da interface clássica (edge-ui) com apigee-sso: remova ou comente as propriedades relacionadas à interface clássica e ao SSO:

EDGEUI_SSO_ENABLED=y
EDGEUI_SSO_CLIENT_NAME=edgeui
EDGEUI_SSO_CLIENT_SECRET=edgeuisecret
EDGEUI_PUBLIC_URIS=
EDGEUI_SSO_CLIENT_OVERWRITE=y
EDGEUI_SSO_REGISTERD_PUBLIC_URIS=$EDGEUI_PUBLIC_URIS

Se você estiver fazendo upgrade da nova interface do Edge (edge-management-ui) com apigee-sso: remova ou comente as propriedades obsoletas relacionadas à interface clássica, ao Shoehorn e ao SSO da versão 4.53.x:

EDGEUI_SSO_ENABLED=y
EDGEUI_SSO_CLIENT_NAME=edgeui
EDGEUI_SSO_CLIENT_SECRET=edgeuisecret
EDGEUI_PUBLIC_URIS=
EDGEUI_SSO_CLIENT_OVERWRITE=y
EDGEUI_SSO_REGISTERD_PUBLIC_URIS=$EDGEUI_PUBLIC_URIS
EDGEUI_ENABLE_UNIFIED_UI=n
SHOEHORN_SCHEME=$MANAGEMENT_UI_SCHEME
SHOEHORN_IP=$MANAGEMENT_UI_IP
SHOEHORN_PORT=9000
CLASSIC_UI_SCHEME=http
CLASSIC_UI_PORT=9000
MANAGEMENT_UI_PUBLIC_URIS=http://Public_IP:3001
MANAGEMENT_UI_SSO_REGISTERD_PUBLIC_URIS=$MANAGEMENT_UI_PUBLIC_URIS
ROUTES_CLASSICUI=""
ROUTES_SHOEHORN=""

Use o comando a seguir no nó apigee-openldap para criar um usuário de máquina para a nova interface do Edge e use as mesmas credenciais ao definir a propriedade no arquivo de configuração silenciosa (configFile) na etapa seguinte. Para mais informações, consulte Criar usuário de máquina para a interface.
```
/opt/apigee/apigee-openldap/bin/apigee-machineuser.sh add -u ui-machine-user@apigee.com -p Secret123
```

Adicione ou atualize as propriedades obrigatórias do SSO da Apigee 4.54.00 e da nova IU do Edge em configFile:

# ==========================================
# SSO Enablement
# ==========================================
ENABLE_SSO=y

# ==========================================
# SSO Hostname/IP and Port config for Apigee SSO
# ==========================================
SSO_PUBLIC_URL_SCHEME=http
SSO_PUBLIC_URL_HOSTNAME=YOUR_SSO_NODE_IP_OR_HOSTNAME #Replace YOUR_SSO_NODE_IP_OR_HOSTNAME with the IP address or hostname of the SSO node.
SSO_PUBLIC_URL_PORT=9099

# ==========================================
# Static Client UI credentials
# ==========================================
MANAGEMENT_UI_SSO_CLIENT_ID=YOUR_SSO_CLIENT_ID #Example : MANAGEMENT_UI_SSO_CLIENT_ID=unifiedui
MANAGEMENT_UI_SSO_CLIENT_SECRET=YOUR_SSO_CLIENT_SECRET #Example : MANAGEMENT_UI_SSO_CLIENT_SECRET=secret123

# ==========================================
# Management UI & SSO redirect URLs
# ==========================================
MANAGEMENT_UI_SCHEME=http
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_PORT=3001

# ==========================================
# Management Server parameters (Required for SSO registration)
# ==========================================
MSIP=MS_IP_OR_HOSTNAME #Replace MS_IP_OR_HOSTNAME with the IP address or hostname of the Management Server node.
ADMIN_EMAIL=your@email.com
APIGEE_ADMINPW=your_password

# ==========================================
# Machine user for UI
# ==========================================
UI_MACHINE_USER=ui-machine-user@apigee.com
UI_MACHINE_PWD=Secret123

# ==========================================
# Postgres connection parameters
# ==========================================
# Postgres username and password as set when you installed Edge.
PG_HOST=PG_IP_OR_HOSTNAME
PG_USER=apigee
PG_PWD=YOUR_PG_PASSWORD

# ==========================================
# Other UI Parameters
# ==========================================
AUTH_MODE=sso

# Y to use Internal/Local LDAP for authentication, N to use external IDP
SSO_LOCAL_LDAP=y

MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_SSO_ENABLED=y
MANAGEMENT_UI_SSO_CSRF_SECRET=YOUR_CSRF_SECRET
MANAGEMENT_UI_SSO_CSRF_EXPIRATION_HOURS=24
MANAGEMENT_UI_SSO_STRICT_TRANSPORT_SECURITY_AGE_HOURS=24
MANAGEMENT_UI_SSO_PUBLIC_KEY_CACHE_HOURS=0.5

Etapa 3: fazer upgrade do componente da interface do New Edge

Interrompa e desinstale os componentes edge-management-ui (nova interface do Edge) e edge-ui (interface do Shoehorn), se a nova interface do Edge estiver em uso :

#Remove 4.53.xx New Edge UI from installation node 
apigee-service edge-management-ui stop
apigee-service edge-management-ui uninstall

#Remove Shoehorn UI from the node with 4.53.xx New Edge UI
apigee-service edge-ui stop
apigee-service edge-ui uninstall

Execute o script update.sh nos nós da interface clássica (edge-ui) para instalar e fazer upgrade para o componente da nova interface do Edge (edge-management-ui):
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```

Etapa 4: interromper o `apigee-sso`

Interrompa o serviço apigee-sso legado em todos os nós em que ele está instalado:

apigee-service apigee-sso stop

Etapa 5: criar o banco de dados `apigee_dex` para o SSO da Apigee no nó do Postgres

No nó principal do Postgres, faça login no Postgresql usando o seguinte comando:
```
psql -h $(hostname -i) -U apigee
```
Execute o seguinte comando no prompt psql para criar o banco de dados de SSO da Apigee:
```
create database apigee_dex;
```

Etapa 6: configurar o SSO da Apigee em nós do OpenLDAP

Execute o seguinte comando no nó apigee-openldap em que o SSO da Apigee será instalado:

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap setup-sso -f configFile

Etapa 7: configurar a interface de gerenciamento para o SSO da Apigee e reiniciar a interface

Execute os seguintes comandos em cada nó que tenha o Edge para nuvem privada 4.54.00 edge-management-ui instalado:

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile

Etapa 8: verificar o upgrade da nova interface do Edge e do SSO da Apigee

Depois de concluir as etapas acima, verifique se a nova interface do Edge 4.54.00 e o SSO da Apigee estão em execução e acessíveis:

Verifique se o serviço edge-management-ui está em execução:
```
apigee-service edge-management-ui status
```
Abra um navegador e acesse:
```
http://MANAGEMENT_UI_NODE_IP:3001
```
Faça login usando suas credenciais de SSO configuradas.

Etapa 9: desinstalar o `apigee-sso` legado

Em todos os nós em que o apigee-sso legado foi instalado, desinstale o componente apigee-sso:

apigee-service apigee-sso uninstall

Upgrade para o Qpid 10.0.1

Esse método garante que não haja inatividade no ambiente de execução do Edge e minimiza a perda de dados de ambiente de execução, se houver, adquiridos para análise.

Para realizar um upgrade no local sem inatividade para o Qpid:

Escolha um nó do Qpid para começar.
Interrompa o agente do Qpid no nó:
```
apigee-service apigee-qpidd stop
```
Bloqueie o tráfego de entrada na porta 5672 do agente de todos os processadores de mensagens aplicando um firewall. É possível aplicar esse firewall no nível da instância do nó do Qpid ou de algum outro componente de firewall/rede externo.

Recomendamos que você faça o mesmo para todos os endereços IP do processador de mensagens. Por exemplo, para descartar solicitações provenientes de endereços IP do processador de mensagens para o nó do Qpid na porta 5672 usando IPTables, use um comando como este:
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
Inicie o agente Qpid novamente para drenar as mensagens atuais, se houver:
```
apigee-service apigee-qpidd start
```
Verifique se as filas atuais estão vazias:
```
/opt/apigee/apigee-qpidd/bin/qpid-stat -q
```
Se as mensagens estiverem travadas na fila de mensagens inativas (DLQ) (ax-q-axgroup-001-consumer-group-001-dl), use as etapas para resolver dados de análise travados na fila de mensagens inativas para drenar a fila.
Depois de verificar se as filas foram drenadas no nó antigo, interrompa apigee-qpidd:
```
apigee-service apigee-qpidd stop
```

Faça upgrade do Qpid no nó:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Restart edge-qpid-server:
```
apigee-service edge-qpid-server restart
```
Remova a regra de firewall aplicada na Etapa 3.

Execute a mesma etapa de remoção para todos os endereços IP do processador de mensagens em que o firewall foi aplicado. Depois que os firewalls forem removidos, as solicitações provenientes de endereços IP do processador de mensagens para o nó do Qpid na porta 5672 serão aceitas. Se você usou iptables para adicionar o firewall, use comandos como os seguintes para remover o firewall e listar as configurações atuais:
```
iptables -F
iptables -L
```
Use o monitoramento da Web para verificar se as filas do Qpid estão recebendo mensagens:
```
http://QPID_NODE_IP:8090
```
Repita as etapas de 1 a 9 para cada nó do Qpid.

Fazer upgrade para o Postgres 18.6

Esta versão do Edge inclui um upgrade para o Postgres 18.6. Como parte desse upgrade, todos os dados do Postgres são migrados para o Postgres 18.6.

A maioria dos sistemas de produção do Edge usa dois nós do Postgres configurados para replicação primária em espera. Durante o processo de atualização, enquanto os nós do Postgres estão inativos para atualização, os dados de análise ainda são gravados nos nós do Qpid. Depois que os nós do Postgres forem atualizados e voltarem a ficar on-line, os dados de análise serão enviados para eles.

A maneira como você realiza a atualização do Postgres depende de como você configurou o repositório de dados para os nós do Postgres:

Se você usa o repositório de dados local para os nós do Postgres , é necessário instalar um novo nó de espera do Postgres durante o upgrade. Depois que o upgrade for concluído, será possível desativar o novo nó de espera do Postgres. O nó de espera extra do Postgres é necessário se você precisar reverter a atualização por qualquer motivo. Se você precisar reverter a atualização, o novo nó de espera do Postgres se tornará o nó principal do Postgres após a reversão. Portanto, ao instalar o novo nó de espera do Postgres, ele precisa estar em um nó que atenda a todos os requisitos de hardware de um servidor Postgres, conforme definido nos requisitos de instalação do Edge.

Em uma configuração de um e dois nós do Edge, as topologias usadas para prototipagem e teste, você tem apenas um nó do Postgres. É possível atualizar esses nós do Postgres diretamente sem precisar criar um novo nó do Postgres.
Se você usa armazenamento de rede para os nós do Postgres , conforme recomendado pela Apigee, não é necessário instalar um novo nó do Postgres. Nos procedimentos abaixo, é possível pular as etapas que especificam a instalação e a desativação de um novo nó de espera do Postgres. Antes de iniciar o processo de atualização, faça um snapshot de rede do repositório de dados usado pelo Postgres. Se ocorrerem erros durante a atualização e você precisar fazer uma reversão, será possível restaurar o nó do Postgres usando esse snapshot.

Como instalar um novo nó de espera do Postgres

Esse procedimento cria um servidor em espera do Postgres em um novo nó. Instale um novo servidor de espera do Postgres para sua versão atual do Edge (4.53.00 ou 4.53.01), não para a versão 4.54.00.

Para realizar a instalação, use o mesmo arquivo de configuração que você usou para instalar a versão atual do Edge.

Para criar um novo nó de espera do Postgres:

No Postgres principal atual, edite o arquivo /opt/apigee/customer/application/postgresql.properties para definir o token a seguir. Se esse arquivo não existir, crie-o:
```
conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust
```
Em que existing_standby_ip é o endereço IP do servidor em espera atual do Postgres e new_standby_ip é o endereço IP do novo nó em espera.

Reinicie o apigee-postgresql no Postgres principal:

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Verifique se o novo nó em espera foi adicionado visualizando o arquivo /opt/apigee/apigee-postgresql/conf/pg_hba.conf no nó principal. As seguintes linhas vão aparecer no arquivo:
```
host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
```
Instale o novo servidor de espera do Postgres:
1. Edite o arquivo de configuração usado para instalar a versão atual do Edge para especificar o seguinte:
```
# IP address of the current primary(master):
PG_MASTER=PG_MASTER_NODE_IP
# IP address of the new standby node
PG_STANDBY=PG_STANDBY_NODE_IP
```
2. Desative o SELinux conforme descrito em Instalar o utilitário apigee-setup do Edge.
3. Faça o download e execute o script de inicialização com base na sua versão atual do Edge:
  - Se você estiver usando o Edge 4.53.00:
    
    Faça o download do arquivo bootstrap_4.53.00.sh do Edge para /tmp/bootstrap_4.53.00.sh:
```
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
```
    Instale o utilitário e as dependências do Edge apigee-service:
```
bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
```
  - Se você estiver usando o Edge 4.53.01:
    
    Faça o download do arquivo bootstrap_4.53.01.sh do Edge para /tmp/bootstrap_4.53.01.sh:
```
curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
```
    Instale o utilitário e as dependências do Edge apigee-service:
```
bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord
```
4. Use apigee-service para instalar o utilitário apigee-setup:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
```
5. Instale o Postgres:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. No novo nó em espera, execute o seguinte comando e verifique se ele é o em espera:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```

Como fazer um upgrade no local do Postgres

Etapa preliminar

Antes de fazer um upgrade no local para o Postgres, siga as etapas abaixo no host principal e no de espera para atualizar a propriedade max_locks_per_transaction em apigee-postgresql:

Se não estiver presente, crie o arquivo /opt/apigee/customer/application/postgresql.properties .

Mude a propriedade desse arquivo para apigee :

chown apigee:apigee /opt/apigee/customer/application/postgresql.properties

Adicione a seguinte propriedade ao arquivo:

conf/postgresql.conf+max_locks_per_transaction=30000

Configure o apigee-postgresql :

apigee-service apigee-postgresql configure

Reinicie o apigee-postgresql :

apigee-service apigee-postgresql restart

Realizar o upgrade no local

Para fazer um upgrade no local para o Postgres 18, siga estas etapas:

Fazer upgrade do Postgres no host principal

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Execute o comando de configuração no host principal:
```
apigee-service apigee-postgresql setup -f configFile
```
Execute o comando de configuração no host principal:
```
apigee-service apigee-postgresql configure
```

Reinicie o host principal:

apigee-service apigee-postgresql restart

Configure-a como principal:

apigee-service apigee-postgresql setup-replication-on-master -f configFile

Verifique se o host principal foi iniciado:

apigee-service apigee-postgresql wait_for_ready

Interrompa o modo de espera:
```
apigee-service apigee-postgresql stop
```
Faça upgrade do modo de espera.

Observação:se essa etapa apresentar erros ou falhar, ela poderá ser ignorada. O update.sh vai tentar iniciar o servidor em espera com uma configuração incorreta. Se a instalação do Postgres for atualizada para a versão 18, o erro poderá ser ignorado.
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
Verifique se o modo de espera está interrompido:
```
apigee-service apigee-postgresql stop
```

Remova a configuração de espera antiga:

rm -rf /opt/apigee/data/apigee-postgresql/

Configure a replicação no servidor em espera:

apigee-service apigee-postgresql setup-replication-on-standby -f configFile

Remova a linha conf/postgresql.conf+max_locks_per_transaction=30000 do arquivo /opt/apigee/customer/application/postgresql.properties no host principal e no de espera. Essa linha foi adicionada na etapa preliminar .

Depois de concluir esse procedimento, o modo de espera será iniciado.

Como desativar um nó do Postgres

Depois que a atualização for concluída, desative o novo nó em espera:

Verifique se o Postgres está em execução:

/opt/apigee/apigee-service/bin/apigee-all status

Se o Postgres não estiver em execução, inicie-o:

/opt/apigee/apigee-service/bin/apigee-all start

Para ver o UUID do novo nó em espera, execute o seguinte comando curl nele:

curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

O UUID do nó vai aparecer no final da saída, no formato:

"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"

Para interromper o novo nó de espera, execute o seguinte comando nele:
```
/opt/apigee/apigee-service/bin/apigee-all stop
```
No nó principal do Postgres, edite /opt/apigee/customer/application/postgresql.properties para remover o novo nó em espera de conf_pg_hba_replication.connection:
```
conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
```

Reinicie o apigee-postgresql no Postgres principal:

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Verifique se o novo nó em espera foi removido visualizando o arquivo /opt/apigee/apigee-postgresql/conf/pg_hba.conf no nó principal. Você verá apenas a seguinte linha nesse arquivo:
```
host replication apigee existing_standby_ip/32 trust
```
Exclua o UUID do nó em espera do ZooKeeper fazendo a seguinte chamada de API Management da Edge no nó do servidor de gerenciamento:
```
curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid
```

Etapas pós-upgrade para o Postgres

Após um upgrade principal do Postgres, as estatísticas internas dele são apagadas. Essas estatísticas ajudam o planejador de consultas do Postgres a usar os índices e caminhos mais adequados para executar consultas.

O Postgres pode recriar gradualmente as estatísticas ao longo do tempo, conforme as consultas são executadas e quando o daemon de autovacuum é executado. No entanto, até que as estatísticas sejam recriadas, as consultas podem ficar lentas.

Para resolver esse problema, execute ANALYZE em todas as tabelas do banco de dados no nó principal do Postgres. Como alternativa, é possível executar ANALYZE em algumas tabelas por vez.

Fazer upgrade para o ZooKeeper 3.8.5

Esta versão do Edge para nuvem privada inclui um upgrade para o ZooKeeper 3.8.5. Como parte desse upgrade, todos os dados do ZooKeeper serão migrados para o ZooKeeper 3.8.5.

Antes de fazer upgrade do ZooKeeper, leia o guia de manutenção do ZooKeeper. A maioria dos sistemas de produção do Edge usa um cluster de nós do ZooKeeper distribuídos em vários data centers. Alguns desses nós são configurados como votantes que participam da eleição de líder do ZooKeeper, e os demais são configurados como observadores. Consulte Sobre líderes, seguidores, eleitores e observadores para mais detalhes. Os nós de votação elegem um líder e, em seguida, se tornam seguidores.

Durante o processo de atualização, pode haver um atraso momentâneo ou uma falha de gravação no ZooKeeper quando o nó líder for encerrado. Isso pode afetar as operações de gerenciamento que gravam no ZooKeeper, como a operação de implantação de um proxy, e as mudanças na infraestrutura da Apigee, como a adição ou remoção de um processador de mensagens etc. Não deve haver impacto nas APIs de ambiente de execução da Apigee (a menos que essas APIs de ambiente de execução chamem APIs de gerenciamento) durante o upgrade do ZooKeeper ao seguir o procedimento abaixo.

Em um nível alto, o processo de upgrade envolve fazer um backup de cada nó. Em seguida, todos os observadores e seguidores são atualizados e, por fim, o nó líder é atualizado.

Fazer um backup

Faça um backup de todos os nós do ZooKeeper para usar caso seja necessário fazer uma reversão. Uma reversão vai restaurar o ZooKeeper para o estado em que estava quando o backup foi feito.

/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

Se você estiver usando máquinas virtuais e tiver a capacidade, também poderá fazer snapshots ou backups de VM para restauração ou reversão (se necessário).

Identificar líder, seguidores e observadores

Se ele não estiver instalado no nó do ZooKeeper, instale o nc:
```
yum install nc
```

Execute o seguinte comando nc no nó, em que 2181 é a porta do ZooKeeper:

echo stat | nc localhost 2181

O resultado será assim:

Zookeeper version: 3.8.5-19f1842d4b6ee1f82cc8b05284959b26c6ae507d, built on 2025-09-03 21:35 UTC
Clients:
 /[0:0:0:0:0:0:0:1]:40696[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 3/4.3333/6
Received: 4
Sent: 3
Connections: 1
Outstanding: 0
Zxid: 0x500000005
Mode: follower

Na linha Mode da saída dos nós, você vai encontrar observer, leader ou follower (ou seja, um votante que não é o líder), dependendo da configuração do nó.

Repita as etapas 1 e 2 em cada nó do ZooKeeper.

Fazer upgrade do ZooKeeper nos nós observador e seguidor

Faça upgrade do ZooKeeper em cada um dos nós observadores e seguidores da seguinte maneira:

Faça o download e execute o bootstrap do Edge para nuvem privada 4.54.00, conforme descrito em Atualizar para 4.54.00 em um nó com uma conexão de Internet externa . O processo provavelmente vai variar dependendo se o nó tem uma conexão de Internet externa ou se você está realizando uma instalação off-line.
Faça upgrade do componente ZooKeeper:
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f silent-config-file
```
Observação: se esses nós tiverem outros componentes instalados (como o Cassandra), você também poderá fazer upgrade deles agora (como com o perfil zk,cs) ou fazer upgrade dos outros componentes mais tarde. A Apigee recomenda que você faça upgrade apenas do ZooKeeper primeiro e verifique se o cluster está funcionando corretamente antes de fazer upgrade de outros componentes.
Repita as etapas acima em cada nó observador e seguidor do ZooKeeper.

Desativar o líder

Depois que todos os nós observadores e seguidores forem atualizados, encerre o líder. No nó identificado como líder, execute o comando abaixo:

/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

Durante esse evento, antes que um novo líder seja eleito, pode haver atrasos momentâneos ou falhas de gravação no ZooKeeper. Isso pode afetar as operações que gravam no ZooKeeper, como a ação de implantação de proxies ou as mudanças na infraestrutura da Apigee, como a adição ou remoção de processadores de mensagens etc.

Verificar se o novo líder foi eleito

Siga as etapas na seção Identificar líder, seguidores e observadores acima para verificar se um novo líder foi eleito entre os seguidores depois que o líder atual foi interrompido. O líder pode ter sido eleito em um data center diferente do atual.

Líder de upgrade

Siga as mesmas etapas descritas em Como fazer upgrade do ZooKeeper nos nós de observador e seguidor acima.

Depois que o nó líder antigo também for atualizado, verifique a integridade do cluster e se há um nó líder.

Fazer upgrade para o Cassandra 5.0.8

A Apigee Edge para nuvem privada 4.54.00 inclui um upgrade do Cassandra para a versão 5.0.8.

Upgrades e reversão

O upgrade do Cassandra 4.0.X para o Cassandra 5.0.X é um processo contínuo.
Não é possível fazer uma reversão direta do Cassandra 5.0.X para o 4.0.X. A reversão usando réplicas ou backups é um procedimento complexo e pode envolver inatividade e/ou perda de dados. É preferível resolver problemas e fazer upgrade para o Cassandra 5.0.X do que reverter.
É importante se familiarizar com os procedimentos de reversão antes de tentar fazer o upgrade. Considerar as nuances da reversão durante o upgrade é fundamental para garantir que os caminhos de reversão adequados estejam disponíveis.

Data center único

O upgrade do Cassandra da versão 4.0.X para a 5.0.X em um único data center é simples, mas a reversão é complexa e pode resultar em inatividade e perda de dados. Para cargas de trabalho de produção, é altamente recomendável adicionar um novo data center com pelo menos nós do Cassandra disponíveis no novo data center antes de iniciar o upgrade. Isso vai permitir a reversão do Cassandra sem perda de dados ou interrupção do tráfego da API. Esse data center extra pode ser desativado após a conclusão do upgrade.

Se não for possível adicionar um novo data center, mas você ainda quiser ter a capacidade de reversão, será necessário fazer backups para restaurar o Cassandra 4.0.X. No entanto, esse método provavelmente envolve inatividade e perda de dados.

Vários data centers

Operar vários data centers com o Edge para nuvem privada 4.53.00 (ou) 4.53.01 oferece mais flexibilidade para reversões durante o upgrade para o Edge para nuvem privada 4.54.00.

As reversões exigem pelo menos um data center executando a versão anterior do Cassandra (4.0.X).

Metodologia de upgrade recomendada

Faça upgrade de um data center do Cassandra por vez: comece fazendo upgrade dos nós do Cassandra individualmente em um único data center. Conclua os upgrades de todos os nós do Cassandra em um data center antes de prosseguir para o próximo.
Pausar e validar:depois de fazer upgrade de um data center, pause para garantir que o cluster da nuvem privada, especialmente o data center atualizado, esteja funcionando corretamente.
Lembrete: só é possível reverter para a versão anterior do Cassandra se você tiver pelo menos um data center ainda executando a versão mais antiga.
Sensível ao tempo: embora seja possível pausar por um curto período (recomendamos algumas horas) para validar a funcionalidade, não é possível permanecer em um estado de versão mista indefinidamente. Isso ocorre porque um cluster do Cassandra não uniforme (com nós em versões diferentes) tem limitações operacionais.
Testes completos: a Apigee recomenda testes abrangentes de desempenho e funcionalidade antes de fazer upgrade do próximo data center. Depois que todos os data centers forem atualizados, não será possível reverter para a versão anterior.

Processo de checkpoint de reversão

Ponto de verificação de reversão única:quando todos os componentes são atualizados para a versão 4.54.00, uma reversão do Cassandra só é possível se pelo menos um data center do Cassandra continuar executando a versão mais antiga. Depois que o último data center do Cassandra for atualizado, o upgrade para o Edge para nuvem privada 4.54.00 será concluído, e não será mais possível fazer a reversão.

Exemplo

Considere um cluster de dois data centers (DC):

Estado inicial:os nós do Cassandra em ambos os DCs estão na versão 4.0.X. Todos os outros nós estão no Edge para nuvem privada versão 4.54.00. Suponha que haja três nós do Cassandra por DC.
Fazer upgrade do DC-1: faça upgrade dos três nós do Cassandra no DC-1, um por um.
Pausar e validar:pause para garantir que o cluster, principalmente o DC-1, esteja funcionando corretamente (verifique o desempenho e a funcionalidade). É possível reverter para o estado inicial usando os nós do Cassandra no DC-2. Essa pausa precisa ser temporária devido às limitações de um cluster do Cassandra de versão mista.
Fazer upgrade do DC-2: faça upgrade dos três nós restantes do Cassandra no DC-2. Depois que todos os nós do Cassandra no DC-2 forem atualizados, o upgrade do Edge para nuvem privada 4.54.00 será concluído.

Pré-requisitos para o upgrade do Cassandra

Você precisa executar o Cassandra 4.0.X com o Edge para nuvem privada 4.53.00 (ou) 4.53.01 e garantir o seguinte:

Defina o Java 17 como a versão padrão do Java no servidor : o Cassandra 5.0.X remove o suporte ao Java 8. Não é possível executar o Cassandra 5.0.X ou o utilitário nodetool com o Java 8. Verifique se o Java 17 está instalado em cada nó do Cassandra e defina-o como a versão padrão antes de executar as etapas de upgrade do Cassandra para que os comandos nodetool sejam executados com o Java 17:
```
alternatives --set java JAVA_17_PATH/bin/java
```
Verifique se a versão padrão ativa do Java é a 17:
```
java -version
```
O cluster inteiro está operacional e totalmente funcional com o Cassandra 4.0.X.
A estratégia de compactação está definida como LeveledCompactionStrategy (um pré-requisito para o upgrade para a versão 4.53.00 ou 4.53.01).
Confirme se cada etapa abaixo foi concluída como parte do upgrade inicial do Cassandra 4.0.X no Edge para nuvem privada de 4.53.00 (ou) 4.53.01.
- O comando post_upgrade foi executado em cada nó do Cassandra durante o upgrade anterior.
- O comando drop_old_tables foi executado em todo o cluster do Cassandra durante o upgrade anterior.

Se você não tiver certeza de que os comandos post_upgrade e drop_old_tables foram executados no Cassandra 4.0.X ao usar o Edge para nuvem privada 4.53.00 (ou) 4.53.01, execute-os novamente antes de tentar fazer o upgrade para a versão 4.54.00.

Etapa 1: preparar para o upgrade

As etapas abaixo são adicionais aos arquivos padrão que você costuma criar, como o arquivo de configuração padrão da Apigee para ativar upgrades de componentes.

Faça backup do Cassandra usando a Apigee.
Crie snapshots de VM dos nós do Cassandra (se possível).
Verifique se a porta 9042 está acessível em todos os componentes do Edge para nuvem privada, incluindo o servidor de gerenciamento, o processador de mensagens, o roteador, o Qpid e o Postgres, para os nós do Cassandra, se ainda não estiver configurada. Consulte os requisitos de porta para mais informações.

Etapa 2: fazer upgrade de todos os nós do Cassandra

Todos os nós do Cassandra precisam ser atualizados um por um em cada data center, um data center por vez. Entre os upgrades de nós em um data center, aguarde alguns minutos para garantir que um nó atualizado tenha sido totalmente iniciado e ingressado no cluster antes de continuar com o upgrade de outro nó no mesmo data center.

Depois de fazer upgrade de todos os nós do Cassandra em um data center, aguarde um tempo (de 30 minutos a algumas horas) antes de prosseguir com os nós no próximo data center. Durante esse período, analise minuciosamente o data center que foi atualizado e verifique se as métricas de função e performance do cluster da Apigee estão intactas. Essa etapa é crucial para garantir a estabilidade do data center em que o Cassandra foi atualizado para a versão 5.0.X, enquanto o restante dos componentes da Apigee foi atualizado para a versão 4.54.00.

Para fazer upgrade de um nó do Cassandra, execute o seguinte comando:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
Depois que um nó for atualizado, execute o seguinte comando nele para fazer algumas validações antes de continuar:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
```

O resultado será algo como:

Cassandra version is verified - [cqlsh 6.2.0 | Cassandra 5.0.8 | CQL spec 3.4.7 | Native protocol v5]
Metadata is verified

Execute o seguinte comando post_upgrade no nó do Cassandra:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade

Execute o seguinte comando cleanup_old_index no nó do Cassandra:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra cleanup_old_index

Execute os seguintes comandos nodetool para recriar índices no nó do Cassandra:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx    
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx

Se você estiver usando a monetização, execute também os seguintes comandos de recriação de índices relacionados aos keyspaces de monetização:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

Atualizar com mTLS da Apigee

Para atualizar a mTLS da Apigee , siga estas etapas:

Como reverter uma atualização

Em caso de falha na atualização, tente corrigir o problema e execute update.sh novamente. É possível executar a atualização várias vezes, e ela vai continuar de onde parou.

Se a falha exigir que você reverta a atualização para a versão anterior, consulte Reverter 4.54.00 para ver instruções detalhadas.

Informações de atualização do Logging

Por padrão, o utilitário update.sh grava informações de registro em:

/opt/apigee/var/log/apigee-setup/update.log

Se a pessoa que executa o utilitário update.sh não tiver acesso a esse diretório, ele vai gravar o registro no diretório /tmp como um arquivo chamado update_username.log.

Se a pessoa não tiver acesso a /tmp, o utilitário update.sh vai falhar.

Atualização sem inatividade

Uma atualização sem inatividade, ou atualização gradual, permite que você atualize a instalação do Edge sem desativar o Edge.

A atualização sem inatividade só é possível com uma configuração de 5 nós ou mais.

A chave para o upgrade sem inatividade é remover cada roteador, um por vez, do balanceador de carga. Em seguida, atualize o roteador e todos os outros componentes na mesma máquina que o roteador e adicione o roteador de volta ao balanceador de carga.

Atualize as máquinas na ordem correta para sua instalação, conforme descrito em Ordem de atualização da máquina .
Quando for hora de atualizar os roteadores, selecione um roteador e torne-o inacessível, conforme descrito em Como ativar/desativar a acessibilidade do servidor (processador de mensagens/roteador) .
Atualize o roteador selecionado e todos os outros componentes do Edge na mesma máquina que o roteador. Todas as configurações do Edge mostram um roteador e um processador de mensagens no mesmo nó.
Torne o roteador acessível novamente.
Repita as etapas de 2 a 4 para os roteadores restantes.
Continue a atualização para as máquinas restantes na instalação.

Antes e depois da atualização, faça o seguinte:

No nó combinado de roteador e processador de mensagens:
- Antes da atualização, faça o seguinte:
  1. Torne o roteador inacessível.
  2. Tornar o processador de mensagens inacessível.
- Após a atualização, faça o seguinte:
  1. Torne o processador de mensagens acessível.
  2. Torne o roteador acessível.
Em nós de roteador único:
- Antes de atualizar, torne o roteador inacessível.
- Após a atualização, torne o roteador acessível.
Em nós únicos do processador de mensagens:
- Antes da atualização, torne o processador de mensagens inacessível.
- Após a atualização, torne o processador de mensagens acessível.

Usar um arquivo de configuração silenciosa

É necessário transmitir um arquivo de configuração silenciosa para o comando de atualização. Embora o arquivo de configuração silenciosa seja, em grande parte, semelhante ao que você usou para instalar o Edge para nuvem privada 4.53.00 ou 4.53.01, talvez seja necessário fazer mudanças em componentes como a interface e o SSO, conforme descrito em Fazer upgrade para a nova interface do Edge e o SSO da Apigee (se instalado).

Atualizar para a versão 4.54.00 em um nó com uma conexão de Internet externa

Use o procedimento a seguir para atualizar os componentes do Edge em um nó:

Se houver, desative todos os jobs cron configurados para realizar uma operação de reparo no Cassandra até que a atualização seja concluída.
Faça login no nó como raiz para instalar os RPMs do Edge.

Observação: embora a instalação do RPM exija acesso raiz, é possível realizar a configuração do Edge sem acesso raiz.
Desative o SELinux conforme descrito em Instalar o utilitário apigee-setup do Edge .

Se você estiver instalando na AWS , execute os seguintes comandos yum-configure-manager:

yum update rh-amazon-rhui-client.noarch
yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Se você estiver usando o Edge para nuvem privada 4.53.00 (ou) 4.53.01:
1. Faça o download do arquivo bootstrap_4.54.00.sh do Edge para /tmp/bootstrap_4.54.00.sh :
```
curl https://software.apigee.com/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
2. Instale o utilitário apigee-service do Edge 4.54.00 e as dependências executando o seguinte comando:
```
bash /tmp/bootstrap_4.54.00.sh apigeeuser=uName apigeepassword=pWord
```
  Em que uName:pWord são o nome de usuário e a senha que você recebeu da Apigee. Se você omitir pWord, será solicitado que você o insira.
  
  Por padrão, o instalador verifica se você tem o Java 17 e 21 instalados.
3. Use apigee-service para atualizar o utilitário apigee-setup, como mostra o exemplo a seguir:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. Atualize o utilitário apigee-validate no servidor de gerenciamento, como mostra o exemplo a seguir:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. Atualize o utilitário apigee-provision no servidor de gerenciamento, como mostra o exemplo a seguir:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
6. Execute o utilitário update nos nós com o seguinte comando:
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
  Faça isso na ordem descrita em Ordem de atualização da máquina.
  
  Em que:
  - component é o componente do Edge a ser atualizado. Os valores possíveis incluem:
    - edge : todos os componentes do Edge, exceto a nova interface do Edge: servidor de gerenciamento, processador de mensagens, roteador, servidor QPID, servidor Postgres
    - ldap : OpenLDAP
    - ue : nova interface do Edge
    - qpid : Qpid da Apigee
    - ps : Apigee Postgresql
    - zk : ZooKeeper
    - cs : Cassandra
  - configFile é o mesmo arquivo de configuração usado para definir os componentes do Edge durante a instalação da versão 4.53.00 ou 4.53.01.
  Observação: o arquivo de configuração precisa ser legível pelo usuário "apigee". Para mudar o proprietário, use o seguinte comando:
```
chown apigee:apigee configFile
```
  É possível executar update.sh em todos os componentes definindo component como "all", mas somente se você tiver um perfil de instalação completo (AIO, na sigla em inglês) do Edge. Exemplo:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
7. Reinicie os componentes da nova interface do Edge em todos os nós que os executam, se ainda não tiver feito isso:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
8. Teste a atualização executando o utilitário apigee-validate no servidor de gerenciamento, conforme descrito em Testar a instalação.

Se você decidir reverter a atualização, use o procedimento descrito em Reverter 4.54.00.

Atualizar para a versão 4.54.00 de um repositório local

Se os nós do Edge estiverem protegidos por um firewall ou, de alguma outra forma, proibidos de acessar o repositório da Apigee pela Internet, será possível realizar a atualização em um repositório local ou espelho do repositório da Apigee.

Depois de criar um repositório local do Edge, você tem duas opções para atualizar o Edge no repositório local:

Crie um arquivo .tar do repositório, copie o arquivo .tar para um nó e atualize o Edge usando o arquivo .tar.
Instale um servidor da Web no nó com o repositório local para que outros nós possam acessá-lo. Nginx e até mesmo o servidor da Web Apache.

Para atualizar de um repositório local 4.54.00:

Crie um repositório local 4.54.00 conforme descrito em "Criar um repositório local da Apigee" em Instalar o utilitário apigee-setup do Edge.

Observação:se você já tiver um repositório, adicione o repositório 4.54.00 a ele, conforme descrito em "Atualizar um repositório local da Apigee" em Instalar o utilitário apigee-setup do Edge.
Instale o apigee-service nos nós de destino usando um dos seguintes métodos:
- Opção 1: instalar o apigee-service de um arquivo .tar
  1. No nó com o repositório local, use o seguinte comando para empacotar o repositório local em um único arquivo .tar chamado /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
  2. Copie o arquivo .tar para o nó em que você quer atualizar o Edge. Por exemplo, copie-o para o diretório /tmp no novo nó.
  3. No novo nó, descompacte o arquivo no diretório /tmp:
```
tar -xzf apigee-4.54.00.tar.gz
```
    Esse comando cria um novo diretório, chamado repos, no diretório que contém o arquivo .tar. Por exemplo: /tmp/repos
  4. Instale o utilitário Edge apigee-service e as dependências de /tmp/repos:
```
bash /tmp/repos/bootstrap_4.54.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
    Observe que você inclui o caminho para o diretório de repositórios nesse comando.
- Opção 2: instalar o apigee-service usando o servidor da Web Nginx
  1. Configure o servidor da Web Nginx conforme descrito em "Instalar do repositório usando o servidor da Web Nginx" em Instalar o utilitário apigee-setup do Edge.
  2. No nó remoto, faça o download do arquivo bootstrap_4.54.00.sh do Edge para /tmp/bootstrap_4.54.00.sh:
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
    Em que uName:pWord são o nome de usuário e a senha que você definiu anteriormente para o repositório, e remoteRepo é o endereço IP ou o nome DNS do nó do repositório.
  3. No nó remoto, instale o utilitário apigee-service do Edge e as dependências:
```
bash /tmp/bootstrap_4.54.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
    Em que uName:pWord são o nome de usuário e a senha do repositório.
Use apigee-service para atualizar o utilitário apigee-setup, como mostra o exemplo a seguir:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
Atualize o utilitário apigee-validate no servidor de gerenciamento, como mostra o exemplo a seguir:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
Atualize o utilitário apigee-provision no servidor de gerenciamento, como mostra o exemplo a seguir:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
Execute o utilitário update nos nós na ordem descrita em Ordem de atualização da máquina:
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
Em que:
- component é o componente do Edge a ser atualizado. Os valores possíveis incluem:
  - edge : todos os componentes do Edge, exceto a nova interface do Edge: servidor de gerenciamento, processador de mensagens, roteador, servidor QPID, servidor Postgres
  - ldap : OpenLDAP
  - ue : nova interface do Edge
  - qpid : Qpid da Apigee
  - ps : Apigee Postgresql
  - zk : ZooKeeper
  - cs : Cassandra
- configFile é o mesmo arquivo de configuração usado para definir os componentes do Edge durante a instalação da versão 4.53.00 ou 4.53.01.
  
  Observação:o arquivo de configuração precisa ser legível pelo usuário "apigee". Para mudar o proprietário, use o seguinte comando:
```
chown apigee:apigee configFile
```
É possível executar update.sh em todos os componentes definindo component como "all", mas somente se você tiver um perfil de instalação completo (AIO, na sigla em inglês) do Edge. Exemplo:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
Reinicie os componentes da interface em todos os nós que os executam, se ainda não tiver feito isso:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
Teste a atualização executando o utilitário apigee-validate no servidor de gerenciamento, conforme descrito em Testar a instalação.

Se você decidir reverter a atualização, use o procedimento descrito em Reverter 4.54.00.

Ordem de atualização da máquina

A ordem em que você atualiza as máquinas em uma instalação do Edge é importante. Faça upgrade dos componentes na sequência abaixo.

Faça upgrade de todos os nós do roteador e do processador de mensagens em todos os data centers usando a opção -c edge.
Faça upgrade de todos os nós do servidor de gerenciamento em todos os data centers usando a opção -c edge.
Faça upgrade de todos os nós LDAP em todos os data centers. Se você estiver fazendo upgrade do Edge para nuvem privada 4.53.00, siga as etapas especiais de upgrade do LDAP.
Faça upgrade da interface e do SSO da Apigee (se instalado) em todos os data centers:
1. Se o apigee-sso não estiver instalado:siga a Opção 1: fazer upgrade da IU (sem o SSO da Apigee) para fazer upgrade para a nova IU do Edge.
2. Se o apigee-sso estiver instalado:siga a Opção 2: fazer upgrade da IU (com o SSO da Apigee) para fazer upgrade para a nova IU do Edge e o SSO da Apigee.
Faça upgrade de todos os componentes do Qpid e do edge-qpid-server em todos os data centers seguindo as etapas especiais do Qpid.
Faça upgrade de todos os componentes Postgresql e edge-postgres-server em todos os data centers seguindo as etapas especiais do Postgres.
Faça upgrade de todos os componentes do Zookeeper em todos os data centers seguindo as etapas especiais de upgrade do Zookeeper.
Faça upgrade de todos os componentes do Cassandra em todos os data centers seguindo as etapas especiais de upgrade do Cassandra.
Não há uma etapa separada para atualizar a Monetização. Ele é atualizado quando você especifica a opção -c edge.

Upgrade independente de 1 nó

Para fazer upgrade de uma configuração independente de um nó para a versão 4.54.00:

Ao fazer upgrade do Edge para nuvem privada 4.53.00, o LDAP precisa ser atualizado primeiro seguindo as etapas para fazer upgrade da versão 4.53.00 para a 4.54.00 antes de iniciar o upgrade de todos os componentes.

Atualize todos os componentes:

/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile

(Se você instalou apigee-adminapi) Atualize o utilitário apigee-adminapi:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade independente de 2 nós

Atualize os seguintes componentes para uma instalação independente de dois nós:

Consulte Topologias de instalação para ver a lista de topologias do Edge e números de nós.

Atualize os componentes do Edge na máquina 1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Atualize o LDAP na máquina 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Atualize a nova interface do Edge na máquina 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Observação:se o apigee-sso estiver instalado, consulte Opção 2: fazer upgrade da interface (com o SSO da Apigee) para ver instruções sobre como configurá-lo para o SSO da Apigee.

Atualize os componentes do Edge na máquina 2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Atualize o Qpid na Máquina 2:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Atualize o Postgres na máquina 2:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Atualize o Cassandra e o ZooKeeper na máquina 1:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se você instalou apigee-adminapi) Atualize o utilitário apigee-adminapi na máquina 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade de 5 nós

Atualize os seguintes componentes para uma instalação de cinco nós:

Consulte Topologias de instalação para ver a lista de topologias do Edge e números de nós.

Atualize os componentes do Edge nas máquinas 2, 3 e 1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Atualize o LDAP na máquina 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Atualize a nova interface do Edge na máquina 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Observação:se o apigee-sso estiver instalado, consulte Opção 2: fazer upgrade da interface (com o SSO da Apigee) para ver instruções sobre como configurá-lo para o SSO da Apigee.

Atualize os componentes do Edge nas máquinas 4 e 5:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Atualize o Qpid nas máquinas 4 e 5:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Atualize o Postgres nas máquinas 4 e 5:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Atualize o Cassandra e o ZooKeeper nas máquinas 1, 2 e 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se você instalou apigee-adminapi) Atualize o utilitário apigee-adminapi na máquina 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade de cluster de 9 nós

Atualize os seguintes componentes para uma instalação em cluster de nove nós:

Consulte Topologias de instalação para ver a lista de topologias do Edge e números de nós.

Atualize os componentes do Edge nas máquinas 4, 5 e 1 (roteador, processador de mensagens e servidor de gerenciamento), nessa ordem:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Atualize o LDAP na máquina 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Atualize a nova interface do Edge na máquina 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Observação:se o apigee-sso estiver instalado, consulte Opção 2: fazer upgrade da interface (com o SSO da Apigee) para ver instruções sobre como configurá-lo para o SSO da Apigee.
Atualize os componentes do Edge nas máquinas 6, 7, 8 e 9, nessa ordem:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Atualize o Qpid nas máquinas 6 e 7:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Atualize o Postgres na máquina 8:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Atualize o Postgres na máquina 9:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Atualize o Cassandra e o ZooKeeper nas máquinas 1, 2 e 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se você instalou apigee-adminapi) Atualize o utilitário apigee-adminapi na máquina 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade de cluster de 13 nós

Atualize os seguintes componentes para uma instalação em cluster de 13 nós:

Consulte Topologias de instalação para ver a lista de topologias do Edge e números de nós.

Atualize os componentes do Edge nas máquinas 10, 11, 6 e 7, nessa ordem:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Atualize o LDAP nas máquinas 4 e 5:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Atualize a nova interface do Edge nas máquinas 6 e 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Observação:se o apigee-sso estiver instalado, consulte Opção 2: fazer upgrade da interface (com o SSO da Apigee) para ver instruções sobre como configurá-lo para o SSO da Apigee.
Atualize os componentes do Edge nas máquinas 12, 13, 8 e 9, nessa ordem:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Atualize o Qpid nas máquinas 12 e 13:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Atualize o Postgres na máquina 8:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Atualize o Postgres na máquina 9:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Atualize o Cassandra e o ZooKeeper nas máquinas 1, 2 e 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se você instalou apigee-adminapi) Atualize o utilitário apigee-adminapi nas máquinas 6 e 7:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade de cluster de 12 nós

Atualize os seguintes componentes para uma instalação em cluster de 12 nós:

Consulte Topologias de instalação para ver a lista de topologias do Edge e números de nós.

Atualize os componentes do Edge (roteador e processador de mensagens):
- Nas máquinas 2 e 3 no Data Center 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- Nas máquinas 8 e 9 no Data Center 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Atualize os componentes do Edge (servidor de gerenciamento):

Na máquina 1 no Data Center 1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Na máquina 7 no Data Center 2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Atualizar LDAP:

Máquina 1 no data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Máquina 7 no data center 2:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Atualize os componentes da nova interface do Edge:
- Na máquina 1 no Data Center 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  Observação:se o apigee-sso estiver instalado, consulte Opção 2: fazer upgrade da interface (com o SSO da Apigee) para ver instruções sobre como configurá-lo para o SSO da Apigee.
- Na máquina 7 no Data Center 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  Observação:se o apigee-sso estiver instalado, consulte Opção 2: fazer upgrade da interface (com o SSO da Apigee) para ver instruções sobre como configurá-lo para o SSO da Apigee.

Atualize os componentes do Edge:

Máquinas 4, 5 e 6 no data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Máquinas 10, 11 e 12 no Data Center 2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Atualize o qpidd:

Máquinas 4 e 5 no data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Máquinas 10 e 11 no Data Center 2:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Atualize o Postgres:

Máquina 6 no data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Máquina 12 no data center 2:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Atualize o Cassandra e o ZooKeeper:

Máquinas 1, 2 e 3 no data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

Nas máquinas 7, 8 e 9 no Data Center 2:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se você instalou apigee-adminapi) Atualize o utilitário apigee-adminapi:

Máquina 1 no data center 1:

/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Máquina 7 no data center 2:

/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Para uma configuração não padrão

Se você tiver uma configuração não padrão, atualize os componentes do Edge na seguinte ordem:

Roteador
processador de mensagens
Servidor de gerenciamento
LDAP
Interface (clássica ou nova)
SSO (se aplicável)
Qpid e edge-qpid-server
Postgres e edge-postgres-server
ZooKeeper
Cassandra
apigee-adminapi

Atualizar a Apigee Edge 4.53.00 ou 4.53.01 para 4.54.00

Quem pode fazer a atualização

Quais componentes você precisa atualizar

Materiais de leitura prévia

Pré-requisitos de upgrade

Propagação automática das configurações de propriedade

Fazer upgrade do roteador e do processador de mensagens

Fazer upgrade do servidor de gerenciamento

Fazer upgrade para o OpenLDAP 2.6.10

Preparação e instalação (todos os servidores LDAP)

Etapas para fazer upgrade do LDAP de 4.53.00 para 4.54.00

Pré-requisitos e considerações

Etapas para fazer upgrade do LDAP de 4.53.01 para 4.54.00

Fazer upgrade para a nova IU do Edge e o SSO da Apigee (se instalado)

Opção 1: fazer upgrade da IU (sem o SSO da Apigee)

Etapa 1: fazer backup dos arquivos de configuração

Etapa 2: atualizar o arquivo de configuração silenciosa para autenticação básica

Etapa 3: fazer upgrade do componente de interface

Etapa 4: verificar o upgrade da nova interface do Edge

Opção 2: fazer upgrade da interface (com o SSO da Apigee)

Etapa 1: fazer backup dos arquivos de configuração

Etapa 2: remover as variáveis de IU/SSO descontinuadas e atualizar o arquivo de configuração silenciosa (configFile)

Etapa 3: fazer upgrade do componente da interface do New Edge

Etapa 4: interromper o apigee-sso

Etapa 5: criar o banco de dados apigee_dex para o SSO da Apigee no nó do Postgres

Etapa 6: configurar o SSO da Apigee em nós do OpenLDAP

Etapa 7: configurar a interface de gerenciamento para o SSO da Apigee e reiniciar a interface

Etapa 8: verificar o upgrade da nova interface do Edge e do SSO da Apigee

Etapa 9: desinstalar o apigee-sso legado

Upgrade para o Qpid 10.0.1

Fazer upgrade para o Postgres 18.6

Como instalar um novo nó de espera do Postgres

Como fazer um upgrade no local do Postgres

Etapa preliminar

Realizar o upgrade no local

Como desativar um nó do Postgres

Etapas pós-upgrade para o Postgres

Fazer upgrade para o ZooKeeper 3.8.5

Fazer um backup

Identificar líder, seguidores e observadores

Fazer upgrade do ZooKeeper nos nós observador e seguidor

Desativar o líder

Verificar se o novo líder foi eleito

Líder de upgrade

Fazer upgrade para o Cassandra 5.0.8

Upgrades e reversão

Data center único

Vários data centers

Metodologia de upgrade recomendada

Processo de checkpoint de reversão

Exemplo

Pré-requisitos para o upgrade do Cassandra

Etapa 1: preparar para o upgrade

Etapa 2: fazer upgrade de todos os nós do Cassandra

Atualizar com mTLS da Apigee

Como reverter uma atualização

Informações de atualização do Logging

Atualização sem inatividade

Usar um arquivo de configuração silenciosa

Atualizar para a versão 4.54.00 em um nó com uma conexão de Internet externa

Atualizar para a versão 4.54.00 de um repositório local

Ordem de atualização da máquina

Upgrade independente de 1 nó

Upgrade independente de 2 nós

Upgrade de 5 nós

Upgrade de cluster de 9 nós

Upgrade de cluster de 13 nós

Upgrade de cluster de 12 nós

Para uma configuração não padrão

Etapa 2: remover as variáveis de IU/SSO descontinuadas e atualizar o arquivo de configuração silenciosa (`configFile`)

Etapa 4: interromper o `apigee-sso`

Etapa 5: criar o banco de dados `apigee_dex` para o SSO da Apigee no nó do Postgres

Etapa 9: desinstalar o `apigee-sso` legado