Guía para desarrolladores de Azure Functions

Artículo
06/26/2024

En Azure Functions, todas las funciones comparten algunos conceptos y componentes técnicos básicos, sin importar su lenguaje o entorno de desarrollo preferido. Este artículo es específico del lenguaje. Elija su languaje preferido en la parte superior del artículo.

En este artículo se supone que ya ha leído la Información general sobre Azure Functions.

Si prefiere saltar directamente, puede completar un tutorial de inicio rápido con Visual Studio, Visual Studio Code o desde el símbolo del sistema.

Si prefiere saltar directamente, puede completar un tutorial de inicio rápido mediante Maven (línea de comandos), Eclipse, IntelliJ IDEA, Gradle, Quarkus, Spring Cloud o Visual Studio Code.

Si prefiere empezar directamente, puede completar un tutorial de inicio rápido usandoVisual Studio Code o desde el símbolo del sistema.

Si prefiere comenzar directamente, puede completar un tutorial de inicio rápido usando Visual Studio Code o desde el símbolo del sistema.

Proyecto de código

En el núcleo de Azure Functions es un proyecto de código específico del lenguaje que implementa una o varias unidades de ejecución de código llamada funciones. Las funciones son simplemente métodos que se ejecutan en la nube de Azure en función de eventos, en respuesta a solicitudes HTTP o según una programación. Piense en su proyecto de código de Azure Functions como un mecanismo para organizar, implementar y administrar colectivamente sus funciones individuales en el proyecto cuando se ejecutan en Azure. Para obtener más información, consulte Organizar funciones.

La forma en que usted presenta su proyecto de código y cómo indica qué métodos en su proyecto son funciones dependerá del lenguaje de desarrollo de su proyecto. Para obtener instrucciones detalladas específicas del lenguaje, consulte la guía para desarrolladores de C#.

La forma en que usted presenta su proyecto de código y cómo indica qué métodos en su proyecto son funciones dependerá del lenguaje de desarrollo de su proyecto. Para obtener instrucciones específicas del lenguaje, consulte Guía para desarrolladores de Node.js.

La forma en que usted presenta su proyecto de código y cómo indica qué métodos en su proyecto son funciones dependerá del lenguaje de desarrollo de su proyecto. Para obtener información específica sobre el lenguaje, consulte Guía para desarrolladores de PowerShell.

Todas las funciones deben tener un desencadenador, que define cómo se inicia la función y puede proporcionar entrada a la función. Opcionalmente, las funciones pueden definir enlaces de entrada y salida. Estos enlaces simplifican las conexiones a otros servicios sin tener que trabajar con los SDK de cliente. Para más información, vea Conceptos básicos sobre los enlaces y desencadenadores de Azure Functions.

Azure Functions proporciona un conjunto de plantillas de función y proyecto específicas del lenguaje que facilitan la creación de nuevos proyectos de código y la adición de funciones al proyecto. Puede usar cualquiera de las herramientas que admiten el desarrollo de Azure Functions para generar nuevas aplicaciones y funciones mediante estas plantillas.

Herramientas de desarrollo

Las siguientes herramientas proporcionan una experiencia integrada de desarrollo y publicación para Azure Functions en su lenguaje preferido:

Visual Studio

Visual Studio Code
Azure Functions Core Tools (símbolo del sistema)

Estas herramientas se integran con las Azure Functions Core Tools para que pueda ejecutar y depurar en su equipo local utilizando el tiempo de ejecución de Functions. Para más información, consulte Codificación y comprobación de las funciones de Azure Functions en un entorno local.

También hay un editor en Azure Portal que le permite actualizar su código y su archivo de definición function.json directamente en el portal. Solo debe usar este editor para realizar pequeños cambios o crear funciones de prueba de concepto. Siempre debe desarrollar las funciones localmente, siempre que sea posible. Para más información, consulte Creación de su primera función en Azure Portal.

La edición del portal solo se admite para Node.js versión 3, que usa el archivo function.json.

Implementación

Al publicar el proyecto de código en Azure, básicamente va a implementar el proyecto en un recurso de aplicación de funciones existente. La aplicación de función proporciona un contexto de ejecución en Azure donde ejecutar las funciones. Como tal, es la unidad de implementación y administración de las funciones. Desde una perspectiva de recursos de Azure, una aplicación de funciones es equivalente a un recurso de sitio (Microsoft.Web/sites) en Azure App Service, que es equivalente a una aplicación web.

Una aplicación de función se compone de una o varias funciones individuales que se administran, implementan y escalan conjuntamente. Todas las funciones de una aplicación de funciones comparten el mismo plan de precios, método de implementación y versión de tiempo de ejecución. Para más información, consulte Cómo administrar una aplicación de funciones.

Cuando la aplicación de funciones y otros recursos necesarios aún no existen en Azure, primero debe crear estos recursos para poder implementar los archivos del proyecto. Puede crear estos recursos de una de estas maneras:

Durante la publicación en Visual Studio

Mediante Visual Studio Code
Uso mediante programación de la CLI de Azure, Azure PowerShell, plantillas de ARM o plantillas de Bicep
En Azure Portal

Además de la publicación basada en herramientas, Functions admite otras tecnologías para implementar código fuente en una aplicación de funciones existente. Para más información, vea Tecnologías de implementación en Azure Functions.

Conexión a los servicios

Un requisito importante de cualquier servicio de proceso basado en la nube es leer datos de y escribir datos en otros servicios en la nube. Functions proporciona un amplio conjunto de enlaces que facilita la conexión a los servicios sin tener que trabajar con los SDK de cliente.

Tanto si usa las extensiones de enlace proporcionadas por Functions como si trabaja directamente con los SDK de cliente, almacena datos de conexión de forma segura y no los incluye en el código. Para obtener más información, consulte Conexiones.

Enlaces

Functions proporciona enlaces para muchos servicios de Azure y algunos servicios de terceros, que se implementan como extensiones. Para obtener más información, consulte la lista completa de enlaces admitidos.

Las extensiones de enlace pueden admitir entradas y salidas, y muchos desencadenadores también actúan como enlaces de entrada. Los enlaces permiten configurar la conexión a los servicios para que el host de Functions pueda controlar el acceso a los datos por usted. Para más información, vea Conceptos básicos sobre los enlaces y desencadenadores de Azure Functions.

Si tiene problemas con errores procedentes de enlaces, consulte la documentación Códigos de error de enlace de Azure Functions.

SDK de cliente

Aunque Functions proporciona enlaces para simplificar el acceso a datos en el código de función, todavía puede usar un SDK de cliente en el proyecto para acceder directamente a un servicio determinado, si lo prefiere. Es posible que tenga que usar los SDK de cliente directamente si las funciones requieren una funcionalidad del SDK subyacente que no es compatible con la extensión de enlace.

Al usar los SDK de cliente, debería usar el mismo proceso para almacenar y acceder a cadenas de conexión usadas por las extensiones de enlace.

Al crear una instancia del SDK de cliente en las funciones, debe obtener la información de conexión requerida por el cliente desde variables de entorno.

Al crear una instancia del SDK de cliente en sus funciones, debe obtener la información de conexión requerida por el cliente de las Variables de entorno.

Conexiones

Como procedimiento recomendado de seguridad, Azure Functions aprovecha la funcionalidad de configuración de la aplicación de Azure App Service para ayudarle a almacenar cadenas, claves y otros tokens de forma más segura necesarios para conectarse a otros servicios. La configuración de la aplicación en Azure se almacena cifrada y la aplicación puede acceder a ella en tiempo de ejecución como variable de entorno name value pares. En el caso de los desencadenadores y enlaces que requieren una propiedad de conexión, establezca el nombre de la configuración de la aplicación en lugar de la cadena de conexión real. No se puede configurar un enlace directamente con una cadena de conexión o una clave.

Por ejemplo, considere una definición de desencadenador que tenga una propiedadconnection. En su lugar, debería establecer connection la conexión con el nombre de una variable de entorno que contiene la cadena de conexión. El uso de esta estrategia de acceso a secretos hace que las aplicaciones sean más seguras y facilita el cambio de conexiones entre entornos. Para obtener aún más seguridad, puede usar conexiones basadas en identidades.

El proveedor de configuración predeterminado utiliza variables de entorno. Estas variables se definen en la configuración de la aplicación cuando se ejecuta en Azure y en el archivo de configuración local al desarrollar localmente.

Valores de conexión

Cuando el nombre de la conexión se resuelve en un solo valor exacto, el tiempo de ejecución identifica el valor como una cadena de conexión, que normalmente incluye un secreto. Los detalles de una cadena de conexión se definen mediante el servicio al que quiere conectarse.

Sin embargo, un nombre de conexión también puede hacer referencia a una colección de varios elementos de configuración, útil para configurar las conexiones basadas en identidades. Las variables de entorno se pueden tratar como una colección mediante un prefijo compartido que termina en doble carácter de subrayado __. A continuación, se puede hacer referencia al grupo. Para ello, establezca el nombre de la conexión en este prefijo.

Por ejemplo, la propiedad connection de una definición de desencadenador de blob de Azure podría ser Storage1. Siempre que no haya ningún valor de cadena único configurado por una variable de entorno denominada Storage1, se podría usar una variable de entorno denominada Storage1__blobServiceUri para informar a la propiedad blobServiceUri de la conexión. Las propiedades de conexión son diferentes para cada servicio. Consulte la documentación del componente que utiliza la conexión.

Nota

Al usar Azure App Configuration o Key Vault para proporcionar la configuración de las conexiones de identidad administrada, los nombres de configuración deben usar un separador de clave válido, como : o / en lugar de __ para asegurarse de que los nombres se resuelven correctamente.

Por ejemplo, Storage1:blobServiceUri.

Configuración de una conexión basada en identidades

Algunas conexiones de Azure Functions pueden estar configuradas para usar una identidad en lugar de un secreto. La compatibilidad depende de la extensión que utiliza la conexión. En algunos casos es posible que se requiera una cadena de conexión en Functions aunque el servicio al que se conecta admita conexiones basadas en identidades. Para obtener un tutorial sobre cómo configurar las aplicaciones de funciones con identidades administradas, consulte el tutorial Creación de una aplicación de funciones con conexiones basadas en identidades.

Nota:

Cuando se ejecuta en un plan de Consumo o Elastic Premium, la aplicación usa las configuraciones WEBSITE_AZUREFILESCONNECTIONSTRING y WEBSITE_CONTENTSHARE al conectarse a Azure Files en la cuenta de almacenamiento usada por la aplicación de funciones. Azure Files no admite el uso de identidades administradas al acceder al recurso compartido de archivos. Para más información, consulte Escenarios de autenticación admitidos en Azure Files

Los siguientes componentes admiten conexiones basadas en identidades:

Origen de la conexión	Planes admitidos	Más información
Desencadenadores y enlaces de Azure Blobs	Todo	Extensión para Azure Blobs, versión 5.0.0 o posterior, Paquete de extensiones 3.3.0 o posterior
Desencadenadores y enlaces de Azure Queues	Todo	Extensión para Azure Queues, versión 5.0.0 o posterior, Paquete de extensiones 3.3.0 o posterior
Azure Tables (cuando se usa Azure Storage)	Todo	Extensión para Azure Tables, versión 1.0.0 o posterior, Paquete de extensiones 3.3.0 o posterior
Azure SQL Database	Todo	Conexión de una aplicación de funciones a Azure SQL con enlaces de identidad y SQL administrados
Desencadenadores y enlaces de Azure Event Hubs	Todo	Extensión para Azure Event Hubs, versión 5.0.0 o posterior, Paquete de extensiones 3.3.0 o posterior
Desencadenadores y enlaces de Azure Service Bus	Todo	Extensión para Azure Service Bus, versión 5.0.0 o posterior, Paquete de extensiones 3.3.0 o posterior
Enlace de salida de Azure Event Grid	All	Extensión de Azure Event Grid, versión 3.3.0 o posterior, Paquete de extensiones 3.3.0 o posterior
Enlaces y desencadenadores de Azure Cosmos DB	Todo	Extensión para Azure Cosmos DB, versión 4.0.0 o una posterior, Paquete de extensiones 4.0.2 o una posterior
Desencadenadores y enlaces de Azure SignalR	Todo	Extensión de Azure SignalR, versión 1.7.0 o posterior Paquete de extensiones 3.6.1 o una posterior
Proveedor de almacenamiento de Durable Functions (Azure Storage)	Todo	Extensión para Durable Functions, versión 2.7.0 o posterior, Paquete de extensiones 3.3.0 o posterior
Almacenamiento necesario para el host ("AzureWebJobsStorage")	All	Conexión al almacenamiento de host con una identidad

Cuando se hospeda en el servicio de Azure Functions, las conexiones basadas en identidades usan una identidad administrada. La identidad asignada por el sistema se usa de manera predeterminada, aunque se puede especificar una identidad asignada por el usuario con las propiedades credential y clientID. Tenga en cuenta que no se admite la configuración de una identidad asignada por el usuario con un identificador de recurso. Cuando se ejecuta en otros contextos, como el de desarrollo local, se usa en su lugar la identidad del desarrollador, aunque se puede personalizar. Consulte Desarrollo local con conexiones basadas en identidades.

Concesión de permiso a la identidad

Cualquier identidad que se utilice debe tener permisos para realizar las acciones previstas. Para la mayoría de los servicios de Azure, esto significa que debe asignar un rol en Azure RBAC mediante roles integrados o personalizados que proporcionen esos permisos.

Importante

Es posible que el servicio de destino muestre algunos permisos que no son necesarios para todos los contextos. Siempre que sea posible, respete el principio de privilegios mínimos y conceda solo los privilegios necesarios a la identidad. Por ejemplo, si la aplicación solo necesita poder leer desde un origen de datos, use un rol que solo tenga permiso de lectura. Sería inadecuado asignar un rol que también permita escribir en ese servicio, ya que sería un permiso excesivo para una operación de lectura. De forma similar, le interesa asegurarse de que la asignación de roles esté limitada solo a los recursos que se deben leer.

Elija una de estas pestañas para obtener información sobre los permisos de cada componente:

Debe crear una asignación de roles que proporcione acceso al contenedor de blobs en tiempo de ejecución. Los roles de administración, como Propietario, no son suficientes. En la tabla siguiente se muestran los roles integrados que se recomiendan al usar la extensión Blob Storage en funcionamiento normal. Tu aplicación puede requerir más permisos según el código que escribas.

Tipo de enlace	Roles integrados de ejemplo
Desencadenador	Propietario de datos de blobs de almacenamiento y Colaborador de datos de cola de almacenamiento¹ También se deben conceder permisos adicionales a la conexión AzureWebJobsStorage.²
Enlace de entrada	Lector de datos de blobs de almacenamiento
Enlace de salida	Propietario de datos de blobs de almacenamiento

¹ El desencadenador de blobs controla los errores en varios reintentos escribiendo blobs dudosos en una cola en la cuenta de almacenamiento especificada por la conexión.

² La conexión AzureWebJobsStorage se usa internamente para blobs y colas que habilitan el desencadenador. Si está configurado para usar una conexión basada en identidades, necesita permisos adicionales más allá del requisito predeterminado. Los permisos necesarios están cubiertos por los roles Propietario de datos de blobs de almacenamiento, Colaborador de datos de la cola de Storage y Colaborador de la cuenta de almacenamiento. Para obtener más información, consulte Conexión al almacenamiento de host con una identidad.

Deberá crear una asignación de roles que proporcione acceso a la cola en tiempo de ejecución. Los roles de administración, como propietario no son suficientes. En la tabla siguiente se muestran los roles integrados que se recomiendan al usar la extensión Queue Storage en funcionamiento normal. Puede que la aplicación precise permisos adicionales en función del código que escriba.

Tipo de enlace	Roles integrados de ejemplo
Desencadenador	Lector de datos de la cola de Storage Blob, Procesador de mensajes de datos de Queue Storage
Enlace de salida	Colaborador de datos de la cola de Storage Blob, Remitente de mensajes de datos de Queue Storage

Debe crear una asignación de roles que proporcione acceso al servicio de tablas de Azure Storage en tiempo de ejecución. Los roles de administración, como Propietario, no son suficientes. En la tabla siguiente se muestran los roles integrados que se recomiendan cuando se usa la extensión para Azure Tables en Azure Storage durante el funcionamiento normal. Puede que la aplicación precise permisos adicionales en función del código que escriba.

Tipo de enlace	Roles integrados de ejemplo (Azure Storage¹)
Enlace de entrada	Lector de datos de tabla de Storage
Enlace de salida	Colaborador de datos de tabla de Storage

¹ Si la aplicación se conecta a tablas de Azure Cosmos DB for Table, no se admite el uso de una identidad y la conexión debe usar una cadena de conexión.

Deberá crear una asignación de roles que proporcione acceso al centro de eventos en tiempo de ejecución. El ámbito de la asignación de roles puede ser para un espacio de nombres de Event Hubs o para el propio centro de eventos. Los roles de administración, como Propietario, no son suficientes. En la tabla siguiente se muestran los roles integrados que se recomiendan al usar la extensión de Event Hubs con un funcionamiento normal. Puede que la aplicación precise permisos adicionales en función del código que escriba.

Tipo de enlace	Roles integrados de ejemplo
Desencadenador	Receptor de los datos de Azure Event Hubs, Propietario de los datos de Azure Event Hubs
Enlace de salida	Emisor de datos de Azure Event Hubs

Tendrá que crear una asignación de roles que proporcione acceso a los temas y las colas en tiempo de ejecución. Los roles de administración, como Propietario, no son suficientes. En la tabla siguiente, se muestran los roles integrados que se recomiendan al usar la extensión de Service Bus en las operaciones normales. Puede que la aplicación precise permisos adicionales en función del código que escriba.

Tipo de enlace	Roles integrados de ejemplo
Desencadenador¹	Receptor de los datos de Azure Service Bus, Propietario de los datos de Azure Service Bus
Enlace de salida	Emisor de datos de Azure Service Bus

¹ Para desencadenar a partir de temas de Service Bus, la asignación de roles debe tener un ámbito efectivo en el recurso de suscripción a Service Bus. Si solo se incluye el tema, se producirá un error. Algunos clientes, como Azure Portal, no exponen el recurso de suscripción a Service Bus como ámbito para la asignación de roles. En tales casos, se podrá usar la CLI de Azure en su lugar. Para obtener más información, consulte Roles integrados de Azure para Azure Service Bus.

Debe crear una asignación de roles que dé acceso al tema de Event Grid en tiempo de ejecución. Los roles de administración, como Propietario, no son suficientes. En la tabla siguiente se muestran los roles integrados que se recomiendan al usar la extensión de Event Hubs con un funcionamiento normal. Puede que la aplicación precise permisos adicionales en función del código que escriba.

Tipo de enlace	Roles integrados de ejemplo
Enlace de salida	Colaborador de EventGrid, Emisor de datos de EventGrid

Cosmos DB no usa Azure RBAC para las operaciones de datos. En su lugar, usa un sistema de RBAC integrado de Cosmos DB que se basa en conceptos similares. Deberá crear una asignación de roles que proporcione acceso a la cuenta de base de datos en tiempo de ejecución. Los roles de administración de Azure RBAC, como Propietario, no son suficientes. En la tabla siguiente se muestran los roles integrados que se recomiendan al usar la extensión de Azure Cosmos DB en funcionamiento normal. Puede que la aplicación precise permisos adicionales en función del código que escriba.

Tipo de enlace	Roles integrados de ejemplo¹
Desencadenador²	Colaborador de datos integrado de Cosmos DB
Enlace de entrada	Lector de datos integrado de Cosmos DB
Enlace de salida	Colaborador de datos integrado de Cosmos DB

¹ Estos roles no se pueden usar en una asignación de roles de RBAC de Azure. Consulte la documentación del sistema de RBAC integrado de Cosmos DB para más información sobre cómo asignar estos roles.

² Cuando se usa la identidad, Cosmos DB trata la creación de contenedores como una operación de administración. No está disponible como una operación de plano de datos para el desencadenador. Deberá asegurarse de crear los contenedores necesarios para el desencadenador (incluido el contenedor de concesión) antes de configurar la función.

Deberá crear una asignación de roles que proporcione acceso a Azure Storage en tiempo de ejecución. Los roles de administración, como Propietario, no son suficientes. Se recomiendan los roles integrados siguientes al usar la extensión Durable Functions con un funcionamiento normal:

Puede que la aplicación precise más permisos en función del código que escriba. Si usa el comportamiento predeterminado o establece connectionName explícitamente en "AzureWebJobsStorage", consulte Conexión al almacenamiento de host con una identidad para otras consideraciones de permisos.

Deberá crear una asignación de roles que proporcione acceso a la cuenta de almacenamiento para "AzureWebJobsStorage" en entorno de ejecución. Los roles de administración, como Propietario, no son suficientes. El rol de Propietario de datos de blobs de almacenamiento cubre las necesidades básicas del almacenamiento de host de Functions: el entorno de ejecución necesita acceso de lectura y escritura a blobs y la capacidad de crear contenedores. Varias extensiones usan esta conexión como ubicación predeterminada para blobs, colas y tablas, y estos usos pueden agregar requisitos como se indica en la tabla siguiente. Puede que necesite permisos adicionales si usa "AzureWebJobsStorage" para cualquier otro fin.

Comprobación de actualización	Roles necesarios	Explicación
Sin extensión (solo host)	Propietario de datos de blobs de almacenamiento	Se usa para la coordinación general, almacén de claves predeterminado.
Blobs de Azure (solo desencadenador)	Todo de: Colaborador de la cuenta de almacenamiento, Propietario de datos de Storage Blob, Colaborador de datos de la cola de Storage	El desencadenador de blobs usa internamente colas de Azure y escribe recibos de blob. Usa AzureWebJobsStorage para estos, independientemente de la conexión configurada para el desencadenador.
Azure Event Hubs (solo desencadenador)	(ningún cambio con respecto al requisito predeterminado) Propietario de datos de blobs de almacenamiento	Los puntos de control se conservan en blobs mediante la conexión AzureWebJobsStorage.
Desencadenador de temporizador	(ningún cambio con respecto al requisito predeterminado) Propietario de datos de blobs de almacenamiento	Para garantizar una ejecución por evento, los bloqueos se toman con blobs mediante la conexión AzureWebJobsStorage.
Funciones duraderas	Todo de: Colaborador de datos de Storage Blob, Colaborador de datos de la cola de Storage, Colaborador de datos de tabla de Storage	Durable Functions usa blobs, colas y tablas para coordinar las funciones de actividad y mantener el estado de orquestación. Usa la conexión AzureWebJobsStorage para todos ellos de manera predeterminada, pero puede especificar una conexión diferente en la configuración de extensiones de Durable Functions.

Propiedades comunes para conexiones basadas en identidades

Una conexión basada en identidades para un servicio de Azure acepta las siguientes propiedades comunes, en las que <CONNECTION_NAME_PREFIX> es el valor de la propiedad connection en la definición de desencadenador o enlace:

Propiedad	Plantilla de variable de entorno	Descripción
Credencial de token	`<CONNECTION_NAME_PREFIX>__credential`	Define cómo se debe obtener un token para la conexión. Esta configuración debe establecerse en `managedidentity` si su función de Azure implementada pretende utilizar la autenticación de identidad administrada. Este valor sólo es válido cuando existe una identidad administrada disponible en el entorno del hospedaje.
Id. de cliente	`<CONNECTION_NAME_PREFIX>__clientId`	Cuando `credential` se establece en `managedidentity`, esta propiedad se puede establecer para especificar la identidad asignada por el usuario que se utilizará al obtener un token. La propiedad acepta un identificador de cliente correspondiente a una identidad asignada por el usuario asignada a la aplicación. No es válido especificar un id. de recurso así como tampoco es válido un id. de cliente. Si no se especifica, se usa la identidad asignada por el sistema. Esta propiedad se usa de forma diferente en escenarios de desarrollo locales, en los que no se debe establecer el elemento `credential`.
Id. de recurso	`<CONNECTION_NAME_PREFIX>__managedIdentityResourceId`	Cuando `credential` se establece en `managedidentity`, esta propiedad se puede establecer para que especifique el identificador de recurso que se utilizará al obtener un token. La propiedad acepta un identificador de recurso correspondiente al Id. de recurso de la identidad administrada definida por el usuario. No es válido especificar un Id. de recurso así como tampoco es válido un Id. de cliente. Si no se especifica ninguna de las dos, se utiliza la identidad asignada por el sistema. Esta propiedad se usa de forma diferente en escenarios de desarrollo locales, en los que no se debe establecer el elemento `credential`.

Es posible que se admitan otras opciones para un tipo de conexión determinado. Consulte la documentación del componente que realiza la conexión.

Desarrollo local con conexiones basadas en identidades

Nota:

El desarrollo local con conexiones basadas en identidades requiere la versión 4.0.3904 de Azure Functions Core Tools, o una versión posterior.

Cuando ejecuta su proyecto de función localmente, la configuración anterior le indica al tiempo de ejecución que use la identidad del desarrollador local. La conexión intenta obtener un token de las siguientes ubicaciones, en orden:

Una caché local compartida entre las aplicaciones de Microsoft
El contexto del usuario actual en Visual Studio
El contexto del usuario actual en Visual Studio Code
El contexto del usuario actual en la CLI de Azure

Si ninguna de estas opciones produce un resultado satisfactorio, se producirá un error.

Es posible que la identidad ya tenga algunas asignaciones de roles en los recursos de Azure usados para el desarrollo, pero es posible que esos roles no proporcionen el acceso a datos necesario. Los roles de administración, como Propietario, no son suficientes. Compruebe los permisos necesarios para las conexiones de cada componente y asegúrese de que se le han asignado.

En algunos casos, puede especificar el uso de una identidad diferente. Puede agregar propiedades de configuración para la conexión que apunten a la identidad alternativa en función de un identificador de cliente y un secreto de cliente para una entidad de servicio de Microsoft Entra. No se admite esta opción de configuración cuando se hospedan en el servicio Azure Functions. Para usar un Id. y un secreto en su máquina local, defina la conexión con las siguientes propiedades adicionales:

Propiedad	Plantilla de variable de entorno	Descripción
Id. de inquilino	`<CONNECTION_NAME_PREFIX>__tenantId`	Id. de inquilino de Microsoft Entra (directorio).
Id de cliente	`<CONNECTION_NAME_PREFIX>__clientId`	Id. de cliente (aplicación) de un registro de aplicación en el inquilino.
Secreto del cliente	`<CONNECTION_NAME_PREFIX>__clientSecret`	Secreto de cliente generado para el registro de la aplicación.

Ejemplo de las propiedades local.settings.json requeridas para la conexión basada en identidades para Azure Blobs:

{
  "IsEncrypted": false,
  "Values": {
    "<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
    "<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
    "<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
    "<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
    "<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
  }
}

Conexión al almacenamiento de host con una identidad

Azure Functions usa la conexión de almacenamiento establecida en AzureWebJobsStorage para habilitar comportamientos básicos, como la coordinación de la ejecución de singleton de los desencadenadores de temporizador y el almacenamiento de claves de aplicación predeterminado. Esta conexión también se puede configurar para usar una identidad.

Precaución

Otros componentes de Functions dependen de AzureWebJobsStorage para los comportamientos predeterminados. No debe moverlo a una conexión basada en identidades si usa versiones anteriores de extensiones que no admiten este tipo de conexión, incluidos desencadenadores y enlaces para Azure Blobs, Event Hubs y Durable Functions. De forma similar, AzureWebJobsStorage se usa para los artefactos de implementación cuando se usa la compilación del lado servidor en Consumo para Linux y, si se habilita, deberá implementar a través de AzureWebJobsStorage.

Además, la aplicación de funciones podría reutilizar AzureWebJobsStorage para otras conexiones de almacenamiento en sus desencadenadores, enlaces o código de función. Asegúrese de que todos los usos de AzureWebJobsStorage pueden utilizar el formato de conexión basado en identidad antes de cambiar esta conexión de una cadena de conexión.

Para usar una conexión basada en identidades para AzureWebJobsStorage, configure las siguientes opciones de la aplicación:

Configuración	Descripción	Valor de ejemplo
`AzureWebJobsStorage__blobServiceUri`	El identificador URI del plano de datos del servicio de blobs de la cuenta de almacenamiento, con el esquema HTTPS.	https://<storage_account_name>.blob.core.windows.net
`AzureWebJobsStorage__queueServiceUri`	El identificador URI del plano de datos del servicio de cola de la cuenta de almacenamiento, con el esquema HTTPS.	https://<storage_account_name>.queue.core.windows.net
`AzureWebJobsStorage__tableServiceUri`	El URI del plano de datos de un Table service de la cuenta de almacenamiento, con el esquema HTTPS.	https://<nombre_cuenta_almacenamiento>.table.core.windows.net

También se pueden establecer Propiedades comunes para conexiones basadas en identidades.

Si configura AzureWebJobsStorage con una cuenta de almacenamiento que utiliza el nombre del servicio y el sufijo DNS predeterminados para Azure global, con el formato https://<accountName>.[blob|queue|file|table].core.windows.net puede, en cambio, establecer AzureWebJobsStorage__accountName en el nombre de la cuenta de almacenamiento. Los puntos de conexión para cada servicio de almacenamiento se deducen para esta cuenta. Esto no funciona cuando la cuenta de almacenamiento está en una nube soberana o tiene un DNS personalizado.

Configuración	Descripción	Valor de ejemplo
`AzureWebJobsStorage__accountName`	Nombre de una cuenta de almacenamiento, válido solo si la cuenta no está en una nube soberana y no tiene un DNS personalizado. Esta sintaxis es única de `AzureWebJobsStorage` y no se puede usar para otras conexiones basadas en identidades.	<storage_account_name>

Comprobación de actualización	Roles necesarios	Explicación
Sin extensión (solo host)	Propietario de datos de blobs de almacenamiento	Se usa para la coordinación general, almacén de claves predeterminado.
Blobs de Azure (solo desencadenador)	Todo de: Colaborador de la cuenta de almacenamiento, Propietario de datos de Storage Blob, Colaborador de datos de la cola de Storage	El desencadenador de blobs usa internamente colas de Azure y escribe recibos de blob. Usa AzureWebJobsStorage para estos, independientemente de la conexión configurada para el desencadenador.
Azure Event Hubs (solo desencadenador)	(ningún cambio con respecto al requisito predeterminado) Propietario de datos de blobs de almacenamiento	Los puntos de control se conservan en blobs mediante la conexión AzureWebJobsStorage.
Desencadenador de temporizador	(ningún cambio con respecto al requisito predeterminado) Propietario de datos de blobs de almacenamiento	Para garantizar una ejecución por evento, los bloqueos se toman con blobs mediante la conexión AzureWebJobsStorage.
Funciones duraderas	Todo de: Colaborador de datos de Storage Blob, Colaborador de datos de la cola de Storage, Colaborador de datos de tabla de Storage	Durable Functions usa blobs, colas y tablas para coordinar las funciones de actividad y mantener el estado de orquestación. Usa la conexión AzureWebJobsStorage para todos ellos de manera predeterminada, pero puede especificar una conexión diferente en la configuración de extensiones de Durable Functions.

Problemas de informes

Elemento	Descripción	Vínculo
Tiempo de ejecución	Host de script, desencadenadores y enlaces, compatibilidad con idiomas	Registre un problema
Plantillas	Problemas de código con la plantilla de creación	Registre un problema
Portal	Interfaz de usuario o problema de la experiencia	Registre un problema