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

Ao hospedar seu aplicativo com 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 Flex Consumption fornece uma definição de configuração (SiteUpdateStrategy) que você pode usar para controlar se o aplicativo de função fica indisponível 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: reinicia todas as instâncias em execução depois de atualizar seu aplicativo com as alterações mais recentes. 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 Azure Functions.
• Atualização contínua: fornece implantações sem tempo de inatividade ao drenar e substituir 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.

• 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 para otimizar o desempenho e a confiabilidade.
• Alterar a estratégia não tem efeito em regiões com disponibilidade geral: em regiões onde as atualizações contínuas estão geralmente disponíveis, alterar siteUpdateStrategy.type por si só não aciona uma atualização do site. Você pode atualizar com segurança a estratégia com antecedência e fazer com que ela se aplique à sua próxima implantação de código ou configuração. Em regiões em que as atualizações sem interrupção ainda estão sendo implementadas, a alteração da estratégia é tratada como qualquer outra alteração de configuração e dispara uma atualização de site que usa a estratégia anterior ; a nova estratégia se aplica a partir da próxima implantação.
• 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 levar a 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 como Recreate. Você pode configurar essa configuração usando a 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 de site

Não há um sinal integrado que indique a conclusão das atualizações do 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ídasPercentComplete: percentual estimado de instâncias originais que são substituídasOriginalStillActiveCount: número estimado de instâncias originais ainda em execuçãoNewCount: 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