Consideraciones de implementación para DevOps
A medida que aprovisiona y actualiza los recursos de Azure, el código de aplicación y las opciones de configuración, un proceso repetible y predecible le ayudará a evitar errores y tiempos de inactividad. Se recomienda el uso de procesos automatizados para la implementación, que se puedan ejecutar a petición y volver a ejecutar en caso de que se produzca algún error. Después de que los procesos de implementación se ejecuten sin incidencias, la documentación del proceso puede mantenerlos de este modo.
Automation
Asegúrese de automatizar las implementaciones y las actualizaciones para activar los recursos a petición, implementar las soluciones rápidamente, minimizar los errores humanos y generar resultados coherentes y repetibles.
Automatización de tantos procesos como sea posible
Los procesos de implementación más confiables son automáticos e idempotentes, es decir, repetibles para generar los mismos resultados.
- Para automatizar el aprovisionamiento de recursos de Azure, puede usar Terraform, Ansible, Chef, Puppet, Azure PowerShell, la CLI de Azure o plantillas de Azure Resource Manager.
- Para configurar VM, puede usar cloud-init (para VM Linux) o Azure Automation State Configuration (DSC).
- Para automatizar la implementación de la aplicación, puede usarAzure DevOps Services, Jenkins u otras soluciones de CI/CD.
Como procedimiento recomendado, cree un repositorio de scripts de automatización por categorías para un acceso rápido, documentado con explicaciones de los parámetros y ejemplos del uso de los scripts. Mantenga esta documentación sincronizada con las implementaciones de Azure y designe una persona responsable de la administración del repositorio.
Los scripts de automatización también pueden activar recursos a petición para la recuperación ante desastres.
Automatización y prueba de la implementación y tareas de mantenimiento
Las aplicaciones distribuidas constan de varias partes que deben funcionar en conjunto. La implementación debe aprovechar las ventajas de los mecanismos probados, como los scripts, que pueden actualizar y validar la configuración y automatizar el proceso de implementación. Pruebe todos los procesos por completo para asegurarse de que los errores no provocan tiempo de inactividad adicional.
Implementación de medidas de seguridad en la implementación
Todas las herramientas de implementación deben incorporar restricciones de seguridad para proteger la aplicación implementada. Defina y aplique cuidadosamente las directivas de implementación y minimice la necesidad de intervención humana.
Proceso de lanzamiento
Uno de los desafíos de la automatización de la implementación es la propia migración, con el traslado del software desde la fase final de pruebas al entorno de producción en vivo. Normalmente es necesario hacer esto rápidamente con el fin de minimizar el tiempo de inactividad. El enfoque de implementación Blue-Green lo lleva a cabo asegurándose de que tiene dos entornos de producción, lo más idénticos posible.
Documentación del proceso de lanzamiento
Sin una documentación detallada del proceso de lanzamiento, un operador podría implementar una actualización incorrecta o configurar de manera incorrecta la configuración de la aplicación. Defina y documente claramente el proceso de lanzamiento y asegúrese de que esté disponible para todo el equipo de operaciones.
Implementación por fases de las cargas de trabajo
La implementación en varias fases y la ejecución de pruebas y validaciones en cada fase antes de pasar a la siguiente garantizan una implementación en producción sin incidencias.
Con un buen uso de los entornos de ensayo y producción, puede insertar actualizaciones en el entorno de producción de una manera muy controlada y minimizar la interrupción de problemas de implementación imprevistos.
- La implementación azul-verdeimplica la implementación de una actualización en un entorno de producción independiente de la aplicación activa. Después de validar la implementación, cambie el enrutamiento de tráfico a la versión actualizada. Una manera de hacerlo es usar los espacios de ensayo disponibles en Azure App Service para almacenar provisionalmente una implementación antes de pasarla a producción.
- Los lanzamientos controlados son similares a las implementaciones azul-verde. En lugar de cambiar todo el tráfico a la aplicación actualizada, solo se enruta una pequeña parte del tráfico a la nueva implementación. Si hay un problema, se revierte a la implementación anterior. Si no lo hay, se enruta gradualmente más tráfico a la nueva versión. Si utiliza Azure App Service, puede usar la característica Testing in production para administrar un lanzamiento controlado.
Entornos de prueba
Si los entornos de desarrollo y prueba son distintos del de producción, es difícil probar y diagnosticar problemas. Por consiguiente, los entornos de desarrollo y prueba deben parecerse tanto como sea posible al de producción. Asegúrese de que los datos de prueba sean coherentes con los datos que se usan en producción, aunque sean datos de ejemplo, no datos de producción real (por motivos de privacidad o de cumplimiento). Planee la generación y anonimización de datos de prueba de ejemplo.
Registro y auditoría
Implemente una estrategia de registro robusta para capturar tanta información específica de la versión como sea posible. Si utiliza técnicas de implementación por etapas, habrá más de una versión de la aplicación en ejecución en producción. Si se produce un problema, determine qué versión lo está produciendo.
Consideraciones sobre la alta disponibilidad
Si la aplicación depende de una única instancia de un servicio, crea un único punto de error. Aprovisione varias instancias para mejorar la resistencia y la escalabilidad.
- Para Azure App Service, seleccione un Plan de App Service que ofrezca varias instancias.
- En el caso de Azure Cloud Services, configure cada uno de los roles para utilizar varias instancias.
- En el caso de Azure Virtual Machines, asegúrese de que la arquitectura de las máquinas virtuales incluye más de una máquina virtual y de que cada una de ellas se incluye en un conjunto de disponibilidad.
Consideraciones sobre la implementación en varias regiones
Se recomienda implementar en varias regiones todas las aplicaciones y servicios de aplicación a excepción de los menos críticos. Si su aplicación se implementa en una sola región, en el caso excepcional de que toda la región no esté disponible, la aplicación tampoco estará disponible. Si decide realizar la implementación en una sola región, considere la posibilidad de preparar una nueva implementación en una región secundaria como respuesta a un error inesperado.
Nueva implementación en una región secundaria
Si ejecuta aplicaciones y bases de datos en una única región principal sin replicación, la estrategia de recuperación podría ser volver a implementar en otra región. Esta solución es asequible pero más adecuada para las aplicaciones no críticas que pueden tolerar tiempos de recuperación más largos. Si elige esta estrategia, automatice el proceso de una nueva implementación tanto como sea posible e incluya escenarios con una nueva implementación en las pruebas de respuesta ante desastres.
Para automatizar el proceso de volver a implementar, considere la posibilidad de usar Azure Site Recovery.