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

O Azure Functions atualmente oferece suporte várias versões do host de runtime. A tabela a seguir fornece detalhes sobre as versões disponíveis, seu nível de suporte e quando elas devem ser usadas:

Versão Nível de suporte Descrição
4.x GA Versão de runtime recomendada para funções em todas as linguagens.Fazer check-out das versões de idioma com suporte.
3.x GA Todas as linguagens com suporte (confira Versões de linguagens com suporte). Chegou ao fim da vida útil (EOL) do suporte estendido em 13 de dezembro de 2022. Recomendamos fortemente que você migre seus aplicativos do Azure Functions versão 3.x para a versão 4.x a fim de obter suporte completo.
2. x GA Com suporte para aplicativos herdados da versão 2. x. Esta versão está no modo de manutenção, com aprimoramentos fornecidos somente em versões posteriores. Chegou ao fim da vida útil (EOL) em 13 de dezembro de 2022. Recomendamos fortemente que você migre seus aplicativos do Azure Functions versão 3.x para a versão 4.x a fim de obter suporte completo.
1.x GA Recomendado somente para aplicativos C# que devem usar o .NET Framework e só oferece suporte ao desenvolvimento no portal do Azure, no portal Azure Stack Hub ou localmente em computadores Windows. Esta versão está no modo de manutenção, com aprimoramentos fornecidos somente em versões posteriores.

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

Níveis de suporte

Há dois níveis de suporte:

  • Geralmente disponível (GA) – com suporte total e aprovado para uso em produção.
  • Versão prévia: ainda não tem suporte, mas espera-se que alcance o status de GA no futuro.

Idiomas

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

A tabela a seguir indica quais linguagens de programação são atualmente compatíveis com cada versão de runtime.

Idioma 1.x 2. x 3.x 4.x
C# GA (.NET Framework 4.8) GA (.NET Core 2.11) GA (.NET Core 3.1)
GA (.NET 6.0)
GA (.NET 7.0)
GA (.NET Framework 4.8)
JavaScript GA (Node.js 6) GA (Node.js 10 e 8) GA (Node.js 14, 12, e 10) GA (Node.js 14)
GA (Node.js 16)
Versão prévia (Node.js 18)
F# GA (.NET Framework 4.8) GA (.NET Core 2.11) GA (.NET Core 3.1) GA (.NET 6.0)
GA (.NET 7.0)
Java N/D GA (Java 8) GA (Java 11 e 8) GA (Java 11 e 8)
GA (Java 17)
PowerShell N/D N/D N/D GA (PowerShell 7.2)
Python N/D GA (Python 3.7) GA (Python 3.9, 3.8, 3.7) GA (Python 3.9, 3.8, 3.7)
Versão prévia (3.10)
TypeScript2 N/D GA GA GA

1 Os aplicativos da biblioteca de classes .NET voltados para o runtime versão 2.x agora podem ser executados no .NET Core 3.1 no modo de compatibilidade do .NET Core 2.x. Para saber mais, confira Considerações sobre funções da v2.x.
2 Suporte por meio de transcompilação para JavaScript.

Consulte o artigo do guia do desenvolvedor específico a um idioma para obter mais informações sobre as versões de idiomas compatíveis.
Para obter informações sobre alterações planejadas para o suporte de linguagem, consulte o roteiro do Azure.

Executar em uma versão específica

A versão do runtime do Functions usada por aplicativos publicados no Azure é determinada pela configuração de aplicativo FUNCTIONS_EXTENSION_VERSION. Em alguns casos e em determinados idiomas, outras configurações podem ser aplicadas.

Por padrão, os aplicativos de funções criados no portal do Azure, pela CLI do Azure ou por ferramentas do Visual Studio são definidos para a versão 4.x. É possível modificar essa versão se necessário. Só é possível fazer downgrade da versão de runtime para a 1.x depois de criar seu aplicativo de funções, mas antes de adicionar quaisquer funções. Você pode migrar para uma versão posterior mesmo com aplicativos que têm funções existentes.

Migrar aplicativos de funções existentes

Quando seu aplicativo tiver funções existentes, você deverá tomar precauções antes de mudar para uma versão de runtime posterior. Os artigos a seguir detalham as alterações interruptivas entre as versões, incluindo alterações interruptivas específicas da linguagem. Eles também fornecem instruções passo a passo para uma migração bem-sucedida do seu aplicativo de funções existente.

Como alterar a versão de aplicativos no Azure

Os seguintes valores de versão de runtime principal são usados:

Valor Destino de runtime
~4 4.x
~3 3.x
~1 1.x

Importante

Não altere essa configuração de aplicativo arbitrariamente, pois podem ser necessárias outras alterações de configuração de aplicativo e alterações em seu código de função. Em vez disso, você deve alterar essa configuração na guia configurações de runtime do Function da Configuração do aplicativo de funções no portal do Azure quando estiver pronto para fazer uma atualização de versão principal. Para aplicativos de funções existentes, siga as instruções de migração.

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

Para resolver os problemas que seu aplicativo de funções possa ter ao executar na versão principal mais recente, é necessário fixá-lo temporariamente em uma versão secundária específica. Fixar proporciona tempo para que seu aplicativo seja executado corretamente na versão principal mais recente. A fixação de uma versão secundária é diferente entre o Windows e o Linux. Para obter mais informações, consulte Como direcionar para versões do Azure Functions runtime.

Versões secundárias mais antigas são removidas periodicamente do Functions. Para receber as notícias mais recentes sobre as versões de Azure Functions, incluindo a remoção de versões secundárias específicas mais antigas, acompanhe os comunicados de Serviço de Aplicativo do Azure.

Fixação de versão ~2.0

Os aplicativos de funções .NET em execução na versão 2.x (~2) são atualizados automaticamente para execução no .NET Core 3.1, que é uma versão de suporte de longo prazo do .NET Core 3. A execução de suas funções .NET no .NET Core 3.1 permite aproveitar as vantagens das atualizações de segurança e dos aprimoramentos do produto mais recentes.

Qualquer aplicativo de funções fixado na ~2.0 continua a ser executado no .NET Core 2.2, que não recebe mais atualizações de segurança e outras atualizações. Para saber mais, confira Considerações sobre funções da v2.x.

Versões de extensão mínimas

Tecnicamente, não há uma correlação entre as versões de extensão de associação e a versão de runtime do Functions. No entanto, a partir da versão 4.x, o runtime do Functions impõe uma versão mínima para todas as extensões de gatilho e associação.

Se receber um aviso sobre um pacote não atender a uma versão mínima necessária, você deverá atualizar esse pacote NuGet para a versão mínima como faria normalmente. Os requisitos mínimos de versão para extensões usadas no Functions v4.x podem ser encontrados no arquivo de configuração vinculado.

Para script C#, atualize a referência do pacote de extensão no host.json conforme a seguir:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

Tecnicamente, não há uma correlação entre as versões de extensão de pacote e a versão de runtime do Functions. No entanto, a partir da versão 4.x, o runtime do Functions impõe uma versão mínima para todos os pacotes de extensão.

Se você receber um aviso sobre sua versão do pacote de extensão não atender a uma versão mínima necessária, atualize sua referência de pacote de extensão existente no host.json da seguinte maneira:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

Para saber mais sobre pacotes de extensão, consulte pacotes de extensão.

Versões do aplicativo desenvolvidas localmente

É possível fazer as atualizações a seguir em aplicativos de funções para alterar localmente as versões direcionadas.

Versões de runtime do Visual Studio

No Visual Studio, você seleciona a versão de runtime quando cria um projeto. As ferramentas do Azure Functions para o Visual Studio dão suporte para as três versões principais do runtime. A versão correta é usada ao depurar e publicar com base nas configurações do projeto. As configurações de versão são definidas no arquivo .csproj nas seguintes propriedades:

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

Você também poderá escolher net6.0, net7.0 ou net48 como a estrutura de destino se estiver usando funções de processo de trabalho isoladas do .NET. O suporte para net7.0 e net48 atualmente está em versão prévia.

Observação

O Azure Functions 4.x requer que a extensão Microsoft.NET.Sdk.Functions seja pelo menos 4.0.0.

VS Code e Azure Functions Core Tools

O Azure Functions Core Tools é usado para o desenvolvimento na linha de comando e também pela extensão do Azure Functions para o Visual Studio Code. Para desenvolvimentos voltados à versão 4.x, instale a versão 4.x do Core Tools. Para desenvolvimentos voltados à versão 3.x, instale a versão 3.x do Core Tools. Para obter mais informações, confira Instalar o Azure Functions Core Tools.

Para desenvolvimento no Visual Studio Code, você também precisará atualizar a configuração do usuário para o azureFunctions.projectRuntime corresponder à versão das ferramentas instaladas. Essa configuração também atualiza os modelos e linguagens utilizados durante a criação do aplicativo de funções. Para criar aplicativos no ~3, atualize a configuração do usuário azureFunctions.projectRuntime para ~3.

Configuração de runtime da extensão do Azure Functions

Associações

A partir da versão 2.x, o runtime usa um novo modelo de extensibilidade de vinculação que oferece estas vantagens:

  • Suporte para extensões de associação de terceiros.

  • Desacoplamento de runtime e associações. Essa alteração permite que extensões de associação sejam lançadas independentemente e com controle de versão. Você pode, por exemplo, optar por atualizar para uma versão de uma extensão que se baseia em uma versão mais recente de um SDK subjacente.

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

Com exceção dos gatilhos HTTP e de temporizador, todas as associações devem ser explicitamente adicionadas ao projeto do aplicativo de funções ou registradas no portal. Para obter mais informações, confira Registrar extensões de associação.

A tabela a seguir mostra quais associações são compatíveis em cada versão de runtime.

Esta tabela mostra as associações que são compatíveis com as versões principais do Azure Functions Runtime:

Tipo 1.x 2.x e posterior1 Gatilho Entrada Saída
Armazenamento de Blobs
Azure Cosmos DB
SQL do Azure (versão prévia)2
Dapr3
Grade de Eventos
Hubs de Evento
HTTP webhooks
Hub IoT
Kafka2
Aplicativos Móveis
Hubs de Notificação
Armazenamento de filas
RabbitMQ2
SendGrid
Barramento de Serviço
SignalR
Armazenamento de tabelas
Timer
Twilio

1 A partir de runtimes de versão 2.x e posteriores, todas as associações, exceto HTTP e Timer, precisam ser registradas. Confira Registrar as extensões de associação.

2 Não há suporte para gatilhos no plano de Consumo. Requer gatilhos controlados por runtime.

3 Com suporte apenas no Kubernetes, IoT Edge e outros modos com auto-hospedagem.

Duração do tempo limite do aplicativo de funções

A duração do tempo limite para funções em um aplicativo de funções é definida pela propriedade functionTimeout no arquivo de projeto host.json. Essa propriedade se aplica especificamente a execuções de função. Depois que o gatilho inicia a execução da função, a função precisa retornar/responder dentro da duração do tempo limite. Para saber mais, confira Melhorar o desempenho e a confiabilidade do Azure Functions.

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

Plano Padrão Máximo1
Plano de Consumo 5 10
Plano Premium 302 Ilimitado
Plano dedicado 302 Ilimitado

1 Independentemente da configuração de tempo limite do aplicativo de funções, 230 segundos é a quantidade de tempo máxima que uma função disparada por HTTP pode levar para responder a uma solicitação. Isso ocorre devido ao tempo limite de ociosidade padrão do Azure Load Balancer. Para tempos de processamento mais longos, considere usar o padrão assíncrono das Durable Functions ou adiar o trabalho real e retornar uma resposta imediata.
2 O tempo limite padrão para a versão 1.x do tempo de execução do Functions é ilimitado.

Próximas etapas

Para saber mais, consulte os recursos a seguir: