Creación y administración de aplicaciones de funciones en el plan de consumo flexible

En este artículo se muestra cómo crear aplicaciones de funciones hospedadas en el plan de consumo flexible en Azure Functions. También se muestra cómo administrar determinadas características de una aplicación hospedada en el plan de consumo flexible.

Los recursos de la aplicación de funciones son específicos del lenguaje. Asegúrese de elegir el lenguaje de desarrollo de código preferido al principio del artículo.

Requisitos previos

  • Una cuenta de Azure con una suscripción activa. Si no la tiene, puede crear una cuenta gratis.

  • CLI de Azure: se usa para crear y administrar recursos en Azure. Al usar la CLI de Azure en el equipo local, asegúrese de usar la versión 2.60.0 o una versión posterior. También puede usar Azure Cloud Shell, que tiene la versión correcta de la CLI de Azure.

  • Para las aplicaciones de Go, use CLI de Azure versión 2.87.0 o posterior. Ejecute az version para comprobar la versión instalada.

Creación de una aplicación de consumo flexible

En esta sección se muestra cómo crear una aplicación de funciones en el plan de consumo flexible mediante la CLI de Azure, Azure Portal o Visual Studio Code. Para obtener un ejemplo de creación de una aplicación en un plan de consumo flexible mediante plantillas de Bicep/ARM, consulte el repositorio de consumo flexible.

Puede omitir esta sección si decide crear e implementar la aplicación mediante Maven.

Para admitir el código de la función, debe crear tres recursos:

  • Un grupo de recursos, que es un contenedor lógico de recursos relacionados.
  • Una cuenta de almacenamiento, que se usa para mantener el estado y otra información sobre sus funciones.
  • Una aplicación de funciones en el plan de consumo flexible, que proporciona el entorno para ejecutar el código de función. Una aplicación de funciones se asigna a un proyecto de función local y le permite agrupar funciones como una unidad lógica, lo que facilita la administración, la implementación y el uso compartido de recursos en el plan de consumo flexible.

  1. Si todavía no lo ha hecho, inicie sesión en Azure:

    az login

    El comando az login inicia sesión en la cuenta de Azure.

  2. Use el az functionapp list-flexconsumption-locations comando para revisar la lista de regiones que admiten actualmente Flex Consumption en orden alfabético.

    az functionapp list-flexconsumption-locations --query "sort_by(@, &name)[].{Region:name}" -o table

  1. Cree un grupo de recursos en una de las regiones admitidas actualmente enumeradas por el comando en el paso anterior.

    az group create --name <RESOURCE_GROUP> --location <REGION>

    En el comando anterior, reemplace por <RESOURCE_GROUP> un valor único en la suscripción y <REGION> por una de las regiones admitidas actualmente. El comando az group create crea un grupo de recursos.

  2. Cree una cuenta de almacenamiento de uso general en su grupo de recursos y región:

    az storage account create --name <STORAGE_NAME> --location <REGION> --resource-group <RESOURCE_GROUP> --sku Standard_LRS --allow-blob-public-access false

    En el ejemplo anterior, reemplace por <STORAGE_NAME> un nombre adecuado para usted y único en Azure Storage. Los nombres deben contener tres a 24 caracteres que constan solo de números y letras minúsculas. Standard_LRS especifica una cuenta de uso general que Azure Functions admite según los requisitos de la cuenta de almacenamiento. El comando az storage account create crea la cuenta de almacenamiento.

    Importante

    La cuenta de almacenamiento se usa para almacenar datos importantes de la aplicación, a veces, incluso, el propio código de la aplicación. Debe limitar el acceso a la cuenta de almacenamiento desde otras aplicaciones y usuarios.

  3. Cree la aplicación de funciones en Azure:

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime dotnet-isolated --runtime-version 8.0

    Las aplicaciones de C# que se ejecutan In-Process no se admiten actualmente al ejecutarse en un plan de consumo flexible.

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime java --runtime-version 17

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime node --runtime-version 20

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime python --runtime-version 3.11

    Para las aplicaciones de Python, Python 3.10 también se admite actualmente.

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime powershell --runtime-version 7.4

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime go --runtime-version 1.0 --functions-version 4
az resource update --resource-group <RESOURCE_GROUP> --resource-type Microsoft.Web/sites --name <APP_NAME> --set properties.siteConfig.http20Enabled=false

    El az resource update comando deshabilita HTTP/2 en la aplicación de funciones, que es necesaria durante la versión preliminar pública de Go.

    En este ejemplo, reemplace tanto <RESOURCE_GROUP> como <STORAGE_NAME> por el grupo de recursos y el nombre de la cuenta que ha usado en el paso anterior, respectivamente. Además, reemplace <APP_NAME> por un nombre único global adecuado para usted. <APP_NAME> también es el dominio del servidor de nombres de dominio (DNS) predeterminado de la aplicación de funciones. El comando az functionapp create crea la aplicación de funciones en Azure.

    El az functionapp create comando crea una aplicación de funciones que se ejecuta en el plan de consumo flexible.

    Dado que ha creado la aplicación sin especificar instancias siempre preparadas, la aplicación solo incurre en costos al ejecutar activamente las funciones. El comando también crea una instancia asociada de Application Insights de Azure en el mismo grupo de recursos con la que puede supervisar la aplicación de funciones y ver registros. Para más información, consulte Supervisión de Azure Functions.

Implementación del proyecto de código

Para la implementación, las aplicaciones del plan de consumo flexible usan un contenedor de Blob Storage para hospedar archivos de paquete .zip que contienen el código del proyecto y todas las bibliotecas necesarias para que se ejecute la aplicación. Para obtener más información, consulte Implementación.

Puede omitir esta sección si decide crear e implementar la aplicación mediante Maven.

Puede optar por implementar el código del proyecto en una aplicación de funciones existente mediante varias herramientas:

La implementación de Go requiere Azure Functions Core Tools versión 4.12 o posterior. Ejecute func --version para comprobar la versión instalada.

Puede usar la CLI de Azure para cargar un archivo de paquete de implementación en el recurso compartido de implementación de una aplicación de funciones en Azure. Para realizar esta implementación, debe generar un archivo de paquete de .zip que se pueda ejecutar cuando el paquete se monte en la aplicación.

Este archivo de paquete debe contener todos los archivos de salida de compilación y las bibliotecas a las que se hace referencia necesarios para que el proyecto se ejecute.

Para los proyectos con un gran número de bibliotecas, empaquete la raíz del archivo del proyecto y solicite una compilación remota.

En los proyectos de Python, empaqueta la carpeta raíz de tu proyecto y solicita siempre una compilación remota. El uso de una compilación remota evita posibles problemas que pueden producirse al compilar un proyecto en Windows para implementarse en Linux.

En el caso de los proyectos de Go, use Core Tools para crear un paquete de .zip listo para ejecutarse localmente y, a continuación, implemente ese paquete con el CLI de Azure. No solicite una compilación remota para los paquetes de Go creados por func pack.

  1. Con la herramienta de desarrollo preferida, compile el proyecto de código.

  2. Cree un archivo .zip que contenga la salida del directorio de compilación. Para obtener más información, vea Estructura del proyecto.

  3. Cuando sea necesario, inicie sesión en la cuenta de Azure y seleccione la suscripción activa mediante el comando az login.

    az login

  4. Ejecute el az functionapp deployment source config-zip comando para implementar el paquete de aplicación ubicado en el relativo <FILE_PATH>.

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP>

  1. Con la herramienta de desarrollo preferida, compile el proyecto de código.

  2. Cree un archivo .zip que contenga la salida del directorio de compilación. Para obtener más información, consulte Estructura de carpetas.

  3. Cuando sea necesario, inicie sesión en la cuenta de Azure y seleccione la suscripción activa mediante el comando az login.

    az login

  4. Ejecute el az functionapp deployment source config-zip comando para implementar el paquete de aplicación ubicado en el relativo <FILE_PATH>.

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP>

  1. Cree un archivo .zip que contenga el directorio raíz del proyecto de código. Para obtener más información, consulte Estructura de carpetas.

  2. Cuando sea necesario, inicie sesión en la cuenta de Azure y seleccione la suscripción activa mediante el comando az login.

    az login

  3. Ejecute el az functionapp deployment source config-zip comando para implementar el paquete de aplicación ubicado en el relativo <FILE_PATH>.

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP>

  1. Cree un archivo .zip que contenga el directorio raíz del proyecto de código. Para obtener más información, consulte Estructura de carpetas.

  2. Cuando sea necesario, inicie sesión en la cuenta de Azure y seleccione la suscripción activa mediante el comando az login.

    az login

  3. Ejecute el az functionapp deployment source config-zip comando para implementar el paquete de aplicación ubicado en el relativo <FILE_PATH>.

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP> --build-remote true

    Asegúrese de establecer --build-remote true para realizar una compilación remota.

  1. Cree un archivo .zip que contenga el directorio raíz del proyecto de código. Para obtener más información, consulte Estructura de carpetas.

  2. Cuando sea necesario, inicie sesión en la cuenta de Azure y seleccione la suscripción activa mediante el comando az login.

    az login

  3. Ejecute el az functionapp deployment source config-zip comando para implementar el paquete de aplicación ubicado en el relativo <FILE_PATH>.

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP> --build-remote true

    Asegúrese de establecer --build-remote true para realizar una compilación remota.

  1. En la carpeta del proyecto raíz, ejecute este comando de Core Tools para compilar y empaquetar el proyecto de Go:

    func pack

    De forma predeterminada, el archivo de salida .zip tiene el mismo nombre que la carpeta del proyecto.

  2. Cuando sea necesario, inicie sesión en su cuenta de Azure y seleccione la suscripción activa mediante el az login comando .

    az login

  3. Ejecute el az functionapp deployment source config-zip comando para implementar el paquete ubicado en <ZIP_FILE_PATH>.

    az functionapp deployment source config-zip --resource-group <RESOURCE_GROUP> --name <APP_NAME> --src <ZIP_FILE_PATH>

Creación e implementación de la aplicación mediante Maven

Puede usar Maven para crear una aplicación de funciones hospedada de Flex Consumption y los recursos necesarios durante la implementación modificando el pom.xml archivo.

  1. Cree un proyecto de código Java completando la primera parte de uno de los siguientes artículos de inicio rápido:

  2. En el proyecto de código de Java, abra el archivo pom.xml y realice estos cambios para crear la aplicación de funciones en el plan de consumo flexible:

    • Cambie el valor de <properties>.<azure.functions.maven.plugin.version> a 1.34.0.

    • En la sección <plugin>.<configuration> de azure-functions-maven-plugin, agregue o quite la marca de comentario del elemento <pricingTier> de la siguiente manera:

      <pricingTier>Flex Consumption</pricingTier>

  3. (Opcional) Personalice el plan de consumo flexible en la implementación de Maven mediante la inclusión de estos elementos en la sección <plugin>.<configuration>:

    • <instanceSize>: establece el tamaño de la memoria de instancia para la aplicación de funciones. El valor predeterminado es 2048.
    • <maximumInstances>: establece el valor más alto para el número máximo de instancias de la aplicación de funciones.
    • <alwaysReadyInstances>: establece el recuento de instancias siempre preparadas con elementos secundarios para grupos de desencadenadores HTTP (<http>), grupos de Durable Functions (<durable>) y otros desencadenadores específicos (<my_function>). Cuando se establece un recuento de instancias mayor que cero, se paga por estas instancias si las funciones se ejecutan o no. Para obtener más información, vea Facturación.

  4. Para poder realizar la implementación, inicie sesión en la suscripción de Azure mediante el CLI de Azure.

    az login

    El comando az login inicia sesión en la cuenta de Azure.

  5. Use el siguiente comando para implementar el proyecto de código en una nueva aplicación de funciones en el plan de consumo flexible.

    mvn azure-functions:deploy

    Maven usa la configuración de la plantilla pom.xml para crear la aplicación de funciones en un plan de consumo flexible en Azure, junto con los demás recursos necesarios. Si estos recursos ya existen, el código se implementa en la aplicación de funciones, sobrescribiendo cualquier código existente.

Creación e implementación de la aplicación go

Las aplicaciones de funciones en Go solo se admiten en el plan Flex Consumption. Para crear, ejecutar e implementar una aplicación de funciones de Go, consulte Creación de una función Go desde la línea de comandos. Para obtener detalles de implementación y estructura de proyectos específicos de Go, consulte la referencia para desarrolladores de Go.

Configurar la integración con redes virtuales

Puede habilitar la integración de red virtual para la aplicación en un plan de consumo flexible al crear la aplicación o en un momento posterior. Antes de habilitar la integración de red virtual, revise los requisitos de comportamiento de red y subred específicos de Flex Consumption.

Cómo funcionan las redes de Flex Consumption

Las instancias de Flex Consumption no usan una dirección IP única de la subred con la que se integra la aplicación. En su lugar, un grupo de puertas de enlace de red administradas por la plataforma (internas para la infraestructura de consumo flexible) usa direcciones IP de la subred para atender todas las aplicaciones integradas con esa subred. Esta arquitectura de multiplexación ip es fundamentalmente diferente de los planes Premium, donde cada instancia usa una dirección IP de la subred.

La guía de 40 direcciones IP por aplicación garantiza que haya suficientes direcciones IP para el grupo de puertas de enlace de la plataforma y otros componentes de infraestructura, pero no es un límite estricto. Planee este mínimo al cambiar el tamaño de la subred, pero comprenda que el consumo de IP real suele ser menor. La plataforma asigna dinámicamente direcciones IP del conjunto de pasarelas compartidas a medida que las aplicaciones integradas en la subred se escalan horizontalmente.

Dimensionamiento y requisitos de las subredes

Elija una subred de tamaño adecuado para las aplicaciones de flex Consumption. En la tabla siguiente se proporcionan instrucciones basadas en su escenario:

Escenario CIDR recomendado Direcciones IP utilizables Notas
Aplicación Single Flex /27 27 Tamaño mínimo de subred admitido para una aplicación
Varias aplicaciones Flex en una subred /26 59 Se recomienda al hospedar varias aplicaciones y para cargas de trabajo a gran escala (más de 1000 instancias); proporciona una capacidad de puerta de enlace adecuada.

Delegación de subred

  • Delegue la subred para Microsoft.App/environments. Esta delegación difiere de los planes Premium y Dedicados, que utilizan Microsoft.Web/serverFarms.
  • Registre el proveedor de recursos Microsoft.App en su suscripción.

Restricciones de uso de subredes

  • La subred aún no se puede usar para puntos de conexión privados o puntos de conexión de servicio y no se puede delegar a otros planes o servicios de hospedaje.
  • No se puede compartir la misma subred entre un entorno de Azure Container Apps y una aplicación de consumo flexible.
  • Los nombres de subred no pueden contener caracteres de subrayado (_), que es una limitación actual del plan de consumo flexible.

Uso compartido de subredes

  • Puede compartir la misma subred con más de una aplicación que se ejecuta en un plan de consumo flexible. Sin embargo, dado que los recursos de red se comparten en todas las aplicaciones, una aplicación de funciones puede afectar al rendimiento de otros usuarios de la misma subred. Tenga en cuenta la demanda agregada al empaquetar varias aplicaciones en una subred pequeña.
  • La subred y la aplicación deben estar en la misma región.

Asignación y planeación de IP

  • Las aplicaciones flex Consumption no asignan una dirección IP única a cada instancia. En su lugar, un grupo de puertas de enlace de red usa direcciones IP de la subred. La guía de reserva de 40 direcciones IP por aplicación ayuda a garantizar que haya suficientes direcciones IP para el grupo de puertas de enlace y otros componentes de infraestructura, pero el uso real suele ser inferior.
  • Una /27 subred (27 direcciones IP utilizables) es suficiente para una sola aplicación que admita hasta 1.000 instancias debido a la multiplexación IP. Para múltiples aplicaciones o cargas de trabajo de gran escala, use una subred /26 para proporcionar suficiente capacidad de puerta de enlace.
  • Cuando muchas aplicaciones comparten una subred y muchas de ellas se escalan horizontalmente generando un tráfico saliente considerable, el rendimiento de la red de salida puede convertirse en un cuello de botella, más que el agotamiento de las direcciones IP. Evalúe el rendimiento a escala de producción planeada.

Habilitación de la integración de red virtual al crear la aplicación

En los ejemplos de esta sección se supone que la cuenta ya contiene una red virtual y una subred.

Active la integración con la red virtual ejecutando el comando az functionapp create e incluyendo los parámetros --vnet y --subnet. La subred debe delegarse a Microsoft.App/environments y debe tener un tamaño mínimo de /27. Para obtener más información, consulte Requisitos y ajuste de tamaño de subred.

  1. Cree la red virtual y la subred, si aún no tiene una.

  2. Complete los pasos del 1 al 4 en Creación de una aplicación de consumo flexible para crear los recursos necesarios para la aplicación.

  3. Ejecute el comando az functionapp create, incluidos los parámetros --vnet y --subnet, como en este ejemplo:

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime go --runtime-version 1.0 --functions-version 4 --vnet <VNET_RESOURCE_ID> --subnet <SUBNET_NAME>
az resource update --resource-group <RESOURCE_GROUP> --resource-type Microsoft.Web/sites --name <APP_NAME> --set properties.siteConfig.http20Enabled=false

    El az resource update comando deshabilita HTTP/2 en la aplicación de funciones, que es necesaria durante la versión preliminar pública de Go.

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime <RUNTIME_NAME> --runtime-version <RUNTIME_VERSION> --vnet <VNET_RESOURCE_ID> --subnet <SUBNET_NAME>

    El valor <VNET_RESOURCE_ID> es el identificador de recurso de la red virtual, que tiene el formato: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Network/virtualNetworks/<VNET_NAME>. Puede usar este comando para obtener una lista de identificadores de red virtual, filtrados por <RESOURCE_GROUP>: az network vnet list --resource-group <RESOURCE_GROUP> --output tsv --query "[]".id.

Para obtener ejemplos de un extremo a otro sobre cómo crear aplicaciones en Flex Consumption con integración de red virtual, consulte estos recursos:

Modificación o eliminación de la integración de red virtual

Puede agregar, cambiar o quitar la integración de red virtual para una aplicación existente.

Use el comando az functionapp vnet-integration add para habilitar la integración con red virtual en una aplicación de funciones existente:

az functionapp vnet-integration add --resource-group <RESOURCE_GROUP> --name <APP_NAME> --vnet <VNET_RESOURCE_ID> --subnet <SUBNET_NAME>

Use el comando az functionapp vnet-integration remove para deshabilitar la integración con red virtual en la aplicación:

az functionapp vnet-integration remove --resource-group <RESOURCE_GROUP> --name <APP_NAME>

Use el comando az functionapp vnet-integration list para enumerar las integraciones con red virtual actuales para la aplicación:

az functionapp vnet-integration list --resource-group <RESOURCE_GROUP> --name <APP_NAME>

Resolver problemas de rendimiento de la red

Cuando una aplicación Flex Consumption se integra con una subred menor que el tamaño recomendado, es posible que experimente una degradación del rendimiento a medida que se escala la aplicación. Este problema también puede producirse si integra varias aplicaciones en la misma subred cuando estas se escalan horizontalmente y tienen un volumen significativo de tráfico saliente.

Síntomas de subredes demasiado pequeñas

Supervise estos síntomas, lo que indica que la capacidad de salida en lugar de las direcciones IP es el factor de limitación:

  • Mayor latencia en las llamadas salientes a dependencias
  • Tiempos de espera de conexión a servicios externos
  • Estos problemas aumentan a medida que la aplicación crece, no de forma repentina como en una caída del servicio

Importante

El tamaño de subred no bloquea el escalado horizontal. La aplicación sigue agregando instancias incluso si la subred está infradimensionada. La degradación del rendimiento se produce en lugar de un límite de escalado estricto.

Supervisión y mitigación

  • Instrumente Application Insights con métricas de latencia de dependencia de salida: donde esta métrica proporciona una señal de advertencia temprana para subredes infradimensionada.
  • Prueba de carga a escala de producción antes de establecer el tamaño de la subred para validar que el tamaño de la subred puede controlar la carga de trabajo esperada.
  • Monitor con Azure Monitor: vaya a Virtual Network>Subnet en Azure Monitor para ver los datos de asignación de IP a través de consultas de Azure Resource Graph y KQL.
  • Ajustar el tamaño correcto de la subred según las instrucciones de la sección anterior. Se recomienda encarecidamente un mínimo de /27; se recomienda /26 para varias aplicaciones.

Nota:

Use al menos una /27 subred para garantizar una estabilidad adecuada de la plataforma. Las subredes significativamente más pequeñas que /27 pueden experimentar problemas al crear puertas de enlace sin ningún mensaje de error explícito.

Configuración de las opciones de implementación

En el plan de consumo flexible, un contenedor de Azure Blob Storage contiene el paquete de implementación con el código de la aplicación. De forma predeterminada, las implementaciones usan la misma cuenta de almacenamiento (AzureWebJobsStorage) y cadena de conexión que el runtime de Functions usa para mantener la aplicación. La configuración DEPLOYMENT_STORAGE_CONNECTION_STRING de la aplicación almacena la cadena de conexión. Sin embargo, puede especificar un contenedor de blobs en otra cuenta de almacenamiento como origen de implementación del código. También puede cambiar el método de autenticación que se usa para acceder al contenedor.

Un origen de implementación personalizado debe cumplir estos criterios:

  • La cuenta de almacenamiento ya debe existir.
  • El contenedor que se va a usar para las implementaciones también debe existir.
  • Cuando más de una aplicación usa la misma cuenta de almacenamiento, cada aplicación debe tener su propio contenedor de implementación. El uso de un contenedor único para cada aplicación impide que los paquetes de implementación se sobrescriban, lo que ocurriría si las aplicaciones compartan el mismo contenedor.

Al configurar la autenticación de almacenamiento de implementación, tenga en cuenta estas consideraciones:

  • Como procedimiento recomendado de seguridad, use identidades administradas al conectarse a Azure Storage desde las aplicaciones. Para obtener más información, consulte Conexiones.
  • Cuando se usa una cadena de conexión para conectarse a la cuenta de almacenamiento de implementación, la configuración de la aplicación que contiene la cadena de conexión ya debe existir.
  • Cuando se usa una identidad administrada asignada por el usuario, se vincula la identidad proporcionada a la aplicación de funciones. También asignas el rol Storage Blob Data Contributor con ámbito en la cuenta de almacenamiento de la implementación a la identidad.
  • Cuando se usa una identidad administrada asignada por el sistema, se crea una identidad cuando aún no existe una identidad asignada por el sistema válida en la aplicación. Cuando existe una identidad asignada por el sistema, asigna a la identidad el rol Storage Blob Data Contributor con alcance a la cuenta de almacenamiento de la implementación.

Para configurar las opciones de implementación al crear la aplicación de funciones en el plan de Consumo flexible:

Use el comando az functionapp create y proporcione estas opciones adicionales que personalizan el almacenamiento de implementación.

Parámetro Descripción
--deployment-storage-name Nombre de la cuenta de almacenamiento de implementación.
--deployment-storage-container-name Nombre del contenedor de la cuenta que va a contener el paquete de implementación de la aplicación.
--deployment-storage-auth-type Tipo de autenticación que se va a usar para conectarse a la cuenta de almacenamiento de implementación. Los valores admitidos incluyen StorageAccountConnectionString, UserAssignedIdentity y SystemAssignedIdentity.
--deployment-storage-auth-value Al usar StorageAccountConnectionString, establezca el valor de este parámetro en el nombre de la configuración de la aplicación que contiene la cadena de conexión de la cuenta de almacenamiento de implementación. Al establecer UserAssignedIdentity, establezca este parámetro en el nombre del identificador de recurso de la identidad que desea usar.

En este ejemplo se crea una aplicación de funciones en el plan de Consumo flexible con una cuenta de almacenamiento de implementación independiente y una identidad asignada por el usuario:

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime dotnet-isolated --runtime-version 8.0 --flexconsumption-location "<REGION>" --deployment-storage-name <DEPLOYMENT_ACCOUNT_NAME> --deployment-storage-container-name <DEPLOYMENT_CONTAINER_NAME> --deployment-storage-auth-type UserAssignedIdentity --deployment-storage-auth-value <MI_RESOURCE_ID>

También puede modificar la configuración de almacenamiento de implementación para una aplicación existente.

Use el az functionapp deployment config set comando para modificar la configuración de almacenamiento de implementación.

az functionapp deployment config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --deployment-storage-name <DEPLOYMENT_ACCOUNT_NAME> --deployment-storage-container-name <DEPLOYMENT_CONTAINER_NAME>

Configuración de la memoria de instancia

Establezca el tamaño de memoria de la instancia para su plan Flex Consumption cuando cree la aplicación. Para obtener más información sobre los tamaños admitidos, consulte Tamaños de instancia.

Para establecer un tamaño de memoria de instancia diferente del predeterminado al crear la aplicación:

Especifique el parámetro --instance-memory en el comando az functionapp create. En este ejemplo se crea una aplicación de C# con un tamaño de instancia de 4096:

az functionapp create --instance-memory 4096 --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime dotnet-isolated --runtime-version 8.0

Puede cambiar la configuración de tamaño de memoria de instancia que usa la aplicación en cualquier momento.

En este ejemplo se usa el az functionapp scale config set comando para cambiar la configuración de tamaño de memoria de instancia a 512 MB:

az functionapp scale config set --resource-group <resourceGroup> --name <APP_NAME> --instance-memory 512

Establecimiento de recuentos de instancias siempre preparadas

Establezca un número específico de instancias siempre listas para los grupos de escalado por función o funciones individuales, para mantener las funciones cargadas y listas para ejecutarse. Existen tres grupos especiales, como en el escalado por función:

  • http - Todas las funciones activadas por HTTP de la aplicación se escalan juntas a sus propias instancias.
  • durable - Todas las funciones activadas de forma duradera (orquestación, actividad, entidad) de la aplicación se escalan juntas en sus propias instancias.
  • blob - Todas las funciones activadas por blobs (Event Grid) de la aplicación se escalan juntas en sus propias instancias.

Use http, durable o blob como nombre para la configuración del par de valores de nombre para configurar recuentos siempre listos para estos grupos. Para todas las demás funciones de la aplicación, configure “Siempre listo” para cada función individual con el formato function:<FUNCTION_NAME>=n.

Para definir una o varias designaciones de instancia siempre listas, use el --always-ready-instances parámetro con el az functionapp create comando . En este ejemplo se establece el recuento de instancias siempre preparadas para todas las funciones desencadenadas por HTTP en 10:

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --always-ready-instances http=10

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime go --runtime-version 1.0 --functions-version 4 --flexconsumption-location <REGION> --always-ready-instances http=10
az resource update --resource-group <RESOURCE_GROUP> --resource-type Microsoft.Web/sites --name <APP_NAME> --set properties.siteConfig.http20Enabled=false

El az resource update comando deshabilita HTTP/2 en la aplicación de funciones, que es necesaria durante la versión preliminar pública de Go.

En este ejemplo se establece el recuento de instancias siempre preparadas para todas las funciones del desencadenador Durable en 3 y se establece el recuento de instancias siempre preparadas en 2 para una función desencadenada por Service Bus denominada function5:

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --always-ready-instances durable=3 function:function5=2

En este ejemplo, se establece en 2 el número de instancias siempre listas para una función desencadenada por Service Bus denominada function5:

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime go --runtime-version 1.0 --functions-version 4 --flexconsumption-location <REGION> --always-ready-instances function:function5=2
az resource update --resource-group <RESOURCE_GROUP> --resource-type Microsoft.Web/sites --name <APP_NAME> --set properties.siteConfig.http20Enabled=false

El az resource update comando deshabilita HTTP/2 en la aplicación de funciones, que es necesaria durante la versión preliminar pública de Go.

También puede modificar instancias siempre preparadas en una aplicación existente agregando o quitando designaciones de instancia o cambiando los recuentos de designación de instancias existentes.

En este ejemplo se usa el comando az functionapp scale config always-ready set para cambiar el recuento de instancias siempre preparadas a 10 para el grupo de desencadenadores HTTP:

az functionapp scale config always-ready set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --settings http=10

Para quitar instancias siempre preparadas, use el comando az functionapp scale config always-ready delete, como en este ejemplo, que quita todas las instancias siempre preparadas del grupo de desencadenadores HTTP y también una función denominada hello_world:

az functionapp scale config always-ready delete --resource-group <RESOURCE_GROUP> --name <APP_NAME> --setting-names http function:hello_world

Establecimiento de límites de simultaneidad HTTP

Si no establece límites específicos, el sistema determina los valores predeterminados de simultaneidad HTTP para las aplicaciones del plan flex Consumption en función de la configuración de tamaño de instancia. Para obtener más información, consulte Simultaneidad del desencadenador HTTP.

A continuación se muestra cómo se establecen los límites de simultaneidad HTTP para una aplicación existente:

Use el comando az functionapp scale config set para establecer límites de simultaneidad HTTP específicos para la aplicación, independientemente del tamaño de instancia.

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --trigger-type http --trigger-settings perInstanceConcurrency=10

En este ejemplo se establece el nivel de simultaneidad del desencadenador HTTP en 10. Después de establecer un valor de simultaneidad HTTP, la aplicación mantiene ese valor a pesar de los cambios en la configuración de tamaño de instancia de la aplicación.

Establecimiento de la estrategia de actualización del sitio

El plan Flex Consumption admite exclusivamente dos estrategias de actualización de sitio diferentes que determinan cómo gestiona la aplicación de funciones los despliegues de código y los cambios de configuración. De forma predeterminada, las aplicaciones del plan de consumo flexible usan la Recreate estrategia, que finaliza las funciones que están ejecutándose durante las implementaciones. Para habilitar implementaciones sin tiempo de inactividad, puede configurar la estrategia RollingUpdate en su lugar. Para obtener más información, consulte Estrategias de actualización del sitio en Flex Consumption.

Nota:

La configuración de la estrategia de actualización de sitio se encuentra actualmente en versión preliminar pública y solo está disponible a través de plantillas de Bicep o ARM. No puede configurar esta opción mediante el CLI de Azure, Azure portal o Visual Studio Code.

El CLI de Azure no admite actualmente la configuración de la estrategia de actualización del sitio. Utiliza plantillas de Bicep o ARM como se describe en la configuración de la estrategia de actualización del sitio.

Configuración de certificados con ámbito de sitio

Flex Consumption presenta certificados de ámbito de sitio, un nuevo modelo en el que los certificados TLS/SSL tienen como ámbito la aplicación de funciones individual en lugar de compartirse entre aplicaciones en el mismo espacio web. En la tabla siguiente se muestran los tipos de certificado admitidos y cómo se agrega cada uno a la aplicación de funciones:

Tipo de certificado Cómo agregar Cuenta para
Certificado administrado de App Service Creado en el portal para un dominio personalizado Límite de certificados privados
Certificado de App Service Comprada a través de Azure y, a continuación, importada Límite de certificados privados
Certificado importado de Key Vault Importado desde Azure Key Vault Límite de certificados privados
Certificado privado cargado (.pfx) Cargado como un archivo PFX Límite de certificados privados
Certificado público cargado (.cer) Cargado como un archivo CER Límite de certificados públicos

Consideraciones para los certificados con ámbito de sitio

  • La compatibilidad para usar certificados con ámbito de sitio con aplicaciones que se ejecutan en un plan Flex Consumption se encuentra actualmente en versión preliminar.
  • Las aplicaciones existentes creadas antes de que esta característica estén disponibles no tienen actualmente una ruta de migración para los certificados. Para usar certificados con ámbito de sitio, cree una nueva aplicación de funciones Flex Consumption.
  • La compatibilidad de CLI de Azure para administrar certificados de ámbito de sitio aún no está disponible. Mientras tanto, use las plantillas Azure portal o ARM/Bicep para administrar certificados.
  • Cada aplicación admite un máximo de tres certificados privados y tres certificados públicos.
  • Los certificados privados deben exportarse como un archivo PFX protegido con contraseña que contenga todos los certificados intermedios y el certificado raíz de la cadena de certificados.
  • Actualmente no se admite el cifrado de un extremo a otro (E2E).
  • Los certificados criptográficos de curva elíptica (ECC) se admiten cuando se cargan como PFX.
  • Dado que Flex Consumption se ejecuta en Linux, el código debe cargar certificados desde rutas de acceso de archivo en lugar de desde el almacén de certificados de Windows. En primer lugar, siga los pasos descritos en Hacer que un certificado sea accesible para el código para cargar certificados en el entorno de tiempo de ejecución. A continuación, para obtener instrucciones sobre cómo leer archivos de certificado desde el código de la aplicación, consulte Load certificates in Linux/Windows containers.

Adición de un certificado

Puede agregar certificados a la aplicación de varias maneras, en función del tipo de certificado. Agregue certificados administrados y Azure gratuitos directamente en el portal.

Seleccione una de las pestañas siguientes para ver cómo agregar un certificado administrado, privado (.pfx), público (.cer) o Key Vault administrado.

Para crear y enlazar un certificado administrado gratuito para un dominio personalizado:

  1. En el portal de Azure, vaya a tu aplicación de funciones.

  2. En el menú izquierdo, expanda Configuración y seleccione Dominios personalizados.

  3. Seleccione Agregar dominio personalizado.

  4. En Certificado TLS/SSL, seleccione Certificado administrado de App Service.

  5. En Tipo TLS/SSL, seleccione SNI SSL.

  6. Complete la validación del dominio y seleccione Agregar.

    El certificado administrado se crea y se enlaza automáticamente al dominio personalizado. El certificado puede tardar hasta 10 minutos en emitirse.

Hacer que un certificado sea accesible desde el código

Después de agregar un certificado, debe conceder acceso de forma explícita al código de la función.

  1. En el portal de Azure, vaya a tu aplicación de funciones.

  2. En el menú de la izquierda, expanda Configuración y seleccione Certificados.

  3. Seleccione Traiga sus propios certificados (.pfx) o Certificados de clave pública (.cer).

  4. Seleccione ... (puntos suspensivos) junto al certificado que desea hacer accesible y, a continuación, elija Hacer accesible al código de la aplicación.

Al habilitar Accesible para el código de la aplicación, la plataforma carga el certificado en el entorno de ejecución en todas las instancias como un archivo.

Los archivos de certificado se denominan mediante huella digital y se colocan en estos directorios:

Tipo de certificado Camino
Certificados públicos (.cer) /var/ssl/certs
Certificados privados (.pfx) /var/ssl/private

Renovación o actualización de un certificado

La plataforma renueva automáticamente los certificados administrados gratuitos. Para todos los demás certificados, la forma de actualizar un certificado que expira depende del origen del certificado:

  • Certificates importados desde Key Vault: al renovar un certificado en Key Vault, el trabajo en segundo plano de la plataforma sincroniza automáticamente el certificado actualizado en la aplicación de funciones en un plazo de 24 horas. La nueva versión del certificado se carga en todas las instancias sin pasos manuales.

  • Certificados cargados: cargue el nuevo certificado y, a continuación, haga que sea accesible para el código de la aplicación. Si el código hace referencia al certificado mediante huella digital, actualice las referencias de huella digital en la configuración del código o de la aplicación.

Visualización de las regiones admitidas actualmente

Para ver la lista de regiones que admiten actualmente los planes de consumo flexible, consulte:

  1. Si todavía no lo ha hecho, inicie sesión en Azure:

    az login

    El comando az login inicia sesión en la cuenta de Azure.

  2. Use el az functionapp list-flexconsumption-locations comando para revisar la lista de regiones que admiten actualmente Flex Consumption en orden alfabético.

    az functionapp list-flexconsumption-locations --query "sort_by(@, &name)[].{Region:name}" -o table

Al crear una aplicación en el portal de Azure o mediante Visual Studio Code, la lista de regiones excluye las regiones no admitidas actualmente.

Supervisión de la aplicación en Azure

Azure Monitor proporciona estos conjuntos distintos de métricas para ayudarle a comprender mejor cómo se ejecuta la aplicación de funciones en Azure:

  • Métricas de la plataforma: proporciona información de nivel de infraestructura
  • Application Insights: proporciona información de nivel de código, incluidos los seguimientos y los registros de errores.

Si habilita Application Insights en la aplicación, puede hacer lo siguiente:

  • Seguimiento de tiempos de ejecución y dependencias detallados
  • Supervisión del rendimiento de funciones individuales
  • Análisis de errores y excepciones
  • Correlación de métricas de plataforma con el comportamiento de la aplicación mediante consultas personalizadas

Para más información, consulte Supervisión de Azure Functions.

Métricas compatibles

Ejecute este script para ver todas las métricas de la plataforma que están disponibles actualmente para la aplicación:

appId=$(az functionapp show --name <APP_NAME> --resource-group <RESOURCE_GROUP> --query id -o tsv)
az monitor metrics list-definitions --resource $appId --query "[].{Name:name.localizedValue,Value:name.value}" -o table

En este ejemplo, reemplace <RESOURCE_GROUP> y <APP_NAME> por los nombres de la aplicación de función y el grupo de recursos. Este script obtiene el identificador de aplicación completo y devuelve las métricas de plataforma disponibles en una tabla.

Visualización de métricas

Puede revisar las métricas actuales en Azure Portal o mediante la CLI de Azure.

En Azure Portal, también puede crear alertas de métricas y anclar gráficos y otros informes a paneles en el portal.

Use este script para generar un informe de las métricas actuales de la aplicación:

appId=$(az functionapp show --name <APP_NAME> --resource-group <RESOURCE_GROUP> --query id -o tsv)

echo -e "\nAlways-ready and on-demand execution counts..."
az monitor metrics list --resource $appId --metric "AlwaysReadyFunctionExecutionCount" --interval PT1H --output table
az monitor metrics list --resource $appId --metric "OnDemandFunctionExecutionCount" --interval PT1H --output table

echo -e "\nExecution units (MB-ms) in always-ready and on-demand execution counts..."
az monitor metrics list --resource $appId --metric "AlwaysReadyFunctionExecutionUnits" --interval PT1H --output table
az monitor metrics list --resource $appId --metric "OnDemandFunctionExecutionUnits" --interval PT1H --output table

echo -e "\nAlways-ready resource utilization..."
az monitor metrics list --resource $appId --metric "AlwaysReadyUnits" --interval PT1H --output table

echo -e "\nMemory utilization..."
az monitor metrics list --resource $appId --metric "AverageMemoryWorkingSet" --interval PT1H --output table
az monitor metrics list --resource $appId --metric "MemoryWorkingSet" --interval PT1H --output table

echo -e "\nInstance count and CPU utilization..."
az monitor metrics list --resource $appId --metric "InstanceCount" --interval PT1H --output table
az monitor metrics list --resource $appId --metric "CpuPercentage" --interval PT1H --output table

Para más información sobre las métricas de Azure Functions, consulte Supervisión de Azure Functions.

Visualización de registros

Al conectar la aplicación a Application Insights, puede analizar mejor el rendimiento de la aplicación y solucionar problemas durante la ejecución. En el recurso de Application Insights para la aplicación:

  • Use Rendimiento para analizar los tiempos de respuesta y las dependencias.
  • Use Errores para identificar los errores que se producen después de la migración.
  • Cree consultas personalizadas en registros para analizar el comportamiento de las funciones.

Por ejemplo, use esta consulta para comparar las tasas de éxito por instancia:

Use esta consulta para comparar las tasas de éxito por instancia:

requests
| where timestamp > ago(7d)
| summarize successCount=countif(success == true), failureCount=countif(success == false) by bin(timestamp, 1h), cloud_RoleName
| render timechart

Use esta consulta para analizar el número de instancias que procesan activamente la función:

let _startTime = ago(20m); //Adjust start time as needed
let _endTime = now(); //Adjust end time as needed
let bins = 1s; //Adjust bin as needed - this will give per second results
requests
| where operation_Name == 'EventHubsTrigger' //Replace with the name of the function in the function app that you are analyzing
| where timestamp between(_startTime .. _endTime)
| make-series dcount(cloud_RoleInstance) default=0 on timestamp from _startTime to _endTime step bins
| render columnchart

Visualización de costos

Dado que puedes ajustar la aplicación para ajustar el rendimiento frente a los costos operativos, es importante realizar un seguimiento de los costos asociados a la ejecución de la aplicación en el plan de consumo flexible.

Para ver los costos actuales:

  1. En la página de la aplicación de funciones de Azure Portal, seleccione el vínculo grupo de recursos.

  2. En la página del grupo de recursos, seleccione Gestión de Costes>Análisis de Costes.

  3. Revise los costos actuales y la trayectoria de costos de la propia aplicación.

  4. Opcionalmente, seleccione Cost Management>Alertas y luego + Agregar para crear una nueva alerta para la aplicación.

Ajuste de la aplicación

El plan de consumo flexible proporciona varias opciones de configuración que puedes ajustar para refinar el rendimiento de la aplicación. El rendimiento y los costos reales pueden variar en función de los patrones de carga de trabajo y la configuración específicos de la aplicación. Por ejemplo, los tamaños de instancia de memoria más altos pueden mejorar el rendimiento de las operaciones que consumen mucha memoria, pero a un costo mayor por período activo.

Estos son algunos ajustes que puede realizar para ajustar el rendimiento frente al costo:

Contenido relacionado

  • Last updated on