Reverter o Apigee Edge 4.53.00

Se você encontrar um erro durante uma atualização para o Edge 4.53.00, poderá reverter o componente que causou o erro e tentar a atualização novamente.

É possível reverter o Edge 4.53.00 para a seguinte versão secundária:

  • Versão 4.52.02

A reversão de uma versão envolve a reversão de todos os componentes que você pode ter atualizado. Além disso, considere alguns pontos especiais ao fazer o rollback do Cassandra para a versão 4.52.02.

Há dois cenários em que talvez seja necessário fazer um rollback:

  1. Reverta para uma versão principal ou secundária anterior. Por exemplo, de 4.53.00 para 4.52.02.
  2. Reverta para uma versão de patch anterior na mesma versão. Por exemplo, de 4.53.00.01 para 4.53.00.00.

Para mais informações, consulte Processo de lançamento do Apigee Edge.

Ordem de reversão

A reversão dos componentes precisa ser feita na ordem inversa em que foram atualizados, exceto os servidores de gerenciamento, que precisam ser revertidos depois do Cassandra.

Uma ordem geral típica de rollback para a nuvem privada 4.53.00 é semelhante a esta:

  1. Reverter o Postgres, o Qpid e outros componentes relacionados à análise
  2. Fazer o rollback de roteadores e processadores de mensagens
  3. Reverter o Cassandra e o Zookeeper
  4. Reverter o servidor de gerenciamento

Por exemplo, digamos que você tenha feito upgrade de todo o cluster do Cassandra, de todos os servidores de gerenciamento e de alguns RMPs da versão 4.52.02 para a 4.53.00 e queira fazer o rollback. Nesse caso, você:

  1. Reverter todos os RMPs um por um
  2. Reverter todo o cluster do Cassandra usando backups
  3. Fazer o rollback dos nós do servidor de gerenciamento do Edge um por um

Quem pode fazer um rollback

O usuário que realiza um rollback precisa ser o mesmo que atualizou o Edge originalmente ou um usuário executando como raiz.

Por padrão, os componentes do Edge são executados como o usuário "apigee". Em alguns casos, talvez você esteja executando componentes do Edge como usuários diferentes. Por exemplo, se o roteador precisar acessar portas privilegiadas, como aquelas abaixo de 1000, execute o roteador como raiz ou como um usuário com acesso a essas portas. Ou você pode executar um componente como um usuário e outro componente como outro usuário.

Componentes com código comum

Os componentes do Edge a seguir compartilham um código comum. Portanto, para reverter qualquer um desses componentes em um nó, é necessário reverter todos os componentes que estão nesse nó.

  • edge-management-server (servidor de gerenciamento)
  • edge-message-processor (processador de mensagens)
  • edge-router (roteador)
  • edge-postgres-server (servidor Postgres)
  • edge-qpid-server (servidor Qpid)

Por exemplo, se você tiver o servidor de gerenciamento, o roteador e o processador de mensagens instalados no nó, para reverter qualquer um deles, é preciso reverter os três.

Reversão do Cassandra

Reversão do Cassandra

Quando um upgrade principal do Cassandra é realizado em um nó específico, o Cassandra modifica o esquema dos dados armazenados nesse nó. Por isso, uma reversão direta no local não é viável.

Cenários de reversão

O Cassandra 4.0.X, disponível com o Edge para nuvem privada 4.53.00, é compatível com outros componentes da nuvem privada 4.52.02.

Consulte a tabela abaixo para um resumo das várias estratégias de rollback que você pode usar:

Cenário Estratégia de reversão
DC único, alguns nós do Cassandra atualizados Usar backups
Data center único, todos os nós do Cassandra atualizados Não faça o rollback do Cassandra. Outros componentes podem ser revertidos.
Data center único, todos os nós (Cassandra e outros) atualizados Não faça o rollback do Cassandra. Outros componentes podem ser revertidos.
Vários data centers, alguns nós em um data center atualizados Recriar com base no DC atual
Vários DCs, todos os nós do Cassandra em alguns DCs atualizados Recriar com base no DC atual
Vários DCs, nós do Cassandra do último DC sendo atualizados Tente concluir o upgrade. Se não for possível, reverta um DC usando o backup. Recrie os DCs restantes do DC revertido.
Vários DCs, todos os nós do Cassandra atualizados Não faça o rollback do Cassandra. Outros componentes podem ser revertidos.
Vários DCs, todos os nós (Cassandra e outros) atualizados Não faça o rollback do Cassandra. Outros componentes podem ser revertidos.

Considerações gerais

Ao considerar um rollback, lembre-se do seguinte:

  • Reversão de componentes de gerenciamento ou de ambiente de execução:se você quiser reverter componentes como edge-management-server, edge-message-processor ou qualquer componente que não seja do Cassandra para a versão 4.52.02 do Private Cloud, é recomendável NÃO reverter o Cassandra. O Cassandra enviado com a nuvem privada 4.53.00 é compatível com todos os componentes não Cassandra do Edge para nuvem privada 4.52.02. É possível fazer o rollback de componentes que não são do Cassandra usando a metodologia listada aqui enquanto o Cassandra permanece na versão 4.0.13.
  • Reversão após o upgrade de todo o cluster do Cassandra para a versão 4.0.X:se todo o cluster do Cassandra for atualizado para a versão 4.0.X como parte do upgrade para a versão 4.53.00 do Private Cloud, é recomendável continuar com essa configuração de cluster e NÃO reverter o Cassandra. Componentes como edge-management-server, edge-message-processor, edge-router etc. da versão 4.52.02 da nuvem privada são compatíveis com a versão 4.0.X do Cassandra.
  • Reversão do Cassandra durante o upgrade: se você encontrar problemas durante o upgrade do Cassandra, considere uma reversão. As estratégias de reversão listadas neste artigo podem ser seguidas com base no estado em que você está durante o processo de upgrade.
  • Reversão usando backups:os backups feitos do Cassandra 4.0.X não são compatíveis com os backups do Cassandra 3.11.X. Para fazer o rollback do Cassandra usando a restauração de backup, é necessário fazer backups do Cassandra 3.11.X antes de tentar o upgrade.

Fazer o rollback do Cassandra usando a recriação

Pré-requisitos

  • Você está operando um cluster do Edge para nuvem privada 4.52.02 em vários data centers.
  • Você está fazendo upgrade do Cassandra da versão 3.11.X para a 4.0.X e encontrou problemas durante o processo.
  • Você tem pelo menos um data center totalmente funcional no cluster ainda executando a versão mais antiga do Cassandra (Cassandra 3.11.X).

Esse procedimento depende do streaming de dados de um data center atual. Isso pode levar muito tempo, dependendo da quantidade de dados armazenados no Cassandra. Prepare-se para desviar o tráfego de tempo de execução desse data center enquanto a reversão estiver em andamento.

Etapas avançadas

  1. Selecione um data center (parcial ou totalmente atualizado) que você quer reverter. Desvie o tráfego de tempo de execução para um data center diferente em funcionamento.
  2. Identifique o nó de seed no data center e comece com um dos nós de seed.
  3. Pare, desinstale e limpe o nó do Cassandra.
  4. Instale a versão mais antiga do Cassandra no nó e configure conforme necessário.
  5. Remova as configurações extras adicionadas anteriormente.
  6. Repita as etapas acima para todos os nós de semente no data center, um por um.
  7. Repita as etapas acima para todos os nós restantes do Cassandra no data center, um por um.
  8. Reconstrua os nós do data center funcional atual, um por um.
  9. Reinicie todos os componentes edge-* no data center conectados ao Cassandra.
  10. Teste e redirecione o tráfego de volta para esse data center.
  11. Repita as etapas para cada data center, um por um.

Etapas detalhadas

  1. Escolha um data center em que todos ou alguns nós do Cassandra serão atualizados. Desvie todo o tráfego de proxy de ambiente de execução e de gerenciamento desse data center enquanto os nós do Cassandra nele são revertidos. Verifique se todos os nós do Cassandra estão no estado UN (Ativo/Normal) quando o comando nodetool ring é executado neles. Se alguns nós estiverem inativos, resolva o problema e coloque esses nós de volta no ar antes de continuar.

    Veja o exemplo abaixo:

    /opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    É possível executar nodetool describecluster nos nós para entender o estado atual de todo o cluster. Por exemplo, o seguinte mostra uma instância de um cluster de dois data centers em que todos os nós DC-1 estão na versão 4 do Cassandra, enquanto todos os nós DC-2 estão na versão 3:

    # On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. Identifique os nós de semente no data center:consulte a seção Como identificar nós de semente no Apêndice. Execute as etapas abaixo em um dos nós de seed:
  3. Pare, desinstale e limpe os dados do nó do Cassandra. Escolha o primeiro nó de semente na versão 4 do Cassandra neste data center. Pare com isso. 
    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra
  4. Instale o software Cassandra mais antigo no nó e defina algumas configurações. Execute o arquivo de bootstrap do Edge para nuvem privada 4.52.02. 
    5. # Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
  5. Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties.
  6. Adicione o seguinte conteúdo ao arquivo. ipOfNode é o endereço IP do nó que o Cassandra usa para se comunicar com outros nós do Cassandra: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. Verifique se o arquivo pertence e pode ser lido pelo usuário do Apigee: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Instale e configure o Cassandra: 
    # Install cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. Verifique se o nó foi iniciado. Verifique o seguinte comando neste nó e em outros nós do cluster. O nó precisa informar que está no estado "UN" (Ativo/Normal): 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. Remova as configurações extras adicionadas anteriormente do arquivo /opt/apigee/customer/application/cassandra.properties.
  11. Repita as etapas de 3 a 10 em todos os nós de seed do Cassandra no data center, um por um.
  12. Repita as etapas de 3 a 10 em todos os nós restantes do Cassandra no data center, um por um.
  13. Recrie todos os nós no data center de um data center que executa a versão mais antiga do Cassandra. Faça esta etapa em um nó por vez: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    Esse procedimento pode levar algum tempo. É possível ajustar streamingthroughput, se necessário. Verifique nodetool netstats para saber o status da conclusão da operação.

  14. (Opcional) Execute o comando de reparo no nó do Cassandra se os dados não estiverem sendo recriados. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. Reinicie todos os componentes edge-* no data center, um por um: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  16. Valide e redirecione o tráfego de volta para esse data center. Execute algumas validações para tráfego de tempo de execução e APIs de gerenciamento nesse data center e comece a redirecionar o tráfego de proxy e da API de gerenciamento de volta para ele.
  17. Repita as etapas acima para cada data center que você quer reverter.

Fazer o rollback do Cassandra usando o backup

Pré-requisitos

  1. Você está fazendo upgrade do Cassandra da versão 3.11.X para a 4.0.X e encontrou problemas durante o processo.
  2. Você tem backups do nó que está revertendo. O backup foi feito antes da tentativa de upgrade da versão 3.11.X para a 4.0.X.

Etapas

  1. Selecione um nó para fazer o rollback. Se você estiver fazendo o rollback de todos os nós em um data center usando backups, comece pelos nós de seed. Consulte a seção "Como identificar nós de semente" no Apêndice.

  2. Pare, desinstale e limpe o nó do Cassandra:

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

  3. Instale o software Cassandra mais antigo no nó e configure-o:

    • Execute o arquivo de bootstrap do Edge para nuvem privada 4.52.02:
      • # Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
    • Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties:
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Verifique se o arquivo pertence ao usuário apigee e pode ser lido:
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Instale e configure o Cassandra:
      • # Install Cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    Verifique se o nó foi iniciado. Verifique o seguinte comando neste nó e em outros nós do cluster. Os nós precisam informar que estão no estado "UN":

    /opt/apigee/apigee-cassandra/bin/nodetool status

  4. Interrompa o serviço do Cassandra e restaure o backup. Consulte a documentação de backup e restauração para mais detalhes:

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

  5. Depois que o backup for restaurado, remova as configurações adicionais:

    Remova a configuração adicionada anteriormente do arquivo /opt/apigee/customer/application/cassandra.properties.

  6. Inicie o serviço do Cassandra no nó:

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

  7. Repita as etapas em cada nó do Cassandra que você quer reverter usando backups, um por vez.

  8. Depois que todos os nós do Cassandra forem restaurados, reinicie todos os componentes edge-* um por um:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Otimizações de backup (opção avançada)

Você pode minimizar (ou eliminar) a perda de dados ao restaurar backups se tiver réplicas disponíveis com os dados mais recentes. Se as réplicas estiverem disponíveis, depois de restaurar o backup, execute um reparo no nó restaurado.

Apêndice

Como identificar nós de semente

Em qualquer nó do Cassandra em um data center, execute o seguinte comando:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

O comando vai gerar várias linhas. Procure a última linha da saída. Os endereços IP listados na última linha são os nós de semente. No exemplo abaixo, DC-1-IP1, DC-1-IP2, DC-2-IP1 e DC-2-IP2 são os IPs do nó de seed:

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

Reverter para uma versão principal ou secundária anterior

Para reverter para uma versão principal ou secundária anterior, faça o seguinte em cada nó que hospeda o componente:

  1. Faça o download do arquivo bootstrap.sh da versão para a qual você quer fazer reversão:

    • Para reverter para a versão 4.52.02, faça o download de bootstrap_4.52.02.sh: 
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
  2. Pare o componente para fazer o rollback:
    1. Para fazer o rollback de qualquer um dos componentes com código comum no nó, é necessário interromper todos eles, como mostra o exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. Para reverter qualquer outro componente no nó, pare apenas esse componente: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Se você estiver fazendo o rollback da monetização, desinstale-a de todos os nós do servidor de gerenciamento e do processador de mensagens: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Desinstale o componente para fazer o rollback no nó:
    1. Para fazer o rollback de qualquer um dos componentes com código comum no nó, desinstale todos eles desinstalando o grupo de componentes edge-gateway, conforme mostrado no exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
    2. Para fazer o rollback do Nginx, faça o seguinte: 
      ###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
    3. Para reverter qualquer outro componente no nó, desinstale apenas esse componente, como mostra o exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      Em que component é o nome do componente.

    4. Para fazer o rollback do roteador de borda, exclua o conteúdo do arquivo /opt/nginx/conf.d e desinstale o grupo de componentes edge-gateway: 
      cd /opt/nginx/conf.d
rm -rf *
  5. Desinstale a versão 4.53.00 do apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Instale a versão 4.52.02 do utilitário apigee-service e as dependências dele. O exemplo a seguir instala a versão 4.52.02 do apigee-service: 
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

    Em que uName e 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.

    Se você receber um erro, verifique se fez o download do arquivo bootstrap.sh na etapa 1.

  7. Instale apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Instale a versão mais antiga do componente: 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    Em que component é o componente a ser instalado e configFile é o arquivo de configuração da versão mais antiga.

  9. Se você estiver fazendo o rollback do Qpid, limpe as iptables: 
    sudo iptables -F
  10. Repita esse processo para cada nó que hospeda o componente que você está revertendo.

Reverter para uma versão de patch anterior

Para fazer o rollback de um componente para uma versão de patch específica, faça o seguinte em cada nó que hospeda o componente:

  1. Faça o download da versão específica do componente: 
    /opt/apigee/apigee-service/bin/apigee-service component_version install

    Em que component_version é o componente e a versão de patch a ser instalada. Exemplo:

    /opt/apigee/apigee-service/bin/apigee-service edge-ui-4.53.00-0.0.20254 install

    Se você estiver usando o repositório on-line da Apigee, determine as versões de componentes disponíveis usando o seguinte comando: 

    yum --showduplicates list comp

    Exemplo:

    yum --showduplicates list edge-ui
  2. Use apigee-setup para instalar o componente: 
    /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

    Exemplo:

    /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile

    Ao instalar um componente, especifique apenas o nome dele, não a versão.

  3. Repita esse processo para cada nó que hospeda o componente que você está revertendo.

Reverter o mTLS

Para reverter a atualização do mTLS, siga estas etapas em todos os hosts:

  1. Parar a Apigee: 
    apigee-all stop
  2. Parar o mTLS: 
    apigee-service apigee-mtls uninstall
  3. Reinstale o mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf