Speicheraspekte für Azure Functions

  • Artikel

Azure Functions erfordert ein Azure Storage-Konto, wenn Sie eine Funktions-App-Instanz erstellen. Die folgenden Speicherdienste können von Ihrer Funktions-App genutzt werden:

Speicherdienst Verwendung in Functions
Azure Blob Storage Aufrechterhalten von Bindungszustand und Funktionsschlüsseln1.
Wird standardmäßig für Aufgabenhubs in Durable Functions verwendet.
Kann zum Speichern von Funktions-App-Code für den Remote-Build des Linux-Verbrauchs oder als Teil externer Paket-URL-Bereitstellungen verwendet werden.
Azure Files2 Dateifreigabe, die zum Speichern und Ausführen Ihres Funktions-App-Codes in einem Verbrauchstarif und Premium-Plan verwendet wird.
Azure Queue Storage Wird standardmäßig für Aufgabenhubs in Durable Functions verwendet. Wird für Fehler- und Wiederholungsbearbeitung in spezifischen Azure Functions-Auslösern verwendet. Wird vom Blob Storage-Trigger für die Objektnachverfolgung verwendet.
Azure Table Storage Wird standardmäßig für Aufgabenhubs in Durable Functions verwendet.

1 Blob Storage ist der Standardspeicher für Funktionsschlüssel, Sie können jedoch einen alternativen Speicher konfigurieren.

2 Azure Files wird standardmäßig eingerichtet, aber Sie können unter bestimmten Bedingungen eine App ohne Azure Files erstellen.

Wichtige Hinweise

Sie müssen die folgenden Fakten in Bezug auf die Speicherkonten berücksichtigen, die von Ihren Funktions-Apps verwendet werden:

  • Wenn Ihre Funktions-App im Verbrauchs- oder Premium-Plan gehostet wird, werden der Funktionscode und die Konfigurationsdateien in Azure Files im verknüpften Speicherkonto gespeichert. Wenn Sie dieses Hauptspeicherkonto löschen, wird der Inhalt ebenfalls gelöscht und kann nicht wiederhergestellt werden. Weitere Informationen finden Sie unter Speicherkonto wurde gelöscht.

  • Wichtige Daten, z. B. der Funktionscode, Zugriffsschlüssel und andere wichtige dienstbezogene Daten, können im Speicherkonto erhalten werden. Sie müssen den Zugriff auf die Speicherkonten, die von Funktions-Apps verwendet werden, wie folgt sorgfältig verwalten:

    • Überwachen und beschränken Sie den Zugriff von Apps und Benutzern auf das Speicherkonto anhand eines Modells der geringsten Rechte. Berechtigungen für das Speicherkonto können von Datenaktionen in der zugewiesenen Rolle oder über die Berechtigung zum Ausführen des listKeys-Vorgangs stammen.

    • Überwachen Sie sowohl Aktivitäten auf Steuerungsebene (z. B. das Abrufen von Schlüsseln) als auch Vorgänge auf Datenebene (z. B. Schreiben in einen Blob) in Ihrem Speicherkonto. Erwägen Sie, Speicherprotokolle an einem anderen Speicherort als Azure Storage zu verwalten. Weitere Informationen finden Sie unter Speicherprotokolle.

Anforderungen an das Speicherkonto

Speicherkonten, die im Rahmen der Erstellung der Funktions-App im Azure-Portal erstellt werden, funktionieren garantiert mit der neuen Funktions-App. Wenn Sie ein vorhandenes Speicherkonto verwenden, enthält die angegebene Liste keine bestimmten nicht unterstützten Speicherkonten. Die folgenden Einschränkungen gelten für Speicherkonten, die von Ihrer Funktions-App verwendet werden. Daher müssen Sie sicherstellen, dass ein vorhandenes Speicherkonto diese Anforderungen erfüllt:

  • Der Kontotyp muss Blob-, Warteschlangen- und Tabellenspeicher unterstützen. Einige Speicherkonten unterstützen keine Warteschlangen und Tabellen. Zu diesen Konten zählen reine Blobspeicherkonten und Azure Storage Premium. Weitere Informationen zu Speicherkontotypen finden Sie in der Übersicht über Azure Storage-Konten.

  • Sie können kein Speicherkonto verwenden, das bereits durch eine Firewall oder ein virtuelles privates Netzwerk gesichert ist, wenn Sie Ihre Funktions-App im Azure-Portal erstellen. Das Portal filtert diese gesicherten Speicherkonten derzeit jedoch nicht aus. Informationen zum Verwenden eines gesicherten Speicherkontos mit Ihrer Funktions-App finden Sie unter Verwenden eines gesicherten Speicherkontos mit Azure Functions.

  • Sie können gesicherte Speicherkonten nicht mit Funktions-Apps verwenden, die im Verbrauchsplan gehostet sind.

  • Wenn Sie Ihre Funktions-App im Portal erstellen, können Sie nur ein vorhandenes Speicherkonto auswählen, das sich in derselben Region wie die Funktions-App, die Sie erstellen, befindet. Dies dient der Leistungsoptimierung und ist keine strikte Einschränkung. Weitere Informationen finden Sie unter Standort des Speicherkontos.

  • Wenn Sie Ihre Funktions-App in einem Plan mit aktivierter Unterstützung für Verfügbarkeitszonen erstellen, werden nur zonenredundante Speicherkonten unterstützt.

Mithilfe der Bereitstellungsautomatisierung können Sie Funktions-Apps in einem Elastic Premium- oder Dedicated-Plan (App Service) erstellen. Sie müssen jedoch bestimmte Netzwerkkonfigurationen in Ihre ARM-Vorlage oder Bicep-Datei einschließen. Wenn Sie diese Einstellungen und Ressourcen nicht einschließen, schlägt ihre automatisierte Bereitstellung möglicherweise bei der Überprüfung fehl. Weitere Informationen finden Sie unter Gesicherte Bereitstellungen.

Speicherkontoanleitung

Jede Funktions-App benötigt für den Betrieb ein Speicherkonto. Wenn dieses Konto gelöscht wird, wird Ihre Funktions-App nicht ausgeführt. Informationen zur Behandlung speicherbezogener Probleme finden Sie unter Behandeln speicherbezogener Probleme. Die folgenden weiteren Überlegungen gelten für das von Funktions-Apps verwendete Speicherkonto.

Standort des Speicherkontos

Für eine optimale Leistung sollte Ihre Funktions-App ein Speicherkonto in derselben Region verwenden, um die Latenz zu verringern. Im Azure-Portal wird diese bewährte Methode erzwungen. Wenn Sie aus irgendeinem Grund ein Speicherkonto in einer anderen Region als Ihre Funktions-App verwenden möchten, müssen Sie Ihre Funktions-App außerhalb des Portals erstellen.

Die Funktions-App benötigt Zugriff auf das Speicherkonto. Wenn Sie ein gesichertes Speicherkonto verwenden müssen, sollten Sie Ihr Speicherkonto auf ein virtuelles Netzwerk beschränken.

Verbindungszeichenfolge für das Speicherkonto

Standardmäßig konfigurieren Funktions-Apps AzureWebJobsStorage-Verbindung als eine Verbindungszeichenfolge, die in der AzureWebJobsStorage-Anwendungseinstellung gespeichert ist. Sie können AzureWebJobsStorage aber auch so konfigurieren, dass eine identitätsbasierte Verbindung ohne Geheimnis verwendet wird.

Funktions-Apps, die in einem Verbrauchsplan (nur Windows) oder einem Elastic Premium Plan (Windows oder Linux) ausgeführt werden, können Azure Files verwenden, um für die Ermöglichung der dynamischen Skalierung die erforderlichen Images zu speichern. Legen Sie für diese Pläne die Verbindungszeichenfolge für das Speicherkonto in der Einstellung WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und den Namen der Dateifreigabe in der Einstellung WEBSITE_CONTENTSHARE fest. Dies ist in der Regel dasselbe Konto, das für AzureWebJobsStorage verwendet wird. Sie können auch eine Funktions-App erstellen, die Azure Files nicht verwendet, die Skalierung ist dann jedoch möglicherweise eingeschränkt.

Hinweis

Eine Verbindungszeichenfolgen für das Speicherkonto muss aktualisiert werden, wenn Sie Speicherschlüssel neu generieren. Erfahren Sie hier mehr über die Verwaltung von Speicherschlüsseln.

Freigegebene Speicherkonten

Es ist möglich, dass mehrere Funktions-Apps dasselbe Speicherkonto ohne Probleme gemeinsam nutzen. Beispielsweise können Sie in Visual Studio mit dem Azurite-Speicheremulator mehrere Apps entwickeln. In diesem Fall verhält sich der Emulator wie ein einzelnes Speicherkonto. Dasselbe Speicherkonto, das von Ihrer Funktions-App verwendet wird, kann auch von zum Speichern Ihrer Anwendungsdaten verwendet werden. Dieser Ansatz ist jedoch in einer Produktionsumgebung nicht immer eine gute Idee.

Möglicherweise müssen Sie separate Speicherkonten verwenden, um Host-ID-Kollisionen zu vermeiden.

Überlegungen zu Richtlinien für die Lebenszyklusverwaltung

Sie sollten keine Lebenszyklusverwaltungsrichtlinien auf das Blob Storage-Konto, das von Ihrer Funktions-App verwendet wird, anwenden. Functions verwendet Blobspeicher, um wichtige Informationen wie Funktionszugriffsschlüssel beizubehalten, und Richtlinien können Blobs (z. B. Schlüssel), die vom Funktionshost benötigt werden, entfernen. Wenn Sie Richtlinien verwenden müssen, schließen Sie Container, die von Functions verwendet werden und das Präfix azure-webjobs oder scm haben, aus.

Speicherprotokolle

Da Funktionscode und Schlüssel möglicherweise im Speicherkonto enthalten sind, ist die Aktivitätsprotokollierung für das Speicherkonto eine gute Möglichkeit, nicht autorisierten Zugriff festzustellen. Azure Monitor-Ressourcenprotokolle können verwendet werden, um Ereignisse auf der Speicherdatenebene nachzuverfolgen. Weitere Informationen zum Konfigurieren und Untersuchen dieser Protokolle finden Sie unter Überwachen von Azure Storage.

Das Azure Monitor-Aktivitätsprotokoll zeigt Ereignisse auf Steuerungsebene an, einschließlich des ListKeys-Vorgangs. Sie sollten jedoch auch Ressourcenprotokolle für das Speicherkonto konfigurieren, um die nachfolgende Verwendung von Schlüsseln oder anderen identitätsbasierten Vorgängen auf Datenebene nachzuverfolgen. Sie sollten mindestens die StorageWrite-Protokollkategorie aktiviert haben, damit Änderungen an den Daten außerhalb des normalen Funktionsvorgangs identifiziert werden können.

Um die potenziellen Auswirkungen von umfassenden Speicherberechtigungen zu begrenzen, sollten Sie ein Nicht-Storage-Ziel für diese Protokolle verwenden, z. B. Log Analytics. Weitere Informationen finden Sie unter Überwachen von Azure Blob Storage.

Optimieren der Speicherleistung

Verwenden Sie für jede Funktions-App ein separates Speicherkonto, um die Leistung zu maximieren. Dies ist besonders wichtig, wenn Sie über Durable Functions oder durch Event Hub ausgelöste Funktionen verfügen, die eine große Menge an Speichertransaktionen generieren. Wenn Ihre Anwendungslogik mit Azure Storage interagiert (direkt mit dem Storage SDK oder über eine der Speicherbindungen), sollten Sie ein dediziertes Speicherkonto verwenden. Wenn Sie z. B. über eine von Event Hub ausgelöste Funktion verfügen, die Daten in Blob Storage schreibt, verwenden Sie zwei Speicherkonten: eines für die Funktions-App und ein weiteres für die Blobs, die von der Funktion gespeichert werden.

Arbeiten mit Blobs

Ein wichtiges Szenario für Functions ist die Dateiverarbeitung von Dateien in einem Blobcontainer, z. B. für Bildverarbeitung oder Stimmungsanalyse. Weitere Informationen finden Sie unter Verarbeiten von Dateiuploads.

Trigger für einen Blobcontainer

Es gibt mehrere Möglichkeiten, den Funktionscode basierend auf Änderungen an Blobs in einem Speichercontainer auszuführen. Verwenden Sie die folgende Tabelle, um zu ermitteln, welcher Funktionstrigger Ihren Anforderungen am besten entspricht:

Aspekt Blob Storage (Abruf) Blob Storage (ereignisbasiert) Queue Storage Event Grid
Latency Hoch (bis zu 10 Min.) Niedrig Medium Niedrig
Einschränkungen des Speicherkontos Nur-Blob-Konten werden nicht unterstützt¹ Universell v1 wird nicht unterstützt none Universell v1 wird nicht unterstützt
Erweiterungsversion Any Storage v5.x oder höher Any Any
Verarbeitet vorhandene Blobs Ja Nr. Nr. Nein
Filter Blob-Namensmuster Ereignisfilter – Ereignisfilter
Erfordert Ereignisabonnement Nein Ja Keine Ja
Unterstützt hohe Skalierung² Nein Ja Ja Ja
BESCHREIBUNG Standardtriggerverhalten, das auf der Abfrage des Containers nach Updates basiert. Weitere Informationen finden Sie in den Beispielen in der Referenz zu Blob Storage-Triggern. Nutzt Blobspeicherereignisse aus einem Ereignisabonnement. Erfordert einen Source-Parameterwert von EventGrid. Weitere Informationen finden Sie im Tutorial: Auslösen von Azure Functions für Blobcontainer mithilfe eines Ereignisabonnements. Die Blobnamen-Zeichenfolge wird einer Speicherwarteschlange manuell hinzugefügt, wenn dem Container ein Blob hinzugefügt wird. Dieser Wert wird direkt von einem Queue Storage-Trigger an eine Blob Storage-Eingabebindung für dieselbe Funktion übergeben. Ermöglicht die flexible Auslösung bei Ereignissen, die nicht von einem Speichercontainer stammen. Verwenden Sie diese Option, wenn auch Nicht-Speicherereignisse Ihre Funktion auslösen sollen. Weitere Informationen finden Sie unter Arbeiten mit Event Grid-Triggern und -Bindungen in Azure Functions.

1 Eingabe- und -Ausgabebindungen für Blob Storage unterstützen reine Blobkonten.
2 Als „hohe Anzahl“ können lose Container mit mehr als 100.000 Blobs oder Speicherkonten mit mehr als 100 Blobupdates pro Sekunde definiert werden.

Speicherdatenverschlüsselung

Azure Storage verschlüsselt alle Daten in einem ruhenden Speicherkonto. Weitere Informationen finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.

Standardmäßig werden Daten mit von Microsoft verwalteten Schlüsseln verschlüsselt. Für eine zusätzliche Kontrolle über die Verschlüsselungsschlüssel können Sie vom Kunden verwaltete Schlüssel bereitstellen, mit denen Blob- und Dateidaten verschlüsselt werden können. Diese Schlüssel müssen in Azure Key Vault vorhanden sein, damit Functions auf das Speicherkonto zugreifen kann. Weitere Informationen finden Sie unter Verschlüsselung im Ruhezustand mithilfe von kundenseitig verwalteten Schlüsseln.

Data Residency in der Region

Wenn alle Kundendaten in einer einzelnen Region verbleiben müssen, muss das Speicherkonto, das der Funktions-App zugeordnet ist, eines mit regionsinterner Redundanz sein. Für Speicherkonten mit regionsinterner Redundanz muss auch Azure Durable Functions verwendet werden.

Andere plattformseitig verwaltete Kundendaten werden nur dann in der Region gespeichert, wenn sie in einer App Service-Umgebung (ASE) mit internem Lastenausgleich gehostet werden. Weitere Informationen finden Sie unter ASE-Zonenredundanz.

Überlegungen zur Host-ID

Funktionen verwenden einen Host-ID-Wert als Möglichkeit, eine bestimmte Funktions-App in gespeicherten Artefakten eindeutig zu identifizieren. Standardmäßig wird diese ID automatisch vom Namen der Funktions-App generiert, der auf die ersten 32 Zeichen abgeschnitten wird. Diese ID wird dann beim Speichern von Korrelations- und Nachverfolgungsinformationen pro App im verknüpften Speicherkonto verwendet. Wenn Sie Funktions-Apps mit Namen mit mehr als 32 Zeichen haben und wenn die ersten 32 Zeichen identisch sind, kann diese Abkürzung zu doppelten Host-ID-Werten führen. Wenn zwei Funktions-Apps mit identischen Host-IDs dasselbe Speicherkonto verwenden, erhalten Sie eine Host-ID-Kollision, da gespeicherte Daten nicht eindeutig mit der richtigen Funktions-App verknüpft werden können.

Hinweis

Die gleiche Art von Host-ID-Kollision kann zwischen einer Funktions-App in einem Produktionsslot und der gleichen Funktions-App in einem Stagingslot auftreten, wenn beide Slots das gleiche Speicherkonto verwenden.

Ab Version 3.x der Funktions-Runtime wird die Host-ID-Kollision erkannt und eine Warnung protokolliert. In Version 4.x wird ein Fehler protokolliert, und der Host wird beendet, was zu einem schweren Fehler führt. Weitere Informationen zur Host-ID-Kollision finden Sie in diesem Problem.

Vermeiden von Host-ID-Kollisionen

Sie können die folgenden Strategien verwenden, um Host-ID-Kollisionen zu vermeiden:

  • Verwenden Sie ein getrenntes Speicherkonto für jede Funktions-App oder jeden Slot, die bzw.der an der Kollision beteiligt ist.
  • Benennen Sie eine Ihrer Funktionsanwendungen in einen Wert um, der weniger als 32 Zeichen lang ist. Dadurch wird die berechnete Host-ID für die App geändert und die Kollision beseitigt.
  • Legen Sie eine explizite Host-ID für eine oder mehrere der kollidierenden Apps fest. Weitere Informationen finden Sie unter Außerkraftsetzung der Host-ID.

Wichtig

Das Ändern des Speicherkontos, das einer vorhandenen Funktions-App zugeordnet ist, oder das Ändern der Host-ID der App kann sich auf das Verhalten vorhandener Funktionen auswirken. Beispielsweise verfolgt ein Blob-Storage-Trigger nach, ob einzelne Blobs verarbeitet werden, indem er Bestätigungen unter einem bestimmten Host-ID-Pfad im Speicher schreibt. Wenn sich die Host-ID ändert oder Sie auf ein neues Speicherkonto verweisen, könnten zuvor verarbeitete Blobs erneut verarbeitet werden.

Außerkraftsetzung der Host-ID

Sie können mithilfe der Einstellung AzureFunctionsWebHost__hostid explizit eine bestimmte Host-ID für Ihre Funktions-App in den Anwendungseinstellungen festlegen. Weitere Informationen finden Sie unter AzureFunctionsWebHost__hostid.

Wenn die Kollision zwischen Slots auftritt, müssen Sie eine spezifische Host-ID für jeden Slot festlegen, einschließlich des Produktionsslots. Sie müssen diese Einstellungen auch als Bereitstellungseinstellungen markieren, damit sie nicht ausgetauscht werden. Informationen zum Erstellen von App-Einstellungen finden Sie unter Arbeiten mit Anwendungseinstellungen.

Cluster mit Azure Arc-Unterstützung

Wenn Ihre Funktions-App in einem Kubernetes-Cluster mit Azure Arc-Unterstützung bereitgestellt wird, ist möglicherweise kein Speicherkonto für Ihre Funktions-App erforderlich. In diesem Fall ist nur ein Speicherkonto für Functions erforderlich, wenn Ihre Funktions-App einen Trigger verwendet, der Speicher erfordert. In der folgenden Tabelle ist angegeben, welche Trigger möglicherweise ein Speicherkonto erfordern und welche nicht:

Nicht erforderlich Speicher möglicherweise erforderlich
• Azure Cosmos DB
• HTTP
• Kafka
• RabbitMQ
• Service Bus		 • Azure SQL
• Blob Storage
• Event Grid
• Event Hubs
• IoT Hub
• Queue Storage
• SendGrid
• SignalR
• Table Storage
• Timer
• Twilio

Um eine Funktions-App in einem Kubernetes-Cluster mit Azure Arc-Unterstützung ohne Speicher zu erstellen, müssen Sie den Azure CLI-Befehl az functionapp create verwenden. Die Version der Azure CLI muss mindestens Version 0.1.7 der Erweiterung appservice-kube enthalten. Verwenden Sie den Befehl az --version, um zu überprüfen, ob die richtige Version der Erweiterung installiert ist.

Das Erstellen Ihrer Funktions-App-Ressourcen mit anderen Methoden als der Azure CLI erfordert ein vorhandenes Speicherkonto. Wenn Sie beabsichtigen, Trigger zu verwenden, die ein Speicherkonto erfordern, sollten Sie das Konto erstellen, bevor Sie die Funktions-App erstellen.

Erstellen einer App ohne Azure Files

Azure Files wird standardmäßig für Elastic Premium und Nicht-Linux-Verbrauchspläne eingerichtet, um als freigegebenes Dateisystem in Szenarien mit hoher Skalierung zu dienen. Das Dateisystem wird von der Plattform für einige Features wie Protokollstreaming verwendet, stellt aber in erster Linie die Konsistenz der bereitgestellten Funktionsnutzdaten sicher. Wenn eine App mithilfe einer externen Paket-URL bereitgestellt wird, wird der App-Inhalt von einem separaten schreibgeschützten Dateisystem bereitgestellt. Dies bedeutet, dass Sie Ihre Funktions-App ohne Azure Files erstellen können. Wenn Sie Ihre Funktions-App mit Azure Files erstellen, wird weiterhin ein schreibbares Dateisystem bereitgestellt. Dieses Dateisystem ist jedoch möglicherweise nicht für alle Funktions-App-Instanzen verfügbar.

Wenn Azure Files nicht verwendet wird, müssen Sie die folgenden Anforderungen erfüllen:

  • Sie müssen die Bereitstellung über eine externe Paket-URL ausführen.
  • Ihre App kann sich nicht auf ein freigegebenes beschreibbares Dateisystem verlassen.
  • Die App kann nicht Version 1.x der Functions-Runtime verwenden.
  • Für Protokollstreaming in Clients wie dem Azure-Portal werden standardmäßig Dateisystemprotokolle verwendet. Sie sollten stattdessen Application Insights-Protokolle verwenden.

Wenn die oben genannten Punkte ordnungsgemäß berücksichtigt werden, könnten Sie die App ohne Azure Files erstellen. Erstellen Sie die Funktions-App, ohne die Anwendungseinstellungen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE anzugeben. Sie können diese Einstellungen vermeiden, indem Sie eine ARM-Vorlage für eine Standardbereitstellung generieren, diese beiden Einstellungen entfernen und die Vorlage dann bereitstellen.

Da Functions Azure Files in Teilen der dynamischen horizontalen Skalierung verwendet, kann die Skalierung eingeschränkt werden, wenn die Ausführung ohne Azure Files in Verbrauchs- und Elastic Premium Plänen erfolgt.

Einbinden von Dateifreigaben

Diese Funktion ist derzeit nur unter Linux verfügbar.

Sie können vorhandene Azure Files-Freigaben in Ihre Linux-Funktions-Apps einbinden. Durch das Einbinden einer Freigabe in Ihre Linux-Funktions-App können Sie vorhandene Machine Learning-Modelle oder andere Daten in Ihren Funktionen verwenden. Sie können den folgenden Befehl verwenden, um eine vorhandene Freigabe in Ihre Linux-Funktions-App einzubinden.

az webapp config storage-account add

Bei diesem Befehl ist share-name der Name der vorhandenen Azure Files-Freigabe, und custom-id kann ein beliebige Zeichenfolge sein, mit der die Freigabe bei der Einbindung in die Funktions-App eindeutig definiert wird. mount-path ist der Pfad, über den in Ihrer Funktions-App auf die Freigabe zugegriffen wird. mount-path muss das Format /dir-name haben und darf nicht mit /home beginnen.

Ein vollständiges Beispiel finden Sie in den Skripts unter Einbinden einer Dateifreigabe in eine Python-Funktions-App mithilfe der Azure CLI.

Derzeit wird als storage-type nur AzureFiles unterstützt. Sie können pro Funktions-App nicht mehr als fünf Freigaben einbinden. Durch die Einbindung einer Dateifreigabe kann sich die Kaltstartdauer ggf. um mindestens 200 bis 300 ms verlängern. Dieser Wert ist noch höher, wenn sich das Speicherkonto in einer anderen Region befindet.

Die eingebundene Freigabe ist für Ihren Funktionscode unter dem angegebenen mount-path verfügbar. Wenn mount-path beispielsweise /path/to/mount lautet, können Sie wie im folgenden Python-Beispiel über Dateisystem-APIs auf das Zielverzeichnis zugreifen:

import os
...

files_in_share = os.listdir("/path/to/mount")

Nächste Schritte

Weitere Informationen zu Hostingoptionen von Azure Functions.

Skalierung und Hosting von Azure Functions