Revierte Apigee Edge 4.53.00

Si encuentras un error durante una actualización a Edge 4.53.00, puedes revertir el componente que causó el error y, luego, volver a intentar la actualización.

Puedes revertir Edge 4.53.00 a la siguiente versión secundaria:

  • Versión 4.52.02

La reversión de una versión implica revertir todos los componentes que hayas actualizado. Además, debes tener en cuenta consideraciones especiales cuando realices la reversión de Cassandra a la versión 4.52.02.

Existen dos situaciones en las que podrías querer realizar una reversión:

  1. Revierte a una versión principal o secundaria anterior. Por ejemplo, de 4.53.00 a 4.52.02.
  2. Revierte a una versión de parche anterior en la misma actualización. Por ejemplo, de 4.53.00.01 a 4.53.00.00.

Para obtener más información, consulta el proceso de lanzamiento de Apigee Edge.

Orden de reversión

La reversión de los componentes debe realizarse en el orden inverso en que se actualizaron, con la excepción de que los servidores de administración deben revertirse después de Cassandra.

Un orden general típico de la reversión para Private Cloud 4.53.00 se verá de la siguiente manera:

  1. Cómo revertir Postgres, Qpid y otros componentes relacionados con las estadísticas
  2. Routers y procesadores de mensajes de reversión
  3. Reversión de Cassandra y Zookeeper
  4. Servidor de administración de reversiones

Por ejemplo, supongamos que actualizaste todo el clúster de Cassandra, todos tus servidores de administración y algunos RMP a la versión 4.53.00 desde la versión 4.52.02 y deseas revertir la actualización. En este caso, debes hacer lo siguiente:

  1. Cómo revertir todos los RMP uno por uno
  2. Cómo revertir todo el clúster de Cassandra con copias de seguridad
  3. Cómo revertir los nodos del servidor de administración de Edge uno por uno

Quién puede realizar una reversión

El usuario que realiza una reversión debe ser el mismo que actualizó Edge originalmente o un usuario que se ejecuta como root.

De forma predeterminada, los componentes de Edge se ejecutan como el usuario "apigee". En algunos casos, es posible que ejecutes componentes de Edge como usuarios diferentes. Por ejemplo, si el router tiene que acceder a puertos con privilegios, como los que son inferiores a 1,000, debes ejecutar el router como root o como un usuario con acceso a esos puertos. También puedes ejecutar un componente como un usuario y otro componente como otro usuario.

Componentes con código común

Los siguientes componentes de Edge comparten código común. Por lo tanto, para revertir cualquiera de estos componentes en un nodo, debes revertir todos los componentes que se encuentran en ese nodo.

  • edge-management-server (servidor de administración)
  • edge-message-processor (procesador de mensajes)
  • edge-router (router)
  • edge-postgres-server (servidor de Postgres)
  • edge-qpid-server (servidor Qpid)

Por ejemplo, si tienes el servidor de administración, el router y el procesador de mensajes instalados en el nodo, para revertir cualquiera de ellos, debes revertir los tres.

Reversión de Cassandra

Reversión de Cassandra

Cuando se realiza una actualización importante de Cassandra en un nodo específico, Cassandra modifica el esquema de los datos almacenados en ese nodo. Por lo tanto, no es posible realizar una reversión directa en el lugar.

Situaciones de reversión

Cassandra 4.0.X, disponible con Edge for Private Cloud 4.53.00, es compatible con otros componentes de Private Cloud 4.52.02.

Consulta la siguiente tabla para obtener un resumen de las diversas estrategias de reversión que puedes usar:

Situación Estrategia de reversión
DC único, algunos nodos de Cassandra actualizados Cómo usar las copias de seguridad
DC único, todos los nodos de Cassandra actualizados No reviertas Cassandra. Otros componentes se pueden revertir.
DC único, todos los nodos (Cassandra y otros) actualizados No reviertas Cassandra. Otros componentes se pueden revertir.
Varios DC, algunos nodos en un DC actualizados Cómo volver a compilar desde un DC existente
Varios DCs, todos los nodos de Cassandra en algunos DCs actualizados Cómo volver a compilar desde un DC existente
Varios DC, nodos de Cassandra del último DC que se actualiza Intenta finalizar la actualización. Si no es posible, revierte 1 DC con la copia de seguridad. Vuelve a compilar los DCs restantes desde el DC revertido.
Varios DC, todos los nodos de Cassandra actualizados No reviertas Cassandra. Otros componentes se pueden revertir.
Varios DC, todos los nodos (Cassandra y otros) actualizados No reviertas Cassandra. Otros componentes se pueden revertir.

Consideraciones generales

Cuando consideres realizar una reversión, ten en cuenta lo siguiente:

  • Reversión de componentes de entorno de ejecución o administración: Si deseas revertir componentes como edge-management-server, edge-message-processor o cualquier componente que no sea de Cassandra a la versión 4.52.02 de Private Cloud, te recomendamos que NO reviertas Cassandra. Cassandra incluido en Private Cloud 4.53.00 es compatible con todos los componentes que no son de Cassandra de Edge for Private Cloud 4.52.02. Puedes revertir los componentes que no sean de Cassandra con la metodología que se indica aquí mientras Cassandra permanezca en la versión 4.0.13.
  • Reversión después de que todo el clúster de Cassandra se actualice a la versión 4.0.X: Si todo el clúster de Cassandra se actualiza a la versión 4.0.X como parte de la actualización a la versión 4.53.00 de Private Cloud, se recomienda que continúes con esta configuración del clúster y NO reviertas Cassandra. Los componentes como edge-management-server, edge-message-processor, edge-router, etc., de la versión 4.52.02 de la nube privada son compatibles con la versión 4.0.X de Cassandra.
  • Reversión de Cassandra durante la actualización de Cassandra: Si tienes problemas durante la actualización de Cassandra, te recomendamos que consideres una reversión. Las estrategias de reversión que se indican en este artículo se pueden seguir según el estado en el que te encuentres durante el proceso de actualización.
  • Reversión con copias de seguridad: Las copias de seguridad de Cassandra 4.0.X no son compatibles con las de Cassandra 3.11.X. Para revertir Cassandra con el restablecimiento de copias de seguridad, debes crear copias de seguridad de Cassandra 3.11.X antes de intentar la actualización.

Cómo revertir Cassandra con la compilación

Requisitos previos

  • Estás operando un clúster de Edge for Private Cloud 4.52.02 en varios centros de datos.
  • Estás en proceso de actualizar Cassandra de la versión 3.11.X a la 4.0.X y tienes problemas durante la actualización.
  • Tienes al menos un centro de datos completamente funcional en el clúster que aún ejecuta la versión anterior de Cassandra (Cassandra 3.11.X).

Este procedimiento se basa en la transmisión de datos desde un centro de datos existente. Esto podría tardar una cantidad significativa de tiempo, según la cantidad de datos almacenados en Cassandra. Debes prepararte para desviar el tráfico del entorno de ejecución de este centro de datos mientras se realiza la reversión.

Pasos de alto nivel

  1. Selecciona un centro de datos (actualizado de forma parcial o total) al que deseas revertir. Desvía el tráfico del entorno de ejecución a otro centro de datos en funcionamiento.
  2. Identifica el nodo inicial en el centro de datos y comienza con uno de ellos.
  3. Detén, desinstala y limpia el nodo de Cassandra.
  4. Instala la versión anterior de Cassandra en el nodo y configúrala según sea necesario.
  5. Quita los parámetros de configuración adicionales que se agregaron antes.
  6. Repite los pasos anteriores para todos los nodos de origen del centro de datos, uno por uno.
  7. Repite los pasos anteriores para todos los nodos de Cassandra restantes en el centro de datos, uno por uno.
  8. Vuelve a compilar los nodos del centro de datos funcional existente, uno por uno.
  9. Reinicia todos los componentes edge-* del centro de datos que estén conectados a Cassandra.
  10. Prueba y desvía el tráfico a este centro de datos.
  11. Repite los pasos para cada centro de datos, uno por uno.

Pasos detallados

  1. Elige un centro de datos en el que se hayan actualizado todos o algunos de los nodos de Cassandra. Desvía todo el tráfico de proxy y de administración del entorno de ejecución de este centro de datos mientras se revierte los nodos de Cassandra en este centro de datos. Asegúrate de que todos los nodos de Cassandra estén en el estado UN (Up/Normal) cuando se ejecute el comando nodetool ring en los nodos. Si algunos nodos están inactivos, soluciona el problema y vuelve a activarlos antes de continuar.

    Consulte el siguiente ejemplo:

    /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

    Puedes ejecutar nodetool describecluster en los nodos para comprender el estado actual de todo el clúster. Por ejemplo, a continuación, se muestra una instancia de un clúster de 2 centros de datos en la que todos los nodos de DC-1 están en la versión 4 de Cassandra, mientras que todos los nodos de DC-2 están en la versión 3 de Cassandra:

    # 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. Identifica los nodos de origen en el centro de datos: Consulta la sección Cómo identificar los nodos de origen en el Apéndice. Ejecuta los siguientes pasos en uno de los nodos de origen:
  3. Detén, desinstala y limpia los datos del nodo de Cassandra. Elige el primer nodo inicial en Cassandra versión 4 en este centro de datos. Detén eso. 
    # 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. Instala el software de Cassandra anterior en el nodo y establece algunos parámetros de configuración. Ejecuta el archivo de inicio de Edge para la nube 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

Establece parámetros de configuración de Cassandra

  1. Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties.
  2. Agrega el siguiente contenido al archivo. ipOfNode es la dirección IP del nodo que Cassandra usa para comunicarse con otros nodos de Cassandra: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  3. Asegúrate de que el usuario apigee sea el propietario del archivo y pueda leerlo: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Instala y configura Cassandra:
    • Instala la versión 3.11.X de Cassandra: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
    • Para configurar Cassandra, pasa el archivo de configuración estándar: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
    • Asegúrate de que Cassandra 3.11.X esté instalado y el servicio se esté ejecutando: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  5. Verifica que se haya iniciado el nodo. Verifica el siguiente comando en este nodo y en otros del clúster. El nodo debe informar que está en el estado "UN" (Up/Normal): 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  6. Quita las configuraciones adicionales que se agregaron antes del archivo /opt/apigee/customer/application/cassandra.properties.
  7. Repite los pasos del 3 al 6 en todos los nodos de origen de Cassandra del centro de datos, uno por uno.
  8. Repite los pasos del 3 al 6 en todos los nodos de Cassandra restantes del centro de datos, uno por uno.
  9. Vuelve a compilar todos los nodos del centro de datos desde un centro de datos que ejecute la versión anterior de Cassandra. Realiza este paso un nodo a la vez: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
    Este procedimiento puede tardar un poco. Puedes ajustar streamingthroughput si es necesario. Verifica el estado con lo siguiente: 
    /opt/apigee/apigee-cassandra/bin/nodetool netstats
  10. Reinicia todos los componentes edge-* del centro de datos, uno por uno: 
    /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
  11. Valida y desvía el tráfico a este centro de datos. Ejecuta algunas validaciones para el tráfico del entorno de ejecución y las APIs de administración en este centro de datos y comienza a redireccionar el tráfico del proxy y de las APIs de administración a él.
  12. Repite los pasos anteriores para cada centro de datos que quieras revertir.

Cómo revertir Cassandra con la copia de seguridad

Requisitos previos

  1. Estás en proceso de actualizar Cassandra de la versión 3.11.X a la 4.0.X y tienes problemas durante la actualización.
  2. Tienes copias de seguridad del nodo al que quieres revertir. La copia de seguridad se realizó antes de intentar la actualización de 3.11.X a 4.0.X.

Pasos

  1. Selecciona un nodo que quieras revertir. Si reviertes todos los nodos de un centro de datos con copias de seguridad, comienza primero con los nodos de origen. Consulta la sección "Cómo identificar nodos de origen" en el Apéndice.

  2. Detén, desinstala y limpia el nodo de 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. Instala el software de Cassandra anterior en el nodo y configúralo:

    • Ejecuta el archivo de inicio de Edge para la nube 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
    • Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties:
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Asegúrate de que el usuario apigee sea el propietario del archivo y que sea legible:
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Instala y configura 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

    Verifica que se haya iniciado el nodo. Verifica el siguiente comando en este nodo y en otros del clúster. Los nodos deben informar que este nodo está en el estado "UN":

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

  4. Detén el servicio de Cassandra y restablece la copia de seguridad. Consulta la documentación de copia de seguridad y restablecimiento para obtener más detalles:

    # 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. Una vez que se restablezca la copia de seguridad, quita la configuración adicional:

    Quita la configuración que se agregó antes del archivo /opt/apigee/customer/application/cassandra.properties.

  6. Inicia el servicio de Cassandra en el nodo:

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

  7. Repite los pasos en cada nodo de Cassandra que desees revertir con copias de seguridad, uno a la vez.

  8. Una vez que se restablezcan todos los nodos de Cassandra, reinicia todos los componentes edge-* uno por uno:

    /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

Optimizaciones de copia de seguridad (opción avanzada)

Puedes minimizar (o eliminar) la pérdida de datos mientras restableces copias de seguridad si tienes réplicas disponibles que contengan los datos más recientes. Si hay réplicas disponibles, después de restablecer la copia de seguridad, ejecuta una reparación en el nodo que se restableció.

Apéndice

Cómo identificar los nodos de origen

En cualquier nodo de Cassandra de un centro de datos, ejecuta el siguiente comando:

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

El comando generará varias líneas. Busca la última línea del resultado. Las direcciones IP que se indican en la última línea son los nodos iniciales. En el siguiente ejemplo, DC-1-IP1, DC-1-IP2, DC-2-IP1 y DC-2-IP2 son las IPs de los nodos de origen:

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

Cómo revertir a una versión principal o secundaria anterior

Para revertir a una versión principal o menor anterior, haz lo siguiente en cada nodo que aloje el componente:

  1. Descarga el archivo bootstrap.sh de la versión a la que deseas revertir:

    • Para revertir a la versión 4.52.02, descarga bootstrap_4.52.02.sh: 
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
  2. Detén el componente para revertirlo:
    1. Para revertir cualquiera de los componentes con código común en el nodo, debes detenerlos todos, como se muestra en el siguiente ejemplo: 
      /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 revertir cualquier otro componente del nodo, detén solo ese componente: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Si reviertes la Monetización, desinstálala de todos los nodos del servidor de administración y del procesador de mensajes: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Desinstala el componente para revertir el nodo:
    1. Para revertir cualquiera de los componentes con código común en el nodo, debes desinstalarlos todos. Para ello, desinstala el grupo de componentes edge-gateway, como se muestra en el siguiente ejemplo: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
    2. Para revertir cualquier otro componente del nodo, desinstala solo ese componente, como se muestra en el siguiente ejemplo: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      En el que component es el nombre del componente.

    3. Para revertir el router de borde, debes borrar el contenido del archivo /opt/nginx/conf.d, además de desinstalar el grupo de componentes edge-gateway: 
      cd /opt/nginx/conf.d
rm -rf *
  5. Desinstala la versión 4.53.00 de apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Instala la versión 4.52.02 de la utilidad apigee-service y sus dependencias. En el siguiente ejemplo, se instala la versión 4.52.02 de apigee-service: 
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
    .

    En el que uName y pWord son el nombre de usuario y la contraseña que recibiste de Apigee. Si omites pWord, se te pedirá que lo ingreses.

    Si recibes un error, asegúrate de haber descargado el archivo bootstrap.sh en el paso 1.

  7. Instala apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Instala la versión anterior del componente: 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    En el que component es el componente que se instalará y configFile es tu archivo de configuración de la versión anterior.

  9. Si reviertes Qpid, borra iptables: 
    sudo iptables -F
  10. Repite este proceso para cada nodo que aloje el componente que quieres revertir.

Cómo revertir a una versión de parche anterior

Para revertir un componente a una versión de parche específica, haz lo siguiente en cada nodo que aloje el componente:

  1. Descarga la versión específica del componente: 
    /opt/apigee/apigee-service/bin/apigee-service component_version install

    Donde component_version es el componente y la versión del parche que se instalará. Por ejemplo:

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

    Si usas el repositorio en línea de Apigee, puedes determinar las versiones de los componentes disponibles con el siguiente comando: 

    yum --showduplicates list comp

    Por ejemplo:

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

    Por ejemplo:

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

    Ten en cuenta que solo debes especificar el nombre del componente cuando lo instales, no la versión.

  3. Repite este proceso para cada nodo que aloje el componente que quieres revertir.

Revierte la mTLS

Para revertir la actualización de mTLS, sigue estos pasos en todos los hosts:

  1. Detén Apigee: 
    apigee-all stop
  2. Detener mTLS: 
    apigee-service apigee-mtls uninstall
  3. Reinstalar mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf