Ontwikkelaarshandleiding voor Azure Functions

In Azure Functions delen specifieke functies enkele belangrijke technische concepten en onderdelen, ongeacht de taal of binding die u gebruikt. Lees dit overzicht dat van toepassing is op al deze informatie voordat u meer leert over specifieke taal of binding.

In dit artikel wordt ervan uitgenomen dat u het overzicht Azure Functions gelezen.

Functiecode

Een functie is het primaire concept in Azure Functions. Een functie bevat twee belangrijke onderdelen: uw code, die in verschillende talen kan worden geschreven, en een configuratie, het bestand function.json. Voor gecompileerde talen wordt dit configuratiebestand automatisch gegenereerd op basis van aantekeningen in uw code. Voor scripttalen moet u het configuratiebestand zelf verstrekken.

Het bestand function.json definieert de trigger, bindingen en andere configuratie-instellingen van de functie. Elke functie kan slechts één trigger hebben. De runtime maakt gebruik van dit configuratiebestand om te bepalen welke gebeurtenissen moeten worden bewaakt en hoe gegevens moeten worden doorgeven aan en worden retourneert na de uitvoering van een functie. Hier volgt een voorbeeld van een function.json-bestand.

{
    "disabled":false,
    "bindings":[
        // ... bindings here
        {
            "type": "bindingType",
            "direction": "in",
            "name": "myParamName",
            // ... more depending on binding
        }
    ]
}

Zie triggers en bindingsconcepten Azure Functionsmeer informatie.

De bindings eigenschap is waar u zowel triggers als bindingen configureert. Elke binding deelt enkele algemene instellingen en enkele instellingen die specifiek zijn voor een bepaald type binding. Voor elke binding zijn de volgende instellingen vereist:

Functie-app

Een functie-app biedt een uitvoeringscontext in Azure waarin uw functies worden uitgevoerd. Dit is dus de eenheid van implementatie en beheer voor uw functies. 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 dezelfde runtimeversie. U kunt een functie-app zien als een manier om uw functies te organiseren en gezamenlijk te beheren. Zie Een functie-app beheren voor meer informatie.

Mapstructuur

De code voor alle functies in een specifieke functie-app bevindt zich in een hoofdprojectmap die een hostconfiguratiebestand bevat. Het bestand host.json bevat runtimespecifieke configuraties en bevindt zich in de hoofdmap van de functie-app. Een bin-map bevat pakketten en andere bibliotheekbestanden die de functie-app nodig heeft. Specifieke mapstructuren die vereist zijn voor de functie-app, zijn afhankelijk van de taal:

• C# gecompileerd (.csproj)
• C#-script (.csx)
• F#-script
• Java
• JavaScript
• Python

In versie 2.x en hoger van de Functions-runtime moeten alle functies in de functie-app dezelfde taalstack delen.

Het bovenstaande is de standaardmapstructuur (en aanbevolen) voor een functie-app. Als u de bestandslocatie van de code van een functie wilt wijzigen, wijzigt u de scriptFile sectie van het bestand function.json. We raden u ook aan pakketimplementatie te gebruiken om uw project te implementeren in uw functie-app in Azure. U kunt ook bestaande hulpprogramma's gebruiken, zoals continue integratie en implementatie en Azure DevOps.

Lokale hulpprogramma's en publiceren gebruiken

Functie-apps kunnen worden geschreven en gepubliceerd met behulp van verschillende hulpprogramma's, waaronder Visual Studio, Visual Studio Code, IntelliJ, Eclipseen Azure Functions Core Tools. Zie Code and test Azure Functions locally voor meer informatie.

Functies bewerken in de Azure Portal

Met de Functions-editor die is ingebouwd Azure Portal kunt u uw code en het bestand function.json rechtstreeks inline bijwerken. Dit wordt alleen aanbevolen voor kleine wijzigingen of proofs of concept- best practice is om een lokaal ontwikkelprogramma zoals VS Code te gebruiken.

Parallelle uitvoering

Wanneer meerdere triggergebeurtenissen sneller optreden dan een functieruntime met één thread kan verwerken, kan de runtime de functie meerdere keren parallel aanroepen. Als een functie-app gebruik maakt van het hostingplan Consumption,kan de functie-app automatisch worden uitschalen. Elk exemplaar van de functie-app, ongeacht of de app wordt uitgevoerd op het hostingplan Consumption of een normaal App Service hostingplan,kan gelijktijdige functie-aanroepen parallel verwerken met behulp van meerdere threads. Het maximum aantal gelijktijdige functie-aanroepen in elk exemplaar van de functie-app varieert op basis van het type trigger dat wordt gebruikt en de resources die worden gebruikt door andere functies in de functie-app.

Versieversies van Functions-runtime

U kunt de versie van de Functions-runtime configureren met behulp van FUNCTIONS_EXTENSION_VERSION de app-instelling. De waarde ~3 geeft bijvoorbeeld aan dat uw functie-app 3.x gebruikt als de belangrijkste versie. Functie-apps worden bijgewerkt naar elke nieuwe secundaire versie wanneer ze worden uitgebracht. Zie How to target Azure Functions runtime versions (Het doel van runtimeversies)voor meer informatie, Azure Functions hoe u de exacte versie van uw functie-app kunt weergeven.

Opslagplaatsen

De code voor Azure Functions wordt open source en opgeslagen in GitHub opslagplaatsen:

• Azure Functions
• Azure Functions host
• Azure Functions portal
• Azure Functions sjablonen
• Azure WebJobs SDK
• Azure WebJobs SDK-extensies

Bindingen

Hier is een tabel met alle ondersteunde bindingen.

Dit tabel geeft de bindingen weer die worden ondersteund in de belangrijkste versies van de Azure Functions-runtime:

¹ Vanaf de rumtime 2.x moeten alle bindingen, behalve HTTP en Timer, worden geregistreerd. Raadpleeg Bindingextensies registreren.

² Triggers worden niet ondersteund in het Consumption-abonnement. Vereist runtime-gestuurde triggers.

³ Alleen ondersteund in Kubernetes, IoT Edge en andere zelf-gehoste modi.

Hebt u problemen met fouten die afkomstig zijn van de bindingen? Bekijk de documentatie Azure Functions bindingsfoutcodes.

Verbindingen

Uw functieproject verwijst naar verbindingsgegevens op naam van de configuratieprovider. De verbindingsgegevens worden niet rechtstreeks geaccepteerd, waardoor ze in verschillende omgevingen kunnen worden gewijzigd. Een triggerdefinitie kan bijvoorbeeld een eigenschap connection bevatten. Dit kan verwijzen naar een connection string, maar u kunt de connection string rechtstreeks in een function.json instellen. In plaats daarvan stelt u in connection op de naam van een omgevingsvariabele die de connection string.

De standaardconfiguratieprovider maakt gebruik van omgevingsvariabelen. Deze kunnen worden ingesteld door Application Instellingen wanneer deze wordt uitgevoerd in de Azure Functions-service of vanuit het lokale instellingenbestand bij het lokaal ontwikkelen.

Verbindingswaarden

Wanneer de verbindingsnaam wordt opgelost naar één exacte waarde, identificeert de runtime de waarde als een connection string, die doorgaans een geheim bevat. De details van een connection string worden gedefinieerd door de service waarmee u verbinding wilt maken.

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 naam van de verbinding in te stellen op dit voorvoegsel.

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

Een op identiteit gebaseerde verbinding configureren

Sommige verbindingen in Azure Functions kunnen worden geconfigureerd voor het gebruik van een identiteit in plaats van een geheim. Ondersteuning is afhankelijk van de extensie die de verbinding gebruikt. In sommige gevallen is een connection string vereist in Functions, zelfs als de service waarmee u verbinding maakt op basis van identiteiten ondersteunt. Zie de zelfstudie Een functie-app maken met op identiteit gebaseerde verbindingen voor een zelfstudie over het configureren van uw functie-apps met beheerde identiteiten.

Op identiteit gebaseerde verbindingen worden ondersteund door de volgende onderdelen:

Wanneer deze worden gehost in Azure Functions-service, gebruiken identiteitsgebaseerde verbindingen 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 eigenschappen clientID en . Wanneer deze wordt uitgevoerd in andere contexten, zoals lokale ontwikkeling, wordt in plaats daarvan uw identiteit van de ontwikkelaar gebruikt, hoewel dit kan worden aangepast. Zie Local development with identity-based connections(Lokale ontwikkeling met op identiteit gebaseerde verbindingen).

Machtiging verlenen aan de identiteit

Elke identiteit die wordt gebruikt, moet machtigingen hebben om de beoogde acties uit te voeren. U moet een rol toewijzen in Azure RBACmet behulp van ingebouwde of aangepaste rollen die deze machtigingen bieden.

Kies een tabblad hieronder voor meer informatie over machtigingen voor elk onderdeel:

Algemene eigenschappen voor op identiteit gebaseerde verbindingen

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

Aanvullende 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

Wanneer de app lokaal wordt uitgevoerd, 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 lukt, treedt er een fout op.

Omdat hiervoor de identiteit van uw ontwikkelaar wordt gebruikt, hebt u mogelijk al een aantal rollen voor ontwikkelingsbronnen, maar bieden ze mogelijk geen toegang tot gegevens. 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 wilt u mogelijk het gebruik van een andere identiteit opgeven. U kunt configuratie-eigenschappen toevoegen voor de verbinding die naar de alternatieve identiteit wijzen op basis van een client-id en clientgeheim voor een Azure Active Directory 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 aanvullende eigenschappen:

Hier is een voorbeeld van eigenschappen local.settings.json die vereist zijn voor een identiteitsgebaseerde 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 (preview)

Azure Functions maakt standaard gebruik van de verbinding 'AzureWebJobsStorage' voor kerngedrag, zoals het coördineren van de singleton-uitvoering van timertriggers en de standaardopslag van app-sleutels. Dit kan ook worden geconfigureerd om gebruik te maken van een identiteit.

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

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

Als u een opslagaccount gebruikt dat gebruikmaakt van het standaard-DNS-achtervoegsel en de servicenaam voor Globale Azure, volgens de indeling, kunt u in plaats daarvan instellen op de naam van https://<accountName>.blob/queue/file/table.core.windows.net AzureWebJobsStorage__accountName uw opslagaccount. De blob- en wachtrij-eindpunten worden afgeleid voor dit account. Dit werkt niet als het opslagaccount zich in een onafhankelijke cloud of een aangepaste DNS heeft.

U moet een roltoewijzing maken die tijdens runtime toegang biedt tot het opslagaccount voor 'AzureWebJobsStorage'. Beheerrollen zoals Eigenaar zijn niet voldoende. De [rol Storage blobgegevenseigenaar] dekt de basisbehoeften van Functions-hostopslag: de runtime heeft zowel lees- als schrijftoegang nodig tot blobs en de mogelijkheid om containers te maken. Er zijn enkele situaties, zoals bij het gebruik van de blobtrigger, Storage [mogelijk] ook een inzender voor wachtrijgegevens nodig zijn. Mogelijk hebt u aanvullende machtigingen nodig als u 'AzureWebJobsStorage' gebruikt voor andere doeleinden.

Problemen met rapportage

Volgende stappen

Zie de volgende resources voor meer informatie:

• Azure Functions-triggers en -bindingen
• Code en test Azure Functions lokaal
• Best practices voor Azure Functions
• Naslaginformatie over Azure Functions C# voor ontwikkelaars
• Azure Functions Node.js voor ontwikkelaars