Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Al crear una instancia de aplicación de funciones en Azure, debe proporcionar acceso a una cuenta de Azure Storage predeterminada. En el diagrama y la tabla siguientes se detalla cómo Azure Functions usa servicios en la cuenta de almacenamiento predeterminada:
Selecciona tu plan de alojamiento al principio de este artículo para ver la guía de almacenamiento que se aplica a tu aplicación de funciones.
| Servicio de Storage | Uso de Functions |
|---|---|
| Azure Blob Storage | Mantener el estado de los enlaces y las teclas de función 1. Origen de implementación para aplicaciones que se ejecutan en un Plan de consumo flexible. Se utiliza por defecto para los task hubs en Durable Functions. Se puede usar para almacenar el código de la aplicación de funciones para la Compilación remota del Consumo para Linux o como parte de las implementaciones de URL de paquetes externos. |
| Azure Files2 | Recurso compartido de archivos que se utiliza para almacenar y ejecutar el código de la aplicación de funciones en un plan de consumo y un plan prémium. Mantener conjuntos de extensiones. Almacene los registros de implementación. Admite dependencias administradas en PowerShell. |
| Azure Queue Storage | Se utiliza por defecto para los task hubs en Durable Functions. Se usa para el control de errores y reintentos en desencadenadores específicos de Azure Functions. Se usa para el seguimiento de objetos mediante el desencadenador Blob Storage. |
| Azure Table Storage | Se utiliza por defecto para los task hubs en Durable Functions. Se usa para realizar el seguimiento de eventos de diagnóstico. |
- Blob Storage es el almacén predeterminado para las claves de función, pero puede configurar un almacén alternativo.
- Azure Files está configurado de forma predeterminada, pero puedes crear una aplicación sin Azure Files en determinadas condiciones.
Consideraciones importantes
Considera los siguientes datos sobre las cuentas de almacenamiento que usan tus aplicaciones de funcionamiento:
Cuando alojas tu aplicación de función en el plan Consumo (Windows) o Premium, almacenas tu código de función y archivos de configuración en Azure Files en la cuenta de almacenamiento vinculada. Si eliminas esta cuenta de almacenamiento, eliminas el contenido de forma permanente. Para obtener más información, consulte Cuenta de almacenamiento eliminada.
La cuenta de almacenamiento conserva datos importantes, como código de función, claves de acceso y otros datos importantes relacionados con el servicio. Debe administrar cuidadosamente el acceso a las cuentas de almacenamiento que usan las aplicaciones de funciones de las siguientes maneras:
Audite y limite el acceso de las aplicaciones y los usuarios a la cuenta de almacenamiento en función de un modelo con privilegios mínimos. Los permisos para la cuenta de almacenamiento pueden proceder de acciones de datos en el rol asignado o del permiso para realizar la operación listKeys.
Supervise la actividad del plano de control (por ejemplo, la recuperación de claves) y las operaciones del plano de datos (como escribir en un blob) en la cuenta de almacenamiento. Considere la posibilidad de mantener los registros de almacenamiento en una ubicación distinta de Azure Storage. Para más información, consulte Registros de Storage.
Si usa Durable Functions, el almacenamiento del concentrador de tareas es especialmente sensible desde el punto de vista de la seguridad, porque el acceso de escritura a este puede usarse para modificar el comportamiento de la aplicación, incluida la activación de la ejecución arbitraria de código. Para obtener más información, consulte Protección del almacenamiento del centro de tareas.
Requisitos de la cuenta de almacenamiento
Las cuentas de almacenamiento que se crean durante el proceso de creación de la aplicación de funciones en el portal de Azure funcionan con la nueva aplicación de funciones. Cuando decide usar una cuenta de almacenamiento existente, la lista proporcionada no incluye determinadas cuentas de almacenamiento no admitidas. Las restricciones siguientes se aplican a las cuentas de almacenamiento que usa la aplicación de funciones. Asegúrate de que una cuenta de almacenamiento existente cumpla con estos requisitos:
- No puede utilizar una cuenta de almacenamiento protegida por la red cuando su aplicación de funciones está hospedada en el plan de Consumo.
El tipo de cuenta debe ser compatible con el almacenamiento en Blob, Cola y Tabla. Algunas cuentas de almacenamiento no admiten el uso de colas y tablas; Estas cuentas incluyen cuentas de almacenamiento de solo blobs y cuentas de Azure Premium Storage. Para más información sobre los tipos de cuentas de almacenamiento, consulte Introducción a las cuentas de almacenamiento.
Al crear la aplicación de funciones en el portal de Azure, solo puede elegir una cuenta de almacenamiento existente en la misma región que la aplicación de funciones que cree. Este requisito es una optimización del rendimiento y no una limitación estricta. Para más información, consulte Ubicación de la cuenta de almacenamiento.
Al crear tu aplicación de función en un plan con compatibilidad con zona de disponibilidad habilitada, solo se admiten cuentas de almacenamiento con redundancia de zona.
Al usar la automatización de implementación para crear la aplicación de funciones con una cuenta de almacenamiento protegida por red, debe incluir configuraciones de red específicas en la plantilla de ARM o en el archivo de Bicep. Si no incluye esta configuración y recursos, es posible que se produzca un error en la validación de la implementación automatizada. Para obtener instrucciones sobre las plantillas ARM y Bicep, consulte Implementaciones seguras. Para obtener información general sobre cómo configurar cuentas de almacenamiento con redes, consulte Cómo usar una cuenta de almacenamiento protegida con Azure Functions.
Guía de la cuenta de almacenamiento
Cada aplicación de función requiere una cuenta de almacenamiento para funcionar. Al eliminar esa cuenta, la aplicación de funciones deja de ejecutarse. Para más información, consulte este artículo sobre la solución de problemas relacionados con el almacenamiento. Las siguientes consideraciones se aplican a la cuenta de almacenamiento que usan las aplicaciones de funciones.
Ubicación de la cuenta de almacenamiento
Para obtener el mejor rendimiento, la aplicación de función debe usar una cuenta de almacenamiento de la misma región, lo que reduce la latencia. El portal de Azure aplica este procedimiento recomendado. Si necesita usar una cuenta de almacenamiento en una región diferente de la aplicación de funciones, debe crear la aplicación de funciones fuera del portal de Azure.
La cuenta de almacenamiento debe ser accesible para la aplicación de funciones. Si necesitas usar una cuenta de almacenamiento segura, considera restringir tu cuenta de almacenamiento a una red virtual.
Configuración de la conexión de la cuenta de almacenamiento
De forma predeterminada, las aplicaciones de funciones configuran la conexión AzureWebJobsStorage como una cadena de conexión almacenada en la configuración de la aplicación AzureWebJobsStorage. También puede configurar AzureWebJobsStorage para usar una conexión basada en identidades sin un secreto.
Las aplicaciones de funciones que se ejecutan en un plan de consumo (solo Windows) o un plan Elastic Premium (Windows o Linux) pueden usar Azure Files para almacenar las imágenes necesarias para habilitar el escalado dinámico. Para estos planes, establezca la cadena de conexión de la cuenta de almacenamiento en la configuración WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y el nombre del recurso compartido de archivos en la configuración WEBSITE_CONTENTSHARE. Este valor suele ser la misma cuenta que se usa para AzureWebJobsStorage. También puede crear una aplicación de funciones que no use Azure Files, pero el escalado puede ser limitado.
Nota:
Debe actualizar la cadena de conexión de una cuenta de almacenamiento al regenerar las claves de almacenamiento. Para obtener más información, consulte Create an Azure storage account.
Cuentas de almacenamiento compartidas
Varias aplicaciones de funciones pueden compartir la misma cuenta de almacenamiento sin problemas. Por ejemplo, en Visual Studio, puede desarrollar varias aplicaciones mediante el emulador de almacenamiento Azurite. En este caso, el emulador actúa como una cuenta de almacenamiento única. La misma cuenta de almacenamiento que usa la aplicación de funciones también puede almacenar los datos de la aplicación. Sin embargo, este enfoque no siempre resulta conveniente en los entornos de producción.
Es posible que tenga que usar cuentas de almacenamiento independientes para evitar colisiones de los id.de host.
Consideraciones sobre la directiva de administración del ciclo de vida
No aplique directivas de administración de ciclo de vida a la cuenta de almacenamiento de blobs utilizada por su aplicación de funciones. Functions usa Blob Storage para conservar información importante, como las claves de acceso de funciones. Las directivas podrían quitar blobs, como claves, necesarias para el host de Functions. Si necesita usar directivas, excluya los contenedores usados por Functions, que llevan el prefijo azure-webjobs o scm.
Registros de almacenamiento
Dado que el código de función y las claves pueden persistir en la cuenta de almacenamiento, el registro de la actividad contra la cuenta de almacenamiento es una buena manera de supervisar los accesos no autorizados. Los registros de recursos de Azure Monitor se pueden usar para realizar un seguimiento de eventos en el plano de datos de almacenamiento. Consulte Monitoring Azure Storage para obtener más información sobre cómo configurar y examinar estos registros.
El registro de actividad Azure Monitor muestra eventos del plano de control, incluida la operación listKeys. Sin embargo, también debe configurar los registros de recursos para que la cuenta de almacenamiento realice un seguimiento del uso posterior de claves u otras operaciones del plano de datos basado en identidades. Debería tener habilitada al menos la categoría de registro StorageWrite para poder identificar las modificaciones de los datos fuera de las operaciones normales de Funciones.
Para limitar el posible impacto de los permisos de almacenamiento de ámbito amplio, considere la posibilidad de usar un destino que no sea de almacenamiento para estos registros, como Log Analytics. Para obtener más información, consulte Monitoring Azure Blob Storage.
Optimización del rendimiento de almacenamiento
Para maximizar el rendimiento, use una cuenta de almacenamiento independiente para cada aplicación de función. Este enfoque es especialmente importante cuando tiene funciones activadas por Durable Functions o Event Hubs, que generan un gran volumen de transacciones de almacenamiento. Cuando la lógica de la aplicación interactúa con Azure Storage, ya sea directamente (mediante el SDK de Storage) o a través de uno de los enlaces de almacenamiento, debe usar una cuenta de almacenamiento dedicada. Por ejemplo, si tiene una función desencadenada por el centro de eventos que escribe algunos datos en Blob Storage, use dos cuentas de almacenamiento: una para la aplicación de funciones y otra para los blobs que almacena la función.
Enrutamiento coherente a través de redes virtuales
Varias aplicaciones de funciones hospedadas en el mismo plan también pueden usar la misma cuenta de almacenamiento para el recurso compartido de contenido de Azure Files, definido por WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Cuando protege esta cuenta de almacenamiento mediante una red virtual, todas estas aplicaciones (incluidos slots) deben usar el mismo valor para vnetContentShareEnabled (anteriormente WEBSITE_CONTENTOVERVNET) y la misma configuración de integración de red virtual para garantizar que el tráfico se dirija de forma coherente a través de la red virtual designada. Una discrepancia en esta configuración entre las aplicaciones que usan la misma cuenta de almacenamiento de Azure Files podría dar lugar al enrutamiento del tráfico a través de redes públicas. En esta configuración, las reglas de red de la cuenta de almacenamiento bloquean el acceso.
La vnetContentShareEnabled guía no se aplica a Flex Consumption, Dedicated, Container Apps o Consumption Hosting.
Trabajo con blobs
Un escenario clave para Functions es el procesamiento de archivos en un contenedor de blobs, como el procesamiento de imágenes o el análisis de sentimiento. Para más información, consulte Procesamiento de cargas de archivos.
Desencadenador en un contenedor de blobs
Hay varias maneras de ejecutar el código de función en función de los cambios en los blobs de un contenedor de almacenamiento, como se indica en este diagrama:
Use la tabla siguiente para determinar qué desencadenador de función se adapta mejor a sus necesidades de procesamiento de blobs agregados o actualizados en un contenedor:
| Estrategia | Desencadenador de blobs (sondeo) | Desencadenador de blobs (controlado por eventos) | Desencadenador de la cola: | Desencadenador de Event Grid |
|---|---|---|---|---|
| Latencia | Alto (hasta 10 minutos) | Bajo | Media | Bajo |
| Limitaciones de la cuenta de almacenamiento | No soporta cuentas solo blob¹ ni cuentas que tengan activado el espacio de nombres jerárquico (HNS), como las cuentas de Azure Data Lake Storage Gen2 | No soporta cuentas de uso general v1 | Ninguno | No soporta cuentas de uso general v1 |
| Tipo de desencadenador | Blob Storage | Blob Storage | Queue Storage | Grid de eventos |
| Versión de la extensión | Cualquiera | Storage v5.x+ | Cualquiera | Cualquiera |
| Procesa los blobs existentes | Sí | No | No | No |
| Filtros | Patrón de nombre de blob | Filtros de eventos | N/D | Filtros de eventos |
| Requiere una suscripción de eventos | No | Sí | No | Sí |
| Admite el plan de consumo flexible | No | Sí | Sí | Sí |
| Admite la gran escala² | No | Sí | Sí | Sí |
| Funciona con restricciones de acceso entrantes | Sí | No | Sí | Sí3 |
| Descripción | Comportamiento predeterminado del desencadenador, que se basa en sondear el contenedor para obtener actualizaciones. Para más información, consulte los ejemplos de la referencia del desencadenador de Blob Storage. | Consume eventos de Blob Storage de una suscripción de eventos. Requiere un valor del parámetro Source de EventGrid. Para más información, consulte Tutorial: Desencadenamiento de Azure Functions en contenedores de blobs mediante una suscripción de eventos. |
La cadena de nombre de blob se agrega manualmente a una cola de almacenamiento cuando se agrega un blob al contenedor. Un desencadenador de Queue Storage pasa este valor directamente a un enlace de entrada de Blob Storage en la misma función. | Proporciona la flexibilidad de desencadenar eventos además de los eventos que proceden de un contenedor de almacenamiento. Úselo cuando también necesite que los eventos que no son de almacenamiento desencadenen la función. Para obtener más información, consulte Cómo trabajar con desencadenadores y enlaces de Event Grid en Azure Functions. |
- La limitación de cuenta solo para blobs se aplica únicamente al desencadenador de Blob Storage basado en sondeo. Los enlaces de entrada y salida de Blob Storage admiten cuentas de solo blob.
- Gran escala se aplica generalmente a contenedores que tienen más de 100 000 blobs en ellos o a cuentas de almacenamiento que tienen más de 100 actualizaciones de blob por segundo.
- Puede solucionar las restricciones de acceso entrantes haciendo que la suscripción de eventos entregue eventos a través de un canal cifrado en el espacio de ip pública mediante una identidad de usuario conocida. Para obtener más información, consulte Entrega de eventos de forma segura mediante identidades administradas.
Cifrado de datos de almacenamiento
Azure Storage cifra todos los datos de una cuenta de almacenamiento en reposo. Para obtener más información, consulte cifrado de Azure Storage para datos en reposo.
De forma predeterminada, los datos se cifran con claves administradas Microsoft. Para obtener más control sobre las claves de cifrado, puede proporcionar claves administradas por el cliente para usarlas para el cifrado de datos de blobs y archivos. Estas claves deben estar presentes en Azure Key Vault para que Functions pueda acceder a la cuenta de almacenamiento. Para más información, consulte Cifrado de los datos de la aplicación en reposo mediante claves administradas por el cliente.
Residencia de datos en la región
Cuando todos los datos del cliente deben permanecer dentro de una sola región, utiliza una cuenta de almacenamiento asociada a la aplicación de función que tenga redundancia dentro de la región. También usa una cuenta de almacenamiento redundante dentro de la región con Azure Durable Functions.
La plataforma almacena otros datos de cliente administrados por la plataforma únicamente dentro de la región cuando se aloja en un App Service Environment (ASE) con equilibrio de carga interno. Para más información, consulte Redundancia de zona de ASE.
Consideraciones sobre el id. de host
Las consideraciones sobre el identificador del host en esta sección no se aplican a Flex Consumption. En este plan de alojamiento, el valor del ID de host se genera de manera que evita estos posibles problemas.
Functions utiliza un valor de ID de host para identificar de forma única una aplicación de funciones particular en artefactos almacenados. Por defecto, el tiempo de ejecución genera automáticamente este ID a partir del nombre de la aplicación de función, truncado a los primeros 32 caracteres. El entorno de ejecución usa este identificador al almacenar información de correlación y seguimiento por aplicación en la cuenta de almacenamiento vinculada. Cuando las aplicaciones de función tienen nombres de más de 32 caracteres y los primeros 32 caracteres son idénticos, este truncado puede dar lugar a valores de identificador de host duplicados. Cuando dos aplicaciones de función con IDs de host idénticos usan la misma cuenta de almacenamiento, se produce una colisión de ID de host porque los datos almacenados no pueden vincularse de forma única a la aplicación de función correcta.
Nota:
El mismo tipo de colisión de ID de host puede producirse entre una aplicación de funciones en una ranura de producción y la misma aplicación de funciones en una ranura de ensayo, cuando ambas ranuras usan la misma cuenta de almacenamiento.
En la versión 4.x del tiempo de ejecución de Functions, se registra un error y el host se detiene, lo que resulta en un fallo total. Para obtener más información, vea HostID Truncation puede causar colisiones.
Evitar colisiones de los id. de host
Utiliza las siguientes estrategias para evitar colisiones con ID de host:
- Utiliza cuentas de almacenamiento separadas para que cada host que colisiona escriba en una cuenta diferente.
- Cambia el nombre de una de tus aplicaciones de Functions para que su nombre tenga menos de 32 caracteres, lo que cambia el identificador de host calculado de la aplicación y elimina la colisión.
- Establezca un identificador de host explícito para una o varias de las aplicaciones en colisión. Para más información, consulte Invalidación del identificador de host.
Importante
Cambiar la cuenta de almacenamiento asociada a una aplicación de funciones existente o cambiar el identificador de host de la aplicación puede afectar al comportamiento de las funciones existentes. Por ejemplo, un desencadenador de Blob Storage hace un seguimiento de si se procesan blobs individuales al escribir recibos en una ruta de acceso del id. de host específica en el almacenamiento. Cuando el id. de host cambia o apunta a una nueva cuenta de almacenamiento, se pueden volver a procesar los blobs procesados anteriormente.
Invalidación del id. de host
Puedes establecer un ID de host explícito para tu aplicación de función en la configuración de la aplicación mediante la opción AzureFunctionsWebHost__hostid. Para más información, consulte AzureFunctionsWebHost__hostid.
Cuando ocurre una colisión entre ranuras, debes establecer un ID de host específico para cada ranura, incluyendo la ranura de producción. También debe marcar esta configuración como configuración de implementación para que no se intercambie. Para obtener información sobre cómo crear la configuración de la aplicación, consulte Trabajar con la configuración de la aplicación.
Creación de una aplicación sin Azure Files
El servicio Azure Files proporciona un sistema de archivos compartido que admite escenarios a gran escala. Cuando la aplicación de funciones se ejecuta en un plan Elastic Premium o en Windows en un plan de consumo, se crea un recurso compartido de Azure Files de forma predeterminada en la cuenta de almacenamiento. Las funciones pueden usar este recurso compartido para funciones como la transmisión de registros y como ubicación compartida de contenido de la app. La ubicación de despliegue depende de la tecnología de despliegue y de la configuración de la aplicación. Por ejemplo, una aplicación que utiliza una URL externa de paquete ejecuta su paquete desde la URL configurada en lugar del recurso compartido de Azure Files.
Usar Azure Files requiere una cadena de conexión, que guardas en la configuración de tu app como WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Azure Files no admite actualmente conexiones basadas en identidades. Si tu escenario requiere que no almacenes ningún secreto en la configuración de la app, debes eliminar la dependencia de tu app de Azure Files. Puede evitar esta dependencia mediante la creación de la aplicación sin la dependencia de Azure Files predeterminada.
Nota:
También deberías considerar ejecutar tu aplicación de funciones en el plan Flex Consumption, que ofrece un mayor control sobre el paquete de despliegue, incluyendo la capacidad de usar conexiones de identidad gestionada. Para obtener más información, consulte Configuración de las opciones de implementación.
Para ejecutar tu aplicación sin el recurso compartido de Azure Files, debes cumplir los siguientes requisitos:
Debes desplegar tu paquete en un contenedor de Azure Blob Storage que no permita el acceso anónimo y establecer la URL de Blob Storage del paquete como
WEBSITE_RUN_FROM_PACKAGEconfiguración de la app.Para evitar almacenar una credencial de despliegue en la URL del paquete, concede acceso a la identidad gestionada de la aplicación de funciones al paquete. Cuando use una identidad asignada por el usuario, establezca también
WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID. Si no puedes usar la identidad gestionada, usa una URL de firma de acceso compartido (SAS) y renuévala antes de que expire el SAS.Para eliminar la cadena de conexión de la cuenta de almacenamiento del host predeterminada de la configuración de la aplicación, configura
AzureWebJobsStoragepara usar una identidad administrada.Debes actualizar manualmente el paquete de despliegue y mantener la URL del paquete de despliegue. Para información sobre cómo reiniciar la aplicación y sincronizar los disparadores al actualizar el paquete, consulta Ejecutar desde una URL externa de paquete.
También debe tener en cuenta las siguientes consideraciones:
- Tu app no puede depender de un sistema de archivos compartido y escribible.
- No se admite la edición del portal.
- Las experiencias de streaming de registros en clientes como el portal de Azure tienen como valor predeterminado los registros del sistema de archivos. En su lugar, deben basarse en registros de Application Insights.
Si los requisitos anteriores se ajustan a su escenario, puede continuar con la creación de una aplicación de funciones sin Azure Files. Cree una aplicación sin las configuraciones de aplicación WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE de alguna de estas maneras:
- Plantillas Bicep/ARM: elimina los dos ajustes de la app de la plantilla ARM o del archivo Bicep y luego despliega la app usando la plantilla modificada.
- El portal de Azure: borra Añadir una conexión de Azure Files en la pestaña de Almacenamiento cuando crees la aplicación en el portal de Azure.
Azure Files se usa para habilitar el escalado horizontal dinámico para Functions. El escalado podría limitarse al ejecutar la aplicación sin Azure Files en el plan Elastic Premium y los planes de consumo que se ejecutan en Windows.
Flex Consumption no depende de un contenido compartido de Azure Files. Utiliza almacenamiento configurable de despliegue de Blob y soporta conexiones de identidad gestionadas. Para obtener más información, consulte Configuración de las opciones de implementación.
Las aplicaciones de planes dedicados no tienen la dependencia predeterminada de Azure Files en el contenido compartido descrita en esta sección.
Las funciones en Azure Container Apps no tienen la dependencia predeterminada de Azure Files en el contenido compartido descrita en esta sección.
Montaje de recursos compartidos de archivos
Esta funcionalidad solo está disponible cuando se ejecuta en Linux.
Puedes montar recursos compartidos de Azure Files en tus aplicaciones de función de Linux, que podrás usar para acceder a archivos existentes, modelos de aprendizaje automático o archivos binarios de gran tamaño desde tus funciones. Para obtener instrucciones conceptuales sobre cómo elegir entre montajes de almacenamiento, enlaces y bases de datos externas, consulte Choose a file access strategy for Azure Functions.
Flex Consumption solo admite montajes de Azure Files mediante Server Message Block (SMB).
Utiliza el siguiente comando para montar un recurso compartido existente en tu aplicación de funciones para Linux.
az webapp config storage-account add
En este comando, share-name es el nombre del recurso compartido de Azure Files existente.
custom-id puede ser cualquier cadena que defina de forma única el recurso compartido cuando se monta en la aplicación de funciones. Además, mount-path es la ruta de acceso desde la que se accede al recurso compartido en la aplicación de funciones.
mount-path debe estar en el formato /dir-name y no puede comenzar con /home.
Para obtener un ejemplo completo, consulte Crear una aplicación de funciones de Python y montar un recurso compartido de Azure Files.
Para Functions on Azure Container Apps, configura un volumen de Azure Files en la app contenedor. Para obtener más información, consulte Cómo utilizar los montajes de almacenamiento en Azure Container Apps.
Los montajes de almacenamiento no se admiten en el plan Consumo .
Importante
Las aplicaciones de funciones que siguen ejecutándose con el tiempo de ejecución v3 en su fase de fin de vida útil en Linux, en un plan de consumo, dejarán de ejecutarse después del 30 de septiembre de 2026. Para evitar interrupciones del servicio, migre la aplicación al entorno de ejecución v4.
La opción de hospedar aplicaciones de funciones en Linux en un plan de consumo se retira el 30 de septiembre de 2028. El plan de consumo de Linux no recibirá nuevas características ni versiones de idioma. Las aplicaciones que se ejecutan en Windows en un plan de consumo no se ven afectadas actualmente. Migre las aplicaciones al plan de consumo flexible antes de la fecha de retirada.