Share via


Implementación sin tiempo de inactividad en Durable Functions

El modelo de ejecución confiable de Durable Functions requiere que las orquestaciones sean deterministas, lo que constituye un desafío adicional que debe tenerse en cuenta al implementar actualizaciones. Cuando una implementación contiene cambios en las signaturas de las funciones de actividad o la lógica del orquestador, las instancias de orquestación en curso producen errores. Esta situación supone especialmente un problema para las instancias de orquestaciones de larga ejecución, que pueden llevar horas o días de trabajo.

Para evitar que se produzcan estos errores, tiene dos opciones:

  • Retrasar la implementación hasta que se hayan completado todas las instancias de orquestación en ejecución.
  • Asegurarse de que todas las instancias de orquestación en ejecución usan las versiones existentes de las funciones.

En el gráfico siguiente se comparan las tres estrategias principales para lograr una implementación sin tiempo de inactividad en Durable Functions:

Estrategia Cuándo se usa Ventajas Desventajas
Control de versiones En aplicaciones que no experimentan cambios importantes frecuentes. Fácil de implementar. Mayor tamaño de la aplicación de funciones en la memoria y mayor número de funciones.
Duplicación de código.
Comprobación de estado con espacio Un sistema que no tenga orquestaciones de larga ejecución que duren más de 24 horas u orquestaciones que se superpongan con frecuencia. Base de código sencilla.
No requiere una administración adicional de la aplicación de funciones.
Requiere administración adicional de la cuenta de almacenamiento o de la central de tareas.
Requiere períodos de tiempo en los que no se ejecuten orquestaciones.
Enrutamiento de aplicaciones Un sistema que no tenga períodos de tiempo en los que no se ejecuten orquestaciones como, por ejemplo, aquellos con orquestaciones que duran más de 24 horas u orquestaciones que se superponen con frecuencia. Controla las nuevas versiones de los sistemas con orquestaciones que se ejecutan continuamente y que tienen cambios importantes. Requiere un enrutador de aplicación inteligente.
Podría maximizar el número de aplicaciones de funciones que permite la suscripción. El valor predeterminado es 100.

En el resto de este documento se describen estas estrategias con más detalle.

Nota

En las descripciones de estas estrategias de implementación sin tiempo de inactividad se supone que usa el proveedor de Azure Storage predeterminado para Durable Functions. Es posible que la guía no sea adecuada si usa un proveedor de almacenamiento que no sea el proveedor predeterminado de Azure Storage. Para más información sobre las diversas opciones del proveedor de almacenamiento y cómo se comparan, consulte la documentación sobre proveedores de almacenamiento de Durable Functions.

Control de versiones

Defina nuevas versiones de las funciones y deje las versiones anteriores en la aplicación de funciones. Como puede ver en el diagrama, la versión de una función forma parte de su nombre. Dado que las versiones anteriores de las funciones se conservan, las instancias de orquestación en curso pueden seguir haciendo referencia a ellas. En cambio, las solicitudes de nuevas instancias de orquestación llaman a la versión más reciente, a la que la función de cliente de orquestación puede hacer referencia desde una configuración de aplicación.

Versioning strategy

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.

Nota

Esta estrategia usa ranuras de implementación para evitar tiempos de inactividad durante la implementación. Para obtener información más detallada sobre cómo crear y usar nuevas ranuras de implementación, consulte Ranuras de implementación de Azure Functions.

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 espacio, establezca la configuración de la aplicación AzureWebJobsStorage en la cadena de conexión de una cuenta de almacenamiento compartida. El entorno de ejecución de Azure Functions usa esta cadena de conexión de la cuenta de almacenamiento para almacenar de forma segura las claves de acceso de las funciones.

  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. La extensión de Durable Functions usa estas cuentas de almacenamiento para una ejecución confiable. Use una cuenta de almacenamiento independiente para cada espacio. No marque este valor como un valor de ranura de implementación.

  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.

Deployment slots and storage accounts

Ejemplos de host.json

Los siguientes fragmentos JSON son ejemplos del valor de la cadena de conexión en el archivo host.json.

Functions 2.0

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

Functions 1.x

{
  "durableTask": {
    "azureStorageConnectionStringName": "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. Cuando use Azure Pipelines, puede crear una función que compruebe estas condiciones, como en el ejemplo siguiente:

[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).

Deployment gate

Azure Pipelines comprueba la ejecución de instancias de orquestación de la aplicación de funciones antes de que se inicie la implementación.

Deployment gate (running)

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

Staging slot

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.

Deployment slot

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 más información, consulte Centrales de tareas en Durable Functions.

Enrutamiento de aplicaciones

Esta estrategia es la más compleja. Sin embargo, se puede usar para las aplicaciones de funciones que no tengan tiempo entre las orquestaciones en ejecución.

Para esta estrategia, debe crear un enrutador de aplicación delante de Durable Functions. Este enrutador se puede implementar con Durable Functions. El enrutador tiene la responsabilidad de:

  • Implemente la aplicación de función.
  • Administrar la versión de Durable Functions.
  • Enrutar las solicitudes de orquestación a las aplicaciones de funciones.

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

  1. Crea una 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 administra la instrucción sobre qué versión del código de la aplicación se implementa en qué aplicación de funciones en Azure.

Application routing (first time)

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.

Application routing (no breaking change)

Si implementa una nueva versión de la aplicación con algún cambio importante, puede aumentar la versión principal o la secundaria. Posteriormente, el enrutador de la aplicación crea una nueva aplicación de funciones en Azure, se implementa en ella y enruta las solicitudes de la nueva versión de la aplicación en 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.

Application routing (breaking change)

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 más información, consulte Administración de instancias con Durable Functions en Azure.

Tracking store settings

Pasos siguientes