Descripción de las estrategias de despliegue
Las arquitecturas descritas en este artículo ilustran cómo crear y desplegar una aplicación moderna con estrategias de despliegue Blue-Green y Canary. Las estrategias de despliegue son modelos y prácticas que permiten modificar o actualizar la aplicación. Las estrategias de despliegue permiten a los equipos DevOps definir cómo se despliegan las aplicaciones en el entorno de producción.
La elección entre diferentes estrategias de despliegue permite a los administradores compensar correctamente el riesgo de desplegar una nueva versión, el impacto de la nueva versión en sus usuarios y la sobrecarga de infraestructura necesaria para implementar la estrategia. Queremos ofrecer a nuestros clientes más opciones para lograr la compensación adecuada en función de las necesidades de su aplicación.
Acerca de los despliegues azul-verde
Con una estrategia de despliegue azul-verde, los equipos de DevOps desean lanzar una nueva versión de su aplicación mediante dos entornos idénticos en los que uno de ellos está activo en un momento determinado. La versión actual de la aplicación se aprovisiona en el entorno activo, mientras que la nueva versión se despliega en el entorno en espera.
El despliegue en el entorno en espera no afecta al entorno activo ni al tráfico del usuario. El pipeline de la versión DevOps puede ejecutar pruebas de validación en la nueva versión y, una vez aprobado, pasa a producción simplemente cambiando el tráfico de usuario al entorno en espera. Este proceso se repetirá para cada nueva versión de la aplicación.
La principal ventaja de esta estrategia es que ofrece un tiempo de inactividad casi cero y capacidades de rollback instantáneo. En caso de cualquier problema con la nueva versión, el tráfico puede volver a la versión estable anterior al instante. Y el entorno en espera está disponible para depurar lo que ha fallado en la versión de la aplicación.
En este diagrama se muestra una arquitectura de despliegue azul-verde:
Descripción de los componentes de despliegue Blue-Green
La arquitectura anterior tiene los siguientes componentes.
-
Región
Una región de OCI es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones y las grandes distancias pueden separarse (entre países e incluso continentes). La arquitectura utiliza una sola región.
-
Proyecto de DevOps
Agrupación lógica de recursos de DevOps necesarios para implantar un flujo de trabajo de integración y despliegue continuos. Los recursos de DevOps pueden ser artefactos, pipelines de compilación, pipelines de despliegue, conexiones externas, disparadores y entornos. Los proyectos DevOps facilitan el registro, la supervisión y las notificaciones de todos los recursos DevOps.
-
Crear pipeline
Un pipeline de compilación toma un ID de confirmación de los repositorios de código fuente y utiliza ese código fuente para ejecutar las instrucciones de compilación. Los pipelines de creación definen un juego de etapas para el proceso de creación: creación, prueba y compilación de artefactos de software, entrega de artefactos a repositorios de OCI y, opcionalmente, disparando un despliegue. El flujo y las instrucciones de la ejecución de creación se definen en el archivo de especificaciones de creación.
-
Etapas de creación
Las etapas son acciones individuales que tienen lugar durante una ejecución de un pipeline. Varias etapas de creación mencionadas aquí son: Etapas de creación gestionadas: una etapa de creación gestionada para crear y probar el código de origen. Etapa de entrega de artefactos: etapa para transferir las salidas de la etapa de creación a varios repositorios. Como imágenes de contenedor para repositorio de contenedor y manifiesto de despliegue al registro de artefactos. Llamar a Despliegue: Etapa para llamar a un pipeline de despliegue una vez finalizadas las etapas de creación, junto con el análisis de las variables exportadas desde la etapa de creación gestionada hasta las etapas del pipeline de despliegue.
-
Repositorio de código
Repositorios de Git privados alojados por el servicio DevOps. Puede almacenar, gestionar y desarrollar código fuente con nuestros repositorios de código DevOps. Pipeline de despliegue Una secuencia de pasos para entregar y desplegar un juego de artefactos en un entorno de destino. El flujo y la lógica de la versión de software se pueden controlar definiendo etapas que se pueden ejecutar en serie o en paralelo.
-
Etapas de despliegue
Las etapas son acciones individuales que se realizan durante una ejecución de un pipeline. Varias etapas de construcción mencionadas aquí son:- Despliegue de OKE azul/verde o despliegue de grupo de instancias azul/verde: etapa para desplegar el código actualizado en entornos de destino.
- Validación de despliegue: etapa opcional para validar los despliegues (funciones de AV)
- Control: Aprobación: etapa de control para aprobar el despliegue en el entorno de producción de destino.
- Turno de tráfico azul/verde de OKE o Turno de tráfico de grupo de instancias azul/verde: etapa final en la que el tráfico de producción se cambiará al último entorno desplegado.
-
Artefacto DevOps
Un artefacto DevOps es una referencia o puntero a cualquier archivo, binario, paquete, manifiesto o imagen que constituya la aplicación. Al crear un artefacto, informe a Oracle DevOps de la ubicación de origen del artefacto real. DevOps soporta los repositorios OCI Container Image Registry y OCI Artifact Registry.
-
Repositorio de artefactos
El repositorio de artefactos crea repositorios para agrupar artefactos similares. Cuando se crea el repositorio, puede cargar artefactos en él. Estos artefactos son una recopilación de archivos de texto, binarios y manifiestos de despliegue que se entregan al entorno de despliegue de destino. Cada artefacto tiene un nombre, que está hecho de su ruta de acceso: versión. La ruta es una cadena para organizar los artefactos.
-
Servicios de registro y notificación de OCI
El servicio de registro de OCI almacena logs relacionados con el despliegue. La salida de tiempo de ejecución de despliegue y los resultados finales del despliegue se muestran como entradas de log. El servicio OCI Notifications proporciona visibilidad del estado más reciente del proyecto de despliegue y sus recursos y toma cualquier acción necesaria. Por ejemplo, se le notifica cuando un evento importante, como una etapa en un pipeline de despliegue en espera de aprobación. Cuando reciba el mensaje de notificación, puede ir a pipelines de despliegue DevOps y aprobar la etapa.
-
entornos de despliegue
Un entorno es una recopilación de recursos informáticos de un cliente en los que se despliegan artefactos. Los entornos pueden ser una función, una máquina virtual de Compute (VM) o una instancia con hardware dedicado, o un cluster de OKE. El despliegue de Blue Green solo está disponible con las máquinas virtuales de cluster de OKE y Compute.
Comprender las ventajas y el uso de despliegues en azul verde
Tanto las ventajas como las desventajas del uso de una estrategia azul verdosa al desplegar una aplicación moderna.
- Los despliegues de Blue Green permiten despliegues rápidos y sin riesgos.
- Hacen lo posible con un mecanismo de reversión simple eficaz.
- Son una forma eficaz de organizar pruebas de software A/B.
- Tiempo de inactividad cero o casi cero, ya que la producción siempre se ofrece a través de uno de los entornos activos (encontrar un equilibrador de carga).
- El mantenimiento del entorno de un despliegue Blue-Green requiere un costo elevado de entornos y recursos idénticos.
- Debe supervisar estrechamente ambos entornos para gestionar la versión entre dos entornos idénticos.
- La gestión de dependencias de base de datos entre despliegues es complicada.
Acerca de los despliegues canarios
Con una estrategia de despliegue Canary, la versión de la aplicación se produce incrementalmente en un subjuego de usuarios. Inicialmente, la nueva versión se despliega en un entorno canario sin tráfico de usuario. El pipeline de la versión DevOps puede ejecutar pruebas de validación con la nueva versión y, una vez listo, enrutar solo un subjuego de usuarios al entorno canario. .
Esta técnica permite al equipo DevOps evaluar la nueva versión de la aplicación con respecto al tráfico de usuario real. Pueden comparar las dos versiones de la aplicación en paralelo antes de desplegar la nueva versión en una base de usuarios más grande. También ofrece mitigación de riesgos, ya que la nueva versión solo está activada para un pequeño subconjunto de usuarios; estos usuarios pueden volver fácilmente a la versión anterior en caso de que se produzcan problemas.
El siguiente diagrama ilustra una estrategia de despliegue de Canary:
Descripción de los componentes de despliegue canario
La arquitectura anterior tiene los siguientes componentes.
-
Región
Una región de OCI es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones y las grandes distancias pueden separarse (entre países e incluso continentes). La arquitectura utiliza una sola región.
-
Proyecto de DevOps
Agrupación lógica de recursos de DevOps necesarios para implantar un flujo de trabajo de integración y despliegue continuos. Los recursos de DevOps pueden ser artefactos, pipelines de compilación, pipelines de despliegue, conexiones externas, disparadores y entornos. Los proyectos DevOps facilitan el registro, la supervisión y las notificaciones de todos los recursos DevOps.
-
Crear pipeline
Un pipeline de compilación toma un ID de confirmación de los repositorios de código fuente y utiliza ese código fuente para ejecutar las instrucciones de compilación. Los pipelines de compilación definen un juego de etapas para el proceso de compilación, lo que permite crear, probar y compilar artefactos de software, entregar artefactos a los repositorios de OCI y, opcionalmente, disparar un despliegue. El flujo y las instrucciones de la ejecución de creación se definen en el archivo de especificaciones de creación.
-
Etapas de creación
Las etapas son acciones individuales que tienen lugar durante una ejecución de un pipeline. Varias etapas de creación mencionadas aquí son:- Etapas de creación gestionadas: etapa de creación gestionada para crear y probar el código de origen.
- Etapa de entrega de artefactos: etapa para transferir las salidas de la etapa de creación a varios repositorios. Al igual que las imágenes de contenedor para el repositorio de contenedor y el manifiesto de despliegue en el registro de artefactos.
- Llamar a despliegue: etapa para llamar a un pipeline de despliegue una vez finalizadas las etapas de creación, junto con el análisis de las variables exportadas desde la etapa de creación gestionada hasta las etapas del pipeline de despliegue.
-
Repositorio de código
Repositorios de Git privados alojados por el servicio DevOps. Puede almacenar, gestionar y desarrollar código fuente con nuestros repositorios de código DevOps.
-
Pipeline de despliegue
Secuencia de pasos para entregar y desplegar un juego de artefactos en un entorno de destino. El flujo y la lógica de la versión de software se pueden controlar definiendo etapas que se pueden ejecutar en serie o en paralelo.
-
Etapas de despliegue
Las etapas son acciones individuales que se realizan durante una ejecución de un pipeline. Varias etapas de construcción mencionadas aquí son:- Despliegue de OKE de Canadá o Despliegue de grupo de instancias de Canadá: ubicación temporal para desplegar el código actualizado en entornos canarios de destino.
- Validación de despliegue: etapa opcional para validar los despliegues (funciones de AV)
- Turno de tráfico de OKE de Canadá o Turno de tráfico de grupo de instancias de Canadá: etapa para cambiar el tráfico al entorno canario en función del límite de rampa (% de tráfico a turno).
- Control: Aprobación: etapa de control para aprobar el despliegue en el entorno de producción de destino.
- Canary Deploy Instance Group Production o OKE Deploy Production: etapa final en la que el tráfico de producción se cambiará al último entorno desplegado.
-
Artefacto DevOps
Un artefacto DevOps es una referencia o puntero a cualquier archivo, binario, paquete, manifiesto o imagen que constituya la aplicación. Al crear un artefacto, informe a Oracle DevOps de la ubicación de origen del artefacto real. DevOps soporta los repositorios OCI Container Image Registry y OCI Artifact Registry.
-
Repositorio de artefactos
El repositorio de artefactos crea repositorios para agrupar artefactos similares. Cuando se crea el repositorio, puede cargar artefactos en él. Estos artefactos son una recopilación de archivos de texto, binarios y manifiestos de despliegue que se entregan al entorno de despliegue de destino. Cada artefacto tiene un nombre, que está hecho de su ruta de acceso: versión. La ruta es una cadena para organizar los artefactos.
-
Servicios de registro y notificación de OCI
El servicio de registro de OCI almacena logs relacionados con el despliegue. La salida de tiempo de ejecución de despliegue y los resultados finales del despliegue se muestran como entradas de log. El servicio OCI Notifications proporciona visibilidad del estado más reciente del proyecto de despliegue y sus recursos y toma cualquier acción necesaria. Por ejemplo, se le notifica cuando un evento importante, como una etapa en un pipeline de despliegue en espera de aprobación. Cuando reciba el mensaje de notificación, puede ir a pipelines de despliegue DevOps y aprobar la etapa.
-
Entornos de despliegue
Un entorno es una recopilación de recursos informáticos de un cliente en los que se despliegan artefactos. Los entornos pueden ser una función, una máquina virtual de Compute (VM) o una instancia con hardware dedicado, o un cluster de OKE. El despliegue de Blue Green solo está disponible con las máquinas virtuales de cluster de OKE y Compute.
Descripción de las ventajas y desventajas de los despliegues canarios
Existen ventajas y desventajas al utilizar una estrategia Canary al desplegar una aplicación moderna.
- Permite probar dos versiones de aplicación en paralelo con usuarios reales.
- No hay tiempo de inactividad para la nueva versión.
- El rollback a una versión anterior es muy sencillo y proporciona el menor riesgo.
- Las pruebas y la validación de la nueva versión pueden ser complejas a escala.
- Recuperar los comentarios de las pruebas de usuario de una nueva versión es una tarea laboriosa.