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

Quando aloja a sua aplicação com Funções do Azure no plano Flex Consumption, pode controlar como as atualizações são implementadas nas 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 configuração (SiteUpdateStrategy) que pode usar para controlar se a sua aplicação de funções sofre períodos de inatividade durante estas atualizações e como as execuções em curso são geridas.

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

• Recriar: Reinicia todas as instâncias em execução depois de atualizar a aplicação com as últimas alterações. Esta 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 alojamento do Funções do Azure.
• Atualização faseada: Proporciona implementações sem tempo de inatividade, retirando de serviço e substituindo 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.

• 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. Estes parâmetros podem mudar para otimizar o desempenho e a fiabilidade.
• Alterar a estratégia não tem efeito nas regiões de disponibilidade geral: Nas regiões onde as atualizações faseadas estão geralmente disponíveis, alterar siteUpdateStrategy.type não desencadeia, por si só, uma atualização do site. Pode atualizar a estratégia com antecedência em segurança e aplicá-la à sua próxima implementação de código ou configuração. Nas regiões onde as atualizações contínuas ainda estão a ser implementadas, alterar a estratégia é tratada como qualquer outra alteração de configuração e desencadeia uma atualização do site que utiliza a estratégia anterior ; A nova estratégia aplica-se a partir da próxima implementação.
• 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.
• Durable Functions: Como misturar versões durante as atualizações pode causar comportamentos inesperados numa orquestração com Durable Functions, use uma estratégia explícita de correspondência de versões de orquestração.
• Infrastructure-as-Code: Implementar alterações de código e configuração em conjunto desencadeia múltiplas atualizações contínuas que podem sobrepor-se.
• 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. Pode configurar esta definição utilizando o CLI do Azure 2.87.0 ou posterior, o Bicep ou modelos ARM com a versão da API 2023-12-01 ou posterior.

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

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

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

Monitoramento de atualizações do site

Não há nenhuma indicação de conclusão integrada para atualizações no 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 devolve valores aproximados:

RollingUpdateComplete: Melhor estimativa de se todas as instâncias originais são substituídasPercentComplete: Percentagem estimada de instâncias originais que são substituídasOriginalStillActiveCount: Número estimado de instâncias originais ainda em funcionamentoNewCount: 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

Aqui estão algumas perguntas comuns sobre estratégias de atualização do site.

Em que é que as atualizações contínuas diferem dos slots de implantação?

Ao contrário dos slots de implementação, as atualizações progressivas não requerem 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. Para obter um guia completo, consulte Recuperar de uma implementação com falha do plano Flex Consumption.

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 a ver erros de execução durante a atualização contínua

Se as novas instâncias falharem ao iniciar ou encontrarem erros em tempo de execução, o problema provavelmente está no código da aplicação, dependências, definições de configuração ou variáveis de ambiente que modificou.

Para resolver o problema, reimplemente a sua última versão saudável 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 registos de erros para identificar que 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