Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Wanneer u een exemplaar van een functie-app in Azure maakt, moet u toegang bieden tot een standaard Azure Storage-account. In het volgende diagram en de volgende tabel ziet u hoe Azure Functions gebruikmaakt van services in het standaardopslagaccount:
| Opslagservice | Gebruik van functies |
|---|---|
| Azure Blob Storage | Behoud de status van bindingen en functietoetsen1. Implementatiebron voor apps die worden uitgevoerd in een Flex Consumption-abonnement. 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. Extensiebundels onderhouden. Sla implementatielogboeken op. Ondersteunt beheerde afhankelijkheden in PowerShell. |
| 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 Tabelopslag | Standaard gebruikt voor taakhubs in Durable Functions. Wordt gebruikt voor het bijhouden van diagnostische gebeurtenissen. |
- Blob Storage is het standaardarchief voor functiesleutels, maar u kunt een alternatief archief configureren.
- 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, blijven behouden 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 u bij het maken van de functie-applicatie in de Azure Portal aanmaakt, werken samen met de nieuwe functie-applicatie. Wanneer u ervoor kiest om een bestaand opslagaccount te gebruiken, bevat de opgegeven lijst geen bepaalde niet-ondersteunde opslagaccounts. De volgende beperkingen gelden voor opslagaccounts die door uw functie-app worden gebruikt. Zorg ervoor dat een bestaand opslagaccount voldoet aan deze vereisten:
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 met een netwerk beveiligd opslagaccount gebruiken wanneer uw functie-app wordt gehost in het verbruiksabonnement.
Wanneer u uw functie-app maakt in Azure Portal, kunt u alleen een bestaand opslagaccount kiezen in dezelfde regio als de functie-app die u maakt. Deze vereiste is een prestatieoptimalisatie 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.
Wanneer u implementatieautomatisering gebruikt om uw functie-app te maken met een met het netwerk beveiligd opslagaccount, moet u specifieke netwerkconfiguraties opnemen in uw ARM-sjabloon of Bicep-bestand. Als u deze instellingen en resources niet opneemt, kan uw geautomatiseerde implementatie mislukken tijdens de validatie. Zie Beveiligde implementaties voor ARM-sjablonen en Bicep-richtlijnen. Zie Een beveiligd opslagaccount gebruiken met Azure Functions voor een overzicht van het configureren van opslagaccounts met netwerken.
Richtlijnen voor opslagaccounts
Voor elke functie-app moet een opslagaccount worden uitgevoerd. Wanneer u dat account verwijdert, stopt uw functie-app met draaien. Als u problemen met betrekking tot opslag wilt oplossen, raadpleegt u Problemen met betrekking tot opslag oplossen. De volgende overwegingen zijn van toepassing op het opslagaccount dat wordt gebruikt door functie-apps.
Locatie van 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 een opslagaccount in een andere regio dan uw functie-app wilt gebruiken, moet u uw functie-app buiten Azure 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 is opgeslagen in de toepassingsinstelling AzureWebJobsStorage. U kunt AzureWebJobsStorage ook configureren om een op identiteit gebaseerde verbinding te gebruiken zonder een geheim.
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. Deze waarde 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
U moet een verbindingsreeks voor een opslagaccount bijwerken wanneer u opslagsleutels opnieuw genereert. Zie Een Azure-opslagaccount maken voor meer informatie.
Gedeelde opslagaccounts
Meerdere functie-apps kunnen zonder problemen hetzelfde opslagaccount delen. In Visual Studio kunt u bijvoorbeeld meerdere apps ontwikkelen met behulp van de Emulator van de Azure-opslag. In dit geval fungeert de emulator als één opslagaccount. Hetzelfde opslagaccount dat door uw functie-app wordt gebruikt, kan ook uw toepassingsgegevens opslaan. 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
Pas geen beleid voor levenscyclusbeheer toe 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. 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. Deze aanpak is met name belangrijk wanneer u Durable Functions of Event Hubs 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.
Consistente routering via virtuele netwerken
Meerdere functie-apps die in hetzelfde abonnement worden gehost, kunnen ook hetzelfde opslagaccount gebruiken voor de Azure Files-inhoudsshare, gedefinieerd door WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Wanneer u dit opslagaccount beveiligt met behulp van een virtueel netwerk, moeten al deze apps dezelfde waarde voor vnetContentShareEnabled (voorheen WEBSITE_CONTENTOVERVNET) gebruiken om ervoor te zorgen dat verkeer consistent wordt gerouteerd via het beoogde virtuele netwerk. Een onjuiste overeenkomst in deze instelling tussen apps die hetzelfde Azure Files-opslagaccount gebruiken, kan leiden tot verkeersroutering via openbare netwerken. In deze configuratie blokkeren netwerkregels voor opslagaccounts de toegang.
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, zoals wordt aangegeven in dit diagram:
Gebruik de volgende tabel om te bepalen welke functietrigger het beste past bij uw behoeften voor het verwerken van toegevoegde of bijgewerkte blobs in een container:
| Strategie | Blobtrigger (polling) | Blobtrigger (gebeurtenisgestuurd) | Wachtrijtrigger | Trigger voor 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 |
| Triggertype | Blob Storage | Blob Storage | Queue Storage | Event Grid |
| Versie van de extensie | Alle | Storage v5.x+ | Alle | Alle |
| Bestaande blobs verwerkt | Ja | Nee. | Nee. | Nee. |
| Filteren | Blob-naampatroon | Gebeurtenisfilters | n.v.t. | Gebeurtenisfilters |
| Vereist gebeurtenisabonnement | Nee. | Ja | Nee. | Ja |
| Ondersteunt het Flex Consumption-abonnement | Nee. | Ja | Ja | Ja |
| Ondersteunt grootschalige² | Nee. | Ja | Ja | Ja |
| Werkt met binnenkomende toegangsbeperkingen | Ja | Nee. | Ja | Ja3 |
| 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. Een Queue Storage-trigger geeft deze waarde rechtstreeks door aan een Blob Storage-invoerbinding voor 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. |
- Blob Storage-invoer- en uitvoerbindingen ondersteunen alleen blob-accounts.
- 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.
- U kunt binnenkomende toegangsbeperkingen omzeilen door het gebeurtenisabonnement gebeurtenissen te laten leveren via een versleuteld kanaal in openbare IP-ruimte met behulp van een bekende gebruikersidentiteit. Zie Gebeurtenissen veilig leveren met behulp van beheerde identiteiten voor meer informatie.
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 meer 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 Uw toepassingsgegevens in rust versleutelen 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
Notitie
De overwegingen voor host-id's in deze sectie zijn niet van toepassing wanneer uw app wordt uitgevoerd in een Flex Consumption-abonnement. In dit hostingabonnement wordt de waarde van de host-id gemaakt op een manier die deze potentiële problemen voorkomt.
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-botsing kan optreden tussen een functie-app in een productiesite en dezelfde functie-app in een staging-site wanneer beide sites hetzelfde opslagaccount gebruiken.
In versie 4.x van de Functions-runtime wordt een fout geregistreerd en wordt de host gestopt, wat resulteert in een harde fout. Zie HostID Truncation kan conflicten veroorzaken voor meer informatie.
Host-id-conflicten voorkomen
U kunt de volgende strategieën gebruiken om conflicten met host-id's te voorkomen:
- Gebruik een afzonderlijk 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 De 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 voor uw functie-app mogelijk geen opslagaccount vereist. In dit geval is voor functies alleen een opslagaccount vereist wanneer uw functie-app gebruikmaakt van een trigger 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
De Azure Files-service biedt een gedeeld bestandssysteem dat ondersteuning biedt voor grootschalige scenario's. Wanneer uw functie-app wordt uitgevoerd in een Elastic Premium-abonnement of in Windows in een verbruiksabonnement, wordt standaard een Azure Files-share gemaakt in uw opslagaccount. Functies gebruiken die gedeelde resources om bepaalde functies, zoals logboekstreaming, mogelijk te maken. Het wordt ook gebruikt als een locatie voor gedeelde pakketimplementatie, die de consistentie van uw geïmplementeerde functiecode garandeert voor alle exemplaren.
Standaard gebruiken functie-apps die worden gehost in Premium- en Verbruiksabonnementen zip-implementatie, met implementatiepakketten die zijn opgeslagen in deze Azure-bestandsshare. Deze sectie is alleen relevant voor deze hostingabonnementen.
Voor het gebruik van Azure Files is het gebruik van een verbindingsreeks vereist, die is opgeslagen in uw app-instellingen als WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Azure Files biedt momenteel geen ondersteuning voor op identiteit gebaseerde verbindingen. Als uw scenario vereist dat u geen geheimen opslaat in app-instellingen, moet u de afhankelijkheid van uw app op Azure Files verwijderen. U kunt afhankelijkheden voorkomen door uw app te maken zonder de standaardafhankelijkheid van Azure Files.
Notitie
U moet ook overwegen om uw functie-app uit te voeren in het Flex Consumption-abonnement, dat meer controle biedt over het implementatiepakket, inclusief de mogelijkheid om beheerde identiteitverbindingen te gebruiken. Zie Implementatie-instellingen configureren voor meer informatie.
Als u uw app wilt uitvoeren zonder de Azure-bestandsshare, moet u voldoen aan de volgende vereisten:
- U moet uw pakket implementeren in een externe Azure Blob Storage-container en vervolgens de URL instellen die toegang tot dat pakket biedt als de
WEBSITE_RUN_FROM_PACKAGEapp-instelling. Met deze methode kunt u uw app-inhoud opslaan in Blob Storage in plaats van Azure Files, dat wel beheerde identiteiten ondersteunt.
U moet het implementatiepakket handmatig bijwerken en de URL van het implementatiepakket onderhouden, die waarschijnlijk een SAS (Shared Access Signature) bevat.
Houd ook rekening met de volgende overwegingen:
- De app kan versie 1.x van de Functions-runtime niet gebruiken.
- Uw app kan niet vertrouwen op een gedeeld beschrijfbaar bestandssysteem.
- Portal bewerken wordt niet ondersteund.
- Logboekstreamingervaringen in clients zoals azure Portal zijn standaard ingesteld op bestandssysteemlogboeken. U moet in plaats daarvan afhankelijk zijn van Application Insights-logboeken.
Als de voorgaande vereisten aansluiten bij uw scenario, kunt u doorgaan met het maken van een functie-app zonder Azure Files. Maak een app zonder de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en WEBSITE_CONTENTSHARE app-instellingen op een van de volgende manieren:
- Bicep/ARM-sjablonen: verwijder de twee app-instellingen uit het ARM-sjabloon- of Bicep-bestand en implementeer vervolgens de app met behulp van de gewijzigde sjabloon.
- Azure-portal: deselecteer Een Azure Files-verbinding toevoegen op het tabblad Storage wanneer u de app maakt in de Azure-portal.
Azure Files wordt gebruikt om dynamisch uitschalen in te schakelen voor Functions. Schaalbaarheid kan worden beperkt wanneer u uw app uitvoert zonder Azure Files in het Elastic Premium-abonnement of de verbruiksabonnementen op Windows.
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.
Belangrijk
Na 30 september 2028 wordt de optie voor het hosten van uw functie-app op Linux in een verbruiksabonnement buiten gebruik gesteld. Als u onderbrekingen wilt voorkomen, migreert u uw bestaande verbruiksabonnement-apps die op Linux worden uitgevoerd naar het Flex Consumption-abonnement vóór die datum. Apps die worden uitgevoerd in Windows in een verbruiksabonnement, worden niet beïnvloed door deze wijziging. Zie de kennisgeving over buitengebruikstelling van het Linux-verbruiksplan voor meer informatie.
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 de naam van de bestaande Azure Files-share.
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 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 mount-pathu bijvoorbeeld /path/to/mount toegang tot de doelmap op bestandssysteem-API's, zoals in het volgende Python-voorbeeld:
import os
...
files_in_share = os.listdir("/path/to/mount")
Gerelateerd artikel
Meer informatie over azure Functions-hostingopties.