Overwegingen bij het gebruik van opslag voor Azure Functions
Azure Functions vereist een Azure Storage-account wanneer u een exemplaar van een functie-app maakt. De volgende opslagservices kunnen worden gebruikt door uw functie-app:
| Opslagservice | Gebruik van functies |
|---|---|
| Azure Blob Storage | Behoud de status van bindingen en functietoetsen1. Standaard gebruikt voor taakhubs in Durable Functions. Kan worden gebruikt om functie-app-code op te slaan voor externe build voor Linux-verbruik of als onderdeel van externe pakket-URL-implementaties. |
| Azure Files2 | Bestandsshare die wordt gebruikt om uw functie-app-code op te slaan en uit te voeren in een verbruiksabonnement en Premium-abonnement. |
| Azure Queue Storage | Standaard gebruikt voor taakhubs in Durable Functions. Wordt gebruikt voor het verwerken van fouten en het opnieuw proberen in specifieke Azure Functions-triggers. Wordt gebruikt voor het bijhouden van objecten door de Blob Storage-trigger. |
| Azure Table storage | Standaard gebruikt voor taakhubs in Durable Functions. |
1 Blob Storage is het standaardarchief voor functiesleutels, maar u kunt een alternatief archief configureren.
2 Azure Files is standaard ingesteld, maar u kunt onder bepaalde voorwaarden een app zonder Azure Files maken.
Belangrijke aandachtspunten
Houd rekening met de volgende feiten met betrekking tot de opslagaccounts die door uw functie-apps worden gebruikt:
Wanneer uw functie-app wordt gehost in het verbruiksabonnement of Premium-abonnement, worden uw functiecode en configuratiebestanden opgeslagen in Azure Files in het gekoppelde opslagaccount. Wanneer u dit opslagaccount verwijdert, wordt de inhoud verwijderd en kan deze niet worden hersteld. Zie Opslagaccount is verwijderd voor meer informatie
Belangrijke gegevens, zoals functiecode, toegangssleutels en andere belangrijke servicegerelateerde gegevens, kunnen worden bewaard in het opslagaccount. U moet de toegang tot de opslagaccounts die door functie-apps worden gebruikt, zorgvuldig beheren op de volgende manieren:
Controleer en beperk de toegang van apps en gebruikers tot het opslagaccount op basis van een model met minimale bevoegdheden. Machtigingen voor het opslagaccount kunnen afkomstig zijn van gegevensacties in de toegewezen rol of via machtigingen voor het uitvoeren van de listKeys-bewerking.
Bewaak de activiteit van het besturingsvlak (zoals het ophalen van sleutels) en gegevensvlakbewerkingen (zoals schrijven naar een blob) in uw opslagaccount. Overweeg opslaglogboeken te onderhouden op een andere locatie dan Azure Storage. Zie Opslaglogboeken voor meer informatie.
Vereisten voor een opslagaccount
Opslagaccounts die zijn gemaakt als onderdeel van de stroom voor het maken van de functie-app in Azure Portal, werken gegarandeerd met de nieuwe functie-app. Wanneer u ervoor kiest om een bestaand opslagaccount te gebruiken, bevat de opgegeven lijst geen bepaalde niet-ondersteunde opslagaccounts. De volgende beperkingen zijn van toepassing op opslagaccounts die worden gebruikt door uw functie-app, dus zorg ervoor dat een bestaand opslagaccount aan deze vereisten voldoet:
Het accounttype moet blob-, wachtrij- en tableopslag ondersteunen. Sommige opslagaccounts bieden geen ondersteuning voor wachtrijen en tabellen. Deze accounts omvatten opslagaccounts met alleen blob en Azure Premium Storage. Zie het overzicht van opslagaccounts voor meer informatie over typen opslagaccounts.
U kunt geen opslagaccount gebruiken dat al is beveiligd met behulp van een firewall of een virtueel particulier netwerk wanneer u uw functie-app maakt in Azure Portal. De portal filtert momenteel echter niet deze beveiligde opslagaccounts. Zie Een beveiligd opslagaccount gebruiken met Azure Functions voor meer informatie over het gebruik van een beveiligd opslagaccount met uw functie-app.
U kunt geen beveiligde opslagaccounts gebruiken met functie-apps die worden gehost in het verbruiksabonnement.
Wanneer u uw functie-app maakt in de portal, kunt u alleen een bestaand opslagaccount kiezen in dezelfde regio als de functie-app die u maakt. Dit is een optimalisatie van prestaties en geen strikte beperking. Zie opslagaccountlocatie voor meer informatie.
Wanneer u uw functie-app maakt op een plan waarvoor ondersteuning voor beschikbaarheidszones is ingeschakeld, worden alleen zone-redundante opslagaccounts ondersteund.
U kunt functie-apps maken in een Elastic Premium- of Dedicated (App Service)-plan met behulp van implementatieautomatisering. U moet echter specifieke netwerkconfiguraties opnemen in uw ARM-sjabloon of Bicep-bestand. Wanneer u deze instellingen en resources niet opneemt, kan uw geautomatiseerde implementatie mislukken tijdens de validatie. Zie Beveiligde implementaties voor meer informatie.
Richtlijnen voor opslagaccounts
Voor elke functie-app moet een opslagaccount worden uitgevoerd. Wanneer dat account wordt verwijderd, wordt uw functie-app niet uitgevoerd. Als u problemen met betrekking tot opslag wilt oplossen, raadpleegt u Problemen met betrekking tot opslag oplossen. De volgende andere overwegingen zijn van toepassing op het opslagaccount dat wordt gebruikt door functie-apps.
De locatie van het opslagaccount
Voor de beste prestaties moet uw functie-app een opslagaccount in dezelfde regio gebruiken, waardoor de latentie wordt verminderd. In Azure Portal wordt deze best practice afgedwongen. Als u om een of andere reden een opslagaccount in een andere regio dan uw functie-app moet gebruiken, moet u uw functie-app buiten de portal maken.
Het opslagaccount moet toegankelijk zijn voor de functie-app. Als u een beveiligd opslagaccount wilt gebruiken, kunt u overwegen uw opslagaccount te beperken tot een virtueel netwerk.
Verbindingsinstelling voor opslagaccount
Functie-apps configureren de AzureWebJobsStorage verbinding standaard als een verbindingsreeks die zijn opgeslagen in de toepassingsinstelling AzureWebJobsStorage, maar u kunt AzureWebJobsStorage ook configureren om een op identiteit gebaseerde verbinding zonder geheim te gebruiken.
Functie-apps die worden uitgevoerd in een verbruiksabonnement (alleen Windows) of een Elastic Premium-abonnement (Windows of Linux) kunnen Azure Files gebruiken om de installatiekopieën op te slaan die nodig zijn om dynamisch schalen mogelijk te maken. Voor deze plannen stelt u de verbindingsreeks in voor het opslagaccount in de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING-instelling en de naam van de bestandsshare in de WEBSITE_CONTENTSHARE-instelling. Dit is meestal hetzelfde account dat wordt gebruikt voor AzureWebJobsStorage. U kunt ook een functie-app maken die geen gebruik maakt van Azure Files, maar het schalen is mogelijk beperkt.
Notitie
Een opslagaccount verbindingsreeks moet worden bijgewerkt wanneer u opslagsleutels opnieuw genereert. Lees hier meer over opslagsleutelbeheer.
Gedeelde opslagaccounts
Het is mogelijk dat meerdere functie-apps hetzelfde opslagaccount delen zonder problemen. In Visual Studio kunt u bijvoorbeeld meerdere apps ontwikkelen met behulp van de Emulator voor opslag van Azurite. In dit geval fungeert de emulator als één opslagaccount. Hetzelfde opslagaccount dat door uw functie-app wordt gebruikt, kan ook worden gebruikt om uw toepassingsgegevens op te slaan. Deze benadering is echter niet altijd een goed idee in een productieomgeving.
Mogelijk moet u afzonderlijke opslagaccounts gebruiken om conflicten met host-id's te voorkomen.
Overwegingen voor levenscyclusbeheerbeleid
U moet geen beleid voor levenscyclusbeheer toepassen op uw Blob Storage-account dat wordt gebruikt door uw functie-app. Functions maakt gebruik van Blob Storage om belangrijke informatie te behouden, zoals functietoegangssleutels, en beleidsregels kunnen blobs (zoals sleutels) verwijderen die nodig zijn voor de Functions-host. Als u beleidsregels moet gebruiken, sluit u containers uit die worden gebruikt door Functions. Deze worden voorafgegaan door azure-webjobs of scm.
Opslaglogboeken
Omdat functiecode en sleutels mogelijk worden bewaard in het opslagaccount, is logboekregistratie van activiteiten voor het opslagaccount een goede manier om te controleren op onbevoegde toegang. Azure Monitor-resourcelogboeken kunnen worden gebruikt voor het bijhouden van gebeurtenissen op het gegevensvlak van de opslag. Zie Bewaking van Azure Storage voor meer informatie over het configureren en onderzoeken van deze logboeken.
In het Activiteitenlogboek van Azure Monitor worden gebeurtenissen van het besturingsvlak weergegeven, waaronder de bewerking listKeys. U moet echter ook resourcelogboeken configureren voor het opslagaccount om het volgende gebruik van sleutels of andere op identiteit gebaseerde gegevensvlakbewerkingen bij te houden. U moet ten minste de storageWrite-logboekcategorie hebben ingeschakeld om wijzigingen in de gegevens buiten normale Functies-bewerkingen te kunnen identificeren.
Als u de mogelijke impact van eventuele opslagmachtigingen binnen het bereik wilt beperken, kunt u overwegen om een niet-opslagbestemming te gebruiken voor deze logboeken, zoals Log Analytics. Zie Azure Blob Storage bewaken voor meer informatie.
Opslagprestaties optimaliseren
Gebruik een afzonderlijk opslagaccount voor elke functie-app om de prestaties te maximaliseren. Dit is vooral belangrijk wanneer u Durable Functions of door Event Hub geactiveerde functies hebt die beide een groot aantal opslagtransacties genereren. Wanneer uw toepassingslogica communiceert met Azure Storage, direct (met behulp van de opslag-SDK) of via een van de opslagbindingen, moet u een speciaal opslagaccount gebruiken. Als u bijvoorbeeld een door Event Hub geactiveerde functie hebt die bepaalde gegevens naar blobopslag schrijft, gebruikt u twee opslagaccounts: een voor de functie-app en een andere voor de blobs die door de functie worden opgeslagen.
Werken met blobs
Een belangrijk scenario voor Functions is bestandsverwerking van bestanden in een blobcontainer, zoals voor afbeeldingsverwerking of sentimentanalyse. Zie Uploads van procesbestanden voor meer informatie.
Trigger op een blobcontainer
Er zijn verschillende manieren om uw functiecode uit te voeren op basis van wijzigingen in blobs in een opslagcontainer. Gebruik de volgende tabel om te bepalen welke functietrigger het beste past bij uw behoeften:
| Overweging | Blob Storage (polling) | Blob Storage (op basis van gebeurtenissen) | Queue Storage | Event Grid |
|---|---|---|---|---|
| Latentie | Hoog (maximaal 10 minuten) | Beperkt | Gemiddeld | Beperkt |
| Beperkingen voor opslagaccounts | Accounts met alleen blobs worden niet ondersteund¹ | algemeen gebruik v1 wordt niet ondersteund | Geen | algemeen gebruik v1 wordt niet ondersteund |
| Versie van de extensie | Alle | Storage v5.x+ | Alle | Alle |
| Bestaande blobs verwerkt | Ja | No | No | Nr. |
| Filters | Blob-naampatroon | Gebeurtenisfilters | N.v.t. | Gebeurtenisfilters |
| Vereist gebeurtenisabonnement | Nr. | Ja | No | Ja |
| Ondersteunt grootschalige² | Nr. | Ja | Ja | Ja |
| Beschrijving | Standaardtriggergedrag, dat afhankelijk is van het peilen van de container voor updates. Zie de voorbeelden in de naslaginformatie over de Blob Storage-trigger voor meer informatie. | Verbruikt blobopslag-gebeurtenissen van een gebeurtenisabonnement. Vereist een Source parameterwaarde van EventGrid. Zie Zelfstudie: Azure Functions activeren voor blobcontainers met behulp van een gebeurtenisabonnement voor meer informatie. |
De blobnaamtekenreeks wordt handmatig toegevoegd aan een opslagwachtrij wanneer een blob wordt toegevoegd aan de container. Deze waarde wordt rechtstreeks door een Queue Storage-trigger doorgegeven aan een Blob Storage-invoerbinding op dezelfde functie. | Biedt de flexibiliteit van het activeren van gebeurtenissen naast gebeurtenissen die afkomstig zijn van een opslagcontainer. Gebruik deze functie wanneer u ook niet-opstaande gebeurtenissen moet activeren. Zie Hoe u werkt met Event Grid-triggers en -bindingen in Azure Functions voor meer informatie. |
1 Blob Storage-invoer- en uitvoerbindingen ondersteunen alleen blob-accounts.
2 Grote schaal kan losjes worden gedefinieerd als containers met meer dan 100.000 blobs in deze containers of opslagaccounts met meer dan 100 blob-updates per seconde.
Opslaggegevensversleuteling
Azure Storage versleutelt alle gegevens in een opslagaccount-at-rest. Zie Azure Storage-versleuteling voor data-at-rest voor meer informatie.
Standaard worden gegevens versleuteld met door Microsoft beheerde sleutels. Voor extra controle over versleutelingssleutels kunt u door de klant beheerde sleutels opgeven voor versleuteling van blob- en bestandsgegevens. Deze sleutels moeten aanwezig zijn in Azure Key Vault voor Functions om toegang te krijgen tot het opslagaccount. Zie Versleuteling-at-rest met behulp van door de klant beheerde sleutels voor meer informatie.
Gegevenslocatie in uw regio
Wanneer alle klantgegevens binnen één regio moeten blijven, moet het opslagaccount dat is gekoppeld aan de functie-app, één zijn met redundantie in de regio. Er moet ook een redundant opslagaccount in de regio worden gebruikt met Azure Durable Functions.
Andere door het platform beheerde klantgegevens worden alleen in de regio opgeslagen wanneer ze worden gehost in een app-omgeving met interne taakverdeling (ASE). Zie ASE-zoneredundantie voor meer informatie.
Overwegingen voor host-id's
Functions gebruikt een host-id-waarde als een manier om een bepaalde functie-app uniek te identificeren in opgeslagen artefacten. Deze id wordt standaard automatisch gegenereerd op basis van de naam van de functie-app, afgekapt tot de eerste 32 tekens. Deze id wordt vervolgens gebruikt bij het opslaan van correlatie- en traceringsgegevens per app in het gekoppelde opslagaccount. Wanneer u functie-apps hebt met namen die langer zijn dan 32 tekens en wanneer de eerste 32 tekens identiek zijn, kan deze afkapping leiden tot dubbele host-id-waarden. Wanneer twee functie-apps met identieke host-id's hetzelfde opslagaccount gebruiken, krijgt u een host-id-botsing omdat opgeslagen gegevens niet uniek kunnen worden gekoppeld aan de juiste functie-app.
Notitie
Dit soort host-id-conflict kan optreden tussen een functie-app in een productiesite en dezelfde functie-app in een staging-site wanneer beide sites hetzelfde opslagaccount gebruiken.
Vanaf versie 3.x van de Functions-runtime wordt een host-id-botsing gedetecteerd en wordt een waarschuwing vastgelegd. In versie 4.x wordt een fout geregistreerd en wordt de host gestopt, wat resulteert in een harde fout. Meer informatie over host-id-botsingen vindt u in dit probleem.
Host-id-conflicten voorkomen
U kunt de volgende strategieën gebruiken om conflicten met host-id's te voorkomen:
- Gebruik een gescheiden opslagaccount voor elke functie-app of sleuf die betrokken is bij de botsing.
- Wijzig de naam van een van uw functie-apps in een waarde van minder dan 32 tekens, waardoor de berekende host-id voor de app wordt gewijzigd en de botsing wordt verwijderd.
- Stel een expliciete host-id in voor een of meer van de botsende apps. Zie Host-id overschrijven voor meer informatie.
Belangrijk
Het wijzigen van het opslagaccount dat is gekoppeld aan een bestaande functie-app of het wijzigen van de host-id van de app kan van invloed zijn op het gedrag van bestaande functies. Met een Blob Storage-trigger wordt bijvoorbeeld bijgehouden of afzonderlijke blobs worden verwerkt door ontvangstbewijzen te schrijven onder een specifiek host-id-pad in de opslag. Wanneer de host-id wordt gewijzigd of u verwijst naar een nieuw opslagaccount, kunnen eerder verwerkte blobs opnieuw worden verwerkt.
De host-id overschrijven
U kunt expliciet een specifieke host-id instellen voor uw functie-app in de toepassingsinstellingen met behulp van de AzureFunctionsWebHost__hostid instelling. Zie AzureFunctionsWebHost__hostid voor meer informatie.
Wanneer de botsing tussen sites plaatsvindt, moet u een specifieke host-id instellen voor elke site, inclusief de productiesite. U moet deze instellingen ook markeren als implementatie-instellingen , zodat ze niet worden verwisseld. Zie Werken met toepassingsinstellingen voor meer informatie over het maken van app-instellingen.
Clusters met Azure Arc
Wanneer uw functie-app is geïmplementeerd in een Kubernetes-cluster met Azure Arc, is een opslagaccount mogelijk niet vereist voor uw functie-app. In dit geval is een opslagaccount alleen vereist voor Functions wanneer uw functie-app een trigger gebruikt waarvoor opslag is vereist. De volgende tabel geeft aan welke triggers mogelijk een opslagaccount vereisen en welke niet.
| Niet vereist | vereist mogelijk opslag |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus |
• Azure SQL • Blob-opslag • Event Grid • Event Hubs • IoT Hub • Wachtrijopslag • SendGrid • SignalR • Tabelopslag • Timer • Twilio |
Als u een functie-app wilt maken in een Kubernetes-cluster met Azure Arc zonder opslag, moet u de Azure CLI-opdracht az functionapp create gebruiken. De versie van de Azure CLI moet versie 0.1.7 of een latere versie van de appservice-kube-extensie bevatten. Gebruik de az --version opdracht om te controleren of de extensie is geïnstalleerd en de juiste versie is.
Voor het maken van uw functie-app-resources met andere methoden dan de Azure CLI is een bestaand opslagaccount vereist. Als u van plan bent om triggers te gebruiken waarvoor een opslagaccount is vereist, moet u het account maken voordat u de functie-app maakt.
Een app maken zonder Azure Files
Azure Files is standaard ingesteld voor elastic Premium- en niet-Linux-verbruiksabonnementen om te fungeren als een gedeeld bestandssysteem in grootschalige scenario's. Het bestandssysteem wordt door het platform gebruikt voor sommige functies, zoals logboekstreaming, maar zorgt voornamelijk voor consistentie van de geïmplementeerde functiepayload. Wanneer een app wordt geïmplementeerd met behulp van een URL van een extern pakket, wordt de app-inhoud geleverd vanuit een afzonderlijk alleen-lezen bestandssysteem. Dit betekent dat u uw functie-app kunt maken zonder Azure Files. Als u uw functie-app maakt met Azure Files, wordt er nog steeds een beschrijfbaar bestandssysteem geleverd. Dit bestandssysteem is echter mogelijk niet beschikbaar voor alle exemplaren van de functie-app.
Wanneer Azure Files niet wordt gebruikt, moet u aan de volgende vereisten voldoen:
- U moet implementeren vanuit een externe pakket-URL.
- Uw app kan niet vertrouwen op een gedeeld beschrijfbaar bestandssysteem.
- De app kan versie 1.x van de Functions-runtime niet gebruiken.
- Logboekstreamingervaringen in clients zoals azure Portal zijn standaard ingesteld op bestandssysteemlogboeken. U moet in plaats daarvan afhankelijk zijn van Application Insights-logboeken.
Als het bovenstaande juist is opgegeven, kunt u de app zonder Azure Files maken. Maak de functie-app zonder de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING instellingen en WEBSITE_CONTENTSHARE toepassingsinstellingen op te geven. U kunt deze instellingen vermijden door een ARM-sjabloon te genereren voor een standaardimplementatie, de twee instellingen te verwijderen en vervolgens de sjabloon te implementeren.
Omdat Functions Azure Files gebruikt tijdens onderdelen van het dynamische uitschaalproces, kan schalen beperkt zijn bij uitvoering zonder Azure Files op Verbruiks- en Elastic Premium-abonnementen.
Bestandsshares koppelen
Deze functionaliteit is alleen actueel wanneer deze wordt uitgevoerd op Linux.
U kunt bestaande Azure Files-shares koppelen aan uw Linux-functie-apps. Door een share te koppelen aan uw Linux-functie-app, kunt u bestaande machine learning-modellen of andere gegevens in uw functies gebruiken. U kunt de volgende opdracht gebruiken om een bestaande share te koppelen aan uw Linux-functie-app.
az webapp config storage-account add
In deze opdracht share-name is dit de naam van de bestaande Azure Files-share en custom-id kan elke tekenreeks zijn die de share uniek definieert wanneer deze is gekoppeld aan de functie-app. mount-path Is ook het pad van waaruit de share wordt geopend in uw functie-app. mount-path moet de indeling /dir-namehebben en kan niet beginnen met /home.
Zie de scripts in Een Python-functie-app maken en een Azure Files-share koppelen voor een volledig voorbeeld.
Op dit moment wordt alleen een storage-type of AzureFiles meer ondersteund. U kunt slechts vijf shares koppelen aan een bepaalde functie-app. Het koppelen van een bestandsshare kan de koude begintijd met ten minste 200-300 ms verhogen of zelfs meer wanneer het opslagaccount zich in een andere regio bevindt.
De gekoppelde share is beschikbaar voor uw functiecode op de mount-path opgegeven. Wanneer hebt /path/to/mountu bijvoorbeeld mount-path toegang tot de doelmap op bestandssysteem-API's, zoals in het volgende Python-voorbeeld:
import os
...
files_in_share = os.listdir("/path/to/mount")
Volgende stappen
Meer informatie over azure Functions-hostingopties.