Estrategias de actualización de sitios en Flex Consumption

Al hospedar la aplicación con Azure Functions en el plan de consumo Flex, puede controlar cómo se implementan las actualizaciones en las instancias en ejecución. Una actualización del sitio se produce siempre que implemente código, modifique la configuración de la aplicación o cambie otras propiedades de configuración. El plan de consumo flexible proporciona una configuración (SiteUpdateStrategy) que puede usar para controlar si la aplicación de funciones experimenta tiempo de inactividad durante estas actualizaciones y cómo se controlan las ejecuciones en curso.

Actualmente, el plan flex Consumption admite estas estrategias de actualización:

• Volver a crear: reinicia todas las instancias en ejecución después de actualizar la aplicación con los cambios más recientes. Este enfoque puede provocar un breve tiempo de inactividad mientras las instancias se reciclan y conservan el comportamiento predeterminado de otros planes de hospedaje de Azure Functions.
• Actualización continua: Proporciona implementaciones sin tiempo de inactividad retirando y reemplazando instancias por lotes. Las ejecuciones en curso se completan de forma natural sin terminación forzada.

Comparación de estrategias

En esta tabla se comparan las dos estrategias de actualización del sitio:

Actualizar comportamientos de estrategia

En esta tabla se compara el proceso de actualización de las dos estrategias:

En esta tabla se comparan las características clave de las dos estrategias:

Consideraciones sobre la estrategia de actualización gradual

Tenga en cuenta estos comportamientos y limitaciones actuales al usar la estrategia de actualización gradual.

• Parámetros administrados por la plataforma: la plataforma controla los parámetros (como el recuento de lotes, las instancias por lote, el número de lotes y los intervalos de purga) que determinan los comportamientos de actualización gradual. Estos parámetros pueden cambiar para optimizar el rendimiento y la confiabilidad.
• El cambio de estrategia no es operativo en las regiones de disponibilidad general: en las regiones donde las actualizaciones graduales están disponibles de forma general, el cambio de siteUpdateStrategy.type no desencadena por sí mismo una actualización del sitio. Puede actualizar de forma segura la estrategia con antelación y aplicarla a la siguiente implementación de código o configuración. En las regiones en las que las actualizaciones progresivas todavía se están desplegando, cambiar la estrategia se trata como cualquier otro cambio de configuración y desencadena una actualización del sitio que utiliza la estrategia anterior; la nueva estrategia se aplica a partir de la siguiente implementación.
• No hay supervisión en tiempo real: actualmente no hay visibilidad del número de instancias que se están purgando, cuántos lotes permanecen o porcentajes de progreso actuales.
• Sin embargo, no hay ninguna señal de finalización: sin embargo, puede supervisar los registros de instancia para calcular cuándo se completa una actualización.
• Escenarios de instancia única: las aplicaciones que se ejecutan en una instancia experimentan un breve tiempo de inactividad similar a la acción de recrear, aunque las ejecuciones en curso continúan hasta completarse.
• Durable Functions: dado que la combinación de versiones durante las actualizaciones puede provocar un comportamiento inesperado en una orquestación duradera, use una estrategia de coincidencia de versión de orquestación explícita.
• Infraestructura como código: la implementación de cambios de código y configuración desencadena varias actualizaciones graduales que pueden superponerse.
• Compatibilidad con versiones anteriores: asegúrese de que los cambios funcionan con la versión anterior durante el período de transición de actualización gradual.

Configuración de la estrategia de actualización

Puede establecer la estrategia de actualización de la aplicación mediante la configuración del sitio SiteUpdateStrategy, que es un elemento secundario de functionAppConfig. De forma predeterminada, SiteUpdateStrategy.type se establece en Recreate. Puede configurar esta opción mediante CLI de Azure 2.87.0 o posterior, Bicep o plantillas de ARM con la versión de API 2023-12-01 o posterior.

az functionapp update-strategy config set \
  --name MyFunctionApp \
  --resource-group MyResourceGroup \
  --type RollingUpdate

functionAppConfig: {
  ...
  siteUpdateStrategy: {
    type: 'RollingUpdate'
  }
  ...
}

"functionAppConfig": {
  ...
  "siteUpdateStrategy": {
    "type": "RollingUpdate"
  }
  ...
}

Supervisión de actualizaciones del sitio

No hay ningún indicador integrado de finalización para las actualizaciones del sitio web. Puede usar consultas KQL en Application Insights como un enfoque de mejor esfuerzo para calcular el progreso gradual de la actualización.

Supervisar el progreso de la actualización gradual

Estas consultas de KQL proporcionan una estimación del mejor esfuerzo del progreso de la actualización gradual mediante el seguimiento de la rotación de instancias en los registros de Application Insights. Este enfoque tiene limitaciones significativas y no debe basarse en la automatización de producción:

// Rolling update completion check
let deploymentStart = datetime('2025-10-30T19:00:00Z'); // Set to your deployment start time
let checkInterval = 10s; // How often you run this query
let buffer = 30s; // Safety buffer for instance detection
//
// Get original instances (active before deployment)
let originalInstances = 
    traces
    | where timestamp between ((deploymentStart - buffer) .. deploymentStart)
    | where cloud_RoleInstance != ""
    | summarize by InstanceId = cloud_RoleInstance;
//
// Get currently active instances
let currentInstances = 
    traces
    | where timestamp >= now() - checkInterval
    | where cloud_RoleInstance != ""
    | summarize by InstanceId = cloud_RoleInstance;
//
// Check completion status
currentInstances
| join kind=leftouter (originalInstances | extend IsOriginal = true) on InstanceId
| extend IsOriginal = isnotnull(IsOriginal)
| summarize 
    OriginalStillActiveInstances = make_set_if(InstanceId, IsOriginal),
    NewInstances = make_set_if(InstanceId, not(IsOriginal)),
    OriginalStillActiveCount = countif(IsOriginal),
    NewCount = countif(not(IsOriginal)),
    TotalOriginal = toscalar(originalInstances | count)
| extend 
    RollingUpdateComplete = iff(OriginalStillActiveCount == 0, "YES", "NO"),
    PercentComplete = round(100.0 * (1.0 - todouble(OriginalStillActiveCount) / todouble(TotalOriginal)), 1)
| project RollingUpdateComplete, PercentComplete, OriginalStillActiveCount, NewCount

Cómo usar esta consulta para la estimación:

1. Pegue esta consulta en el panel de Registros del recurso de Application Insights asociado a la aplicación de funciones.
2. Establezca deploymentStart en la marca de tiempo cuando la actualización del sitio sea exitosa.
3. Ejecute la consulta periódicamente para calcular el progreso. Establezca el intervalo de sondeo sea al menos tan largo como el tiempo medio de ejecución de la función y asegúrese de que la variable de la consulta checkInterval coincida con esta frecuencia de sondeo.
4. La consulta devuelve valores aproximados:

RollingUpdateComplete: mejor estimación de si se reemplazanPercentComplete todas las instancias originales: porcentaje estimado de instancias originales que se reemplazanOriginalStillActiveCount: Número estimado de instancias originales que siguen en ejecuciónNewCount: Número de nuevas instancias actualmente activas.

Tenga en cuenta estas limitaciones al usar estas consultas:

1. Intervalo de tiempo: el deploymentStart tiempo representa cuándo la actualización del sitio devuelve éxito, pero es posible que la actualización gradual real no se inicie inmediatamente. Durante este intervalo, los eventos de escalado horizontal aprovisionan instancias que ejecutan la versión original. Dado que la consulta solo realiza un seguimiento de las instancias activas en deploymentStart, no supervisa estas nuevas instancias de versión original, lo que podría provocar señales de finalización falsas.
2. Detección basada en registros: este enfoque se basa en los registros de aplicación para deducir el estado de la instancia en lugar de consultar directamente el estado de la instancia. Es posible que las instancias se ejecuten pero no se registren activamente, lo que conduce a señales de finalización falsas cuando las instancias originales siguen activas, pero no emitieron registros dentro de la checkInterval ventana.

Recomendación para producción: use actualizaciones graduales cuando las implementaciones de tiempo de inactividad cero sean críticas. Asegúrese de que las canalizaciones de implementación no requieren esperar la finalización de la actualización antes de continuar con los pasos posteriores. Utilice "volver a crear" cuando necesite una actualización más rápida y predecible y pueda tolerar un breve tiempo de inactividad.

Preguntas más frecuentes

Estoy acostumbrado a los entornos de implementación para despliegues sin tiempo de inactividad. ¿Cómo difieren las actualizaciones graduales?

• A diferencia de los slots de implementación, las actualizaciones graduales no requieren infraestructura adicional. Configura siteUpdateStrategy.type como "RollingUpdate" para implementaciones sin tiempo de inactividad.
• Las actualizaciones graduales conservan las ejecuciones en curso, mientras que las ranuras de implementación las finalizan durante los intercambios. Algunas propiedades del sitio y la configuración persistente no pueden cambiarse y es necesario modificar el entorno de producción directamente.
• A diferencia de las ranuras de implementación, las actualizaciones graduales no proporcionan un entorno independiente para realizar pruebas de canario ni permiten enrutar un porcentaje del tráfico en vivo. Si necesita estas características, use un plan que admita ranuras de implementación, como Elastic Premium, o administre aplicaciones independientes de Flex Consumption detrás de un administrador de tráfico.

¿Cómo revierto una actualización del sitio?

• Actualmente no hay ninguna característica para revertir una actualización del sitio. Si es necesario realizar una reversión, inicie otra actualización del sitio con el estado anterior del código o la configuración.

¿Cómo se controlan los desencadenadores de temporizador?

• Los desencadenadores de temporizador mantienen su naturaleza de única instancia (singleton). Una vez que se marca una aplicación de función activada por temporizador para purgar, las nuevas funciones del temporizador se ejecutan en su versión más reciente.

Veo errores en tiempo de ejecución durante la actualización gradual... ¿qué salió mal?

• Si las nuevas instancias no se inician o detectan errores en tiempo de ejecución, es probable que el problema se encuentre en el código de la aplicación, las dependencias, las opciones de configuración o las variables de entorno que modificó.
• Para resolver el problema, vuelva a implementar la última versión correcta conocida para restaurar el tiempo de ejecución. A continuación, pruebe los cambios propuestos en un entorno de desarrollo o ensayo antes de volver a intentarlo. Revise los registros de errores para identificar qué cambio específico provocó el problema.

Pasos siguientes

• Más información sobre el plan de consumo flexible
• Más información sobre cómo difieren las implementaciones en Flex Consumption
• Aprenda a escribir plantillas de infraestructura como código