Ranuras de implementación e intercambio

Las ranuras de implementación son entornos activos y separados para una aplicación web de App Service, cada uno con su propio nombre de host (por ejemplo, myapp-staging.azurewebsites.net). Las ranuras comparten el mismo plan y los mismos recursos de App Service que la ranura de producción, pero se ejecutan de forma independiente. Permiten realizar despliegues blue-green: puede validar una nueva versión en una ranura de staging y después intercambiarla con la de producción sin tiempo de inactividad. Las ranuras están disponibles a partir del nivel Standard.

Añada una nueva ranura de implementación a su aplicación web mediante Azure Portal o la CLI. Cada ranura obtiene su propia URL, configuración de la aplicación y cadenas de conexión. Puede crear hasta 5 ranuras en Standard y hasta 20 ranuras en el nivel Premium. Entre los nombres habituales de las ranuras se incluyen staging, canary, hotfix e integration, que reflejan las distintas etapas de la canalización de lanzamiento.

Antes de realizar el intercambio, es fundamental preparar la ranura de staging para que la nueva versión se inicialice por completo. Una instancia de App Service en frío responde lentamente a las primeras solicitudes mientras se inicializa el entorno de ejecución, algo inaceptable en producción. Habilite Auto Swap o envíe manualmente solicitudes HTTP de preparación a la ranura de staging. App Service también admite una configuración applicationInitialization para definir rutas de preparación que deben devolver 200 antes de considerar que la ranura está lista.

Un intercambio cambia de forma atómica las ranuras de staging y producción. Durante un intercambio, App Service dirige primero el tráfico a las instancias de staging que ejecutan el código nuevo, espera a que se inicialicen y, después, redirige todo el tráfico de producción a las nuevas instancias; las instancias de producción anteriores se convierten en la nueva ranura de staging. Esto simplifica enormemente la reversión: basta con realizar otro intercambio.

La configuración de la aplicación se puede marcar como específica de la ranura o no específica de la ranura (intercambiable). La configuración no específica de la ranura se desplaza con la ranura de implementación al realizar un intercambio; por tanto, la cadena de conexión de la base de datos de staging sigue al código hasta producción. La configuración específica de la ranura permanece asociada a la ranura independientemente de los intercambios; así, producción conserva siempre su cadena de conexión de la base de datos de producción. Marque la configuración como específica de la ranura mediante la casilla «deployment slot setting» o la CLI.

App Service admite la división del tráfico: puede dirigir un porcentaje del tráfico de producción a una ranura que no sea de producción sin realizar un intercambio completo. Esto permite realizar lanzamientos canary, en los que se desplaza gradualmente el tráfico del 5 % al 10 % y después al 50 % a medida que aumenta su confianza en la nueva versión, supervisando las tasas de error en cada paso. Los usuarios que acceden a la ranura canary reciben una cookie persistente que los mantiene en la misma versión para conservar la coherencia de la sesión.

Auto Swap intercambia automáticamente una ranura de staging con la de producción cada vez que se implementa código nuevo en ella. Es ideal para canalizaciones de CI/CD en las que desea que cada implementación correcta pase inmediatamente a producción. Auto Swap espera a que las solicitudes HTTP de la ranura de staging devuelvan 200 antes de completar el intercambio. Habilítelo por ranura en Azure Portal o mediante la CLI, pero úselo con precaución, ya que no existe una etapa de aprobación manual entre la implementación y producción.

Siga estas prácticas recomendadas para las ranuras de implementación: valide siempre en staging antes de realizar el intercambio con producción; use configuración específica de la ranura para mantener aisladas las conexiones de producción a la base de datos de las de staging; ejecute pruebas de humo en la URL de la ranura de staging después de la implementación; configure rutas de comprobación de estado para garantizar que App Service no complete el intercambio si la nueva versión no funciona correctamente; y etiquete las implementaciones para poder rastrear qué commit está activo en cada ranura.

En una canalización de CI/CD habitual, la etapa de compilación compila y prueba el código, la etapa de implementación inserta el artefacto en la ranura de staging, una etapa de pruebas de integración ejecuta pruebas automatizadas en la URL de staging y la etapa de intercambio intercambia staging con producción, opcionalmente con una aprobación manual. Este patrón es compatible de forma nativa tanto con Azure Pipelines como con GitHub Actions mediante la acción de implementación de App Service.

Durante y después de un intercambio de ranuras, supervise las métricas clave en Azure Monitor para confirmar que la nueva versión funciona correctamente. Preste atención a los picos de errores HTTP 5xx, el tiempo medio de respuesta y la utilización de CPU/memoria. Configure alertas de métricas que se activen si las tasas de error superan un umbral; esto le proporcionará una señal para revertir rápidamente el intercambio. La detección inteligente de Application Insights puede alertarle automáticamente de anomalías después de una implementación.

Las ranuras de implementación son preferibles a mantener aplicaciones de App Service completamente independientes para staging y producción, ya que comparten el mismo plan (sin coste adicional), permiten realizar intercambios con reversión con un solo clic, admiten la división del tráfico y se administran dentro del mismo recurso de App Service. Use aplicaciones independientes únicamente cuando staging necesite SKU de planes fundamentalmente diferentes, requisitos de aislamiento o una facturación completamente separada.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que las ranuras de implementación proporcionan entornos aislados que permiten realizar despliegues blue-green; la configuración específica de la ranura mantiene la configuración específica del entorno, como las URL de bases de datos, asociada a la ranura y no al código; y la división del tráfico permite realizar lanzamientos canary dirigiendo un porcentaje del tráfico de producción a una nueva versión. A continuación, exploraremos el autoescalado y los dominios personalizados.