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, filen function.json. 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.
Filen function.json definierar 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 på en function.json-fil.
{
"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 filen function.json. Vi rekommenderar också att du använder paketdistribution för att distribuera ditt projekt till funktionsappen i Azure. Du kan också använda befintliga verktyg som kontinuerlig integrering och distribution och Azure DevOps.
Anteckning
Om du distribuerar ett paket manuellt ser du till att distribuera filen host.json och funktionsmapparna 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 Funktionsredigeraren som är inbyggd i Azure Portal kan du uppdatera din kod och din function.json-fil direkt infogade. 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 How to target Azure Functions runtime versions.
Centrallager
Koden för Azure Functions är öppen källkod och lagras GitHub lagringsplatsen:
- Azure Functions
- Azure Functions värd
- Azure Functions portal
- Azure Functions mallar
- Azure WebJobs SDK
- Azure WebJobs SDK-tillägg
Bindningar
Här är en tabell med alla bindningar som stöds.
Den här tabellen visar de bindningar som stöds i de större versionerna av Azure Functions runtime:
| Typ | 1.x | 2.x och högre1 | Utlösare | Indata | Resultat |
|---|---|---|---|---|---|
| Blob Storage | ✔ | ✔ | ✔ | ✔ | ✔ |
| Azure Cosmos DB | ✔ | ✔ | ✔ | ✔ | ✔ |
| Azure SQL (förhandsversion) | ✔ | ✔ | ✔ | ||
| 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 bindningstillägg.
2 Utlösare stöds inte i förbrukningsplanen. Kräver körningsdrivna utlösare.
3 Stöds endast i Kubernetes, IoT Edge och andra lägen med egen värd.
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 Program 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, vilket är användbart för att konfigurera identitetsbaserade anslutningar. Miljövariabler kan behandlas som en samling med hjälp av ett delat prefix som slutar med dubbla understreck __ . Du kan sedan referera till gruppen genom att ange anslutningsnamnet till det här prefixet.
Egenskapen för en connection Azure Blob-utlösardefinition kan till exempel vara "Storage1". Så länge det inte finns något enskilt strängvärde som konfigurerats av en miljövariabel med namnet "Storage1" kan en miljövariabel med namnet användas för att informera egenskapen Storage1__blobServiceUri blobServiceUri för anslutningen. Anslutningsegenskaperna är olika för varje tjänst. Läs dokumentationen för komponenten 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. En självstudiekurs om hur du konfigurerar funktionsappar med hanterade identiteter finns i självstudien Skapa en funktionsapp med identitetsbaserade anslutningar.
Identitetsbaserade anslutningar stöds av följande komponenter:
| Anslutningens källa | Planer som stöds | Läs mer |
|---|---|---|
| Azure Blob-utlösare och bindningar | Alla | Tilläggsversion 5.0.0 eller senare |
| Utlösare och bindningar i Azure Queue | Alla | Tilläggsversion 5.0.0 eller senare |
| Azure Event Hubs utlösare och bindningar | Alla | Tilläggsversion 5.0.0 eller senare |
| Azure Service Bus utlösare och bindningar | Alla | Tilläggsversion 5.0.0 eller senare |
| Azure Cosmos DB utlösare och bindningar – förhandsversion | Elastiska Premium | Tilläggsversion 4.0.0-preview1 eller senare |
| Lagring som krävs av värden ("AzureWebJobsStorage") – förhandsversion | Alla | Ansluta till värdlagring med en identitet |
Anteckning
Identitetsbaserade anslutningar stöds inte med Durable Functions.
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 din utvecklaridentitet i stället, även om detta kan anpassas. Se Lokal utveckling med identitetsbaserade anslutningar.
Bevilja behörighet till identiteten
Den identitet som används måste ha behörighet att utföra de avsedda åtgärderna. Du måste tilldela en roll i Azure RBACmed hjälp av inbyggda eller anpassade roller som ger dessa behörigheter.
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 kunna läsa från en datakälla använder du en roll som bara har behörighet att läsa. Det skulle vara olämpligt att tilldela en roll som också tillåter skrivning till tjänsten, eftersom detta skulle vara överdriven behörighet för en läsåtgärd. På samma sätt vill du se till att rolltilldelningen endast är begränsad till de resurser som behöver läsas.
Välj en flik nedan om du vill veta mer om behörigheter för varje komponent:
- Azure Blobs-tillägg
- Azure Queues-tillägg
- Event Hubs tillägg
- Service Bus tillägg
- Azure Cosmos DB tillägg (förhandsversion)
- Functions-värdlagring (förhandsversion)
Du måste skapa en rolltilldelning som ger åtkomst till blobcontainern vid körning. Hanteringsroller som Ägare räcker inte. I följande tabell visas inbyggda roller som rekommenderas när du använder Blob Storage-tillägget i normal drift. Programmet kan kräva ytterligare behörigheter baserat på den kod som du skriver.
| Bindningstyp | Exempel på inbyggda roller |
|---|---|
| Utlösare | [Storage blobdataägare och] Storage [Queue Data Contributor]1 |
| Indatabindning | Storage Blob Data-läsare |
| Utdatabindning | Storage Blob Data-ägare |
1 Som standard använder blobutlösaren Azure Queues internt. Det kräver därför även Storage [queue data contributor-behörighet] för att skapa och ta emot meddelanden.
Vanliga egenskaper för identitetsbaserade anslutningar
En identitetsbaserad anslutning för en Azure-tjänst accepterar följande vanliga egenskaper, där är värdet för din egenskap i <CONNECTION_NAME_PREFIX> connection utlösar- eller bindningsdefinitionen:
| Egenskap | Mall för miljövariabler | Description |
|---|---|---|
| Token-autentiseringsuppgifter | <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 | <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. |
Ytterligare alternativ kan stödjas för en viss anslutningstyp. Läs dokumentationen för komponenten som upprättar anslutningen.
Lokal utveckling med identitetsbaserade anslutningar
Anteckning
Lokal utveckling med identitetsbaserade anslutningar kräver uppdaterade versioner av Azure Functions Core Tools. Du kan kontrollera den installerade versionen genom att köra func -v . För Functions v3 använder du version 3.0.3904 eller senare. För Functions v4 använder du version 4.0.3904 eller senare.
När du kör lokalt anger ovanstående konfiguration 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.
Eftersom detta använder din utvecklaridentitet kanske du redan har vissa roller mot utvecklingsresurser, men de kanske inte ger dataåtkomst. Hanteringsroller som Ägare räcker inte. Dubbelkolla vilka behörigheter som krävs för anslutningar för varje komponent och se till att du har dem tilldelade till dig själv.
I vissa fall kanske du vill ange användning av en annan identitet. Du kan lägga till konfigurationsegenskaper för anslutningen som pekar på den alternativa identiteten baserat på ett klient-ID och en klienthemlighet för Azure Active Directory tjänstens huvudnamn. Det här konfigurationsalternativet stöds inte när det finns i Azure Functions tjänsten. Om du vill använda ett ID och en hemlighet på den lokala datorn definierar du anslutningen med följande ytterligare egenskaper:
| Egenskap | Mall för miljövariabler | Description |
|---|---|---|
| Klientorganisations-ID | <CONNECTION_NAME_PREFIX>__tenantId |
Id Azure Active Directory klientorganisation (katalog). |
| Klient-ID | <CONNECTION_NAME_PREFIX>__clientId |
Klient-ID:t (program) för en appregistrering i klientorganisationen. |
| Klienthemlighet | <CONNECTION_NAME_PREFIX>__clientSecret |
En klienthemlighet som genererades för appregistreringen. |
Här är ett exempel på local.settings.json egenskaper som krävs för identitetsbaserad anslutning till 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>"
}
}
Ansluta till värdlagring med en identitet (förhandsversion)
Azure Functions som standard använder "AzureWebJobsStorage"-anslutningen för kärnbeteenden som att samordna singleton-körning av timerutlösare och standardlagring av appnyckel. Detta kan även konfigureras för att utnyttja en identitet.
Varning
Andra komponenter i Functions förlitar sig på "AzureWebJobsStorage" för standardbeteenden. Du bör inte flytta den till en identitetsbaserad anslutning om du använder äldre versioner av tillägg som inte stöder den här typen av anslutning, inklusive utlösare och bindningar för Azure Blobs och Event Hubs. På samma sätt används för distributionsartefakter när du använder version på serversidan i Linux-förbrukning, och om du aktiverar det måste du distribuera AzureWebJobsStorage via ett externt distributionspaket.
Dessutom återanvänder vissa appar "AzureWebJobsStorage" för andra lagringsanslutningar i sina utlösare, bindningar och/eller funktionskod. Se till att alla användningsområden för "AzureWebJobsStorage" kan använda det identitetsbaserade anslutningsformatet innan du ändrar anslutningen från en anslutningssträng.
Om du vill använda en identitetsbaserad anslutning för "AzureWebJobsStorage" konfigurerar du följande appinställningar:
| Inställning | Beskrivning | Exempelvärde |
|---|---|---|
AzureWebJobsStorage__blobServiceUri |
URI:t för dataplanet för blobtjänsten för lagringskontot med hjälp av HTTPS-schemat. | https://<storage_account_name>.blob.core.windows.net |
AzureWebJobsStorage__queueServiceUri |
URI:t för dataplanet för lagringskontots kötjänst med hjälp av HTTPS-schemat. | https://<storage_account_name>.queue.core.windows.net |
Vanliga egenskaper för identitetsbaserade anslutningar kan också anges.
Om du använder ett lagringskonto som använder dns-standardsuffixet och tjänstnamnet för globala Azure kan du i stället ange namnet på ditt lagringskonto i https://<accountName>.blob/queue/file/table.core.windows.net AzureWebJobsStorage__accountName följande format. Blob- och köslutpunkterna härförs för det här kontot. Detta fungerar inte om lagringskontot finns i ett suveränt moln eller har en anpassad DNS.
| Inställning | Beskrivning | Exempelvärde |
|---|---|---|
AzureWebJobsStorage__accountName |
Kontonamnet för ett lagringskonto, endast giltigt om kontot inte finns i ett suveränt moln och inte har en anpassad DNS. | <storage_account_name> |
Du måste skapa en rolltilldelning som ger åtkomst till lagringskontot för "AzureWebJobsStorage" vid körning. Hanteringsroller som Ägare räcker inte. Rollen Storage Blob Data-ägare omfattar de grundläggande behoven för Functions-värdlagring – körningen behöver både läs- och skrivåtkomst till blobar och möjligheten att skapa containrar. Det finns vissa situationer, som när du använder blobutlösaren, [där Storage ködatadeltagare] också kan behövas. Du kan behöva ytterligare behörigheter om du använder "AzureWebJobsStorage" för andra ändamål.
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: