Comprenda las estrategias modernas de despliegue de aplicaciones con Oracle Cloud Infrastructure DevOps
La entrega rápida de software es esencial para ejecutar de forma eficaz sus aplicaciones en la nube. El servicio Oracle DevOps proporciona una plataforma de integración y despliegue continuos (CI/CD) para desarrolladores que puede utilizar para crear, probar y desplegar fácilmente software y aplicaciones en Oracle Cloud.
DevOps Los pipelines de creación y despliegue reducen los errores controlados por cambios y disminuyen el tiempo que los clientes invierten en la creación y el despliegue de versiones. El servicio también proporciona repositorios de Git privados para almacenar su código y soporta conexiones a repositorios de código externos. Tanto si migra cargas de trabajo a OCI (desde ubicaciones locales u otras nubes) como si desarrolla nuevas aplicaciones en OCI, puede utilizar el servicio DevOps para simplificar el ciclo de vida de entrega de software.
Arquitectura
En estas arquitecturas de referencia se describen dos estrategias de despliegue diferentes: la estrategia azul-verde y la estrategia canaria.
Las estrategias de despliegue son modelos y prácticas que permiten modificar o actualizar la aplicación. Permiten a los equipos de 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. Las estrategias presentadas aquí ofrecen a los clientes más opciones para lograr la compensación adecuada, en función de sus necesidades de aplicación.
Despliegue Blue-Green
Una estrategia de despliegue Blue-Green permite a los equipos de DevOps publicar 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. Si surgen problemas con la nueva versión, el tráfico puede volver al instante a la versión estable anterior. Además, el entorno en espera está disponible para depurar problemas con la versión de la aplicación.
- Permite despliegues rápidos y sin riesgos.
- Ofrece un mecanismo de rollback eficaz y sencillo.
- Es una forma eficaz de organizar pruebas de software A/B.
- Requiere poco o ningún tiempo de inactividad, ya que la producción siempre es servida por uno de los entornos activos (controlado por un equilibrador de carga).
- Ejecutar entornos idénticos es caro y el mantenimiento requiere muchos recursos.
- Al gestionar una versión entre dos entornos idénticos, debe supervisar de cerca ambos entornos.
- La gestión de dependencias de base de datos entre despliegues puede ser complicada.
En este diagrama se muestra una arquitectura de despliegue azul-verde:
Descripción de la ilustración blue-green-deployment.png
Despliegue de Canarias
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 si surgen problemas.
- Puede probar dos versiones de aplicaciones en paralelo con usuarios reales.
- Sin tiempo de inactividad para las nuevas versiones.
- La reversión a una versión anterior es muy fácil y conlleva el menor riesgo.
- La prueba y validación de una nueva versión a escala puede ser compleja.
- La recuperación de los comentarios de las pruebas de usuario en una nueva versión requiere mucho tiempo.
El siguiente diagrama ilustra una estrategia de despliegue de Canary:
Descripción de la ilustración canary-deployment.png
- 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 DevOps necesarios para implementar 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ónLas etapas son acciones individuales que se realizan durante una ejecución de pipeline. Varias etapas de construcció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; por ejemplo, imágenes de contenedor al repositorio de contenedor o el 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 estos 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. Las etapas de creación de los despliegues Blue-Green son:
- Despliegue de OKE azul/verde o despliegue de grupo de instancias azul/verde: etapa en la que despliega el código actualizado en entornos de destino.
- Validación de despliegue: etapa opcional en la que puede utilizar Functions para validar los despliegues.
- 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 cambia al último entorno desplegado.
- Despliegue de OKE de Canadá o Despliegue de grupo de instancias de Canadá: etapa en la que despliega el código actualizado en entornos de destino.
- Validación de despliegue: etapa opcional en la que puede utilizar Functions para validar los despliegues.
- Turno de tráfico de OKE de Canadá o Turno de tráfico de grupo de instancias de Canadá: etapa en la que, según el límite de rampa (% del tráfico que se va a desplazar), cambia el tráfico hacia el entorno canario.
- 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 cambia 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. Una vez creados, puede cargar artefactos en este repositorio. 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
Este entorno es una recopilación de los recursos informáticos en los que se despliegan artefactos. Los entornos pueden ser una función, una máquina virtual informática (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.
Recomendaciones
- Unidades informáticas
Esta arquitectura utiliza una imagen del sistema operativo Oracle Linux con una unidad flexible E3 o E4 con recursos mínimos para alojar hosts informáticos en los nodos de cluster de OKE. Si la aplicación necesita más memoria o núcleos, puede elegir una unidad diferente.
- VCN
Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque según el número de recursos que planea asociar a subredes en la VCN. Utilice bloques CIDR que estén dentro del espacio de dirección IP privada estándar. Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR. Esta arquitectura utiliza una VCN pública para alojar Oracle Container Engine for Kubernetes. También puede utilizar una VCN privada. En ese caso, utilice un gateway de NAT para otorgar acceso al cluster a través de la red pública de Internet.
- Oracle Container Engine for Kubernetes (HORAS)
Esta arquitectura se despliega en el cluster de OKE como uno de los entornos de destino. Los nodos de trabajador se despliegan en un sistema operativo Oracle Linux E3 o E4. Esta arquitectura utiliza tres nodos de trabajador en el cluster, pero puede crear hasta 1.000 nodos en cada cluster.
- Grupo de instancias
Si selecciona esta arquitectura para desplegar en un grupo de instancias, se crean nuevas instancias informáticas con la unidad que elija en su arrendamiento.
- Registro de imágenes de contenedor
Esta arquitectura despliega Registry como registro privado de Docker para uso interno. Las imágenes de Docker se transfieren al registro y se extraen del mismo. También puede utilizar Registry como registro público de Docker, lo que permite a cualquier usuario con acceso a Internet y conocimiento de la URL correspondiente extraer imágenes de repositorios públicos en Oracle Cloud.
- Registro de artefactos
Esta arquitectura crea un artefacto para el software y la configuración utilizados por un despliegue de grupo de instancias, OKE y Functions. La arquitectura crea un repositorio de registro de artefactos para uso interno. Los binarios de software, las configuraciones de texto y despliegue se cargan y descargan desde el repositorio de registro de artefactos.
Consideraciones
Al utilizar el servicio DevOps de Oracle para desplegar una plataforma de despliegue e integración continuas (CI/CD), tenga en cuenta estos factores.
- Despliegues soportados por DevOps
DevOps soporta despliegues en OKE, hosts informáticos y funciones. Esta arquitectura se despliega en un cluster de OKE. Considere el despliegue en otros puntos finales en función de sus requisitos específicos.
- Soporte de Linux
Solo están soportados los hosts de Linux para despliegues de grupos de instancias en instancias informáticas.
- artefactos desplegados
Los artefactos que desplegar con DevOps deben estar en un registro de artefactos de OCI o en un repositorio de registro de imágenes de contenedor.
- Agrupación de aplicaciones
Como mejor práctica, agrupe cada aplicación y todos sus microservicios en un solo proyecto.
Despliegue
El código de Terraform de esta arquitectura de referencia está disponible como una pila de ejemplo en Oracle Cloud Infrastructure Resource Manager. También puede descargar el código desde GitHub y personalizarlo para adaptarlo a sus necesidades específicas.
- Realice el despliegue con la pila de ejemplo en Oracle Cloud Infrastructure Resource Manager:
- Haga clic en el botón que corresponde a la estrategia de despliegue deseada y, a continuación, siga las instrucciones de los pasos 2 a 6:
Para... Haga clic... Instancias canarias 
Canary OKE Instancias azules-verdes OKE verde azul Si aún no ha iniciado sesión, introduzca el arrendamiento y las credenciales de usuario.
- Seleccione la región en la que desea desplegar la pila.
- Siga las indicaciones en pantalla e instrucciones para crear la pila.
- Después de crear la pila, haga clic en Acciones de Terraform y seleccione Plan.
- Espere a que se complete el trabajo y revise el plan.
Para realizar cambios, vuelva a la página Detalles de pila, haga clic en Editar pila y realice los cambios necesarios. A continuación, vuelva a ejecutar la acción Plan.
- Si no es necesario realizar más cambios, vuelva a la página Detalles de pila, haga clic en Acciones de Terraform y seleccione Aplicar.
- Haga clic en el botón que corresponde a la estrategia de despliegue deseada y, a continuación, siga las instrucciones de los pasos 2 a 6:
- Desplegar con el código de Terraform en GitHub:
- Vaya a GitHub.
- Clone o descargue el repositorio en su equipo local.
- Siga las instrucciones del documento
README.