Lagringsöverväganden för Azure Functions
Azure Functions kräver ett Azure Storage-konto när du skapar en funktionsappinstans. Följande lagringstjänster kan användas av funktionsappen:
| Lagringstjänst | Funktionsanvändning |
|---|---|
| Azure Blob Storage | Underhåll bindningstillstånd och funktionsnycklar1. Används som standard för aktivitetshubbar i Durable Functions. Kan användas för att lagra funktionsappkod för Linux Consumption remote build eller som en del av externa paket-URL-distributioner. |
| Azure Files2 | Filresurs som används för att lagra och köra din funktionsappkod i en förbrukningsplan och premiumplan. |
| Azure Queue Storage | Används som standard för aktivitetshubbar i Durable Functions. Används för fel- och återförsökshantering i specifika Azure Functions-utlösare. Används för objektspårning av Blob Storage-utlösaren. |
| Azure Table Storage | Används som standard för aktivitetshubbar i Durable Functions. |
1 Blob Storage är standardlagringsplatsen för funktionsnycklar, men du kan konfigurera ett alternativt arkiv.
2 Azure Files har konfigurerats som standard, men du kan skapa en app utan Azure Files under vissa förhållanden.
Viktigt!
Du måste tänka igenom följande fakta om de lagringskonton som används av dina funktionsappar:
När din funktionsapp finns i förbrukningsplanen eller Premium-planen lagras funktionskoden och konfigurationsfilerna i Azure Files i det länkade lagringskontot. När du tar bort det här lagringskontot tas innehållet bort och kan inte återställas. Mer information finns i Lagringskontot har tagits bort
Viktiga data, till exempel funktionskod, åtkomstnycklar och andra viktiga tjänstrelaterade data, kan sparas i lagringskontot. Du måste noggrant hantera åtkomsten till de lagringskonton som används av funktionsappar på följande sätt:
Granska och begränsa åtkomsten för appar och användare till lagringskontot baserat på en modell med lägsta behörighet. Behörigheter till lagringskontot kan komma från dataåtgärder i den tilldelade rollen eller via behörighet att utföra åtgärden listKeys.
Övervaka både kontrollplansaktivitet (till exempel hämtning av nycklar) och dataplansåtgärder (till exempel att skriva till en blob) i ditt lagringskonto. Överväg att underhålla lagringsloggar på en annan plats än Azure Storage. Mer information finns i Lagringsloggar.
Krav för Storage-konto
Lagringskonton som skapats som en del av funktionsappens skapa flöde i Azure-portalen kommer garanterat att fungera med den nya funktionsappen. När du väljer att använda ett befintligt lagringskonto innehåller den angivna listan inte vissa lagringskonton som inte stöds. Följande begränsningar gäller för lagringskonton som används av funktionsappen, så du måste se till att ett befintligt lagringskonto uppfyller dessa krav:
Kontotypen måste ha stöd för blob-, kö- och tabelllagring. Vissa lagringskonton stöder inte köer och tabeller. Det gäller till exempel lagringskonton med endast bloblagring och Azure Premium Storage. Mer information om lagringskontotyper finns i Översikt över lagringskonto.
Du kan inte använda ett lagringskonto som redan skyddas med hjälp av en brandvägg eller ett virtuellt privat nätverk när du skapar funktionsappen i Azure-portalen. Portalen filtrerar dock för närvarande inte bort dessa skyddade lagringskonton. Information om hur du använder ett skyddat lagringskonto med din funktionsapp finns i Så här använder du ett skyddat lagringskonto med Azure Functions.
Du kan inte använda skyddade lagringskonton med funktionsappar som finns i förbrukningsplanen.
När du skapar din funktionsapp i portalen får du bara välja ett befintligt lagringskonto i samma region som den funktionsapp som du skapar. Det här är en prestandaoptimering och inte en strikt begränsning. Mer information finns i Lagringskontots plats.
När du skapar din funktionsapp i en plan med stöd för tillgänglighetszoner aktiverat stöds endast zonredundanta lagringskonton .
Du kan skapa funktionsappar i en Elastic Premium- eller Dedikerad (App Service)-plan med hjälp av distributionsautomatisering. Du måste dock inkludera specifika nätverkskonfigurationer i ARM-mallen eller Bicep-filen. När du inte inkluderar de här inställningarna och resurserna kan den automatiserade distributionen misslyckas i valideringen. Mer information finns i Säkra distributioner.
Vägledning för lagringskonto
Varje funktionsapp kräver ett lagringskonto för att fungera. När kontot tas bort körs inte funktionsappen. Information om hur du felsöker lagringsrelaterade problem finns i Så här felsöker du lagringsrelaterade problem. Följande andra överväganden gäller för lagringskontot som används av funktionsappar.
Lagringskontoplats
För bästa prestanda bör din funktionsapp använda ett lagringskonto i samma region, vilket minskar svarstiden. Azure-portalen tillämpar den här bästa praxisen. Om du av någon anledning behöver använda ett lagringskonto i en annan region än din funktionsapp måste du skapa funktionsappen utanför portalen.
Lagringskontot måste vara tillgängligt för funktionsappen. Om du behöver använda ett skyddat lagringskonto bör du överväga att begränsa ditt lagringskonto till ett virtuellt nätverk.
Inställning för lagringskontoanslutning
Som standard konfigurerar AzureWebJobsStorage funktionsappar anslutningen som en anslutningssträng som lagras i programinställningen AzureWebJobsStorage, men du kan också konfigurera AzureWebJobsStorage att använda en identitetsbaserad anslutning utan hemlighet.
Funktionsappar som körs i en förbrukningsplan (endast Windows) eller en Elastic Premium-plan (Windows eller Linux) kan använda Azure Files för att lagra de avbildningar som krävs för att aktivera dynamisk skalning. För dessa planer anger du anslutningssträng för lagringskontot i inställningen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING och namnet på filresursen i inställningen WEBSITE_CONTENTSHARE. Detta är vanligtvis samma konto som används för AzureWebJobsStorage. Du kan också skapa en funktionsapp som inte använder Azure Files, men skalningen kan vara begränsad.
Kommentar
Ett lagringskonto anslutningssträng måste uppdateras när du återskapar lagringsnycklar. Läs mer om hantering av lagringsnycklar här.
Delade lagringskonton
Det är möjligt för flera funktionsappar att dela samma lagringskonto utan problem. I Visual Studio kan du till exempel utveckla flera appar med hjälp av Azurite Storage-emulatorn. I det här fallet fungerar emulatorn som ett enda lagringskonto. Samma lagringskonto som används av funktionsappen kan också användas för att lagra dina programdata. Den här metoden är dock inte alltid en bra idé i en produktionsmiljö.
Du kan behöva använda separata lagringskonton för att undvika kollisioner med värd-ID.
Principöverväganden för livscykelhantering
Du bör inte tillämpa livscykelhanteringsprinciper på ditt Blob Storage-konto som används av funktionsappen. Functions använder Blob Storage för att bevara viktig information, till exempel funktionsåtkomstnycklar, och principer kan ta bort blobar (till exempel nycklar) som krävs av Functions-värden. Om du måste använda principer undantar du containrar som används av Functions, som är prefix med azure-webjobs eller scm.
Lagringsloggar
Eftersom funktionskod och nycklar kan sparas i lagringskontot är loggning av aktivitet mot lagringskontot ett bra sätt att övervaka obehörig åtkomst. Azure Monitor-resursloggar kan användas för att spåra händelser mot lagringsdataplanet. Mer information om hur du konfigurerar och undersöker loggarna finns i Övervaka Azure Storage .
Aktivitetsloggen för Azure Monitor visar kontrollplanshändelser, inklusive listKeys-åtgärden. Du bör dock även konfigurera resursloggar för lagringskontot för att spåra efterföljande användning av nycklar eller andra identitetsbaserade dataplansåtgärder. Du bör ha minst logkategorin StorageWrite aktiverad för att kunna identifiera ändringar av data utanför normala Functions-åtgärder.
Om du vill begränsa den potentiella effekten av alla brett begränsade lagringsbehörigheter bör du överväga att använda ett icke-lagringsmål för dessa loggar, till exempel Log Analytics. Mer information finns i Övervaka Azure Blob Storage.
Optimera lagringsprestanda
Använd ett separat lagringskonto för varje funktionsapp för att maximera prestandan. Detta är särskilt viktigt när du har Durable Functions- eller Event Hub-utlösta funktioner, som båda genererar en stor mängd lagringstransaktioner. När din programlogik interagerar med Azure Storage, antingen direkt (med hjälp av Storage SDK) eller via någon av lagringsbindningarna, bör du använda ett dedikerat lagringskonto. Om du till exempel har en Händelsehubb-utlöst funktion som skriver vissa data till bloblagring använder du två lagringskonton – ett för funktionsappen och ett annat för de blobar som lagras av funktionen.
Arbeta med blobar
Ett nyckelscenario för Functions är filbearbetning av filer i en blobcontainer, till exempel för bildbearbetning eller attitydanalys. Mer information finns i Bearbeta filuppladdningar.
Utlösare för en blobcontainer
Det finns flera sätt att köra funktionskoden baserat på ändringar i blobar i en lagringscontainer. Använd följande tabell för att avgöra vilken funktionsutlösare som passar bäst för dina behov:
| Att tänka på | Blob Storage (avsökning) | Blob Storage (händelsebaserad) | Queue Storage | Event Grid |
|---|---|---|---|---|
| Svarstid | Hög (upp till 10 min) | Låg | Medium | Låg |
| Begränsningar för lagringskonto | Endast Blob-konton stöds inte¹ | generell användning v1 stöds inte | inget | generell användning v1 stöds inte |
| Tilläggsversion | Alla | Lagring v5.x+ | Valfri | Valfri |
| Bearbetar befintliga blobar | Ja | No | No | Nej |
| Filter | Mönster för blobnamn | Händelsefilter | saknas | Händelsefilter |
| Kräver händelseprenumeration | Nej | Ja | No | Ja |
| Stöder storskaligt² | Nej | Ja | Ja | Ja |
| beskrivning | Standardutlösarbeteende, som förlitar sig på att avsöka containern efter uppdateringar. Mer information finns i exemplen i bloblagringsutlösarreferensen. | Förbrukar bloblagringshändelser från en händelseprenumeration. Kräver parametervärdet SourceEventGrid. Mer information finns i Självstudie: Utlösa Azure Functions på blobcontainrar med hjälp av en händelseprenumeration. |
Blobnamnsträngen läggs till manuellt i en lagringskö när en blob läggs till i containern. Det här värdet skickas direkt av en kölagringsutlösare till en Blob Storage-indatabindning på samma funktion. | Ger flexibiliteten att utlösa händelser förutom de som kommer från en lagringscontainer. Använd när du också behöver låta icke-lagringshändelser utlösa funktionen. Mer information finns i Arbeta med Event Grid-utlösare och bindningar i Azure Functions. |
1 Blob Storage-indata- och utdatabindningar stöder endast blobkonton.
2 Hög skala kan definieras löst som containrar som har mer än 100 000 blobar i sig eller lagringskonton som har mer än 100 blobuppdateringar per sekund.
Kryptering av lagringsdata
Azure Storage krypterar alla data i ett lagringskonto i vila. För mer information, se Azure Storage-kryptering för vilande data.
Som standard krypteras data med Microsoft-hanterade nycklar. För ytterligare kontroll över krypteringsnycklar kan du ange kundhanterade nycklar som ska användas för kryptering av blob- och fildata. Dessa nycklar måste finnas i Azure Key Vault för att Functions ska kunna komma åt lagringskontot. Mer information finns i Kryptering i vila med kundhanterade nycklar.
Datahemvist i regionen
När alla kunddata måste finnas kvar i en enda region måste lagringskontot som är associerat med funktionsappen vara ett med redundans i regionen. Ett redundant lagringskonto i regionen måste också användas med Azure Durable Functions.
Andra plattformshanterade kunddata lagras endast i regionen när du är värd för en internt belastningsutjämnad App Service-miljön (ASE). Mer information finns i ASE-zonredundans.
Överväganden för värd-ID
Functions använder ett värd-ID-värde som ett sätt att unikt identifiera en viss funktionsapp i lagrade artefakter. Som standard genereras detta ID automatiskt från namnet på funktionsappen, trunkerat till de första 32 tecknen. Det här ID:t används sedan vid lagring av korrelations- och spårningsinformation per app i det länkade lagringskontot. När du har funktionsappar med namn som är längre än 32 tecken och när de första 32 tecknen är identiska kan den här trunkeringen resultera i duplicerade värd-ID-värden. När två funktionsappar med identiska värd-ID:er använder samma lagringskonto får du en värd-ID-kollision eftersom lagrade data inte kan länkas unikt till rätt funktionsapp.
Kommentar
Samma typ av värd-ID collison kan inträffa mellan en funktionsapp i en produktionsplats och samma funktionsapp i ett mellanlagringsfack, när båda platserna använder samma lagringskonto.
Från och med version 3.x av Functions-körningen identifieras en kollision mellan värd-ID och en varning loggas. I version 4.x loggas ett fel och värden stoppas, vilket resulterar i ett hårt fel. Mer information om kollision med värd-ID finns i det här problemet.
Undvika kollisioner med värd-ID
Du kan använda följande strategier för att undvika kollisioner med värd-ID:
- Använd ett avgränsat lagringskonto för varje funktionsapp eller fack som ingår i kollisionen.
- Byt namn på en av dina funktionsappar till ett värde som är mindre än 32 tecken långt, vilket ändrar det beräknade värd-ID:t för appen och tar bort kollisionen.
- Ange ett explicit värd-ID för en eller flera av de kolliderande apparna. Mer information finns i åsidosättning av värd-ID.
Viktigt!
Att ändra lagringskontot som är associerat med en befintlig funktionsapp eller ändra appens värd-ID kan påverka beteendet för befintliga funktioner. En Blob Storage-utlösare spårar till exempel om den bearbetas enskilda blobar genom att skriva kvitton under en specifik värd-ID-sökväg i lagringen. När värd-ID:t ändras eller du pekar på ett nytt lagringskonto kan tidigare bearbetade blobar bearbetas på nytt.
Åsidosätt värd-ID:t
Du kan uttryckligen ange ett specifikt värd-ID för funktionsappen i programinställningarna med hjälp av inställningen AzureFunctionsWebHost__hostid . Mer information finns i AzureFunctionsWebHost__hostid.
När kollisionen inträffar mellan platser måste du ange ett specifikt värd-ID för varje fack, inklusive produktionsplatsen. Du måste också markera de här inställningarna som distributionsinställningar så att de inte byts ut. Information om hur du skapar appinställningar finns i Arbeta med programinställningar.
Azure Arc-aktiverade kluster
När din funktionsapp distribueras till ett Azure Arc-aktiverat Kubernetes-kluster kanske inte ett lagringskonto krävs av funktionsappen. I det här fallet krävs endast ett lagringskonto av Functions när funktionsappen använder en utlösare som kräver lagring. Följande tabell anger vilka utlösare som kan kräva ett lagringskonto och vilka som inte gör det.
| Krävs inte | kan kräva lagring |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus |
• Azure SQL • Bloblagring • Event Grid • Event Hubs • IoT Hub • Kölagring • SendGrid • SignalR • Tabelllagring • Timer • Twilio |
Om du vill skapa en funktionsapp i ett Azure Arc-aktiverat Kubernetes-kluster utan lagring måste du använda Azure CLI-kommandot az functionapp create. Versionen av Azure CLI måste innehålla version 0.1.7 eller en senare version av appservice-kube-tillägget. az --version Använd kommandot för att kontrollera att tillägget är installerat och att det är rätt version.
För att skapa dina funktionsappresurser med andra metoder än Azure CLI krävs ett befintligt lagringskonto. Om du planerar att använda utlösare som kräver ett lagringskonto bör du skapa kontot innan du skapar funktionsappen.
Skapa en app utan Azure Files
Azure Files konfigureras som standard för elastic premium- och icke-Linux-förbrukningsplaner som fungerar som ett delat filsystem i storskaliga scenarier. Filsystemet används av plattformen för vissa funktioner, till exempel loggströmning, men det garanterar främst konsekvens för den distribuerade funktionsnyttolasten. När en app distribueras med hjälp av en extern paket-URL hanteras appinnehållet från ett separat skrivskyddat filsystem. Det innebär att du kan skapa din funktionsapp utan Azure Files. Om du skapar din funktionsapp med Azure Files tillhandahålls fortfarande ett skrivbart filsystem. Det här filsystemet kanske dock inte är tillgängligt för alla funktionsappinstanser.
När Azure Files inte används måste du uppfylla följande krav:
- Du måste distribuera från en extern paket-URL.
- Din app kan inte förlita sig på ett delat skrivbart filsystem.
- Appen kan inte använda version 1.x av Functions-körningen.
- Loggströmningsupplevelser i klienter som Azure-portalen är standard för filsystemloggar. Du bör i stället förlita dig på Application Insights-loggar.
Om ovanstående är korrekt redovisat kan du skapa appen utan Azure Files. Skapa funktionsappen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING utan att ange programinställningarna och WEBSITE_CONTENTSHARE . Du kan undvika de här inställningarna genom att generera en ARM-mall för en standarddistribution, ta bort de två inställningarna och sedan distribuera mallen.
Eftersom Functions använder Azure Files under delar av den dynamiska utskalningsprocessen kan skalningen begränsas när den körs utan Azure Files på förbruknings- och Elastic Premium-abonnemang.
Montera filresurser
Den här funktionen är endast tillgänglig när den körs på Linux.
Du kan montera befintliga Azure Files-resurser i dina Linux-funktionsappar. Genom att montera en resurs i din Linux-funktionsapp kan du använda befintliga maskininlärningsmodeller eller andra data i dina funktioner. Du kan använda följande kommando för att montera en befintlig resurs i din Linux-funktionsapp.
az webapp config storage-account add
I det här kommandot share-name är namnet på den befintliga Azure Files-resursen och custom-id kan vara valfri sträng som unikt definierar resursen när den monteras i funktionsappen. mount-path Är också sökvägen som resursen nås från i funktionsappen. mount-path måste vara i formatet /dir-name, och det kan inte börja med /home.
Ett fullständigt exempel finns i skripten i Skapa en Python-funktionsapp och montera en Azure Files-resurs.
För närvarande stöds endast en storage-type av AzureFiles . Du kan bara montera fem resurser till en viss funktionsapp. Om du monterar en filresurs kan du öka den kalla starttiden med minst 200–300 ms, eller ännu mer när lagringskontot finns i en annan region.
Den monterade resursen är tillgänglig för funktionskoden vid angiven mount-path . När är /path/to/mountkan du till exempel mount-path komma åt målkatalogen efter filsystem-API:er, som i följande Python-exempel:
import os
...
files_in_share = os.listdir("/path/to/mount")
Nästa steg
Läs mer om värdalternativ för Azure Functions.