Estratégias de atualização do site no Flex Consumption

Ao hospedar seu aplicativo com o Azure Functions no plano Flex Consumption, você pode controlar como as atualizações são implantadas em instâncias em execução. Uma atualização de site ocorre sempre que você implanta código, modifica as configurações do aplicativo ou altera outras propriedades de configuração. O plano Flex Consumption fornece uma definição de configuração do site (SiteUpdateStrategy) que pode ser usada para controlar se a sua aplicação de funções enfrenta tempo morto durante estas atualizações e como as execuções em curso são tratadas.

Atualmente, o plano Flex Consumption suporta estas estratégias de atualização:

• Recriar: o Functions reinicia todas as instâncias em execução depois de substituir o código pela versão mais recente. Essa abordagem pode causar um breve tempo de inatividade enquanto as instâncias são recicladas e preserva o comportamento padrão de outros planos de hospedagem do Azure Functions.
• Atualização em fases (versão de teste): proporciona implantações sem tempo de inatividade ao drenar e substituir instâncias em lotes. As execuções em curso são concluídas naturalmente sem interrupção forçada.

Comparação de estratégias

Esta tabela compara as duas estratégias de atualização do site:

Atualizar comportamentos de estratégia

Este quadro compara o processo de atualização das duas estratégias:

Este quadro compara as principais características das duas estratégias:

Considerações sobre a estratégia de atualização contínua

Tenha esses comportamentos e limitações atuais em mente ao usar a estratégia de atualização contínua. Essa lista é mantida durante o período de visualização e pode mudar à medida que o recurso se aproxima da disponibilidade geral (GA).

• Parâmetros gerenciados pela plataforma: a plataforma controla os parâmetros (como contagem de lotes, instâncias por lote, número de lotes e intervalos de drenagem) que determinam comportamentos de atualização contínua. Esses parâmetros podem mudar antes do GA para otimizar o desempenho e a confiabilidade.
• Sem monitorização em tempo real: atualmente não há visibilidade de quantas instâncias estão sendo drenadas, quantos lotes restam ou quais são as percentagens de progresso correntes.
• Sem sinal de conclusão: no entanto, você pode monitorar os logs de instância para estimar quando uma atualização é concluída.
• Cenários de instância única: os aplicativos executados em uma instância experimentam um breve tempo de inatividade semelhante ao da recriação, embora as execuções em andamento ainda sejam concluídas.
• Funções Duráveis: Como a mistura de versões durante as atualizações pode causar um comportamento inesperado numa orquestração durável, use uma estratégia explícita de correspondência de versão de orquestração.
• Infraestrutura como código: a implantação de alterações de código e configuração juntas aciona várias atualizações contínuas que podem se sobrepor.
• Compatibilidade com versões anteriores: certifique-se de que as alterações funcionam com a versão anterior durante o período de transição da atualização contínua.

Configure sua estratégia de atualização

Você pode definir a estratégia de atualização para o seu aplicativo usando a configuração de site SiteUpdateStrategy, que é filho de functionAppConfig. Por padrão, SiteUpdateStrategy.type é definido como Recreate. Atualmente, apenas os modelos Bicep e ARM com a versão de API 2023-12-01 ou posterior suportam a alteração dessa propriedade.

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

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

As alterações na estratégia de atualização do site entrarão em vigor na próxima atualização do site. Por exemplo, alterar type de Recreate para RollingUpdate utiliza a estratégia de recriação para essa atualização. Todas as atualizações de site subsequentes usam atualizações graduais.

Monitoramento de atualizações do site

Durante a pré-visualização pública, não há nenhum indicador de conclusão incorporado para atualizações do site. Você pode usar consultas KQL no Application Insights como uma abordagem de melhor esforço para estimar o progresso da atualização contínua.

Monitorando o progresso contínuo da atualização

Essas consultas KQL fornecem uma estimativa de melhor esforço do progresso da atualização contínua, rastreando a rotatividade da instância nos logs do Application Insights. Essa abordagem tem limitações significativas e não deve ser usada para automação da produção:

// 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

Como usar esta consulta para estimativa:

1. Cole essa consulta na folha Logs do recurso Application Insights associado ao seu aplicativo de função.
2. Defina deploymentStart como o carimbo de data/hora quando a atualização do site retornar com êxito.
3. Execute a consulta periodicamente para estimar o progresso. Defina o intervalo de sondagem para ser pelo menos tão longo quanto o tempo médio de execução da função e verifique se a checkInterval variável na consulta corresponde a essa frequência de sondagem.
4. A consulta retorna valores aproximados:
   • RollingUpdateComplete: Melhor estimativa de se todas as instâncias originais foram substituídas
   • PercentComplete: Porcentagem estimada de instâncias originais que são substituídas
   • OriginalStillActiveCount: Número estimado de instâncias originais ainda em execução
   • NewCount: Número de novas instâncias atualmente ativas

Tenha estas limitações em mente ao usar estas consultas:

1. Intervalo de tempo: o deploymentStart tempo representa quando a atualização do site retorna com êxito, mas a atualização contínua real pode não ser iniciada imediatamente. Durante essa lacuna, todos os eventos de expansão provisionam instâncias que executam a versão original. Como a consulta rastreia apenas instâncias ativas no deploymentStart, ela não monitora essas novas instâncias da versão original, potencialmente causando falsos sinais de conclusão.

2. Deteção baseada em log: essa abordagem depende de logs de aplicativos para inferir o estado da instância em vez de consultar diretamente o status da instância. As instâncias podem estar em execução, mas não a registar ativamente, levando a falsos sinais de conclusão quando as instâncias originais ainda estão ativas, mas não emitem logs dentro da janela checkInterval.

Recomendação para produção: use atualizações contínuas quando implantações com tempo de inatividade zero forem críticas. Certifique-se de que seus pipelines de implantação não exijam aguardar a conclusão da atualização antes de prosseguir para as etapas subsequentes. Utilize a recriação quando precisar de tempos de atualização mais rápidos e previsíveis e puder tolerar um breve tempo de inatividade.

FAQ

Estou acostumado a utilizar deployment slots para implantações sem interrupções. Qual é a diferença entre as atualizações contínuas?

• Ao contrário dos slots de implantação, as atualizações contínuas não exigem infraestrutura adicional. Defina siteUpdateStrategy.type para "RollingUpdate" para implantações sem interrupções.
• As atualizações contínuas preservam as execuções em andamento, enquanto os slots de implantação as encerram durante as trocas. Certas propriedades do site e configurações fixas não podem ser trocadas e exigem a modificação direta do slot de produção.
• Ao contrário dos slots de implantação, as atualizações contínuas não fornecem um ambiente separado para que você possa testar alterações ou rotear uma porcentagem do tráfego ao vivo. Se você precisar desses recursos, use um plano que ofereça suporte a slots de implantação, como o Elastic Premium, ou gerencie aplicativos Flex Consumption separados atrás de um gerenciador de tráfego.

Como faço para reverter uma atualização do site?

• Atualmente, não há nenhum recurso para reverter uma atualização do site. Se uma reversão for necessária, inicie outra atualização do site com o estado anterior do código ou da configuração.

Como são tratados os gatilhos de temporizador?

• Os gatilhos do temporizador mantêm sua natureza singleton. Assim que um aplicativo de função acionado por temporizador é marcado para drenagem, novas funções de temporizador são executadas na versão mais recente.

Estou vendo erros de tempo de execução durante a atualização contínua... O que correu mal?

• Se novas instâncias falharem ao iniciar ou encontrarem erros de tempo de execução, o problema provavelmente estará no código do aplicativo, dependências, definições de configuração ou variáveis de ambiente que você modificou.
• Para resolver o problema, reimplante sua última versão íntegra conhecida para restaurar o tempo de execução. Em seguida, teste as alterações propostas em um ambiente de desenvolvimento ou preparo antes de tentar novamente. Revise os logs de erros para identificar qual alteração específica causou o problema.

Próximos passos

• Saiba mais sobre o plano Flex Consumption
• Saiba mais sobre como as implantações diferem no Flex Consumption
• Saiba como escrever modelos de infraestrutura como código