Estratégias de atualização de site em Flex Consumption

Ao hospedar seu aplicativo com o Azure Functions no plano de Consumo Flex, 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 o código, modifica as configurações do aplicativo ou altera outras propriedades de configuração. O plano de Consumo Flexível fornece uma configuração de site (SiteUpdateStrategy) que você pode usar para controlar se o aplicativo de função experimenta tempo de inatividade durante essas atualizações e como as execuções em andamento são tratadas.

Atualmente, o plano de consumo flex dá suporte a 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 contínua (versão prévia): proporciona implantações sem tempo de inatividade, esvaziando e substituindo instâncias em lotes. As execuções em andamento são concluídas naturalmente sem encerramento forçado.

Comparação de estratégia

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

Atualizar comportamentos de estratégia

Esta tabela compara o processo de atualização das duas estratégias:

Esta tabela compara as principais características das duas estratégias:

Considerações sobre a estratégia de atualização sem interrupção

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

• 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 sem interrupção. Esses parâmetros podem ser alterados antes da GA para otimizar o desempenho e a confiabilidade.
• Nenhum monitoramento em tempo real: atualmente, não há visibilidade de quantas instâncias estão sendo esvaziadas, quantos lotes permanecem ou percentuais de progresso no momento.
• Sem sinal de conclusão: no entanto, você pode monitorar os logs de instância para estimar quando uma atualização for concluída.
• Cenários de instância única: os aplicativos em execução em uma instância experimentam um breve tempo de inatividade semelhante ao processo de recriação, embora as execuções em andamento ainda sejam concluídas.
• Durable Functions: como a combinação de versões durante as atualizações pode causar um comportamento inesperado em uma orquestração durável, use uma estratégia de correspondência de versão de orquestração explícita.
• Infraestrutura como Código: implantar alterações de código e configuração em conjunto dispara várias atualizações sem interrupção que podem se sobrepor.
• Compatibilidade com versões anteriores: verifique se as alterações funcionam com a versão anterior durante o período de transição de atualização sem interrupção.

Configurar sua estratégia de atualização

Você pode definir a estratégia de atualização para seu aplicativo usando a configuração do site SiteUpdateStrategy, que é um filho de functionAppConfig. Por padrão, SiteUpdateStrategy.type é definido comoRecreate. Atualmente, somente modelos Bicep e ARM com versão 2023-12-01 de API ou posterior dão suporte à 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, mudar type de Recreate para RollingUpdate usa a estratégia de recriação para essa atualização. Todas as atualizações de site subsequentes usam atualizações sem interrupção.

Monitoramento de atualizações de site

Durante a visualização pública, não há nenhum sinal interno de conclusão para atualizações de site. Use as consultas KQL no Application Insights como uma abordagem de melhor esforço para estimar o progresso da atualização sem interrupção.

Monitorando o andamento da atualização gradual

Essas consultas KQL fornecem uma estimativa aproximada do progresso da atualização contínua, acompanhando a substituição de instâncias nos registros do Application Insights. Essa abordagem tem limitações significativas e não deve ser confiada para a automação de 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 essa consulta para estimativa:

1. Cole essa consulta na folha Logs do recurso Application Insights associado ao seu aplicativo de funções.
2. Defina deploymentStart como o carimbo de data/hora quando a atualização do site for concluída com êxito.
3. Execute a consulta periodicamente para estimar o progresso. Defina o intervalo de sondagem como pelo menos 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 são substituídas
   • PercentComplete: percentual estimado 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 ativas no momento

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

1. Intervalo de tempo: o deploymentStart tempo representa quando a atualização do site retorna êxito, mas a atualização contínua 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 em deploymentStart, ela não monitora essas novas instâncias da versão original, potencialmente causando sinais de conclusão falsos.

2. Detecção baseada em log: essa abordagem depende de logs de aplicativo 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 registrando ativamente, levando a falsos sinais de conclusão quando as instâncias originais ainda estão ativas, mas não emitiram logs dentro da janela checkInterval.

Recomendação para produção: use atualizações contínuas quando implantações sem tempo de inatividade forem críticas. Verifique se os pipelines de implantação não exigem aguardar a conclusão da atualização antes de prosseguir para as etapas subsequentes. Utilize recriar quando precisar de um prazo de atualização mais rápido e previsível e puder tolerar um curto período de inatividade.

perguntas frequentes

Estou acostumado com slots de implantação para implantações sem tempo de inatividade. Como as atualizações sem interrupção diferem?

• Ao contrário dos slots de implantação, as atualizações sem interrupção não exigem nenhuma infraestrutura adicional. Defina siteUpdateStrategy.type como "RollingUpdate" para implantações sem tempo de inatividade.
• As atualizações sem interrupção preservam as execuções em andamento, enquanto os slots de implantação as encerram durante as trocas. Determinadas propriedades do site e configurações persistentes não podem ser alternadas e exigem a modificação direta do slot de produção.
• Ao contrário dos slots de implantação, as atualizações sem interrupção não fornecem um ambiente separado para que você possa testar alterações ou rotear uma porcentagem do tráfego dinâmico. Se você precisar desses recursos, use um plano que dê suporte a slots de implantação, como o Elastic Premium, ou gerencie aplicativos de Consumo Flex separados por trás de um gerenciador de tráfego.

Como reverter uma atualização de site?

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

Como os gatilhos de temporizador são tratados?

• Os gatilhos de temporizador mantêm a natureza singleton. Depois que um aplicativo de funções disparado pelo temporizador é marcado para esvaziar, novas funções de temporizador são executadas na versão mais recente.

Estou vendo erros de runtime durante a atualização sem interrupção... O que deu errado?

• Se novas instâncias não forem iniciadas ou encontrarem erros de runtime, o problema provavelmente estará no código do aplicativo, nas dependências, nas configurações ou nas variáveis de ambiente que você modificou.
• Para resolver o problema, reimplante a 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 teste antes de tentar novamente. Examine os logs de erros para identificar qual alteração específica causou o problema.

Próximas etapas

• Saiba mais sobre o plano de consumo Flex
• Saiba mais sobre as diferenças nas implantações do Flex Consumption
• Saiba como escrever modelos de infraestrutura como código