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:
Azure Functions Core Tools (opdrachtprompt)
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:
- Tijdens het publiceren van Visual Studio
Visual Studio Code gebruiken
Programmatisch met behulp van Azure CLI-, Azure PowerShell-, ARM-sjablonen of Bicep-sjablonen
In Azure Portal
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 extensie die gebruikmaakt 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
De volgende onderdelen ondersteunen op identiteit gebaseerde verbindingen:
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:
- Azure Blobs-extensie
- Azure Queues-extensie
- Azure Tables-extensie
- Event Hubs-extensie
- Service Bus-extensie
- Event Grid-extensie
- Azure Cosmos DB-extensie
- Azure SignalR-extensie
- Durable Functions-opslagprovider
- Hostopslag van Functions
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 managedidentity op, 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 managedidentity op, 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.
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 AzureWebJobsStorage
gebruiken, 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: