Introducción a las versiones de tiempo de ejecución de Azure Functions

Artículo
02/24/2023
Tiempo de lectura: 10 minutos

Actualmente, Azure Functions admite varias versiones del host del entorno de ejecución. En la tabla siguiente se detallan las versiones disponibles, su nivel de compatibilidad y cuándo se deben usar:

Versión	Nivel de compatibilidad	Descripción
4.x	GA	*Versión recomendada en tiempo de ejecución para funciones en todos los lenguajes.* Consulte Versiones de lenguajes compatibles.
3.x	GA^*	Alcanzó el fin de la vida útil (EOL) para el soporte extendido el 13 de diciembre de 2022. Se recomienda encarecidamente migrar las aplicaciones a la versión 4.x para obtener soporte completo.
2.x	GA^*	Alcanzó el fin de la vida útil (EOL) el 13 de diciembre de 2022. Se recomienda encarecidamente migrar las aplicaciones a la versión 4.x para obtener soporte completo.
1.x	Disponibilidad general	Solo se admite para aplicaciones de C# que deben usar .NET Framework. Esta versión está en modo de mantenimiento y solo se realizarán mejoras en versiones posteriores. Se recomienda encarecidamente migrar las aplicaciones a la versión 4.x, que admite .NET Framework 4.8.

^*Para obtener una declaración de compatibilidad detallada sobre las versiones de fin de ciclo de vida, consulte este artículo sobre la migración.

En este artículo se detallan algunas de las diferencias entre estas versiones, cómo se puede crear cada versión y cómo cambiar la versión en la que se ejecutan las funciones.

Niveles de soporte

Hay dos niveles de compatibilidad:

Disponibilidad general (GA) : totalmente compatible y aprobado para su uso en producción.
Versión preliminar: todavía no se admite, pero se espera que llegue al estado de disponibilidad general en el futuro.

Lenguajes

Todas las funciones de una aplicación de función deben compartir el mismo lenguaje. Eligió el lenguaje de las funciones en su aplicación de funciones al crearla. El lenguaje de la aplicación de funciones se mantiene en la configuración FUNCTIONS_WORKER_RUNTIME y no se debe cambiar cuando hay funciones existentes.

En la siguiente tabla se indican los lenguajes de programación que se admiten actualmente en cada versión del entorno de ejecución.

Idioma	1.x	2.x¹	3.x¹	4.x
C#	Disponibilidad general (.NET Framework 4.8)	Disponibilidad general (.NET Core 2.1)	Disponibilidad general (.NET Core 3.1)	Disponibilidad general (.NET 6.0) Disponibilidad general (.NET 7.0) Disponibilidad general (.NET Framework 4.8)
JavaScript	Disponibilidad general (Node.js 6)	Disponibilidad general (Node.js 10 & 8)	Disponibilidad general (Node.js 14, 12, & 10)	Disponibilidad general (Node.js 18, 16, & 14)
F#	Disponibilidad general (.NET Framework 4.8)	Disponibilidad general (.NET Core 2.1¹)	Disponibilidad general (.NET Core 3.1)	Disponibilidad general (.NET 6.0) Disponibilidad general (.NET 7.0)
Java	N/D	Disponibilidad general (Java 8)	Disponibilidad general (Java 11 & 8)	Disponibilidad general (Java 11 & 8) Disponibilidad general (Java 17)
PowerShell	N/D	N/D	N/D	Disponibilidad general (PowerShell 7.2)
Python	N/D	Disponibilidad general (Python 3.7)	GA (Python 3.9, 3.8, 3.7)	Disponibilidad general (Python 3.10, 3.9, 3.8, 3.7)
TypeScript²	N/D	GA	Disponibilidad general	Disponibilidad general

¹ Alcanzó el fin de la vida útil (EOL) el 13 de diciembre de 2022. Se recomienda encarecidamente migrar las aplicaciones a la versión 4.x para obtener soporte completo.
² Se admite mediante la transpilación de JavaScript.

Para más información sobre las versiones del lenguaje que se admiten, consulte el artículo de la guía para desarrolladores específica del lenguaje.
Para información sobre los cambios planeados en la compatibilidad de lenguaje, consulte Azure roadmap.

Ejecución en una versión específica

La versión del sistema en ejecución de Functions que usan las aplicaciones publicadas en Azure viene determinada por la configuración de la aplicación FUNCTIONS_EXTENSION_VERSION. En algunos casos y para determinados idiomas, se puede aplicar otra configuración.

De forma predeterminada, las aplicaciones de funciones que se crean en Azure Portal, con la CLI de Azure o desde las herramientas de Visual Studio se establecen en la versión 4.x. Puede modificar esta versión en caso necesario. Solo puede degradar la versión del entorno en tiempo de ejecución a 1.x después de crear la aplicación de funciones, pero antes de agregar ninguna función. Se permite el cambio a una versión posterior incluso en aplicaciones con funciones existentes.

Migración de las aplicaciones de funciones existentes

Cuando la aplicación tiene funciones existentes, debe tomar precauciones antes de pasar a una versión posterior de runtime. En los siguientes artículos se detallan los cambios importantes entre versiones, incluidos los cambios importantes específicos de cada idioma. También se proporcionan instrucciones paso a paso para una migración correcta de la aplicación de funciones existente.

Cambio de la versión de las aplicaciones en Azure

Se usan los siguientes valores principales de la versión del runtime:

Value	Destino del entorno en tiempo de ejecución
`~4`	4.x
`~1`	1.x

Importante

No cambie este valor de aplicación sin motivo, ya que puede requerir otros cambios de valor de aplicación y cambios en el código de función. En su lugar, debe cambiar este valor en la pestaña Configuración del tiempo de ejecución de la función de la aplicación de funciones Configuración en Azure Portal cuando esté listo para realizar una actualización de la versión principal. Para las aplicaciones de funciones existentes, siga las instrucciones de migración.

Anclaje a una versión secundaria específica

Para resolver problemas que pueda tener la aplicación de funciones al ejecutarse en la versión principal más reciente, tiene que anclar temporalmente la aplicación a una versión secundaria determinada. El anclaje le proporciona tiempo para que la aplicación se ejecute correctamente en la versión principal más reciente. La forma de anclar a una versión secundaria difiere entre Windows y Linux. Para más información, consulte Cómo seleccionar un destino para versiones en tiempo de ejecución de Azure Functions.

Las versiones secundarias anteriores se quitan periódicamente de Functions. Para obtener las últimas noticias sobre las versiones de Azure Functions, incluida la eliminación de versiones secundarias específicas anteriores, revise los anuncios de Azure App Service.

Versiones de extensión mínimas

Técnicamente no hay correlación entre las versiones de extensión de enlace y la versión del entorno de ejecución de Functions. Pero a partir de la versión 4.x, el entorno de ejecución de Functions aplica una versión mínima para todas las extensiones de desencadenador y enlace.

Si recibe una advertencia sobre un paquete que no cumple una versión mínima necesaria, debe actualizar ese paquete NuGet a la versión mínima como lo haría normalmente. Los requisitos mínimos de versión de las extensiones usadas en Functions v4.x se pueden encontrar en el archivo de configuración vinculado.

En el caso del script de C#, actualice la referencia del conjunto de extensiones en host.json de la siguiente manera:

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

Técnicamente no hay correlación entre las versiones del conjunto de extensiones y la versión del entorno de ejecución de Functions. Pero a partir de la versión 4.x, el entorno de ejecución de Functions aplica una versión mínima para los conjuntos de extensiones.

Si recibe una advertencia sobre una versión del conjunto de extensiones que no cumple una versión mínima necesaria, actualice la referencia del conjunto de extensiones existente en host.json de la siguiente manera:

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

Para más información sobre los conjuntos de extensiones, vea Conjuntos de extensiones.

Versiones de aplicaciones desarrolladas de forma local

Puede hacer que las siguientes actualizaciones de las aplicaciones de funciones cambien localmente las versiones de destino.

Versiones de Runtime en Visual Studio

En Visual Studio se selecciona la versión del entorno de ejecución al crear un proyecto. Las herramientas de Azure Functions para Visual Studio son compatibles con las tres versiones principales del entorno de ejecución. Se usa la versión correcta al depurar y publicar en función de configuración del proyecto. La configuración de la versión se define en el archivo .csproj en las siguientes propiedades:

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

También puede elegir net6.0, net7.0 o net48 como plataforma de destino si usa funciones de proceso de trabajo aislado de .NET. La compatibilidad con net7.0 y net48 se encuentra actualmente en versión preliminar.

Nota

Azure Functions 4.x requiere que la extensión Microsoft.NET.Sdk.Functions sea al menos 4.0.0.

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

VS Code y Azure Functions Core Tools

Azure Functions Core Tools se usa para el desarrollo de la línea de comandos, pero también lo usa la extensión de Azure Functions para Visual Studio Code. Para más información, consulte Instalación de Azure Functions Core Tools.

Para el desarrollo en Visual Studio Code es posible que deba actualizar la configuración de usuario en azureFunctions.projectRuntime para que coincida con la versión de las herramientas instaladas. Esta configuración también actualiza las plantillas y los lenguajes utilizados durante la creación de la aplicación de función.

Enlaces

A partir de la versión 2.x, el entorno de ejecución usa un nuevo modelo de extensibilidad de enlaces que ofrece estas ventajas:

Compatibilidad con extensiones de enlace de terceros.
Desacoplamiento de tiempo de ejecución y enlaces. Este cambio permite el control de versiones y la publicación de las extensiones de enlace de forma independiente. Por ejemplo, puede elegir actualizar a una versión de una extensión que se basa en una versión más reciente de un SDK subyacente.
Un entorno de ejecución más ligero, donde solo se conocen y se cargan en tiempo de ejecución los enlaces que están en uso.

A excepción de los desencadenadores HTTP y de temporizador, todos los enlaces deben agregarse explícitamente al proyecto de aplicación de funciones o registrarse en el portal. Para más información, consulte Registro de extensiones de enlace.

En la siguiente tabla se indica qué enlaces se admiten en cada versión del entorno de ejecución.

En esta tabla se muestran los enlaces que son compatibles con las versiones principales del entorno en tiempo de ejecución de Azure Functions:

Tipo	1.x	2.x y posteriores¹	Desencadenador	Entrada	Output
Blob Storage	✔	✔	✔	✔	✔
Azure Cosmos DB	✔	✔	✔	✔	✔
Azure SQL (versión preliminar)²		✔	✔	✔	✔
Dapr³		✔	✔	✔	✔
Event Grid	✔	✔	✔		✔
Event Hubs	✔	✔	✔		✔
HTTP webhooks	✔	✔	✔		✔
IoT Hub	✔	✔	✔
Kafka²		✔	✔		✔
Mobile Apps	✔			✔	✔
Centros de notificaciones	✔				✔
Queue Storage	✔	✔	✔		✔
RabbitMQ²		✔	✔		✔
SendGrid	✔	✔			✔
Service Bus	✔	✔	✔		✔
SignalR		✔	✔	✔	✔
Table storage	✔	✔		✔	✔
Temporizador	✔	✔	✔
Twilio	✔	✔			✔

¹ A partir del entorno en tiempo de ejecución de la versión 2.x, se deben registrar todos los enlaces, excepto HTTP y el temporizador. Consulte Registro de extensiones de enlace.

² Los desencadenadores no se admiten en el plan de consumo. Requiere desencadenadores controlados por el runtime.

³ Solo se admite en Kubernetes, IoT Edge y otros modos autohospedados.

Duración del tiempo de espera de una aplicación de función

La duración del tiempo de espera de las funciones en una aplicación de funciones se define mediante la propiedad functionTimeout en el archivo de proyecto host.json. Esta propiedad se aplica específicamente a las ejecuciones de funciones. Una vez que el desencadenador inicia la ejecución de la función, la función debe devolver o responder dentro de la duración del tiempo de espera. Para más información, consulte Mejorar el rendimiento y la confiabilidad de Azure Functions.

En la tabla siguiente se muestran los valores predeterminados y máximos (en minutos) para planes específicos:

Plan	Valor predeterminado	Máximo ¹
Plan de consumo	5	10
Plan Premium	30²	Sin límite
Plan dedicado	30²	Sin límite

¹ Independientemente de la configuración del tiempo de espera de la aplicación de función, 230 segundos es la cantidad de tiempo máxima que una función desencadenada por HTTP puede tardar en responder a una solicitud. Esto se debe al tiempo de espera de inactividad predeterminado de Azure Load Balancer. Para tiempos de procesamiento más largos, considere la posibilidad de usar el patrón asincrónico de Durable Functions o aplazar el trabajo real y devolver una respuesta inmediata.
² El tiempo de espera predeterminado para la versión 1.x del runtime de Functions es ilimitado.

Pasos siguientes

Para obtener más información, consulte los siguientes recursos: