Despliegue sin tiempo de inactividad para Durable Functions

El modelo de ejecución reliable de Durable Functions requiere que las orquestaciones sean deterministas, lo que crea un desafío al implementar actualizaciones. Cuando una implementación contiene cambios importantes (como firmas de función de actividad modificadas o lógica de orquestador modificada), se produce un error en las instancias de orquestación en curso. Esta situación es especialmente un problema para las orquestaciones de larga duración, que podrían representar horas o días de trabajo.

En la tabla siguiente se comparan cuatro estrategias para lograr la implementación sin tiempo de inactividad. Elija la estrategia que mejor se adapte a la carga de trabajo:

Control de versiones de orquestación

La característica de versionado de orquestación es la estrategia recomendada para las implementaciones sin interrupciones con cambios importantes. Permite que diferentes versiones de orquestaciones coexistan y se ejecuten simultáneamente sin conflictos.

Con control de versiones de orquestación:

• Cada instancia de orquestación recibe una versión que se le asocia de manera permanente en el momento de su creación.
• Los trabajadores que ejecutan versiones más recientes del orquestador pueden seguir ejecutando instancias de versiones anteriores.
• Los trabajadores que ejecutan versiones de orquestación anteriores no pueden ejecutar instancias de versiones más nuevas.
• Las funciones del orquestador pueden examinar su versión y la ejecución de la rama en consecuencia.

Este enfoque facilita las actualizaciones graduales en las que los trabajadores que ejecutan diferentes versiones de su aplicación pueden coexistir de forma segura. A diferencia de las otras estrategias de este artículo, el control de versiones de orquestación es independiente del back-end y funciona con cualquier proveedor de almacenamiento.

Para conocer los pasos completos de implementación, incluido cómo configurar el control de versiones, controlar la bifurcación de versiones en el código de orquestador y administrar las actualizaciones graduales, consulte Control de versiones de orquestación.

Las estrategias restantes son alternativas para aquellos escenarios donde el versionado de orquestación no es adecuado.

Control de versiones basado en nombres

Con esta estrategia, creará nuevas versiones de las funciones junto con las versiones anteriores en la misma aplicación de funciones. La versión de cada función se convierte en parte de su nombre (por ejemplo, MyOrchestrator_v1, MyOrchestrator_v2). Dado que se conservan las versiones anteriores, las instancias de orquestación en ejecución pueden seguir haciendo referencia a ellas. Las solicitudes de nuevas instancias de orquestación llaman a la versión más reciente, a la cual la función cliente de orquestación puede hacer referencia desde la configuración de la aplicación. En el diagrama siguiente se muestra este enfoque.

En esta estrategia, se deben copiar todas las funciones y actualizar sus referencias a otras funciones. Puede simplificar esto mediante la escritura de un script. Este es un ejemplo de proyecto con un script de migración.

Comprobación de estado con espacio

Mientras se ejecuta la versión actual de la aplicación de funciones en el espacio de producción, implemente la nueva versión de esa aplicación en el espacio de ensayo. Antes de intercambiar entre los espacios de producción y de ensayo, compruebe si hay instancias de orquestación en ejecución. Una vez completadas todas las instancias de orquestación, puede realizar el intercambio. Esta estrategia funciona cuando hay períodos predecibles en los que no hay instancias de orquestación en curso. Este es el mejor enfoque cuando las orquestaciones no son de ejecución prolongada y cuando las ejecuciones de la orquestación no se superponen con frecuencia.

Configuración de la aplicación de funciones

Use el procedimiento siguiente para configurar este escenario.

1. Agregue ranuras de implementación a la aplicación de funciones en los espacios de ensayo y de producción.

2. En cada ranura, establezca la configuración de la aplicación AzureWebJobsStorage en la conexión de una cuenta de almacenamiento compartida. El entorno de ejecución de Azure Functions usa esta conexión de cuenta de almacenamiento para almacenar de forma segura las claves de acceso de functions. Para obtener el máximo nivel de seguridad, debe usar una conexión de identidad administrada a la cuenta de almacenamiento.

3. Para cada espacio, cree un nuevo valor para la aplicación; por ejemplo, DurableManagementStorage. Establezca su valor en la cadena de conexión de distintas cuentas de almacenamiento. Estas cuentas de almacenamiento las usa la extensión Durable Functions para ejecución confiable. Use una cuenta de almacenamiento independiente para cada espacio. No marque este valor como un valor de ranura de implementación. Una vez más, las conexiones basadas en identidades administradas son las más seguras.

4. En la sección durableTask del archivo host.json de la aplicación de funciones, especifique connectionStringName (Durable 2.x) o azureStorageConnectionStringName (Durable 1.x) como nombre del valor de aplicación que ha creado en el paso 3.

En el diagrama siguiente se muestra la configuración descrita de las ranuras de implementación y las cuentas de almacenamiento. En este posible escenario anterior a la implementación, la versión 2 de una aplicación de funciones se ejecuta en el espacio de producción, mientras que la versión 1 permanece en el espacio de ensayo.

ejemplo de host.json

El fragmento JSON siguiente muestra la configuración de cadena de conexión en el archivo host.json.

{
  "version": 2.0,
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub",
      "storageProvider": {
        "connectionStringName": "DurableManagementStorage"
      }
    }
  }
}

Configuración de la canalización de CI/CD

Configure la canalización de CI/CD para que se implemente solo cuando la aplicación de funciones no tenga instancias de orquestación pendientes o en ejecución. Al usar Azure Pipelines, puede crear una función que compruebe estas condiciones, como en el ejemplo de C# siguiente. El mismo patrón se aplica a otros lenguajes: consultar instancias de orquestación con estado Pending o Running y devuelve si existe alguna.

[FunctionName("StatusCheck")]
public static async Task<IActionResult> StatusCheck(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestMessage req,
    [DurableClient] IDurableOrchestrationClient client,
    ILogger log)
{
    var runtimeStatus = new List<OrchestrationRuntimeStatus>();

    runtimeStatus.Add(OrchestrationRuntimeStatus.Pending);
    runtimeStatus.Add(OrchestrationRuntimeStatus.Running);

    var result = await client.ListInstancesAsync(new OrchestrationStatusQueryCondition() { RuntimeStatus = runtimeStatus }, CancellationToken.None);
    return (ActionResult)new OkObjectResult(new { HasRunning = result.DurableOrchestrationState.Any() });
}

A continuación, configure la puerta de ensayo para que espere hasta que no haya orquestaciones en ejecución. Para más información, consulte Release deployment control using gates (Liberar control de implementaciones mediante puertas).

Azure Pipelines comprueba si hay instancias de orquestación en ejecución en su aplicación de funciones antes de que comience la implementación.

Ahora la nueva versión de la aplicación de funciones se debería implementar en el espacio de ensayo.

Por último, intercambie los espacios.

Los valores de configuración de la aplicación que no están marcados como valores de configuración de la ranura de implementación también se intercambian, por lo que la aplicación de la versión 2 conserva su referencia a la cuenta de almacenamiento A. Dado que se realiza un seguimiento del estado de la orquestación en la cuenta de almacenamiento, las orquestaciones que se ejecutan en la aplicación de la versión 2 continúan ejecutándose en la nueva ranura sin interrupción.

Para usar la misma cuenta de almacenamiento en ambos espacios, puede cambiar los nombres de las centrales de tareas. En este caso, debe administrar el estado de los espacios y la configuración de HubName de las aplicaciones. Para obtener más información, consulte Task hubs en Durable Functions.

Enrutamiento de solicitudes

Esta estrategia es la más compleja, pero es la única opción para los sistemas con orquestaciones de ejecución continua que nunca tienen un periodo de inactividad para los intercambios de slots.

Para esta estrategia, se crea un enrutador de application delante de la Durable Functions, por ejemplo, una función de Azure con desencadenadores HTTP o una instancia de API Management que enruta en función de los encabezados de versión. El enrutador es responsable de:

• Implementación de la aplicación de funciones.
• Administrar qué versión de la aplicación está activa.
• Enrutamiento de solicitudes de orquestación a la aplicación de funciones correcta en función de la versión.

La primera vez que se recibe una solicitud de orquestación, el enrutador realiza las tareas siguientes:

1. Crea una nueva aplicación de funciones en Azure.
2. Implementa el código de la aplicación de funciones en la nueva aplicación de funciones en Azure.
3. Reenvía la solicitud de orquestación a la nueva aplicación.

El enrutador gestiona el estado de qué versión del código de tu aplicación está desplegada en qué aplicación de función en Azure.

El enrutador dirige las solicitudes de implementación y orquestación a la aplicación de funciones adecuada según la versión que se envíe con la solicitud. Omite la versión de revisión.

Si implementa una nueva versión de la aplicación sin ningún cambio importante, puede aumentar la versión de revisión. El enrutador se implementa en la aplicación de funciones existente y las solicitudes de la versión anterior y de la nueva del código se enrutan hacia la misma aplicación de funciones.

Si implementa una nueva versión de la aplicación con algún cambio importante, puede aumentar la versión principal o la secundaria. A continuación, el enrutador de aplicaciones crea una nueva aplicación de funciones en Azure, la implementa y enruta las solicitudes de la nueva versión de la aplicación a ella. En el siguiente diagrama, las orquestaciones en ejecución en la versión 1.0.1 de la aplicación continúan ejecutándose, pero las solicitudes de la versión 1.1.0 se enrutan a la nueva aplicación de funciones.

El enrutador supervisa el estado de las orquestaciones en la versión 1.0.1 y quita las aplicaciones una vez finalizadas todas las orquestaciones.

Seguimiento de la configuración de almacén

Cada aplicación de funciones debe usar colas de programación independientes, posiblemente en cuentas de almacenamiento independientes. Si quiere consultar todas las instancias de orquestaciones en todas las versiones de la aplicación, puede compartir las tablas de instancia y de historial entre las aplicaciones de funciones. Puede compartir tablas configurando las opciones trackingStoreConnectionStringName y trackingStoreNamePrefix en el archivo de configuración de host.json para que todas usen los mismos valores.

Para obtener más información, consulte Administrar instancias en Durable Functions en Azure.

Pasos siguientes