Consideraciones de almacenamiento de Azure Functions
Azure Functions necesita una cuenta de Azure Storage para crear una instancia de la aplicación de funciones. La aplicación de funciones podría usar los siguientes servicios de almacenamiento:
| Servicio de Storage | Uso de Functions |
|---|---|
| Almacenamiento de blobs de Azure | 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 de manera predeterminada en la central de tareas de 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. |
| Azure Queue Storage | Se utiliza de manera predeterminada en la central de tareas de 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 de manera predeterminada en la central de tareas de Durable Functions. |
- 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 puede crear una aplicación sin Azure Files en determinadas condiciones.
Consideraciones importantes
Debe tener en cuenta los siguientes hechos relacionados con las cuentas de almacenamiento usadas por las aplicaciones de función:
Cuando la aplicación de funciones se hospeda en el plan de Consumo o en el plan Premium, el código de función y los archivos de configuración se almacenan en Azure Files en la cuenta de almacenamiento vinculada. Al eliminar esta cuenta de almacenamiento, el contenido se borra y no se puede recuperar. Para más información, consulte Se eliminó la cuenta de almacenamiento .
Los datos importantes, como el código de función, las claves de acceso y otros datos importantes relacionados con el servicio, se pueden conservar en la cuenta de almacenamiento. 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.
Requisitos de la cuenta de almacenamiento
Las cuentas de almacenamiento creadas como parte del flujo de creación de la aplicación de función en el Azure Portal están garantizadas para funcionar con la nueva aplicación de función. 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 usadas por la aplicación de funciones, por lo que debe asegurarse de que una cuenta de almacenamiento existente cumple estos requisitos:
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 solo de blobs y Azure Premium Storage. Para más información sobre los tipos de cuentas de almacenamiento, consulte Introducción a las cuentas de almacenamiento.
No puede utilizar una cuenta de almacenamiento protegida por la red cuando su aplicación de funciones está hospedada en el plan de Consumo.
Al crear la aplicación de funciones en el portal, solo se le permite elegir una cuenta de almacenamiento existente en la misma región que la aplicación de funciones que va a crear. Se trata de 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 la aplicación de funciones en un plan con la compatibilidad con zonas de disponibilidad habilitada, solo se admiten cuentas de almacenamiento con redundancia de zona.
Cuando utilice la automatización de la implementación para crear su aplicación de funciones con una cuenta de almacenamiento protegida por red, debe incluir configuraciones de red específicas en su plantilla de ARM o archivo de Bicep. Si no incluye esta configuración y recursos, la implementación automatizada podría producir un error en la validación. Para obtener instrucciones más específicas sobre ARM y Bicep, vea Implementaciones protegidas. Para obtener información general sobre cómo configurar cuentas de almacenamiento con redes, vea Cómo utilizar una cuenta de almacenamiento segura con Azure Functions.
Guía de la cuenta de almacenamiento
Cada aplicación de función requiere una cuenta de almacenamiento para funcionar. Si se elimina esa cuenta, la aplicación de funciones no se ejecutará. Para más información, consulte este artículo sobre la solución de problemas relacionados con el almacenamiento. Las consideraciones que se indican a continuación también se aplican a la cuenta de almacenamiento que se utiliza en 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. En Azure Portal se aplica este procedimiento recomendado. Si, por alguna razón, necesita usar una cuenta de almacenamiento de una región diferente a la de la aplicación de funciones, debe crear la aplicación de funciones fuera del portal.
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 manera predeterminada, las aplicaciones de funciones establecen la conexión AzureWebJobsStorage como una cadena de conexión almacenada en la configuración de la aplicación AzureWebJobsStorage, pero también puede configurar AzureWebJobsStorage para que use una conexión basada en identidad sin 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 para la cuenta de almacenamiento en la configuración de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y el nombre del recurso compartido de archivos en la configuración de WEBSITE_CONTENTSHARE. Normalmente es 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 podría ser limitado.
Nota:
Se debe actualizar una cadena de conexión de la cuenta de almacenamiento cuando se regeneran las claves de almacenamiento. Más información sobre la administración de las claves de almacenamiento.
Cuentas de almacenamiento compartidas
Una misma cuenta de almacenamiento puede estar compartida entre varias aplicaciones de funciones sin que se produzcan problemas. Por ejemplo, en Visual Studio, puede desarrollar varias aplicaciones con el Emulador de Azurite Storage. En este caso, el emulador actúa como una cuenta de almacenamiento única. La cuenta de almacenamiento que se utiliza en la aplicación de funciones puede usarse también para 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 debe aplicar directivas de administración del ciclo de vida a la cuenta de Blob Storage que usa la aplicación de funciones. Functions usa Blob Storage para conservar información importante, como las claves de acceso de funciones, y las directivas pueden quitar blobs (como claves) necesarios 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 los eventos en el plano de datos de almacenamiento. Consulta Supervisión de Azure Storage para más información sobre cómo configurar y examinar estos registros.
El registro de actividad de Azure Monitor muestra los 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 más información, consulte Supervisión de 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. Esto es especialmente importante si tiene funciones desencadenadas 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 (con 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 Event Hubs que escribe datos en Blob Storage, use dos cuentas de almacenamiento: una para la aplicación de función y otra para los blobs que almacena la función.
Enrutamiento coherente a través de redes virtuales
Varias aplicaciones de funciones hospedas en el mismo plan también pueden usar la misma cuenta de almacenamiento para el recurso compartido de contenido Azure Files (definido por WEBSITE_CONTENTAZUREFILECONNECTIONSTRING). Cuando esta cuenta de almacenamiento también está protegida por una red virtual, todas estas aplicaciones también deben usar el mismo valor para vnetContentShareEnabled (anteriormente WEBSITE_CONTENTOVERVNET) para garantizar que el tráfico se enruta de forma coherente a través de la red virtual prevista. Un error de coincidencia en esta configuración entre las aplicaciones que usan la misma cuenta de almacenamiento de Azure Files puede dar lugar a que el tráfico se enrute a través de redes públicas, lo que hace que las reglas de red de la cuenta de almacenamiento bloqueen el acceso.
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 según los cambios en los blobs de un contenedor de almacenamiento. Use la tabla siguiente para determinar qué desencadenador de función se adapta mejor a sus necesidades:
| Estrategia | Contenedor (sondeo) | Contenedor (eventos) | Desencadenador de cola | Event Grid |
|---|---|---|---|---|
| Latencia | Alto (hasta 10 minutos) | Bajo | Media | Bajo |
| Limitaciones de la cuenta de almacenamiento | Las cuentas de solo blobs no se admiten¹ | no se admite la versión 1 de uso general | ninguno | no se admite la versión 1 de uso general |
| Tipo de desencadenador | Blob Storage | Blob Storage | Queue Storage | Event Grid |
| Versión de la extensión | Any | Storage v5.x+ | Any | Any |
| Procesa los blobs existentes | Sí | No | N.º | 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í |
| 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 obtener 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 procedentes 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. |
- 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.
Cifrado de datos de almacenamiento
Azure Storage cifra todos los datos de las cuentas de almacenamiento en reposo. Para más información, consulte Cifrado de Azure Storage para datos en reposo.
De manera predeterminada, los datos se cifran con claves administradas por Microsoft. Para tener un mayor control sobre las claves de cifrado, puede proporcionar claves administradas por el cliente que puede usar para el cifrado de datos de archivos y blobs. Estas claves deben estar presentes en Azure Key Vault para que Azure Functions pueda acceder a la cuenta de almacenamiento. Para más información, consulte Cifrado en reposo con claves administradas por el cliente.
Residencia de datos en la región
Cuando todos los datos del cliente deban permanecer dentro de una única región, la cuenta de almacenamiento asociada a la aplicación de funciones debe ser una que tenga redundancia en la región. También se debe usar una cuenta de almacenamiento con redundancia en la región con Azure Durable Functions.
Otros datos de clientes administrados por la plataforma solo se almacenan dentro de la región cuando se hospedan en una instancia de 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
Functions usa un valor de id. de host como una manera de identificar de forma exclusiva una aplicación de funciones determinada en los artefactos almacenados. De manera predeterminada, este identificador se genera automáticamente a partir del nombre de la aplicación de funciones, truncado a los primeros 32 caracteres. A continuación, este identificador se usa al almacenar la información de seguimiento y correlación por aplicación en la cuenta de almacenamiento vinculada. Cuando tiene aplicaciones de funciones con nombres de más de 32 caracteres y cuando los primeros 32 caracteres son idénticos, este truncamiento puede dar lugar a valores de id. de host duplicados. Cuando dos aplicaciones de funciones con id. de host idénticos usan la misma cuenta de almacenamiento, se obtiene una colisión de id. de host porque los datos almacenados no se pueden vincular de forma única a la aplicación de funciones correcta.
Nota:
Esta misma colisión del 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.
A partir de la versión 3.x del runtime de Functions, se detecta la colisión del id. de host y se registra una advertencia. En la versión 4.x, se registra un error y se detiene el host, lo que da lugar a un error grave. Puede encontrar más detalles sobre la colisión de los id. de host en esta incidencia.
Evitar colisiones de los id. de host
Puede usar las siguientes estrategias para evitar colisiones de id. de host:
- Use una cuenta de almacenamiento separada para cada aplicación de funciones o ranura implicada en la colisión.
- Cambie el nombre de una de las aplicaciones de funciones a un valor con una longitud inferior a 32 caracteres, lo que cambia el Id. 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 id. de host.
Importante
Cambiar la cuenta de almacenamiento asociada a una aplicación de funciones existente o cambiar el id. de host de la aplicación puede afectar el comportamiento de las funciones existentes. Por ejemplo, un desencadenador de Blob Storage realiza un seguimiento de si se procesan blobs individuales escribiendo recibos en una ruta de acceso de identificador 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
Puede establecer explícitamente un id. de host específico para la aplicación de funciones en la configuración de la aplicación mediante la configuración AzureFunctionsWebHost__hostid. Para más información, consulte AzureFunctionsWebHost__hostid.
Cuando se produce la colisión entre ranuras, debe establecer un identificador de host específico para cada ranura, incluida 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.
Clústeres habilitados para Azure Arc
Cuando la aplicación de funciones se implementa en un clúster de Kubernetes habilitado para Azure Arc, es posible que la aplicación de funciones no requiera una cuenta de almacenamiento. En este caso, Functions solo requiere una cuenta de almacenamiento cuando la aplicación de funciones usa un desencadenador que requiere almacenamiento. En la siguiente tabla se indica qué desencadenadores pueden requerir una cuenta de almacenamiento y cuáles no.
| No se requiere | puede requerir almacenamiento |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus |
• Azure SQL • Blob Storage • Event Grid • Event Hubs • IoT Hub • Queue Storage • SendGrid • SignalR • Table Storage • Temporizador • Twilio |
Para crear una aplicación de función en un clúster de Kubernetes habilitado para Azure Arc sin almacenamiento, debe usar el comando az functionapp create de la CLI de Azure. La versión de la CLI de Azure debe incluir la versión 0.1.7 o una versión posterior de la extensión appservice-kube. Use el comando az --version para comprobar que la extensión está instalada y es la versión correcta.
La creación de recursos de la aplicación de funciones mediante métodos distintos de la CLI de Azure requiere una cuenta de almacenamiento existente. Si tiene previsto usar los desencadenadores que requieran una cuenta de almacenamiento, debe crear la cuenta antes de crear la aplicación de funciones.
Creación de una aplicación sin Azure Files
El servicio de Azure Files proporciona un sistema de archivos compartido que admite escenarios a gran escala. Cuando su aplicación de función se ejecuta en Windows en un plan Elástico Premium o Consumo, se crea de forma predeterminada un recurso compartido Azure Files en su cuenta de almacenamiento. Ese recurso compartido es utilizado por Functions para habilitar ciertas características, como el streaming de registros. También se utiliza como ubicación de implementación de paquetes compartidos, lo que garantiza la coherencia del código de la función implementada en todas las instancias.
De forma predeterminada, las aplicaciones de funciones hospedadas en planes Premium y Consumo usan implementación zip, con paquetes de implementación almacenados en este recurso compartido de archivos de Azure. Esta sección solo es relevante para estos planes de hosting.
El uso de Azure Files requiere el uso de una cadena de conexión, que se almacena en la configuración de la aplicación como WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Azure Files no admite actualmente conexiones basadas en identidades. Si el escenario requiere que no almacene secretos en la configuración de la aplicación, debe quitar la dependencia de la aplicación en Azure Files. Para ello, cree su aplicación sin la dependencia predeterminada de Azure Files.
Nota:
También debe considerar la ejecución en su aplicación de funciones en el plan de consumo flexible, que proporciona un mayor control sobre el paquete de implementación, incluida la posibilidad de utilizar conexiones de identidad administradas. Para obtener más información, consulte Configurar los ajustes de implementación en el artículo Consumo flexible.
Para ejecutar la aplicación sin el recurso compartido de archivos de Azure, debe cumplir los siguientes requisitos:
- Debe implementar su paquete en un contenedor de almacenamiento Azure Blob remoto y luego establecer la URL que proporciona acceso a ese paquete como la configuración de la aplicación
WEBSITE_RUN_FROM_PACKAGE. Esta opción le permite almacenar el contenido de la aplicación en Blob Storage en lugar de Azure Files, que admite identidades administradas.
Usted es responsable de actualizar manualmente el paquete de implementación y de mantener la URL del paquete de implementación, que probablemente contenga una firma de acceso compartido (SAS).
- La aplicación no puede basarse en un sistema de archivos grabable compartido.
- La aplicación no puede usar la versión 1.x del tiempo de ejecución de Functions.
- Las experiencias de streaming de registros en clientes como Azure Portal 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. Para ello, puede crear una aplicación sin la configuración de la aplicación WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE. Para empezar, genere una plantilla de ARM para una implementación estándar, elimine las dos configuraciones y luego implemente la plantilla modificada.
Dado que 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 Elástico Premium y los planes Consumo que se ejecutan en Windows.
Montaje de recursos compartidos de archivos
Esta funcionalidad solo está disponible cuando se ejecuta en Linux.
Puede montar recursos compartidos de Azure Files existentes en las aplicaciones de funciones de Linux. Al montar un recurso compartido en la aplicación de funciones de Linux, se pueden aprovechar los modelos de aprendizaje automático existentes u otros datos en las funciones. Puede usar el siguiente comando para montar un recurso compartido existente en la aplicación de funciones de Linux.
az webapp config storage-account add
En este comando, share-name es el nombre del recurso compartido existente de Azure Files y 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, vea los scripts de Creación de una aplicación de funciones de Python y montaje de un recurso compartido de Azure Files.
Actualmente, solo se admite storage-type de AzureFiles. Solo puede montar cinco recursos compartidos en una aplicación de funciones determinada. El montaje de un recurso compartido de archivos puede aumentar el tiempo de arranque en frío en al menos 200-300 ms, o incluso más, si la cuenta de almacenamiento se encuentra en una región diferente.
El recurso compartido montado está disponible para el código de función en el valor mount-path especificado. Por ejemplo, cuando mount-path es /path/to/mount, puede acceder al directorio de destino mediante las API del sistema de archivos, como en el siguiente ejemplo de Python:
import os
...
files_in_share = os.listdir("/path/to/mount")
Pasos siguientes
Más información sobre las opciones de hospedaje de Azure Functions.