Implantação de tempo de inatividade zero para Durable Functions

O modelo de execução confiável de Durable Functions requer que as orquestrações sejam determinísticas, o que cria um desafio ao implantar atualizações. Quando uma implantação contém alterações interruptivas , como assinaturas de função de atividade modificada ou lógica de orquestrador alterada, as instâncias de orquestração in-flight falham. Essa situação é especialmente um problema para orquestrações de longa execução, que podem representar horas ou dias de trabalho.

A tabela a seguir compara quatro estratégias para alcançar a implantação de tempo de inatividade zero. Escolha a estratégia que melhor corresponda à sua carga de trabalho:

Versionamento de orquestração

O recurso de controle de versão de orquestração é a estratégia recomendada para implantações de tempo de inatividade zero com alterações significativas. Ele permite que diferentes versões de orquestrações coexistam e executem simultaneamente sem conflitos.

Com controle de versão de orquestração:

• Cada instância de orquestração obtém uma versão permanentemente associada a ela quando criada.
• Os trabalhadores que executam versões mais recentes do orquestrador podem continuar executando instâncias de versão mais antigas.
• Os trabalhadores que executam versões de orquestração mais antigas não podem executar instâncias de versão mais recentes.
• As funções do orquestrador podem examinar a versão e a execução da ramificação de forma adequada.

Essa abordagem facilita atualizações sem interrupção em que os trabalhadores que executam diferentes versões do seu aplicativo podem coexistir com segurança. Ao contrário das outras estratégias neste artigo, o controle de versão de orquestração é independente de back-end e funciona com qualquer provedor de armazenamento.

Para obter as etapas completas de implementação, incluindo como configurar o controle de versão, manipular a ramificação de controle de versão no código do orquestrador e gerenciar atualizações contínuas, veja Controle de Versão da Orquestração.

As estratégias restantes são alternativas para cenários em que o versionamento de orquestração não é adequado.

Controle de versão baseado em nome

Com essa estratégia, você cria novas versões de suas funções junto com as versões antigas no mesmo aplicativo de funções. A versão de cada função se torna parte de seu nome (por exemplo, MyOrchestrator_v1, ). MyOrchestrator_v2 Já que as versões anteriores são preservadas, as instâncias de orquestração em andamento podem continuar a referenciá-las. Solicitações para novas instâncias de orquestração solicitam a versão mais recente, à qual sua função de cliente de orquestração pode fazer referência a partir das configurações do aplicativo. O diagrama a seguir ilustra essa abordagem.

Nessa estratégia, cada função deve ser copiada e suas referências a outras funções devem ser atualizadas. Você pode facilitar escrevendo um script. Aqui está um projeto de exemplo com um script de migração.

Verificação de status com slot

Embora a versão atual do seu aplicativo de funções esteja em execução no slot de produção, implante a nova versão do seu aplicativo de funções em seu slot de preparo. Antes de trocar os slots de produção e de preparo, verifique se há alguma instância de orquestração em execução. Depois que todas as instâncias de orquestração forem concluídas, você poderá fazer a troca. Essa estratégia funciona quando você tem períodos previsíveis em que não há instâncias de orquestração em andamento. Essa é a melhor abordagem quando suas orquestrações não são de execução longa e quando suas execuções de orquestração não se sobrepõem com frequência.

Configuração do aplicativo de funções

Use o procedimento a seguir para configurar esse cenário.

1. Adicione slots de implantação ao seu aplicativo de funções para preparo e produção.

2. Para cada slot, defina a Configuração do aplicativo AzureWebJobsStorage à conexão de uma conta de armazenamento compartilhado. Essa conexão de conta de armazenamento é usada pelo runtime do Azure Functions para armazenar com segurança as chaves de acesso das funções. Quanto ao nível mais alto de segurança, você deve usar uma conexão de identidade gerenciada à sua conta de armazenamento.

3. Para cada slot, crie uma nova configuração de aplicativo, por exemplo, DurableManagementStorage. Defina seu valor para a cadeia de conexão de contas de armazenamento diferentes. Essas contas de armazenamento são usadas pela extensão Durable Functions para execução confiável. Use uma conta de armazenamento separada para cada slot. Não marque essa configuração como uma configuração de slot de implantação. Novamente, as conexões baseadas em identidade gerenciada são as mais seguras.

4. Na seção durableTask do arquivo host.json, especifique connectionStringName (Durável 2.x) ou azureStorageConnectionStringName (Durável 1.x) como o nome da configuração do aplicativo que você criou na etapa 3.

O diagrama a seguir mostra a configuração descrita de slots de implantação e contas de armazenamento. Nesse cenário potencial de pré-implantação, a versão 2 de um aplicativo de funções está em execução no slot de produção, enquanto a versão 1 permanece no slot de preparo.

Captura de tela da configuração dos slots de implantação e contas de armazenamento antes da troca de slots para a implantação sem tempo de inatividade das Durable Functions.

exemplo de host.json

O fragmento JSON a seguir mostra a configuração de cadeia de conexão no arquivo host.json.

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

Configuração de pipeline de CI/CD

Configure seu pipeline de CI/CD para implantação somente quando seu aplicativo de funções não tiver instâncias de orquestração pendentes ou em execução. Ao usar Azure Pipelines, você pode criar uma função que verifica essas condições, como no exemplo de C# a seguir. O mesmo padrão se aplica a outras linguagens – consulte instâncias de orquestração com status de Pending ou Running e retorne se alguma existir.

[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() });
}

Em seguida, configure o portão de preparo para esperar até que nenhuma orquestração esteja em execução. Para obter mais informações, consulte Liberar controle de implantação usando portões

Azure Pipelines verifica se o aplicativo de funções executa instâncias de orquestração antes do início da implantação.

Agora, a nova versão do seu aplicativo de funções deve ser implantada no slot de preparo.

Por fim, troque os slots.

As configurações do aplicativo que não são marcadas como configurações do slot de implantação também são trocadas, portanto, o aplicativo da versão 2 mantém sua referência à conta de armazenamento A. Como o estado de orquestração é acompanhado na conta de armazenamento, todas as orquestrações em execução no aplicativo da versão 2 continuam a ser executadas no novo slot sem interrupção.

Para usar a mesma conta de armazenamento para ambos os slots, você pode alterar os nomes dos hubs de tarefas. Nesse caso, você precisa gerenciar o estado de seus slots e as configurações de HubName do seu aplicativo. Para saber mais, consulte os hubs de tarefas em Durable Functions.

Roteamento de aplicativo

Essa estratégia é a mais complexa, mas é a única opção para sistemas com orquestrações em execução contínua que nunca têm uma janela ociosa para trocas de slot.

Para essa estratégia, você cria um roteador application na frente do Durable Functions , por exemplo, uma função Azure com gatilhos HTTP ou uma instância de Gerenciamento de API que roteia com base em cabeçalhos de versão. O roteador é responsável por:

• Implantando o aplicativo de funções.
• Gerenciando qual versão do aplicativo está ativa.
• Roteando solicitações de orquestração para o aplicativo de funções correto com base na versão.

Na primeira vez que uma solicitação de orquestração é recebida, o roteador realiza as seguintes tarefas:

1. Cria um novo aplicativo de funções no Azure.
2. Implanta o código do aplicativo de funções no novo aplicativo de funções em Azure.
3. Encaminha a solicitação de orquestração para o novo aplicativo.

O roteador gerencia o estado cuja versão do código do aplicativo é implantada no aplicativo de funções no Azure.

O roteador direciona as solicitações de implantação e orquestração para o aplicativo de funções apropriado com base na versão enviada com a solicitação. Ele ignora a versão do patch.

Ao implantar uma nova versão do seu aplicativo sem uma alteração significativa, você pode incrementar a versão do patch. O roteador é implantado em seu aplicativo de funções existente e envia solicitações para as versões antigas e novas do código, que são roteadas para o mesmo aplicativo de funções.

Ao implantar uma nova versão do seu aplicativo com uma alteração significativa, você pode incrementar a versão principal ou secundária. Em seguida, o roteador de aplicativo cria uma nova função no Azure, implanta-a e roteia as solicitações para a nova versão do seu aplicativo. No diagrama a seguir, a execução de orquestrações na versão 1.0.1 do aplicativo continua em execução, mas as solicitações para a versão 1.1.0 são roteadas para o novo aplicativo de funções.

O roteador monitora o status das orquestrações na versão 1.0.1 e remove os aplicativos após a conclusão de todas as orquestrações.

Configurações do repositório de rastreamento

Cada aplicativo de funções deve usar filas de agendamento separadas, possivelmente em contas de armazenamento separadas. Se você quiser consultar todas as instâncias de orquestrações em todas as versões do seu aplicativo, você pode compartilhar instâncias e tabelas de histórico em seus aplicativos de funções. Você pode compartilhar tabelas configurando trackingStoreConnectionStringName e trackingStoreNamePrefix configurações no arquivo configurações host.json para que todas usem os mesmos valores.

Para obter mais informações, consulte Gerenciar instâncias no Durable Functions no Azure.

Próximas Etapas