Se usó la API de Cloud Translation para traducir esta página.

Revierte Apigee Edge 4.52.02

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

Puedes revertir Edge 4.52.02 a cualquiera de las siguientes versiones principales:

Versión 4.52.01
Versión 4.52.00
Versión 4.51.00

La reversión de una versión implica revertir todos los componentes que hayas actualizado. Además, según la versión desde la que comenzaste, es posible que debas considerar pasos especiales antes de revertir ciertos componentes de software. En la siguiente tabla, se enumeran los diversos componentes de software para los que se pueden necesitar pasos especiales durante la reversión:

Revierte a la versión	Consideraciones especiales para el software
4.52.01	Cassandra
4.52.00	Zookeeper, Cassandra, Qpid
4.51.00	Zookeeper, Postgres, Cassandra, Qpid

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

Revierte a una versión principal o secundaria anterior. Por ejemplo, de 4.52.02 a 4.52.00.
Revierte a una versión de parche anterior en la misma versión. Por ejemplo, de 4.52.00.02 a 4.52.00.01.

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 seguir el orden inverso de su actualización, con la excepción de que los servidores de administración deben revertirse después de Cassandra. Cassandra, los componentes del entorno de ejecución y el servidor de administración deben revertirse con un enfoque de centro de datos por centro de datos (DC por DC), lo que redirecciona temporalmente el tráfico a los centros de datos funcionales.

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

Un solo centro de datos

En el caso de la configuración de un solo centro de datos, el procedimiento de reversión tendrá un impacto significativo en el tráfico del entorno de ejecución y en ciertas APIs de administración.

Revierte Qpid y otros componentes relacionados con las estadísticas
Routers y procesadores de mensajes de reversión
Cómo revertir Cassandra
Servidor de administración de reversión
Revierte Postgres y Zookeeper

Varios centros de datos

En una configuración de varios centros de datos, las reversiones deben seguir un enfoque de centro de datos por centro de datos (DC por DC) que redirecciona temporalmente el tráfico a los centros de datos funcionales. Esto garantiza la continuidad del tráfico, evita el tiempo de inactividad y habilita un proceso de reversión controlado para Cassandra, el servidor de administración y los nodos de tiempo de ejecución.

Revierte Qpid y otros componentes relacionados con las estadísticas en todos los DCs.
Bloquea el tráfico en el primer centro de datos y redirecciona el tráfico a otros DCs.
Routers y procesadores de mensajes de reversión en el primer centro de datos
Revierte Cassandra en el primer centro de datos.
Servidor de administración de reversión en el primer centro de datos
Desbloquea el tráfico en el primer centro de datos y sigue los pasos del 2 al 6 hasta que el último centro de datos revierta los nodos de entorno de ejecución, Cassandra y el servidor de administración.
Revierte Postgres, Zookeeper y LDAP en todos los DCs.

A modo de ejemplo, supongamos que actualizaste todo el clúster de Cassandra, todos los servidores de administración y algunos procesadores de mensajes de tiempo de ejecución (RMP) de la versión 4.52.01 a la 4.52.02 y necesitas realizar una reversión. En este caso, la reversión se debe realizar de la siguiente manera:

Bloquea el tráfico al primer centro de datos (centro de datos) y redirecciona el tráfico a los otros DCs activos para garantizar la continuidad del servicio.
Routers y procesadores de mensajes de reversión en el primer centro de datos
Revierte Cassandra en el primer centro de datos restableciendo desde una copia de seguridad o una instantánea de VM.
Revierte el servidor de administración en el primer centro de datos.
Desbloquea el tráfico al primer centro de datos.
Repite los pasos del 1 al 5 para cada centro de datos restante hasta que se reviertan todos los nodos de entorno de ejecución, Cassandra y los servidores de administración.

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 debe 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

Cuando se realiza una actualización importante de Cassandra en un nodo en particular, Cassandra modifica el esquema de los datos almacenados en el nodo, lo que hace que no sea posible una reversión directa. Existen dos metodologías para realizar la reversión. Usarás una de estas metodologías según el estado de la actualización desde la que realizas la reversión.

Metodologías para revertir

Situaciones de reversión

Edge for Private Cloud 4.52.02 incluye una actualización en Cassandra y el controlador que usan el procesador de mensajes y el servidor de administración para conectarse a Cassandra. Como resultado, las actualizaciones y la reversión de estos 3 componentes están estrechamente vinculadas. En la siguiente tabla, se enumeran ejemplos generales de situaciones de reversión para estos tres componentes específicos. La reversión de otros componentes debe seguir el orden de la reversión.

En esta sección, se describen varias situaciones de reversión junto con la metodología recomendada que se debe seguir, según los enfoques descritos anteriormente.

Situación	Estrategia de reversión
Un solo centro de datos, algunos nodos de Cassandra actualizados	Restablecimiento de copias de seguridad
Un solo centro de datos, todos los nodos de Cassandra actualizados	Restablecimiento de copias de seguridad
Un solo centro de datos, todos los nodos (Cassandra, servidor de administración y nodos de entorno de ejecución) actualizados	Reversión de nodos de tiempo de ejecución Restablecimiento de la copia de seguridad de Cassandra Reversión de administración
Varios centros de datos, algunos o todos los nodos de Cassandra en el primer centro de datos actualizados	Vuelve a compilar desde un centro de datos existente
Se actualizaron varios centros de datos, todos los nodos de Cassandra, el servidor de administración y los nodos de entorno de ejecución en el primer centro de datos.	Reversión de nodos de tiempo de ejecución Restablecimiento de la reconstrucción de Cassandra Reversión de administración Esto se debe realizar en un centro de datos a la vez.
Varios centros de datos, algunos o todos los nodos de Cassandra del último centro de datos se actualizaron	Cómo revertir el último centro de datos con una copia de seguridad Revierte los centros de datos restantes con copias de seguridad o recomposiciones, uno a la vez.
Varios centros de datos, todos los nodos de Cassandra, el servidor de administración y los nodos de tiempo de ejecución actualizados en todos los DCs	Reversión de nodos de tiempo de ejecución Restablecimiento de copias de seguridad de Cassandra Reversión de administración Esto se debe realizar un centro de datos a la vez.

Por lo general, debes tener en cuenta lo siguiente cuando reviertas Cassandra:

Reversión de componentes de administración o entorno de ejecución
Si necesitas revertir componentes, como el servidor de administración de Edge o el procesador de mensajes de Edge, a una versión anterior de Edge Private Cloud en cualquier centro de datos (DC), asegúrate de que Cassandra también se revierta en ese centro de datos específico al mismo tiempo. Esto es necesario para evitar fallas de tráfico de administración y tiempo de ejecución.
Cómo revertir a la versión anterior con copias de seguridad
Las copias de seguridad que se toman de Cassandra 3.11.x no son compatibles con las de Cassandra 2.1.x. Para habilitar la reversión con el restablecimiento de copias de seguridad, asegúrate de crear copias de seguridad de Cassandra 2.1.x antes de realizar la actualización.
Cómo aislar el centro de datos para la reversión
Para evitar el tiempo de inactividad, asegúrate de que el tráfico se redireccione a centros de datos completamente funcionales y se bloquee en el centro de datos que se está revirtiendo.

Cómo revertir Cassandra con la compilación

Requisitos previos

Estás operando un clúster de Edge for Private Cloud 4.51.00, 4.52.00 o 4.52.01 en varios centros de datos.
Estás en proceso de actualizar Cassandra de la versión 2.1.X a la 3.11.X y tienes problemas durante la actualización.
Tienes al menos 1 centro de datos completamente funcional en el clúster que aún tiene la versión anterior de Cassandra (Cassandra 2.1.X).

Pasos de alto nivel

Elige un centro de datos (actualizado de forma parcial o total) al que deseas revertir. Redirecciona todo el tráfico de la aplicación de este centro de datos a otro centro de datos completamente funcional.
Si se actualizaron el router y el procesador de mensajes, revierte todos los nodos del router y del procesador de mensajes del centro de datos, uno a la vez.
Detén Cassandra en un nodo, desinstálalo y limpia todos los datos asociados.
Instala el arranque de la versión anterior y configura la versión 2.1.x de Cassandra en el nodo limpiado.
Vuelve a compilar el nodo desde el centro de datos funcional existente que aún ejecuta Cassandra 2.1.x.
Realiza los pasos del 3 al 5 en cada nodo de Cassandra restante del centro de datos, uno a la vez.
Vuelve a ejecutar la configuración del servidor de administración en el centro de datos.
Realiza pruebas para validar la reversión. Una vez verificado, redirecciona el tráfico de la aplicación al centro de datos restablecido.
Repite los pasos anteriores para los otros centros de datos que requieran una reversión, uno a la vez.

Pasos detallados para borrar y usar los nodos existentes en el clúster para volver a compilar el nodo:

Comienza con el nodo que deseas revertir.

Asegúrate de que el tráfico se redireccione a centros de datos completamente funcionales antes de continuar con los siguientes pasos.
Si se actualizaron el router y Message Processor, revierte todos los nodos de router y Message Processor a la versión anterior en el centro de datos, uno a la vez.

Detén Cassandra en el nodo:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

Desinstala el software de Cassandra del nodo:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

Quita el directorio de datos del nodo:

rm -rf /opt/apigee/data/apigee-cassandra

Descarga y ejecuta el inicio de la versión anterior de Edge para la nube privada a la que deseas revertir:

Ejemplo: Para revertir a la versión 4.52.01

Descarga el bootstrap de 4.52.01:

curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’

Ejecuta el inicio de la versión 4.52.01:

sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord

Instala el software de Cassandra en el nodo:
```
apigee-service apigee-cassandra install
```

Agrega la siguiente propiedad en el archivo /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh.

JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=<cass_ip-address>"

Ejemplo:

JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=10.0.0.1"

Configura Cassandra en el nodo:
```
/opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile
```
Nota: En caso de que falle la configuración de Cassandra, edita el archivo /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh y quita la línea que contiene lo siguiente: JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=<cass_ip-address>" Después de hacer este cambio, vuelve a ejecutar la secuencia de comandos setup.sh anterior para volver a intentar la configuración.
Después de que Cassandra esté EN FUNCIONAMIENTO, quita el CWC anterior del siguiente archivo:/opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh.
Reinicia el nodo de Cassandra
```
apigee-service apigee-cassandra restart
```

Proporciona el nombre del centro de datos funcional para ejecutar la reconstrucción en el nodo:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild -h <node-IP> <functional-dc>

Ejemplo:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild -h 10.0.0.1 dc-2

Repite los pasos anteriores en cada nodo que quieras revertir en el centro de datos, uno a la vez.

Una vez que se reviertan y vuelvan a compilar todos los nodos de Cassandra del centro de datos

Ejecuta la configuración de cualquiera de los nodos de servidor de administración en el centro de datos que se revertirá. Asegúrate de que el servidor de administración sea de la versión revertida. De lo contrario, revierte el servidor de administración también.

Cómo revertir el servidor de administración a una versión anterior

Detén el servidor de administración:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server stop

Si usas la monetización, desinstálala también:

/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall

Desinstala edge-gateway y apigee-cassandra-client:

/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall

Descarga y ejecuta el inicio de la versión anterior. Por ejemplo, ejecuta los siguientes pasos para descargar y ejecutar el inicio de la versión 4.52.01.

curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’

sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord

Configuración del servidor de administración

Ejecuta la configuración de un nodo de servidor de administración:
```
/opt/apigee/apigee-setup/bin/setup.sh -p mt -f configFile
```
Después de completar los pasos anteriores, redirecciona el tráfico al centro de datos con la versión anterior.

Optimización después de la reconstrucción

En los pasos anteriores, todos los datos del nodo se transmiten desde el centro de datos remoto durante la reconstrucción. Puedes optimizar este proceso con una reparación una vez que se hayan transmitido todas las réplicas al centro de datos local. Esto evita la transmisión entre centros de datos y debería ser más rápido que volver a compilar todos los nodos desde un centro de datos remoto.

Ejemplo: Supongamos que tienes seis nodos de Cassandra en el centro de datos local. De forma predeterminada, el factor de replicación de Apigee es tres, por lo que cada nodo posee el 50% de los datos. En este caso, puedes volver a compilar los nodos 1 y 4 siguiendo el procedimiento anterior. Para los nodos 2, 3, 5 y 6, sigue los pasos que se indican a continuación para restablecer la copia de seguridad y ejecutar una reparación.

Sigue el procedimiento hasta los pasos anteriores según se documenta para volver a crear réplicas en el centro de datos local.
Para los nodos restantes, sigue los pasos que se indican a continuación en cada uno de ellos, uno a la vez.

Restablece la copia de seguridad que capturaste en este nodo (nota: es probable que esta copia de seguridad tenga datos inactivos, ya que se tomó antes de que iniciaras la actualización de Cassandra):
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file
```
Si tienes una instantánea de VM del nodo, puedes restablecerla en lugar de restablecer la copia de seguridad de Cassandra.
Después de restablecer la copia de seguridad, inicia el servicio de Cassandra en el nodo:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
```

Ejecuta una reparación en el nodo para que los datos más recientes se puedan transmitir desde un centro de datos existente:

/opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -dc <local-dc-name>

Ejemplo:

/opt/apigee/apigee-cassandra/bin/nodetool -h 10.0.0.1 repair -dc dc-1

Repite todos los pasos anteriores mencionados en el paso 2 en cada nodo que quieras reparar.

Cómo revertir Cassandra con una copia de seguridad o una instantánea de VM

Este procedimiento es el único disponible si actualizaste todo el clúster de Cassandra y deseas revertir la actualización. Además, las copias de seguridad de Apigee son específicas del nodo. No es posible restablecer una copia de seguridad tomada de un nodo a otro. Las copias de seguridad de Cassandra incluyen información de metadatos de nodos (como la dirección IP, la posición del anillo, etcétera).

Requisitos previos

Estás en proceso de actualizar Cassandra de la versión 2.1.X a la 3.11.X en el último centro de datos y tienes problemas durante la actualización.
Tienes copias de seguridad del nodo antes de la actualización que quieres revertir. Se realizó la copia de seguridad antes de intentar actualizar de 2.1.X a 3.11.X.

Pasos de alto nivel

Elige un centro de datos (actualizado de forma parcial o total) para revertir la acción. Redirecciona todo el tráfico del entorno de ejecución de este centro de datos a otro centro de datos completamente funcional.
Si se actualizaron el router y el procesador de mensajes, revierte todos los nodos del router y del procesador de mensajes en el centro de datos, uno a la vez.
Detén Cassandra en un nodo, desinstálalo y limpia todos los datos asociados.
Instala el arranque de la versión anterior y configura la versión 2.1.x de Cassandra en el nodo limpiado.
Detén el nodo de Cassandra y limpia todos los datos asociados.
Restablece el nodo de Cassandra desde la copia de seguridad que se tomó antes de la actualización.
Repite los pasos del 3 al 6 para cada uno de los nodos de Cassandra restantes en el centro de datos, uno a la vez.
Vuelve a ejecutar la configuración del servidor de administración en el centro de datos.
Realiza pruebas para validar la reversión. Una vez verificado, redirecciona el tráfico del entorno de ejecución al centro de datos restablecido.
Repite los pasos anteriores para los otros centros de datos que requieran una reversión, uno a la vez.
(Opcional) Ejecuta el comando de reparación en todos los nodos de Cassandra de todos los centros de datos si hay inconsistencias entre ellos.

Pasos detallados para revertir Cassandra con copias de seguridad o instantáneas de VM

Comienza con 1 nodo de Cassandra en el clúster

Asegúrate de que el tráfico se redireccione a centros de datos completamente funcionales antes de continuar con los siguientes pasos.
Si se actualizaron el router y el procesador de mensajes, revierte todos los nodos del router y el procesador de mensajes a la versión anterior en el centro de datos, uno a la vez.

Detén Cassandra en el nodo:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

Desinstala el software de Cassandra del nodo:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

Quita el directorio de datos del nodo:

rm -rf /opt/apigee/data/apigee-cassandra

Descarga y ejecuta el inicio de la versión anterior de Edge para la nube privada a la que deseas revertir:

Ejemplo: Para revertir a la versión 4.52.01

Descarga el bootstrap de 4.52.01:

curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’

Ejecuta el inicio de la versión 4.52.01:

sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord

Configura Cassandra en el nodo:

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

Detén Cassandra en el nodo:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

Borra el directorio de datos del nodo:

rm -rf /opt/apigee/data/apigee-cassandra/data

Restablece la copia de seguridad:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file

Inicia el servicio de Cassandra en el nodo

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

Repite los pasos en cada nodo de Cassandra de a uno.
Ejecuta la configuración de cualquiera de los nodos de servidor de administración en el centro de datos que se revertirá. Asegúrate de que el servidor de administración sea de la versión revertida. De lo contrario, revierte el servidor de administración también.
Después de completar los pasos anteriores, redirecciona el tráfico al centro de datos con la versión anterior.
(Opcional) Ejecuta el comando de reparación en todos los nodos de Cassandra de todos los centros de datos si hay inconsistencias entre ellos.
```
/opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -pr
```

Revierte la actualización de Zookeeper 3.8.3

Si quieres revertir a las versiones 4.52.00 o 4.51.00, deberás consultar algunos pasos especiales antes de revertir Zookeeper. Estos pasos se indican en Rollback.

Si quieres revertir a la versión 4.52.01, haz lo mismo con Zookeeper que con cualquier software, como se indica en la sección Cómo revertir a una versión principal o secundaria anterior que aparece a continuación.

Reversión de Qpid

Si quieres revertir a las versiones 4.52.00 o 4.51.00, deberás consultar algunos pasos especiales antes de revertir Qpid. Estos pasos se indican en Rollback.

Si quieres revertir a la versión 4.52.01, revierte Qpid como lo harías con cualquier software, como se indica en Cómo revertir a una versión principal o secundaria anterior.

Revierte la actualización de Postgres 10.17

Si quieres revertir a la versión 4.51.00, deberás consultar algunos pasos especiales antes de revertir Postgres. Estos pasos se indican en Rollback.

Si quieres revertir a la versión 4.52.01 o 4.52.00, haz lo mismo con Postgres que con cualquier software, como se indica en la sección Cómo revertir a una versión principal o secundaria anterior que aparece a continuación.

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

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

Descarga el archivo bootstrap.sh de la versión a la que deseas revertir:
- Para revertir a la versión 4.51.00, descarga bootstrap_4.51.00.sh.

Detén el componente para revertirlo:

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

Para revertir cualquier otro componente del nodo, detén solo ese componente:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

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
```
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 y apigee-cassandra-client, como se muestra en el siguiente ejemplo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
```
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client 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 *
```

Desinstala la versión 4.52.02 de apigee-setup:

/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

Instala la versión 4.51.00 de la utilidad apigee-service y sus dependencias. En el siguiente ejemplo, se instala la versión 4.51.00 de apigee-service:
```
sudo bash /tmp/bootstrap_4.51.00.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 se produce un error, asegúrate de haber descargado el archivo bootstrap.sh en el paso 1.

Instala apigee-setup:

/opt/apigee/apigee-service/bin/apigee-service apigee-setup install

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.
Si reviertes Qpid, borra iptables:
```
sudo iptables -F
```
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:

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.51.05-0.0.3749 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 component
```
Por ejemplo:
```
yum --showduplicates list edge-ui
```
Usa apigee-setup para instalar el componente:
```
/opt/apigee/apigee-setup/bin/setup.sh -p component -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.
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:

Detén Apigee:
```
apigee-all stop
```
Detén la mTLS:
```
apigee-service apigee-mtls uninstall
```

Reinstala mTLS:

apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf