Visão geral das versões de runtime do Azure Functions

Azure Functions atualmente suporta duas versões do host em tempo de execução. A tabela a seguir detalha as versões runtime atualmente suportadas, o respetivo nível de suporte e quando elas devem ser usadas:

Este artigo detalha algumas das diferenças entre as versões suportadas, como você pode criar cada versão e como alterar a versão na qual suas funções são executadas.

Níveis de apoio

Existem dois níveis de apoio:

• Geralmente disponível (GA) - Totalmente suportado e aprovado para uso em produção.
• Pré-visualização - Ainda não é suportada, mas espera-se que alcance o estado de Disponibilidade Geral no futuro.

Idiomas

Todas as funções em um aplicativo de função devem compartilhar o mesmo idioma. Você escolhe o idioma das funções em seu aplicativo de função ao criar o aplicativo. O idioma do seu aplicativo de função é mantido na configuração FUNCTIONS_WORKER_RUNTIME e não pode ser alterado quando há funções existentes.

Certifique-se de selecionar sua linguagem de desenvolvimento preferida na parte superior do artigo.

Para informações sobre alterações planeadas ao suporte de línguas, consulte as atualizações do roteiro Azure.

Para obter informações sobre as versões de idioma de versões anteriormente suportadas do runtime do Functions, consulte Versões obsoletas do runtime.

Executar em uma versão específica

A versão do runtime Functions usada pelas aplicações publicadas em Azure é ditada pela definição FUNCTIONS_EXTENSION_VERSION da aplicação. Em alguns casos e para determinados idiomas, outras configurações podem ser aplicadas.

Por defeito, as aplicações de funções criadas no portal do Azure, pela Azure CLI ou pelas ferramentas do Visual Studio estão definidas para a versão 4.x. Você pode modificar esta versão, se necessário. Você só pode fazer o downgrade da versão de tempo de execução para 1.x depois de criar seu aplicativo de função, mas antes de adicionar quaisquer funções. A atualização para uma versão principal posterior é permitida mesmo com aplicativos que tenham funções existentes.

Migrando aplicativos de função existentes

Quando seu aplicativo tiver funções existentes, você deve tomar precauções antes de passar para uma versão de tempo de execução principal posterior. Os artigos a seguir detalham as alterações disruptivas entre as versões principais, incluindo modificações significativas específicas à linguagem. Eles também fornecem instruções passo a passo para uma migração bem-sucedida do seu aplicativo de função existente.

• Migrar da versão runtime 3.x para a versão 4.x
• Migrar da versão runtime 1.x para a versão 4.x

Alterar a versão das aplicações no Azure

Os seguintes valores principais de versão de tempo de execução são usados:

Fixação a uma versão secundária específica

Para resolver problemas que seu aplicativo de função poderia ter ao ser executado na versão principal mais recente, você deve fixar temporariamente seu aplicativo em uma versão secundária específica. A anexação dá-lhe tempo para a sua aplicação ser executada corretamente na versão principal mais recente. A forma como fixas uma versão menor difere entre Windows e Linux. Para saber mais, veja Como direcionar versões de runtime do Azure Functions.

As versões secundárias mais antigas são periodicamente removidas do Functions. Para as últimas notícias sobre os lançamentos do Azure Functions, incluindo a remoção de versões menores antigas específicas, acompanhe os anúncios do Azure App Service.

Versões de extensão mínima

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

Versões desativadas

Essas versões do runtime do Functions chegaram ao fim do suporte estendido em 13 de dezembro de 2022.

Assim que possível, você deve migrar seus aplicativos para a versão 4.x para obter suporte total. Para um conjunto completo de instruções de migração específicas da língua, veja Migrar aplicações para Azure Functions versão 4.x.

Os aplicativos que usam as versões 2.x e 3.x ainda podem ser criados e implantados a partir do seu pipeline de DevOps de CI/CD, e todos os aplicativos existentes continuam a ser executados sem alterações ininterruptas. No entanto, seus aplicativos não são qualificados para novos recursos, patches de segurança e otimizações de desempenho. Você só pode obter suporte de serviço relacionado depois de atualizar seus aplicativos para a versão 4.x.

As versões 2.x e 3.x já não são suportadas devido ao fim do suporte para o .NET Core 3.1, que era uma dependência do núcleo. Este requisito afeta todas as linguagens suportadas por Azure Functions.

Versões de aplicativos desenvolvidas localmente

Você pode fazer as seguintes atualizações para aplicativos funcionais para alterar localmente as versões de destino.

Versões de runtime do Visual Studio

No Visual Studio, selecionas a versão em tempo de execução quando crias um projeto. As ferramentas Azure Functions para Visual Studio suportam as duas principais versões de runtime. A versão correta é usada durante a depuração e publicação com base nas configurações do projeto. As configurações de versão são definidas no arquivo .csproj nas seguintes propriedades:

<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

<TargetFramework>net48</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>

Visual Studio Code e Azure Functions Core Tools

Azure Functions Core Tools é usado para desenvolvimento de linha de comandos e também pela extensão Azure Functions para Visual Studio Code. Para mais informações, consulte Install the Azure Functions Core Tools.

Para o desenvolvimento do Visual Studio Code, também pode ser necessário atualizar as definições de utilizador associadas a azureFunctions.projectRuntime, para que correspondam à versão das ferramentas instaladas. Essa configuração também atualiza os modelos e idiomas usados durante a criação do aplicativo de função.

Vínculos

A partir da versão 2.x, o runtime utiliza um novo modelo de extensibilidade de ligação binding extensibility model que oferece as seguintes vantagens:

• Suporte para extensões de vinculação que não sejam da Microsoft.

• Desacoplamento de tempo de execução e vinculações. Essa alteração permite que as extensões de vinculação sejam versionadas e liberadas de forma independente. Você pode, por exemplo, optar por atualizar para uma versão de uma extensão que depende de uma versão mais recente de um SDK subjacente.

• Um ambiente de execução mais leve, onde apenas as ligações em uso são conhecidas e carregadas pelo tempo de execução.

Com exceção dos gatilhos HTTP e de temporizador, todas as associações devem ser explicitamente adicionadas ao projeto do aplicativo de função ou registradas no portal. Para mais informações, consulte padrões de expressão de ligação do Azure Functions.

Esta tabela mostra as ligações suportadas nas principais versões do runtime do Azure Functions:

1. Registe todas as ligações exceto HTTP e temporizador. Veja Registar extensões de ligação do Azure Functions. Este passo não é necessário ao usar a versão 1.x do runtime de Functions.
2. O suporte para a versão 1.x do runtime Azure Functions termina a 14 de setembro de 2026. Migra as tuas aplicações para a versão 4.x para suporte total.
3. Os gatilhos não são suportados no plano de Consumo. Este tipo de vinculação requer triggers acionados por tempo de execução.
4. Este tipo de binding é suportado apenas no Kubernetes, Azure IoT Edge e outros modos auto-hospedados.

Duração do timeout da aplicação de função

A functionTimeout propriedade no ficheiro de projeto host.json define a duração do timeout para funções numa aplicação de funções. Esta propriedade aplica-se especificamente a execuções de funções. Depois de o disparador iniciar a execução da função, a função precisa de regressar ou responder dentro do tempo de timeout. Quando uma execução ultrapassa esta duração, ocorre um erro de timeout e o processo worker da linguagem reinicia. Para uma aplicação C# que é executada em processo, o próprio processo anfitrião reinicia. Para evitar timeouts e subsequentes reinicios de processos, é importante escrever funções robustas. Para mais informações, consulte Melhorar o desempenho e a fiabilidade Azure Functions.

A tabela a seguir mostra os valores padrão e máximo (em minutos) para planos específicos:

1. Independentemente da definição de tempo limite da aplicação de funções, 230 segundos é o tempo máximo que uma função ativada por HTTP pode demorar a responder a um pedido. Este limite existe devido ao timeout default idle do Azure Load Balancer. Para tempos de processamento mais longos, considere usar o padrão assíncrono Durable Functions ou demeter o trabalho real e devolver uma resposta imediata.
2. Não há uma duração máxima de tempo limite de execução imposta. No entanto, o período de carência dado à execução de uma função é de 60 minutos durante a redução de escala para os planos Flex Consumption e Premium, e um período de carência de 10 minutos é dado durante as atualizações da plataforma.
3. Requer que o plano do Serviço de Aplicativo esteja definido como Sempre Ativado. Um período de carência de 10 minutos é dado durante as atualizações da plataforma.
4. O timeout padrão para a versão 1.x do runtime do host Functions é ilimitado.
5. Quando o número mínimo de réplicas é definido como zero, o tempo limite padrão depende dos gatilhos específicos usados no aplicativo.

Estes valores assumem que o processo host do Azure Functions inicia e corre corretamente. Há um tempo máximo de 60 segundos para que o processo específico do trabalhador da língua também comece. O tempo limite de inicialização do processo de trabalho não é configurável no momento.

Conteúdo relacionado

Para obter mais informações, consulte os seguintes recursos:

• Desenvolver Azure Functions localmente usando Core Tools
• Como especificar as versões do runtime do Azure Functions
• Notas de lançamento