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

O Azure Functions atualmente oferece suporte a três versões do host de runtime: 3.x, 2.x e 1.x. Todas elas oferecem suporte a cenários de produção.

Importante

A versão 1.x está no modo de manutenção e só dá suporte ao desenvolvimento no portal do Azure, no portal do Azure Stack Hub ou localmente em computadores com Windows. Os aprimoramentos são fornecidos somente em versões mais recentes.

Este artigo detalha algumas das diferenças entre as diversas versões, como criar cada uma delas e como alterá-las.

Idiomas

A partir da versão 2.x, o runtime usa um modelo de extensibilidade de linguagem e todas as funções em um aplicativo de funções devem compartilhar a mesma linguagem. A linguagem das funções em um aplicativo de funções é escolhida ao criar o aplicativo e é mantida na configuração FUNCTIONS_WORKER_RUNTIME.

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
C#1 GA (.NET Framework 4.8) GA (.NET Core 2.12) GA (.NET Core 3.1)
GA (.NET 5.0)
JavaScript GA (Nó 6) GA (Node 10 e 8) GA (Node 14, 12 e 10)
F# GA (.NET Framework 4.8) GA (.NET Core 2.12) GA (.NET Core 3.1)
Java N/D GA (Java 8) GA (Java 11 e 8)
PowerShell N/D GA (PowerShell Core 6) GA (PowerShell 7.0 e Core 6)
Python N/D GA (Python 3.7 e 3.6) GA (Python 3.8, 3.7 e 3.6)
Versão prévia (Python 3.9)
TypeScript N/D GA3 GA3

1 Está disponível uma versão experimental do Azure Functions que permite usar a versão prévia do .NET 6.0. Para saber mais, confira a página da Versão prévia inicial do Azure Functions v4. 2 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.
3 Suporte por meio de transposiçã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

Por padrão, os aplicativos de funções criados no portal do Azure e na CLI do Azure são definidos para a versão 3.x. É possível modificar essa versão conforme 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 entre a 2.x e a 3.x mesmo com aplicativos que têm funções existentes. Antes de migrar um aplicativo com funções existentes da 2.x para a 3.x, esteja ciente de quaisquer alterações interruptivas entre a 2.x e a 3.x.

Antes de fazer uma alteração na versão principal do runtime, teste primeiro seu código existente por meio da implementação em outro aplicativo de funções que esteja em execução na versão principal mais recente. Esse teste ajuda a garantir sua execução correta após a atualização.

Não há suporte para downgrades da v3.x para a v2.x. Quando possível, sempre execute seus aplicativos na versão mais recente do runtime do Functions com suporte.

Como alterar a versão de aplicativos no Azure

A versão do runtime do Functions usada por aplicativos publicados no Azure é determinada pela configuração de aplicativo FUNCTIONS_EXTENSION_VERSION. Há suporte para os seguintes valores de versão de runtime principal:

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

Importante

Não altere essa configuração arbitrariamente, pois isso pode requerer outras alterações da configuração do aplicativo e do código de função.

Para obter mais informações, consulte Como direcionar para versões do Azure Functions runtime.

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

Para resolver problemas com seu aplicativo de funções em execução na versão principal mais recente, é necessário fixá-lo em uma versão secundária específica. Isso dá 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.

Como migrar da versão 2.x para a 3.x

O Azure Functions versão 3.x é compatível com versões anteriores à versão 2.x. Muitos aplicativos devem poder ser atualizados com segurança para a 3.x sem nenhuma alteração de código. Embora a migração para a 3. x seja incentivada, execute testes extensivos antes de alterar a versão principal em aplicativos de produção.

Alterações interruptivas entre a 2.x e a 3.x

Faça as alterações a seguir antes de atualizar um aplicativo 2.x para a 3.x.

JavaScript

  • As associações de saída atribuídas pelo context.done ou pelos valores de retorno agora se comportam da mesma forma que a configuração em context.bindings.

  • O objeto de gatilho de temporizador é camelCase em vez de PascalCase

  • As funções disparadas pelo Hub de Eventos com o binário dataType receberão uma matriz binary em vez de string.

  • A carga de solicitação HTTP não pode mais ser acessada por meio de context.bindingData.req. Ela ainda pode ser acessada como um parâmetro de entrada context.req e no context.bindings.

  • Não há mais suporte para o Node.js 8 e ele não será executado em funções da 3.x.

.NET Core

A principal diferença entre as versões durante a execução das funções da biblioteca de classes do .NET é o runtime do .NET Core. A versão 2.x do Functions foi projetada para ser executada no .NET Core 2.2 e a versão 3.x foi projetada para ser executada no .NET Core 3.1.

Observação

Devido a problemas de suporte no .NET Core 2.2, os aplicativos de funções fixados na versão 2 (~2) estão essencialmente em execução no .NET Core 3.1. Para saber mais, consulte o Modo de compatibilidade do Functions v2.x.

Como migrar da 1.x para versões mais recentes

Um aplicativo existente escrito para usar o runtime da versão 1.x pode ser migrado para usar uma versão mais recente. A maioria das alterações necessárias está relacionada a alterações no runtime da linguagem, como alterações de API C# entre o .NET Framework 4.8 e o .NET Core. Você também precisará verificar se seu código e suas bibliotecas são compatíveis com o runtime de linguagem escolhido. Por fim, não deixe de observar as alterações no gatilho, associações e recursos destacados abaixo. Para obter os melhores resultados de migração, é necessário criar um novo aplicativo de funções em uma nova versão e compatibilizar o código de função existente da versão 1.x com o novo aplicativo.

Embora seja possível fazer "localmente" uma atualização manual da configuração do aplicativo, migrar da versão 1.x para uma mais recente inclui algumas alterações interruptivas. Por exemplo, em C#, o objeto de depuração é alterado de TraceWriter para ILogger. Ao criar um novo projeto na versão 3.x, você começa com funções atualizadas com base nos modelos mais recentes da versão 3.x.

Alterações em gatilhos e ligações após a versão 1.x

A partir da versão 2.x, é necessário instalar as extensões de ligações e gatilhos específicos usadas pelas funções em seu aplicativo. A única exceção para isso são os gatilhos de temporizador e HTTP, que não exigem uma extensão. Para obter mais informações, confira Registrar e instalar extensões de associação.

Também há algumas alterações no function.json ou em atributos da função entre as versões. Por exemplo, a propriedade path do Hub de Eventos agora é eventHubName. Veja a tabela de associação existente para obter links para a documentação de cada associação.

Alterações nos recursos e funcionalidades após a versão 1.x

Alguns recursos foram removidos, atualizados ou substituídos após a versão 1.x. Esta seção detalha as mudanças aplicadas às versões mais recentes após ter usado a versão 1.x.

As seguintes alterações foram feitas na versão 2.x:

  • As chaves para chamar pontos de extremidade HTTP são sempre armazenadas criptografadas no Armazenamento de Blobs do Azure. Na versão 1.x, as chaves eram armazenadas nos Arquivos do Azure por padrão. Ao atualizar um aplicativo da versão 1.x para a 2.x, os segredos existentes que estão nos Arquivos do Azure serão redefinidos.

  • A versão 2.x do runtime não inclui suporte interno para provedores de webhook. Essa alteração foi feita para melhorar o desempenho. Você ainda pode usar gatilhos HTTP como pontos de extremidade para webhooks.

  • O arquivo de configuração de host (host.json) deve estar vazio ou ter a cadeia de caracteres "version": "2.0".

  • Para melhorar o monitoramento, o painel WebJobs no portal, o qual usou a configuração AzureWebJobsDashboard, é substituído com o Azure Application Insights, que usa a configuração APPINSIGHTS_INSTRUMENTATIONKEY. Para saber mais, consulte Monitorar Azure Functions.

  • Todas as funções em um aplicativo de funções devem compartilhar a mesma linguagem de programação. Quando você cria um aplicativo de funções, você deve escolher para ele uma pilha de runtime. A pilha de runtime é especificada pelo valor FUNCTIONS_WORKER_RUNTIME nas configurações do aplicativo. Esse requisito foi adicionado para melhorar o tempo de inicialização e o volume. Ao desenvolver localmente, você também deve incluir essa configuração no arquivo local.settings.json.

  • O tempo limite padrão para as funções em um plano do Serviço de Aplicativo foi alterado para 30 minutos. Você pode alterar manualmente o tempo limite para ilimitado, usando a configuração functionTimeout em host.json.

  • Restrições de simultaneidade HTTP são implementadas por padrão para funções de plano de consumo, com um padrão de 100 solicitações simultâneas por instância. Você pode alterar isso na configuração maxConcurrentRequests no arquivo host.json.

  • Devido às limitações do .NET Core, o suporte a funções de script F# (.fsx) foi removido. Funções F# compiladas (.fs) ainda são compatíveis.

  • O formato da URL de webhooks de gatilho da Grade de Eventos foi alterado para https://{app}/runtime/webhooks/{triggerName}.

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:

Versão 3.x
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>

Observação

O Azure Functions 3.x e o .NET requerem que a extensão Microsoft.NET.Sdk.Functions seja pelo menos 3.0.0.

Versão 2.x
<TargetFramework>netcoreapp2.1</TargetFramework>
<AzureFunctionsVersion>v2</AzureFunctionsVersion>
Versão 1.x
<TargetFramework>net472</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
Como atualizar aplicativos da 2.x para a 3.x no Visual Studio

É possível abrir uma função existente voltada à 2.x e migrar para a 3.x editando o arquivo .csproj e atualizando os valores acima. O Visual Studio gerencia as versões de runtime automaticamente para você com base nos metadados do projeto. No entanto, caso você nunca tenha criado um aplicativo da 3.x antes, é possível que o Visual Studio ainda não tenha os modelos e o runtime para a 3.x em seu computador. Isso pode ocorrer na forma de um erro como "não há nenhum runtime do Functions disponível que corresponda à versão especificada no projeto". Para buscar os modelos e o runtime mais recentes, acesse a experiência para criar um novo projeto de função. Ao chegar à tela de seleção da versão e do modelo, aguarde o Visual Studio concluir a busca pelos modelos mais recentes. Depois que os modelos mais recentes do .NET Core 3 estiverem disponíveis e forem exibidos, será possível executar e depurar qualquer projeto configurado para a versão 3.x.

Importante

As funções da versão 3.x só poderão ser desenvolvidas no Visual Studio se ele estiver na versão 16.4 ou mais recente.

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 3.x, instale a versão 3.x do Core Tools. Para desenvolvimentos voltados à versão 2.x, instale a versão 2.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 do azureFunctions.projectRuntime para ~3.

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

Aplicativos Maven e Java

É possível migrar aplicativos Java da versão 2.x para a 3.x instalando a versão 3.x do Core Tools que precisa ser executada localmente. Depois de verificar se seu aplicativo funciona corretamente no local com a versão 3.x, atualize o arquivo POM.xml do aplicativo para modificar a configuração FUNCTIONS_EXTENSION_VERSION para ~3, como no exemplo a seguir:

<configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~3</value>
        </property>
    </appSettings>
</configuration>

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
Dapr3
Grade de Eventos
Hubs de Evento
HTTP e 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 de um aplicativo de funções é definida pela propriedade functionTimeout no arquivo de projeto host.json. A seguinte tabela mostra os valores padrão e máximo em minutos para os planos e as diferentes versões de runtime:

Plano Versão de Runtime Padrão Máximo
Consumo 1.x 5 10
Consumo 2. x 5 10
Consumo 3.x 5 10
Premium 1.x Ilimitado Ilimitado
Premium 2. x 30 Ilimitado
Premium 3.x 30 Ilimitado
Serviço de Aplicativo 1.x Ilimitado Ilimitado
Serviço de Aplicativo 2. x 30 Ilimitado
Serviço de Aplicativo 3.x 30 Ilimitado

Observação

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.

Próximas etapas

Para saber mais, consulte os recursos a seguir: