Recuerde que estamos usando la configuración del modelo que se muestra en el diagrama a continuación, y preste atención a las etiquetas disponibles allí, ya que las usaremos activamente en nuestros ejemplos.
| Componentes de software | Versiones |
|---|---|
| Plataforma de contenedores Red Hat OpenShift | 4.5.7 |
| Gestión avanzada de clústeres de Red Hat | 2.0 Fix Pack 2.0.2 |
Repositorio de Git
También usaremos el repositorio de Git del artículo anterior:
| Rama | Descripción |
|---|---|
| config | Almacena archivos base para aplicaciones que se utilizan en todos los entornos. |
| Pinchar | Almacena archivos de superposición para aplicaciones utilizadas en entornos de producción. |
| etapa | Almacena archivos de superposición para aplicaciones que se utilizan en entornos de prueba. |
Implementación azul / verde con Red Hat ACM
En el artículo anterior, implementamos nuestra aplicación de palabras inversas en dos entornos, desarrollo y producción. Digamos que en Desarrollo tenemos la versión 0.0.3 y en Producción 0.0.2.
Ahora digamos que los desarrolladores han lanzado la versión 0.0.4 y queremos hacer una implementación azul-verde en los clústeres de Desarrollo y Producción utilizando las capacidades de GitOps de ACM.
En el artículo anterior, creamos los recursos necesarios de Canal, Reglas de ubicación, Suscripciones y Aplicaciones en ACM, de modo que cuando implementemos la nueva versión, solo Git funcionará en ambos clústeres.
Actualización de la aplicación en el entorno de desarrollo
Dado que ya se han creado todos los recursos necesarios, solo necesitamos cambiar las descripciones de la aplicación en Git para poder actualizar las versiones en los entornos correspondientes.
NOTA. Dado que aquí solo estamos demostrando las capacidades de GitOps de ACM, enviaremos los cambios directamente a las ramas del repositorio, lo cual no es bueno. En la vida real, debe tener un proceso bien definido para realizar cambios en diferentes entornos, puede leer más sobre esto aquí .
1. Vaya a nuestro repositorio de Git clonado:
NOTA: Si reprodujo los ejemplos del artículo anterior, entonces ya tiene una rama clonada de este repositorio aquí .
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. Primero, queremos actualizar la versión de la aplicación en el entorno de Desarrollo para poder probarla antes de introducir cambios en el entorno de Producción. Por lo tanto, trabajaremos con la rama de escenario.
git checkout stage
3. Ahora necesita actualizar la superposición para la implementación de la aplicación para que esta implementación use la imagen de la nueva versión (0.0.4).
Hasta ahora, la versión 0.0.3 se está ejecutando en el clúster de desarrollo.
sed -i "s/v0.0.3/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. Antes de realizar cambios, verifique el estado actual de la aplicación en el clúster de desarrollo.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Como puede ver, la versión 0.0.3 se está ejecutando actualmente en el entorno de desarrollo:
Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3
5. Confirme el archivo y empújelo a la rama del escenario.
NOTA. Una vez más, en la vida real no deberías. Debe tener un proceso bien definido para esto.
git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed development reverse-words app version to v0.0.4"
git push origin stage
6. Dado que ya tenemos una Suscripción, al detectar una nueva confirmación en nuestro repositorio y rama, ACM realizará las acciones para cambiar el estado actual al deseado, como está escrito en Git.
oc --context dev -n reverse-words-stage get pods
Como puede ver, se han detectado cambios y la nueva versión del pod se implementa con la nueva versión de la aplicación.
NAME READY STATUS RESTARTS AGE
reverse-words-5ff744d4bd-kkfvn 0/1 ContainerCreating 0 3s
reverse-words-68b9b894dd-jfgpf 1/1 Running 0 109m
7. Ahora ejecutemos la solicitud a la aplicación y asegurémonos de haber implementado la versión 0.0.4.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Stage Release v0.0.4. App version: v0.0.4
8. La versión de producción permanece intacta.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production release v0.0.2. App version: v0.0.2
9. Ahora puede ejecutar las pruebas de validación y, si todo está bien, implementar la nueva versión de la aplicación en producción.
Actualización de la aplicación en el entorno de producción
1. Vaya al repositorio de Git clonado.
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. Creemos que hemos probado con éxito la nueva versión de la aplicación en el clúster de Desarrollo y es hora de hacer los cambios apropiados para implementarla en el clúster de Producción, por lo que ahora trabajaremos con la rama prod.
git checkout prod
3. La superposición para la implementación de la aplicación debe actualizarse para que esta implementación utilice la imagen de la nueva versión (0.0.4).
Hasta ahora, la versión 0.0.2 se está ejecutando en el clúster de producción
sed -i "s/v0.0.2/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. Antes de realizar cambios, verifique el estado actual de la aplicación en el clúster de producción.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Como puede ver, la versión 0.0.2 se está ejecutando actualmente en el entorno de producción:
Reverse Words Release: Stage Release v0.0.2. App version: v0.0.2
5. Confirme el archivo y empújelo a la rama prod.
NOTA. Una vez más, en la vida real no deberías. Debe tener un proceso bien definido para esto.
git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed production reverse-words app version to v0.0.4"
git push origin prod
6. Dado que ya tenemos una Suscripción, al detectar una nueva confirmación en nuestro repositorio y rama, ACM realizará las acciones para cambiar el estado actual al deseado, como está escrito en Git.
oc --context pro -n reverse-words-prod get pods
Como puede ver, se han detectado cambios y la nueva versión del pod se implementa con la nueva versión de la aplicación.
NAME READY STATUS RESTARTS AGE
reverse-words-68795d69ff-6t4c7 0/1 ContainerCreating 0 5s
reverse-words-7dd94446c-vkzr8 1/1 Running 0 115m
7. Ahora ejecutemos la solicitud a la aplicación y asegurémonos de haber implementado la versión 0.0.4.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production Release v0.0.4. App version: v0.0.4
8. Eso es todo, hemos actualizado nuestra aplicación a la versión 0.0.4 en ambos entornos: Desarrollo y Producción.
Conclusión
En la primera parte de esta serie, cubrimos los aspectos de ACM que se incluyen en la categoría de GitOps. Hoy aprendimos cómo usar ACM para implementaciones azul-verde, migración de aplicaciones entre clústeres y recuperación ante desastres. En la próxima publicación, le mostraremos cómo migrar sin problemas su aplicación de contraseñas entre nuestros clústeres usando ACM.