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 maakt in Azure, moet u toegang verlenen tot een standaardaccount Azure Storage. In het volgende diagram en de volgende tabel ziet u hoe Azure Functions services gebruikt in het standaardopslagaccount:
Selecteer je hostingplan bovenaan dit artikel om de opslagrichtlijnen te bekijken die van toepassing zijn op je functie-app.
| 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 Linux Consumption remote build of als onderdeel van externe pakket-URL-deployments. |
| Azure Files2 | Bestandsdeling die wordt gebruikt voor het opslaan en uitvoeren van uw functie-app-code 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 afhandelen van fouten en het opnieuw proberen in specifiek Azure Functions triggers. Wordt door de Blob Storage-trigger gebruikt voor het volgen van objecten. |
| Azure Table Storage | 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 maken zonder Azure Files.
Belangrijke aandachtspunten
Overweeg de volgende feiten over de opslagaccounts die door je werkapplicaties worden gebruikt:
Wanneer je je functie-app host op het Consumption-plan (Windows) of Premium-abonnement, sla je je functiecode en configuratiebestanden op in Azure Files in het gekoppelde opslagaccount. Als je dit opslagaccount verwijdert, verwijder je de inhoud permanent. Zie Opslagaccount is verwijderd voor meer informatie.
Het opslagaccount bewaart belangrijke gegevens, zoals functiecode, toegangssleutels en andere belangrijke dienstgerelateerde gegevens. 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.
Als u Durable Functions gebruikt, is de taakhubopslag met name beveiligingsgevoelig, omdat schrijftoegang tot de opslag kan worden gebruikt om het gedrag van toepassingen te wijzigen, waaronder het activeren van willekeurige code-uitvoering. Zie Uw taakhubopslag beveiligen voor meer informatie.
Vereisten voor een opslagaccount
Opslagaccounts die u tijdens het maken van de functietoepassing in de Azure-portal creëert, zijn compatibel met de nieuwe functietoepassing. 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 aan deze eisen voldoet:
- U kunt geen met een netwerk beveiligd opslagaccount gebruiken wanneer uw functie-app wordt gehost in het verbruiksabonnement.
Het accounttype moet blob-, wachtrij- en tableopslag ondersteunen. Sommige opslagaccounts bieden geen ondersteuning voor wachtrijen en tabellen. Deze accounts omvatten opslagaccounts voor alleen blobs en Azure Premium Storage. Zie het overzicht van opslagaccounts voor meer informatie over typen opslagaccounts.
Wanneer u uw functie-app maakt in de 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. Raadpleeg Secured deployments voor richtlijnen over ARM-sjablonen en Bicep. Zie Het gebruik van een beveiligd opslagaccount met Azure Functions voor een overzicht van het configureren van opslagaccounts met netwerken.
Richtlijnen voor opslagaccounts
Voor elke functie-app is een opslagaccount vereist om te werken. Wanneer u dat account verwijdert, stopt uw functie-app met draaien. Ga naar Problemen met betrekking tot opslag oplossen om problemen met betrekking tot opslag op te lossen. 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. De Azure-portal dwingt deze best practice af. Als u een opslagaccount in een andere regio dan uw functie-app wilt gebruiken, moet u uw functie-app buiten de 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 standaard de AzureWebJobsStorage-verbinding 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 afbeeldingen op te slaan die nodig zijn om dynamische schaalbaarheid te ondersteunen. Voor deze abonnementen stelt u de verbindingsreeks in voor het opslagaccount in de instelling WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en de naam van de bestandsshare in de instelling WEBSITE_CONTENTSHARE. 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 schaalaanpassing is mogelijk beperkt.
Notitie
U moet de verbindingsreeks van een opslagaccount bijwerken wanneer u de opslagsleutels opnieuw genereert. Zie Maak een Azure-opslagaccount 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 Azurite-opslagemulator. 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 van 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 Monitoring Azure Storage voor meer informatie over het configureren en onderzoeken van deze logboeken.
In het activiteitenlogboek 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 een breed bereik wilt beperken, kunt u overwegen om een niet-opslagdoel voor deze logboeken te gebruiken, zoals Log Analytics. Zie Monitoring Azure Blob Storage 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, rechtstreeks (met behulp van de Storage SDK) of via een van de opslagbindingen, moet u een toegewezen 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 (inclusief slots) dezelfde waarde gebruiken voor vnetContentShareEnabled (voorheen WEBSITE_CONTENTOVERVNET) en dezelfde configuratie voor virtuele netwerkintegratie, zodat verkeer consistent wordt gerouteerd via het beoogde virtuele netwerk. Een onjuiste overeenkomst in deze instelling tussen apps die gebruikmaken van hetzelfde Azure Files opslagaccount, kan leiden tot verkeersroutering via openbare netwerken. In deze configuratie blokkeren netwerkregels voor opslagaccounts de toegang.
De vnetContentShareEnabled richtlijn geldt niet voor Flex Consumption, Dedicated, Container Apps of Consumption Hosting.
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) | Laag | Gemiddeld | Laag |
| Beperkingen voor opslagaccounts | Ondersteunt geen accounts voor alleen blobs¹ en accounts waarvoor een hiërarchische naamruimte (HNS) is ingeschakeld, zoals Azure Data Lake Storage Gen2-accounts | Ondersteunt geen algemene v1-accounts | Geen | Ondersteunt geen algemene v1-accounts |
| Triggertype | Blob-opslag | Blob-opslag | Wachtrijopslag | Event Grid |
| Versie van de extensie | Alle | Storage v5.x+ | Alle | Alle |
| Verwerkt bestaande blobs | 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 hoge schaalbaarheid² | Nee. | Ja | Ja | Ja |
| Werkt met binnenkomende toegangsbeperkingen | Ja | Nee. | Ja | Ja3 |
| Beschrijving | Het standaardtriggergedrag berust op het peilen van de container voor updates. Raadpleeg voor meer informatie de voorbeelden in de Blob Storage-triggerreferentie. | Verbruikt blobopslag-gebeurtenissen van een gebeurtenisabonnement. Vereist een Source parameterwaarde van EventGrid. Zie Tutorial: Trigger Azure Functions op 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-opslagevenementen uw functie moet laten triggeren. Zie Hoe u werkt met Event Grid-triggers en -bindingen in Azure Functions voor meer informatie. |
- De beperking voor accounts met alleen blobs geldt alleen voor de op polling gebaseerde Blob Storage-trigger. Blob Storage-invoer- en uitvoerbindingen ondersteunen alleen blob-accounts.
- Een hogere schaal kan losjes worden gedefinieerd als containers met meer dan 100.000 blobs 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 in rusttoestand. Voor meer informatie, zie Azure Storage-versleuteling voor gegevens in rust.
Standaard worden gegevens versleuteld met 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 zodat Functions toegang heeft 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, gebruik dan een opslagaccount dat gekoppeld is aan de functie-app en dat redundantie binnen de regio heeft. Gebruik ook een redundant opslagaccount binnen de regio met Azure Durable Functions.
Het platform slaat andere door het platform beheerde klantgegevens alleen binnen de regio op wanneer je host in een intern App Service Environment (ASE) met taakverdeling. Zie ASE-zoneredundantie voor meer informatie.
Overwegingen voor Host-ID's
De overwegingen over host ID in deze sectie zijn niet van toepassing op Flex Consumption. In dit hostingplan wordt de host ID-waarde zo gecreëerd dat deze potentiële problemen worden voorkomen.
Functions gebruikt een host ID-waarde om een specifieke functie-app uniek te identificeren in opgeslagen artefacten. Standaard genereert de runtime deze ID automatisch uit de naam van de functie-app, ingekort tot de eerste 32 tekens. De runtime gebruikt deze ID bij het opslaan van per-app correlatie- en trackinginformatie in het gekoppelde opslagaccount. Wanneer functie-apps namen hebben die langer zijn dan 32 tekens en de eerste 32 tekens identiek zijn, kan deze afkaping resulteren in dubbele host ID-waarden. Wanneer twee functie-apps met identieke host-ID's hetzelfde opslagaccount gebruiken, ontstaat er een botsing met host-ID's omdat opgeslagen data niet uniek gekoppeld kan worden aan de juiste functie-app.
Notitie
Hetzelfde soort host-ID-botsing kan optreden tussen een functie-app in een productieslot en dezelfde functie-app in een staging-slot, wanneer beide slots hetzelfde opslagaccount gebruiken.
In versie 4.x van de Functions-runtime wordt een fout gelogd en stopt de host, wat resulteert in een harde fout. Zie HostID Truncation kan conflicten veroorzaken voor meer informatie.
Host-id-conflicten voorkomen
Gebruik de volgende strategieën om botsingen met host-ID's te voorkomen:
- Gebruik aparte opslagaccounts zodat elke botsende host naar een ander account schrijft.
- Hernoem een van je functie-apps zodat de naam minder dan 32 tekens is, wat de berekende host-ID van de app verandert en de botsing verwijdert.
- 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. Bijvoorbeeld, een Blob Storage-trigger houdt bij welke afzonderlijke blobs het verwerkt door verwerkingsbewijzen 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
Je kunt een expliciete host-ID instellen voor je functie-app in de applicatie-instellingen door de AzureFunctionsWebHost__hostid instelling te gebruiken. Zie AzureFunctionsWebHost__hostid voor meer informatie.
Wanneer er een botsing plaatsvindt tussen slots, moet je voor elke slot een specifieke host-ID instellen, inclusief de productieslot. 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.
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 op Windows in een verbruiksabonnement, wordt er standaard een Azure Files share gemaakt in uw opslagaccount. Functies kunnen deze share gebruiken voor functies zoals logstreaming en als gedeelde locatie van app-inhoud. De implementatielocatie hangt af van de implementatietechnologie en de configuratie van de app. Bijvoorbeeld, een app die een externe pakket-URL gebruikt, draait zijn pakket vanaf de geconfigureerde URL in plaats van de Azure Files-deling.
Het gebruik van Azure Files vereist een verbindingsreeks, die je in je app-instellingen opslaat als WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Azure Files biedt momenteel geen ondersteuning voor op identiteit gebaseerde verbindingen. Als je scenario vereist dat je geen geheimen opslaat in de app-instellingen, moet je de afhankelijkheid van je app van Azure Files verwijderen. U kunt deze afhankelijkheid voorkomen door uw app te maken zonder de standaardafhankelijkheid Azure Files.
Notitie
Je zou ook moeten overwegen om je functie-app te draaien in het Flex Consumption-plan, dat meer controle biedt over het deployment-pakket, inclusief de mogelijkheid om managed identity-verbindingen te gebruiken. Zie Implementatie-instellingen configureren voor meer informatie.
Om je app zonder de Azure Files-share te draaien, moet je aan de volgende eisen voldoen:
Je moet je pakket uitrollen in een Azure Blob Storage-container die geen anonieme toegang toestaat, en de Blob Storage-URL van het pakket als app-instelling
WEBSITE_RUN_FROM_PACKAGEinstellen.Om te voorkomen dat je een implementatiecredential in de pakket-URL opslaat, verleen je de beheerde identiteit van de functie-app toegang tot het pakket. Wanneer je een door de gebruiker toegewezen beheerde identiteit gebruikt, stel ook
WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_IDin. Als je managed identity niet kunt gebruiken, gebruik dan een shared access signature (SAS) URL en verleng deze voordat de SAS verloopt.Om de verbindingsreeks voor het standaardhostopslagaccount uit je app-instellingen te verwijderen, configureer je
AzureWebJobsStoragedeze voor het gebruik van een beheerde identiteit.Je moet het deploymentpakket handmatig bijwerken en de URL van het deploymentpakket bijhouden. Voor informatie over het herstarten van de app en het synchroniseren van triggers bij het updaten van het pakket, zie Run from an external package URL.
Houd ook rekening met de volgende overwegingen:
- Je app kan niet vertrouwen op een gedeeld beschrijfbaar bestandssysteem.
- Portal bewerken wordt niet ondersteund.
- Logboekstreaming-ervaringen in clients, zoals de 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 rol vervolgens de app uit met behulp van het aangepaste sjabloon.
- Het Azure-portaal: schakel Een Azure Files-verbinding toevoegen uit op het tabblad Opslag wanneer u de app aanmaakt in het Azure-portaal.
Azure Files wordt gebruikt om dynamisch uitschalen in te schakelen voor Functions. Schaalaanpassing kan beperkt zijn wanneer u uw app zonder gebruik te maken van Azure Files uitvoert in het Elastic Premium-abonnement en in verbruiksplannen die op Windows draaien.
Flex Consumption is niet afhankelijk van een Azure Files-contentdeling. Het gebruikt configureerbare Blob-deployment-opslag en ondersteunt beheerde identiteitsverbindingen. Zie Implementatie-instellingen configureren voor meer informatie.
Dedicated plan-apps hebben niet de standaard Azure Files content-share afhankelijkheid zoals beschreven in deze sectie.
Functies in Azure Container Apps hebben niet de standaard Azure Files content-share afhankelijkheid zoals beschreven in deze sectie.
Bestandsshares koppelen
Deze functionaliteit is alleen beschikbaar wanneer het op Linux draait.
Je kunt Azure Files-shares mounten in je Linux-functie-apps, waarmee je bestaande bestanden, machine learning-modellen of grote binaries in je functies kunt benaderen. Zie Keuze van een strategie voor bestandstoegang voor Azure Functions voor conceptuele richtlijnen voor het kiezen tussen opslagkoppelingen, bindingen en externe databases.
Flex Consumption ondersteunt alleen Server Message Block (SMB) Azure Files-mounts.
Gebruik het volgende commando om een bestaande share te koppelen aan je Linux-functie-app.
az webapp config storage-account add
In deze opdracht is share-name 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 Maak een Python-functie-app en koppel een Azure Files share voor een volledig voorbeeld.
Voor Functions in Azure Container Apps, configureer je een Azure Files-volume in de containerapp. Zie Opslagkoppelingen gebruiken in Azure Container Apps voor meer informatie.
Opslagkoppelingen worden niet ondersteund in het Consumption-abonnement.
Belangrijk
Functie-apps die nog steeds de end-of-life v3-runtime op Linux uitvoeren in een verbruiksabonnement, worden na 30 september 2026 niet meer uitgevoerd. Als u serviceonderbreking wilt voorkomen, migreert u uw app naar de v4-runtime.
De optie voor het hosten van functie-apps in Linux in een verbruiksabonnement wordt op 30 september 2028 buiten gebruik gesteld. Het Linux Consumption-abonnement krijgt geen nieuwe functies of taalversies. Apps die worden uitgevoerd op Windows in een verbruiksabonnement, worden momenteel niet beïnvloed. Migreer uw apps naar het Flex Consumption-abonnement vóór de buitengebruikstellingsdatum.