Utvecklarguide för Azure Functions

I Azure Functions delar vissa funktioner några grundläggande tekniska begrepp och komponenter, oavsett vilket språk eller bindning du använder. Innan du börjar lära dig information som är specifik för ett visst språk eller en viss bindning måste du läsa igenom den här översikten som gäller för alla.

Den här artikeln förutsätter att du redan har läst Azure Functions översikt.

Funktionskod

En funktion är det primära konceptet i Azure Functions. En funktion innehåller två viktiga delar – din kod, som kan skrivas på flera olika språk, och en del config, function.jspå filen. För kompilerade språk genereras den här konfigurationsfilen automatiskt från anteckningar i koden. För skriptspråk måste du ange konfigurationsfilen själv.

I function.jspå filen definieras funktionens utlösare, bindningar och andra konfigurationsinställningar. Varje funktion har endast en utlösare. Körningen använder den här konfigurationsfilen för att fastställa de händelser som ska övervakas och hur data ska överföras till och returnera data från en funktionskörning. Följande är ett exempel function.jspå filen.

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

Mer information finns i Azure Functions utlösare och bindningar.

Egenskapen bindings är den plats där du konfigurerar både utlösare och bindningar. Varje bindning delar några vanliga inställningar och vissa inställningar som är specifika för en viss typ av bindning. Varje bindning kräver följande inställningar:

Egenskap Värden Typ Kommentarer
typ Namnet på bindningen.

Till exempel queueTrigger.
sträng
riktning in, out sträng Anger om bindningen är till för att ta emot data till funktionen eller skicka data från funktionen.
name Funktionsidentifierare.

Till exempel myQueue.
sträng Namnet som används för de bundna data i funktionen. För C# är detta ett argumentnamn; för JavaScript är det nyckeln i en nyckel/värde-lista.

Funktionsapp

En funktionsapp tillhandahåller en körningskontext i Azure där dina funktioner körs. Därför är det distributions- och hanteringsenheten för dina funktioner. En funktionsapp består av en eller flera enskilda funktioner som hanteras, distribueras och skalas tillsammans. Alla funktioner i en funktionsapp delar samma prisplan, distributionsmetod och körningsversion. Tänk på en funktionsapp som ett sätt att organisera och gemensamt hantera dina funktioner. Mer information finns i Hantera en funktionsapp.

Anteckning

Alla funktioner i en funktionsapp måste redigeras på samma språk. I tidigare versioner av Azure Functions-körningen krävdes inte detta.

Mappstrukturen

Koden för alla funktioner i en specifik funktionsapp finns i en rotprojektmapp som innehåller en värdkonfigurationsfil. Filen host.jsinnehåller körningsspecifika konfigurationer och finns i funktionsappens rotmapp. En bin-mapp innehåller paket och andra biblioteksfiler som funktionsappen kräver. Specifika mappstrukturer som krävs av funktionsappen beror på språk:

I version 2.x och senare av Functions-körningen måste alla funktioner i funktionsappen dela samma språkstack.

Ovanstående är standardmappstrukturen (och rekommenderas) för en funktionsapp. Om du vill ändra filplatsen för en funktions kod ändrar du avsnittet scriptFile i function.jspå filen. Vi rekommenderar också att du använder paketdistribution för att distribuera ditt projekt till din funktionsapp i Azure. Du kan också använda befintliga verktyg som kontinuerlig integrering och distribution och Azure DevOps.

Anteckning

Om du distribuerar ett paket manuellt måste du distribuerahost.js på fil- och funktionsmappar direkt till wwwroot mappen. Inkludera inte mappen wwwroot i dina distributioner. Annars får du wwwroot\wwwroot mappar.

Använda lokala verktyg och publicering

Funktionsappar kan redigeras och publiceras med en mängd olika verktyg, inklusive Visual Studio, Visual Studio Code, IntelliJ, Eclipse och Azure Functions Core Tools. Mer information finns i Koda och testa Azure Functions lokalt.

Redigera funktioner i Azure Portal

Med Functions-redigeraren som är inbyggd Azure Portal kan du uppdatera koden ochfunction.jsdirekt i filen. Detta rekommenderas endast för små ändringar eller konceptbevis – bästa praxis är att använda ett lokalt utvecklingsverktyg som VS Code.

Parallell körning

När flera utlösande händelser inträffar snabbare än en enkeltrådig funktionskörning kan bearbeta dem, kan körningen anropa funktionen flera gånger parallellt. Om en funktionsapp använder värdplanen Förbrukningkan funktionsappen skalas ut automatiskt. Varje instans av funktionsappen, oavsett om appen körs på förbrukningsvärdplanen eller en vanlig App Service-värdplan,kan bearbeta samtidiga funktionsanrop parallellt med hjälp av flera trådar. Det maximala antalet samtidiga funktionsanrop i varje funktionsappinstans varierar beroende på vilken typ av utlösare som används samt de resurser som används av andra funktioner i funktionsappen.

Versionshantering för Functions-körning

Du kan konfigurera versionen av Functions-körningen med hjälp av FUNCTIONS_EXTENSION_VERSION appinställningen. Värdet "~3" anger till exempel att funktionsappen kommer att använda 3.x som huvudversion. Funktionsappar uppgraderas till varje ny delversion när de släpps. Mer information, inklusive hur du visar den exakta versionen av funktionsappen, finns i Så här riktar du Azure Functions för körningsversioner.

Centrallager

Koden för Azure Functions är öppen källkod och lagras GitHub lagringsplatsen:

Bindningar

Här är en tabell med alla bindningar som stöds.

I den här tabellen visas de bindningar som stöds i huvud versionerna av Azure Functions Runtime:

Typ 1.x 2. x och högre1 Utlösare Indata Resultat
Blob Storage
Azure Cosmos DB
Dapr3
Event Grid
Event Hubs
HTTP &-Webhooks
IoT Hub
Kafka2
Mobile Apps
Notification Hubs
Queue Storage
Rabbitmq2
SendGrid
Service Bus
SignalR
Table Storage
Timer
Twilio

1 från och med version 2. x-körningen måste alla bindningar utom http och timer registreras. Se Registrera bindnings tillägg.

2 utlösare stöds inte i förbruknings planen. Kräver runtime-drivna utlösare.

3 stöds endast i Kubernetes, IoT Edge och andra egna lägen.

Har du problem med fel som kommer från bindningarna? Läs dokumentationen Azure Functions om bindningsfelkoder.

Anslutningar

Funktionsprojektet refererar till anslutningsinformation efter namn från dess konfigurationsprovider. Anslutningsinformationen godkänns inte direkt, vilket gör att de kan ändras mellan miljöer. En utlösardefinition kan till exempel innehålla en connection -egenskap. Detta kan referera till en anslutningssträng, men du kan inte ange anslutningssträngen direkt i en function.json . I stället skulle du ange connection namnet på en miljövariabel som innehåller anslutningssträngen.

Standardkonfigurationsprovidern använder miljövariabler. Dessa kan anges av Application Inställningar när de körs i Azure Functions-tjänsten eller från den lokala inställningsfilen när du utvecklar lokalt.

Anslutningsvärden

När anslutningsnamnet matchas till ett enda exakt värde identifierar körningen värdet som en anslutningssträng , som vanligtvis innehåller en hemlighet. Information om en anslutningssträng definieras av den tjänst som du vill ansluta till.

Ett anslutningsnamn kan dock även referera till en samling med flera konfigurationsobjekt. Miljövariabler kan behandlas som en samling med hjälp av ett delat prefix som slutar med dubbla understreck __ . Gruppen kan sedan refereras genom att ange anslutningsnamnet till det här prefixet.

Egenskapen för en Azure connection Blob-utlösardefinition kan till exempel vara Storage1 . Så länge det inte finns något enskilt strängvärde konfigurerat med som namn Storage1 används Storage1__serviceUri det för serviceUri anslutningens egenskap. Anslutningsegenskaperna är olika för varje tjänst. Läs dokumentationen för tillägget som använder anslutningen.

Konfigurera en identitetsbaserad anslutning

Vissa anslutningar i Azure Functions konfigureras för att använda en identitet i stället för en hemlighet. Stödet beror på tillägget med hjälp av anslutningen. I vissa fall kan en anslutningssträng fortfarande krävas i Functions även om tjänsten som du ansluter till stöder identitetsbaserade anslutningar.

Identitetsbaserade anslutningar stöds av följande utlösare och bindningstillägg i alla planer:

Anteckning

Identitetsbaserade anslutningar stöds inte med Durable Functions.

Tilläggsnamn Tilläggsversion
Azure-blobb Version 5.0.0-beta1 eller senare
Azure Queue Version 5.0.0-beta1 eller senare
Azure Event Hubs Version 5.0.0-beta1 eller senare
Azure Service Bus Version 5.0.0-beta2 eller senare

Lagringsanslutningarna som används av Functions-körningen ( AzureWebJobsStorage ) kan också konfigureras med hjälp av en identitetsbaserad anslutning. Se Ansluta till värdlagring med en identitet nedan.

När identitetsbaserade anslutningar Azure Functions i tjänsten använder de en hanterad identitet. Den system tilldelade identiteten används som standard, även om en användar tilldelad identitet kan anges med credential egenskaperna clientID och . När den körs i andra kontexter, till exempel lokal utveckling, används utvecklaridentiteten i stället, även om detta kan anpassas med hjälp av alternativa anslutningsparametrar.

Bevilja behörighet till identiteten

Den identitet som används måste ha behörighet att utföra de avsedda åtgärderna. Detta görs vanligtvis genom att tilldela en roll i Azure RBAC eller ange identiteten i en åtkomstprincip, beroende på vilken tjänst du ansluter till. Läs dokumentationen för varje tillägg om vilka behörigheter som behövs och hur de kan anges.

Viktigt

Vissa behörigheter kan exponeras av måltjänsten som inte är nödvändiga för alla kontexter. Om möjligt ska du följa principen om minsta behörighet och endast bevilja identiteten de behörigheter som krävs. Om appen till exempel bara behöver läsa från en blob använder du rollen Storage Blob Data Reader eftersom Storage Blob Data-ägare inkluderar för många behörigheter för en läsåtgärd. Följande roller omfattar de primära behörigheter som krävs för varje tillägg i normal drift:

Tjänst Exempel på inbyggda roller
Azure-blobar Storage Blob Data Reader Storage Blob Data-ägare
Azure Queues Storage Queue Data Reader, Storage Queue Data Message Processor, Storage Queue Data Message Sender, Storage Queue Data Contributor
Event Hubs Azure Event Hubs Data Receiver, Azure Event Hubs Data Sender, Azure Event Hubs Data Owner
Service Bus Azure Service Bus Data Receiver, Azure Service Bus Data Sender, Azure Service Bus Data Owner

Anslutningsegenskaper

En identitetsbaserad anslutning för en Azure-tjänst accepterar följande egenskaper:

Egenskap Krävs för tillägg Miljövariabel Beskrivning
Tjänst-URI Azure Blob1, Azure Queue <CONNECTION_NAME_PREFIX>__serviceUri Dataplanets URI för den tjänst som du ansluter till.
Fullständigt kvalificerat namnområde Event Hubs, Service Bus <CONNECTION_NAME_PREFIX>__fullyQualifiedNamespace Det fullständigt kvalificerade Event Hubs och Service Bus namnområdet.
Token-autentiseringsuppgifter (Valfritt) <CONNECTION_NAME_PREFIX>__credential Definierar hur en token ska hämtas för anslutningen. Rekommenderas endast när du anger en användar tilldelad identitet när den ska anges till "managedidentity". Detta är endast giltigt när det finns i Azure Functions tjänsten.
Klient-ID (Valfritt) <CONNECTION_NAME_PREFIX>__clientId När credential är inställt på "managedidentity" anger den här egenskapen den användar tilldelade identitet som ska användas när du hämtar en token. Egenskapen accepterar ett klient-ID som motsvarar en användar tilldelad identitet till programmet. Om inget anges används den system tilldelade identiteten. Den här egenskapen används på olika sätt i lokala utvecklingsscenariernär credential inte ska anges.

1 Både blob- och kötjänst-URI:er krävs för Azure Blob.

Ytterligare alternativ kan stödjas för en viss anslutningstyp. Läs dokumentationen för den komponent som upprättar anslutningen.

Lokal utveckling med identitetsbaserade anslutningar

När du kör lokalt anger konfigurationen ovan att körningen ska använda din lokala utvecklaridentitet. Anslutningen försöker hämta en token från följande platser i ordning:

  • En lokal cache som delas mellan Microsoft-program
  • Den aktuella användarkontexten i Visual Studio
  • Den aktuella användarkontexten i Visual Studio Code
  • Den aktuella användarkontexten i Azure CLI

Om inget av dessa alternativ lyckas uppstår ett fel.

I vissa fall kanske du vill ange en annan identitet. Du kan lägga till konfigurationsegenskaper för anslutningen som pekar på den alternativa identiteten.

Anteckning

Följande konfigurationsalternativ stöds inte när de finns i Azure Functions tjänsten.

Om du vill ansluta Azure Active Directory ett huvudnamn för tjänsten med ett klient-ID och en hemlighet definierar du anslutningen med följande obligatoriska egenskaper utöver anslutningsegenskaperna ovan:

Egenskap Miljövariabel Beskrivning
Klient-ID:t <CONNECTION_NAME_PREFIX>__tenantId Id Azure Active Directory klientorganisation (katalog).
Klient-ID <CONNECTION_NAME_PREFIX>__clientId Klient-ID (program) för en appregistrering i klientorganisationen.
Klienthemlighet <CONNECTION_NAME_PREFIX>__clientSecret En klienthemlighet som genererades för appregistreringen.

Exempel på local.settings.json egenskaper som krävs för identitetsbaserad anslutning med Azure Blob:

{
  "IsEncrypted": false,
  "Values": {
    "<CONNECTION_NAME_PREFIX>__serviceUri": "<serviceUri>",
    "<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
    "<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
    "<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
  }
}

Ansluta till värdlagring med en identitet

Azure Functions använder som standard anslutningen för kärnbeteenden som att koordinera singleton-körning av AzureWebJobsStorage timerutlösare och standardlagring av appnyckel. Detta kan även konfigureras för att utnyttja en identitet.

Varning

Vissa appar AzureWebJobsStorage återanvänds för lagringsanslutningar i sina utlösare, bindningar och/eller funktionskod. Se till att alla användningsområden AzureWebJobsStorage för kan använda det identitetsbaserade anslutningsformatet innan du ändrar anslutningen från en anslutningssträng.

Om du vill konfigurera anslutningen på det här sättet kontrollerar du att appens identitet har rollen Storage Blob Data-ägare för att kunna stödja kärnvärdfunktionerna. Du kan behöva ytterligare behörigheter om du använder "AzureWebJobsStorage" för andra ändamål.

Om du använder ett lagringskonto som använder DNS-standardsuffixet och tjänstnamnet för globala Azure kan du ange namnet på ditt https://<accountName>.blob/queue/file/table.core.windows.net AzureWebJobsStorage__accountName lagringskonto i följande format.

Om du i stället använder ett lagringskonto i ett suveränt moln eller med anpassad DNS anger AzureWebJobsStorage__serviceUri du till URI:t för din blobtjänst. Om "AzureWebJobsStorage" används för andra tjänster kan du i stället ange AzureWebJobsStorage__blobServiceUri AzureWebJobsStorage__queueServiceUri , och AzureWebJobsStorage__tableServiceUri separat.

Rapportera problem

Objekt Beskrivning Länk
Körning Skript värd, utlösare & bindningar, språk stöd Filen ett problem
Mallar Kod problem med skapande mall Filen ett problem
Portal Användar gränssnitt eller problem Filen ett problem

Nästa steg

Mer information finns i följande resurser: