Delen via


Ontwikkelaarshandleiding voor Azure Functions

In Azure Functions delen alle functies enkele belangrijke technische concepten en onderdelen, ongeacht uw voorkeurstaal of ontwikkelomgeving. Dit artikel is taalspecifiek. Kies uw voorkeurstaal bovenaan het artikel.

In dit artikel wordt ervan uitgegaan dat u het overzicht van Azure Functions al hebt gelezen.

Als u liever meteen aan de slag gaat, kunt u een quickstart-zelfstudie voltooien met Visual Studio, Visual Studio Code of vanaf de opdrachtprompt.

Als u liever meteen aan de slag gaat, kunt u een quickstart-zelfstudie voltooien met behulp van Maven (opdrachtregel), Eclipse, IntelliJ IDEA, Gradle, Quarkus, Spring Cloud of Visual Studio Code.

Als u liever meteen aan de slag gaat, kunt u een quickstart-zelfstudie voltooien met Visual Studio Code of vanaf de opdrachtprompt.

Als u liever meteen aan de slag gaat, kunt u een quickstart-zelfstudie voltooien met Visual Studio Code of vanaf de opdrachtprompt.

Als u liever meteen aan de slag gaat, kunt u een quickstart-zelfstudie voltooien met Visual Studio Code of vanaf de opdrachtprompt.

Als u liever meteen aan de slag gaat, kunt u een quickstart-zelfstudie voltooien met Visual Studio Code of vanaf de opdrachtprompt.

Codeproject

In de kern van Azure Functions is een taalspecifiek codeproject dat een of meer eenheden code-uitvoering implementeert die functies worden genoemd. Functies zijn gewoon methoden die worden uitgevoerd in de Azure-cloud op basis van gebeurtenissen, in reactie op HTTP-aanvragen of volgens een schema. Denk aan uw Azure Functions-codeproject als mechanisme voor het organiseren, implementeren en gezamenlijk beheren van uw afzonderlijke functies in het project wanneer ze worden uitgevoerd in Azure. Zie Uw functies organiseren voor meer informatie.

De manier waarop u uw codeproject indeelt en hoe u aangeeft welke methoden in uw project functies zijn, is afhankelijk van de ontwikkeltaal van uw project. Zie de handleiding voor C#-ontwikkelaars voor gedetailleerde taalspecifieke richtlijnen.

De manier waarop u uw codeproject indeelt en hoe u aangeeft welke methoden in uw project functies zijn, is afhankelijk van de ontwikkeltaal van uw project. Zie de Java-ontwikkelaarshandleiding voor taalspecifieke richtlijnen.

De manier waarop u uw codeproject indeelt en hoe u aangeeft welke methoden in uw project functies zijn, is afhankelijk van de ontwikkeltaal van uw project. Zie de handleiding Node.js ontwikkelaars voor taalspecifieke richtlijnen.

De manier waarop u uw codeproject indeelt en hoe u aangeeft welke methoden in uw project functies zijn, is afhankelijk van de ontwikkeltaal van uw project. Zie de Handleiding voor PowerShell-ontwikkelaars voor taalspecifieke richtlijnen.

De manier waarop u uw codeproject indeelt en hoe u aangeeft welke methoden in uw project functies zijn, is afhankelijk van de ontwikkeltaal van uw project. Zie de Python-ontwikkelaarshandleiding voor taalspecifieke richtlijnen.

Alle functies moeten een trigger hebben, waarmee wordt gedefinieerd hoe de functie wordt gestart en invoer kan worden gegeven aan de functie. Uw functies kunnen desgewenst invoer- en uitvoerbindingen definiëren. Deze bindingen vereenvoudigen verbindingen met andere services zonder dat u met client-SDK's hoeft te werken. Zie Concepten van Azure Functions-triggers en -bindingen voor meer informatie.

Azure Functions biedt een set taalspecifieke project- en functiesjablonen waarmee u eenvoudig nieuwe codeprojecten kunt maken en functies kunt toevoegen aan uw project. U kunt elk van de hulpprogramma's gebruiken die ondersteuning bieden voor Azure Functions-ontwikkeling om nieuwe apps en functies te genereren met behulp van deze sjablonen.

Ontwikkelhulpprogramma’s

De volgende hulpprogramma's bieden een geïntegreerde ontwikkel- en publicatie-ervaring voor Azure Functions in uw voorkeurstaal:

Deze hulpprogramma's kunnen worden geïntegreerd met Azure Functions Core Tools , zodat u fouten kunt uitvoeren en fouten kunt opsporen op uw lokale computer met behulp van de Functions-runtime. Zie Code and test Azure Functions lokaal voor meer informatie.

Er is ook een editor in Azure Portal waarmee u uw code en uw function.json definitiebestand rechtstreeks in de portal kunt bijwerken. U moet deze editor alleen gebruiken voor kleine wijzigingen of het maken van proof-of-concept-functies. U moet uw functies altijd lokaal ontwikkelen, indien mogelijk. Zie Uw eerste functie maken in Azure Portal voor meer informatie.

Portalbewerking wordt alleen ondersteund voor Node.js versie 3, die gebruikmaakt van het function.json-bestand.

Implementatie

Wanneer u uw codeproject publiceert naar Azure, implementeert u uw project in feite in een bestaande functie-app-resource. Een functie-app biedt een uitvoeringscontext in Azure waarin uw functies worden uitgevoerd. Als zodanig is het de eenheid van implementatie en beheer voor uw functies. Vanuit het oogpunt van Een Azure-resource is een functie-app gelijk aan een siteresource (Microsoft.Web/sites) in Azure-app Service, wat gelijk is aan een web-app.

Een functie-app bestaat uit een of meer afzonderlijke functies die samen worden beheerd, geïmplementeerd en geschaald. Alle functies in een functie-app delen hetzelfde prijsplan, dezelfde implementatiemethode en runtimeversie. Zie Een functie-app beheren voor meer informatie.

Wanneer de functie-app en andere vereiste resources nog niet bestaan in Azure, moet u deze resources eerst maken voordat u uw projectbestanden kunt implementeren. U kunt deze resources op een van de volgende manieren maken:

Naast publiceren op basis van hulpprogramma's ondersteunt Functions andere technologieën voor het implementeren van broncode in een bestaande functie-app. Zie Implementatietechnologieën in Azure Functions voor meer informatie.

Verbinding maken met services

Een belangrijke vereiste van elke cloudgebaseerde rekenservice is het lezen van gegevens van en het schrijven van gegevens naar andere cloudservices. Functies bieden een uitgebreide set bindingen waarmee u gemakkelijker verbinding kunt maken met services zonder dat u hoeft te werken met client-SDK's.

Of u nu de bindingsextensies van Functions gebruikt of rechtstreeks met client-SDK's werkt, u slaat de verbindingsgegevens veilig op en neemt deze niet op in uw code. Zie Verbindingen voor meer informatie.

Bindingen

Functions biedt bindingen voor veel Azure-services en enkele services van derden, die worden geïmplementeerd als extensies. Zie de volledige lijst met ondersteunde bindingen voor meer informatie.

Bindingextensies kunnen zowel invoer- als uitvoer ondersteunen, en veel triggers fungeren ook als invoerbindingen. Met bindingen kunt u de verbinding met services configureren, zodat de Functions-host de gegevenstoegang voor u kan verwerken. Zie Concepten van Azure Functions-triggers en -bindingen voor meer informatie.

Als u problemen ondervindt met fouten die afkomstig zijn van bindingen, raadpleegt u de documentatie over Azure Functions-bindingsfoutcodes .

Client-SDK 's

Hoewel Functions bindingen biedt om de toegang tot gegevens in uw functiecode te vereenvoudigen, kunt u desgewenst nog steeds een client-SDK in uw project gebruiken om rechtstreeks toegang te krijgen tot een bepaalde service. Mogelijk moet u client-SDK's rechtstreeks gebruiken als uw functies een functionaliteit vereisen van de onderliggende SDK die niet wordt ondersteund door de bindingsextensie.

Wanneer u client-SDK's gebruikt, moet u hetzelfde proces gebruiken voor het opslaan en openen van verbindingsreeks die worden gebruikt door bindingsextensies.

Wanneer u een client-SDK-exemplaar in uw functies maakt, moet u de verbindingsgegevens ophalen die de client nodig heeft vanuit omgevingsvariabelen.

Wanneer u een client-SDK-exemplaar in uw functies maakt, moet u de verbindingsgegevens ophalen die de client nodig heeft vanuit omgevingsvariabelen.

Wanneer u een client-SDK-exemplaar in uw functies maakt, moet u de verbindingsgegevens ophalen die de client nodig heeft vanuit omgevingsvariabelen.

Wanneer u een client-SDK-exemplaar in uw functies maakt, moet u de verbindingsgegevens ophalen die de client nodig heeft vanuit omgevingsvariabelen.

Wanneer u een client-SDK-exemplaar in uw functies maakt, moet u de verbindingsgegevens ophalen die de client nodig heeft vanuit omgevingsvariabelen.

Connecties

Als best practice voor beveiliging maakt Azure Functions gebruik van de functionaliteit voor toepassingsinstellingen van Azure-app Service om u te helpen tekenreeksen, sleutels en andere tokens die nodig zijn om verbinding te maken met andere services veiliger op te slaan. Toepassingsinstellingen in Azure worden versleuteld opgeslagen en kunnen tijdens runtime worden geopend door uw app als omgevingsvariabeleparen name value . Voor triggers en bindingen waarvoor een verbindingseigenschap is vereist, stelt u de naam van de toepassingsinstelling in in plaats van de werkelijke verbindingsreeks. U kunt een binding niet rechtstreeks configureren met een verbindingsreeks of sleutel.

Denk bijvoorbeeld aan een triggerdefinitie met een connection eigenschap. In plaats van de verbindingsreeks stelt connection u in op de naam van een omgevingsvariabele die de verbindingsreeks bevat. Door deze toegangsstrategie voor geheimen te gebruiken, zijn uw apps veiliger en kunt u eenvoudiger verbindingen tussen omgevingen wijzigen. Voor nog meer beveiliging kunt u op identiteit gebaseerde verbindingen gebruiken.

De standaardconfiguratieprovider maakt gebruik van omgevingsvariabelen. Deze variabelen worden gedefinieerd in toepassingsinstellingen wanneer ze worden uitgevoerd in Azure en in het bestand met lokale instellingen bij het lokaal ontwikkelen.

Verbindingswaarden

Wanneer de verbindingsnaam wordt omgezet in één exacte waarde, identificeert de runtime de waarde als een verbindingsreeks, die doorgaans een geheim bevat. De details van een verbindingsreeks zijn afhankelijk van de service waarmee u verbinding maakt.

Een verbindingsnaam kan echter ook verwijzen naar een verzameling van meerdere configuratie-items, handig voor het configureren van op identiteit gebaseerde verbindingen. Omgevingsvariabelen kunnen worden behandeld als een verzameling met behulp van een gedeeld voorvoegsel dat eindigt op dubbele onderstrepingstekens __. Er kan vervolgens naar de groep worden verwezen door de verbindingsnaam in te stellen op dit voorvoegsel.

De eigenschap voor een Azure Blob-triggerdefinitie kan bijvoorbeeld connection zijn Storage1. Zolang er geen enkele tekenreekswaarde is geconfigureerd door een omgevingsvariabele met de naam Storage1, kan een omgevingsvariabele met de naam Storage1__blobServiceUri worden gebruikt om de blobServiceUri eigenschap van de verbinding te informeren. De verbindingseigenschappen verschillen voor elke service. Raadpleeg de documentatie voor het onderdeel dat gebruikmaakt van de verbinding.

Notitie

Wanneer u Azure-app Configuratie of Key Vault gebruikt om instellingen voor beheerde identiteitverbindingen te bieden, moeten instellingsnamen een geldig sleutelscheidingsteken gebruiken, zoals : of / in plaats van de __ sleutelkluis om ervoor te zorgen dat namen correct worden omgezet.

Bijvoorbeeld: Storage1:blobServiceUri.

Een op identiteit gebaseerde verbinding configureren

Sommige verbindingen in Azure Functions kunnen worden geconfigureerd om een identiteit te gebruiken in plaats van een geheim. Ondersteuning is afhankelijk van de runtimeversie en de extensie met behulp van de verbinding. In sommige gevallen is een verbindingsreeks mogelijk nog steeds vereist in Functions, ook al ondersteunt de service waarmee u verbinding maakt, identiteitsverbindingen. Zie de zelfstudie over het maken van een functie-app met op identiteit gebaseerde verbindingen voor een zelfstudie over het configureren van uw functie-apps met beheerde identiteiten.

Notitie

Bij uitvoering in een Verbruiks- of Elastic Premium-abonnement gebruikt uw app de en WEBSITE_CONTENTSHARE instellingen bij het WEBSITE_AZUREFILESCONNECTIONSTRING maken van verbinding met Azure Files in het opslagaccount dat wordt gebruikt door uw functie-app. Azure Files biedt geen ondersteuning voor het gebruik van beheerde identiteit bij het openen van de bestandsshare. Zie Ondersteunde verificatiescenario's voor Azure Files voor meer informatie

Op identiteit gebaseerde verbindingen worden alleen ondersteund op Functions 4.x. Als u versie 1.x gebruikt, moet u eerst migreren naar versie 4.x.

De volgende onderdelen ondersteunen op identiteit gebaseerde verbindingen:

Verbindingsbron Ondersteunde plannen Meer informatie
Azure Blobs-triggers en -bindingen Alle Azure Blobs-extensie versie 5.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Queues-triggers en -bindingen Alle Azure Queues-extensie versie 5.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Tables (bij gebruik van Azure Storage) Alle Azure Tables-extensie versie 1.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure SQL-database Alle Een functie-app verbinden met Azure SQL met beheerde identiteiten en SQL-bindingen
Azure Event Hubs-triggers en -bindingen Alle Azure Event Hubs-extensie versie 5.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Service Bus-triggers en -bindingen Alle Azure Service Bus-extensie versie 5.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Event Grid-uitvoerbinding Alle Azure Event Grid-extensie versie 3.3.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Cosmos DB-triggers en -bindingen Alle Azure Cosmos DB-extensie versie 4.0.0 of hoger,
Uitbreidingsbundel 4.0.2 of hoger
Azure SignalR-triggers en -bindingen Alle Azure SignalR-extensie versie 1.7.0 of hoger
Uitbreidingsbundel 3.6.1 of hoger
Durable Functions-opslagprovider (Azure Storage) Alle Durable Functions-extensie versie 2.7.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Host-vereiste opslag ('AzureWebJobsStorage') Alle Verbinding maken met hostopslag met een identiteit

Wanneer deze worden gehost in de Azure Functions-service, maken identiteitsverbindingen gebruik van een beheerde identiteit. De door het systeem toegewezen identiteit wordt standaard gebruikt, hoewel een door de gebruiker toegewezen identiteit kan worden opgegeven met de credential en clientID eigenschappen. Houd er rekening mee dat het configureren van een door de gebruiker toegewezen identiteit met een resource-id niet wordt ondersteund. Wanneer uw ontwikkelaarsidentiteit wordt uitgevoerd in andere contexten, zoals lokale ontwikkeling, wordt in plaats daarvan uw ontwikkelaarsidentiteit gebruikt, hoewel dit kan worden aangepast. Zie Lokale ontwikkeling met op identiteit gebaseerde verbindingen.

Toestemming verlenen aan de identiteit

Elke identiteit die wordt gebruikt, moet machtigingen hebben om de beoogde acties uit te voeren. Voor de meeste Azure-services betekent dit dat u een rol in Azure RBAC moet toewijzen met behulp van ingebouwde of aangepaste rollen die deze machtigingen bieden.

Belangrijk

Sommige machtigingen worden mogelijk weergegeven door de doelservice die niet nodig is voor alle contexten. Waar mogelijk moet u zich houden aan het principe van minimale bevoegdheid, waarbij de identiteit alleen vereiste bevoegdheden verleent. Als de app bijvoorbeeld alleen uit een gegevensbron moet kunnen lezen, gebruikt u een rol die alleen gemachtigd is om te lezen. Het zou ongepast zijn om een rol toe te wijzen die ook schrijfbewerkingen naar die service toestaat, omdat dit overmatige machtigingen zou zijn voor een leesbewerking. Op dezelfde manier wilt u ervoor zorgen dat de roltoewijzing alleen is afgestemd op de resources die moeten worden gelezen.

Kies een van deze tabbladen voor meer informatie over machtigingen voor elk onderdeel:

U moet een roltoewijzing maken die tijdens runtime toegang biedt tot uw blobcontainer. Beheerrollen zoals Eigenaar zijn niet voldoende. In de volgende tabel ziet u ingebouwde rollen die worden aanbevolen bij het gebruik van de Blob Storage-extensie in normale werking. Uw toepassing vereist mogelijk verdere machtigingen op basis van de code die u schrijft.

Bindingstype Voorbeeld van ingebouwde rollen
Trigger Eigenaar van opslagblobgegevens en Inzendervoor opslagwachtrijgegevens 1

Er moeten ook extra machtigingen worden verleend aan de AzureWebJobsStorage-verbinding.2
Invoerbinding Lezer voor opslagblobgegevens
Uitvoerbinding Eigenaar van opslagblobgegevens

1 De blobtrigger verwerkt fouten in meerdere nieuwe pogingen door gif-blobs naar een wachtrij te schrijven in het opslagaccount dat is opgegeven door de verbinding.

2 De AzureWebJobsStorage-verbinding wordt intern gebruikt voor blobs en wachtrijen die de trigger inschakelen. Als deze is geconfigureerd voor het gebruik van een op identiteit gebaseerde verbinding, heeft deze extra machtigingen nodig dan de standaardvereiste. De vereiste machtigingen vallen onder de rollen Eigenaar van opslagblobgegevens, Inzender voor opslagwachtrijgegevens en Inzender voor opslagaccounts. Zie Verbinding maken met hostopslag met een identiteit voor meer informatie.

Algemene eigenschappen voor op identiteit gebaseerde verbindingen

Een op identiteit gebaseerde verbinding voor een Azure-service accepteert de volgende algemene eigenschappen, waarbij <CONNECTION_NAME_PREFIX> de waarde van uw connection eigenschap in de trigger- of bindingsdefinitie is:

Eigenschappen Sjabloon voor omgevingsvariabele Beschrijving
Tokenreferenties <CONNECTION_NAME_PREFIX>__credential Hiermee definieert u hoe een token moet worden verkregen voor de verbinding. Deze instelling moet worden ingesteld managedidentity op als uw geïmplementeerde Azure-functie van plan is om verificatie van beheerde identiteiten te gebruiken. Deze waarde is alleen geldig wanneer een beheerde identiteit beschikbaar is in de hostingomgeving.
Client ID <CONNECTION_NAME_PREFIX>__clientId Wanneer credential deze eigenschap is ingesteld managedidentityop, kan deze eigenschap worden ingesteld om de door de gebruiker toegewezen identiteit op te geven die moet worden gebruikt bij het verkrijgen van een token. De eigenschap accepteert een client-id die overeenkomt met een door de gebruiker toegewezen identiteit die aan de toepassing is toegewezen. Het is ongeldig om zowel een resource-id als een client-id op te geven. Als dit niet is opgegeven, wordt de door het systeem toegewezen identiteit gebruikt. Deze eigenschap wordt anders gebruikt in lokale ontwikkelscenario's, wanneer credential deze niet moeten worden ingesteld.
Resource-id <CONNECTION_NAME_PREFIX>__managedIdentityResourceId Wanneer credential deze eigenschap is ingesteld managedidentityop, kan deze eigenschap worden ingesteld om de resource-id op te geven die moet worden gebruikt bij het verkrijgen van een token. De eigenschap accepteert een resource-id die overeenkomt met de resource-id van de door de gebruiker gedefinieerde beheerde identiteit. Het is ongeldig om zowel een resource-id als een client-id op te geven. Als er geen van beide zijn opgegeven, wordt de door het systeem toegewezen identiteit gebruikt. Deze eigenschap wordt anders gebruikt in lokale ontwikkelscenario's, wanneer credential deze niet moeten worden ingesteld.

Andere opties kunnen worden ondersteund voor een bepaald verbindingstype. Raadpleeg de documentatie voor het onderdeel dat de verbinding maakt.

Omgevingsvariabelen voor Azure SDK

Let op

Het gebruik van de omgevingsvariabelen van de Azure SDK EnvironmentCredential wordt niet aanbevolen vanwege de mogelijk onbedoelde impact op andere verbindingen. Ze worden ook niet volledig ondersteund wanneer ze worden geïmplementeerd in Azure Functions.

De omgevingsvariabelen die zijn gekoppeld aan de Azure SDK's EnvironmentCredential kunnen ook worden ingesteld, maar deze worden niet verwerkt door de Functions-service voor het schalen van verbruiksplannen. Deze omgevingsvariabelen zijn niet specifiek voor één verbinding en worden als standaard toegepast, tenzij een bijbehorende eigenschap niet is ingesteld voor een bepaalde verbinding. Als deze bijvoorbeeld AZURE_CLIENT_ID is ingesteld, wordt dit gebruikt alsof <CONNECTION_NAME_PREFIX>__clientId deze is geconfigureerd. Als u deze standaardinstelling expliciet <CONNECTION_NAME_PREFIX>__clientId instelt, wordt deze standaardinstelling overschreven.

Lokale ontwikkeling met op identiteit gebaseerde verbindingen

Notitie

Voor lokale ontwikkeling met op identiteit gebaseerde verbindingen is versie 4.0.3904 van Azure Functions Core Tools of een latere versie vereist.

Wanneer u uw functieproject lokaal uitvoert, geeft de bovenstaande configuratie aan dat de runtime uw lokale ontwikkelaarsidentiteit moet gebruiken. De verbinding probeert een token op te halen van de volgende locaties, in volgorde:

  • Een lokale cache die wordt gedeeld tussen Microsoft-toepassingen
  • De huidige gebruikerscontext in Visual Studio
  • De huidige gebruikerscontext in Visual Studio Code
  • De huidige gebruikerscontext in de Azure CLI

Als geen van deze opties is geslaagd, treedt er een fout op.

Uw identiteit heeft mogelijk al enkele roltoewijzingen voor Azure-resources die worden gebruikt voor ontwikkeling, maar deze rollen bieden mogelijk niet de benodigde gegevenstoegang. Beheerrollen zoals Eigenaar zijn niet voldoende. Controleer welke machtigingen vereist zijn voor verbindingen voor elk onderdeel en zorg ervoor dat u ze aan uzelf hebt toegewezen.

In sommige gevallen kunt u het gebruik van een andere identiteit opgeven. U kunt configuratie-eigenschappen toevoegen voor de verbinding die verwijzen naar de alternatieve identiteit op basis van een client-id en clientgeheim voor een Microsoft Entra-service-principal. Deze configuratieoptie wordt niet ondersteund wanneer deze wordt gehost in de Azure Functions-service. Als u een id en geheim op uw lokale computer wilt gebruiken, definieert u de verbinding met de volgende extra eigenschappen:

Eigenschappen Sjabloon voor omgevingsvariabele Beschrijving
Tenant-id <CONNECTION_NAME_PREFIX>__tenantId De id van de Microsoft Entra-tenant (directory).
Client ID <CONNECTION_NAME_PREFIX>__clientId De client-id (toepassing) van een app-registratie in de tenant.
Clientgeheim <CONNECTION_NAME_PREFIX>__clientSecret Een clientgeheim dat is gegenereerd voor de app-registratie.

Hier volgt een voorbeeld van eigenschappen die local.settings.json vereist zijn voor een op identiteit gebaseerde verbinding met 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>"
  }
}

Verbinding maken met hostopslag met een identiteit

De Azure Functions-host maakt gebruik van de opslagverbinding die is ingesteld AzureWebJobsStorage om kerngedrag mogelijk te maken, zoals het coördineren van singleton-uitvoering van timertriggers en standaardopslag van app-sleutels. Deze verbinding kan ook worden geconfigureerd voor het gebruik van een identiteit.

Let op

Andere onderdelen in Functions zijn afhankelijk AzureWebJobsStorage van standaardgedrag. Verplaats deze niet naar een op identiteit gebaseerde verbinding als u oudere versies van extensies gebruikt die dit type verbinding niet ondersteunen, inclusief triggers en bindingen voor Azure Blobs, Event Hubs en Durable Functions. Op dezelfde manier AzureWebJobsStorage wordt gebruikt voor implementatieartefacten bij het gebruik van build aan de serverzijde in Linux-verbruik. Als u dit inschakelt, moet u implementeren via een extern implementatiepakket.

Bovendien kan uw functie-app hergebruiken AzureWebJobsStorage voor andere opslagverbindingen in hun triggers, bindingen en/of functiecode. Zorg ervoor dat alle toepassingen van AzureWebJobsStorage de id-gebaseerde verbindingsindeling kunnen gebruiken voordat u deze verbinding wijzigt vanuit een verbindingsreeks.

Als u een op identiteit gebaseerde verbinding wilt AzureWebJobsStoragegebruiken, configureert u de volgende app-instellingen:

Instelling Beschrijving Voorbeeldwaarde
AzureWebJobsStorage__blobServiceUri De gegevensvlak-URI van de blobservice van het opslagaccount met behulp van het HTTPS-schema. <https:// storage_account_name.blob.core.windows.net>
AzureWebJobsStorage__queueServiceUri De gegevensvlak-URI van de wachtrijservice van het opslagaccount met behulp van het HTTPS-schema. <https:// storage_account_name.queue.core.windows.net>
AzureWebJobsStorage__tableServiceUri De gegevensvlak-URI van een tabelservice van het opslagaccount met behulp van het HTTPS-schema. <https:// storage_account_name.table.core.windows.net>

Algemene eigenschappen voor op identiteit gebaseerde verbindingen kunnen ook worden ingesteld.

Als u configureert AzureWebJobsStorage met behulp van een opslagaccount dat gebruikmaakt van het standaard-DNS-achtervoegsel en de servicenaam voor globale Azure, kunt u in plaats daarvan https://<accountName>.[blob|queue|file|table].core.windows.net instellen AzureWebJobsStorage__accountName op de naam van uw opslagaccount. De eindpunten voor elke opslagservice worden afgeleid voor dit account. Dit werkt niet wanneer het opslagaccount zich in een onafhankelijke cloud bevindt of een aangepaste DNS heeft.

Instelling Beschrijving Voorbeeldwaarde
AzureWebJobsStorage__accountName De accountnaam van een opslagaccount, alleen geldig als het account zich niet in een onafhankelijke cloud bevindt en geen aangepaste DNS heeft. Deze syntaxis is uniek voor AzureWebJobsStorage en kan niet worden gebruikt voor andere op identiteit gebaseerde verbindingen. <storage_account_name>

U moet een roltoewijzing maken die tijdens runtime toegang biedt tot het opslagaccount voor AzureWebJobsStorage. Beheerrollen zoals Eigenaar zijn niet voldoende. De rol Eigenaar van opslagblobgegevens heeft betrekking op de basisbehoeften van De hostopslag van Functions. De runtime heeft zowel lees- als schrijftoegang nodig tot blobs en de mogelijkheid om containers te maken. Verschillende extensies gebruiken deze verbinding als een standaardlocatie voor blobs, wachtrijen en tabellen. Deze extensies kunnen vereisten toevoegen, zoals vermeld in de onderstaande tabel. Mogelijk hebt u aanvullende machtigingen nodig als u 'AzureWebJobsStorage' gebruikt voor andere doeleinden.

Toestel Vereiste rollen Uitleg
Geen extensie (alleen host) Eigenaar van opslagblobgegevens Wordt gebruikt voor algemene coördinatie, standaardsleutelarchief
Azure Blobs (alleen activeren) Alles van:
Inzender voor opslagaccounts,
Eigenaar van opslagblobgegevens,
Inzender voor opslagwachtrijgegevens
De blobtrigger maakt intern gebruik van Azure Queues en schrijft blobbevestigingen. Hiervoor wordt AzureWebJobsStorage gebruikt, ongeacht de verbinding die is geconfigureerd voor de trigger.
Azure Event Hubs (alleen activeren) (geen wijziging ten laste van de standaardvereiste)
Eigenaar van opslagblobgegevens
Controlepunten blijven behouden in blobs met behulp van de AzureWebJobsStorage-verbinding.
Timertrigger (geen wijziging ten laste van de standaardvereiste)
Eigenaar van opslagblobgegevens
Om ervoor te zorgen dat één uitvoering per gebeurtenis wordt uitgevoerd, worden vergrendelingen met blobs gebruikt met behulp van de AzureWebJobsStorage-verbinding.
Durable Functions Alles van:
Inzender voor opslagblobgegevens,
Inzender voor opslagwachtrijgegevens,
Inzender voor opslagtabelgegevens
Durable Functions maakt gebruik van blobs, wachtrijen en tabellen om activiteitsfuncties te coördineren en de indelingsstatus te behouden. Hiervoor wordt standaard de AzureWebJobsStorage-verbinding gebruikt, maar u kunt een andere verbinding opgeven in de configuratie van de Durable Functions-extensie.

Problemen melden

Item Beschrijving Koppeling
Runtime Scripthost, triggers en bindingen, taalondersteuning Een probleem melden
Sjablonen Codeprobleem met aanmaaksjabloon Een probleem melden
Portal Probleem met de gebruikersinterface of -ervaring Een probleem melden

Opensource-opslagplaatsen

De code voor Azure Functions is open source en u vindt belangrijke onderdelen in deze GitHub-opslagplaatsen:

Volgende stappen

Voor meer informatie raadpleegt u de volgende bronnen: