Freigeben über

Bereitstellungstechnologien in Azure Functions

Sie können verschiedene Technologien verwenden, um Ihren Azure Functions Projektcode für Azure bereitzustellen. Dieser Artikel bietet eine Übersicht über die für Sie verfügbaren Bereitstellungsmethoden sowie Empfehlungen für in den jeweiligen verschiedenen Szenarien zu verwendende beste Methode. Darüber hinaus enthält sie eine umfassende Liste und wichtige Details zu den zugrunde liegenden Bereitstellungstechnologien.

Bereitstellungsmethoden

Die Bereitstellungstechnologie, die Sie zum Veröffentlichen von Code in Ihrer Funktions-App in Azure verwenden, hängt von Ihren spezifischen Anforderungen und dem Punkt im Entwicklungszyklus ab. Beispielsweise können Sie während der Entwicklung und beim Testen direkt aus Ihrem Entwicklungstool bereitstellen, z. B. Visual Studio Code. Wenn sich Ihre App in der Produktionsphase befindet, verwenden Sie zur kontinuierlichen Veröffentlichung wahrscheinlich eher die Quellcodeverwaltung oder eine automatisierte Veröffentlichungspipeline, die zusätzliche Validierungs- und Testvorgänge umfassen kann.

In der folgenden Tabelle werden die verfügbaren Bereitstellungsmethoden für Ihr Codeprojekt beschrieben.

Bereitstellungstyp Methoden Am besten geeignet für:
Toolsbasiert • Azure CLI
• Visual Studio Code veröffentlichen
• Visual Studio veröffentlichen
• Veröffentlichung in Core Tools		 Bereitstellungen während der Entwicklung und andere improvisierte Bereitstellungen. Bereitstellen des Codes bei Bedarf mithilfe lokaler Entwicklungstools.
Von App Service verwaltet • Bereitstellungscenter (CI/CD)
• Containerbereitstellungen		 Continuous Deployment (CI/CD) aus der Quellcodeverwaltung oder aus einer Containerregistrierung. Die App Service-Plattform (Kudu) verwaltet Bereitstellungen.
Externe Pipelines • Azure Pipelines
• GitHub Actions		 Produktionspipelinen, die Validierung, Tests und andere Aktionen umfassen, die als Teil einer automatisierten Bereitstellung ausgeführt werden müssen. Die Pipeline verwaltet Bereitstellungen.

Verwenden Sie die beste Technologie für Ihr spezifisches Szenario. Viele Bereitstellungsmethoden basieren auf der ZIP-Bereitstellung, die für die Bereitstellung empfohlen wird.

Bereitstellungstechnologie: Verfügbarkeit

Die Bereitstellungsmethode hängt auch von Ihrem Hostingplan sowie von dem Betriebssystem ab, unter dem Sie Ihre Funktions-App ausführen.

Derzeit bietet Functions fünf Optionen zum Hosten Ihrer Funktions-Apps:

Jeder Plan weist ein anderes Verhalten auf. Nicht alle Bereitstellungstechnologien sind für jeden Hostingplan und jedes Betriebssystem verfügbar. Im folgenden Diagramm finden Sie Informationen zu den unterstützten Bereitstellungstechnologien:

Bereitstellungstechnologie Flex-Verbrauch Nutzung Elastic Premium Dediziert Container-Apps
OneDeploy ✔
ZIP-Bereitstellung ✔ ✔ ✔
Externe Paket-URL1 ✔ ✔ ✔
Docker-Container Nur Linux Nur Linux Nur Linux ✔
Quellcodeverwaltung nur Windows ✔ ✔
Lokales Git1 nur Windows ✔ ✔
FTPS1 nur Windows ✔ ✔
Bearbeitung im Portal2 ✔ ✔ ✔

1 Bereitstellungstechnologien, die eine manuelle Synchronisierung von Triggern erfordern, werden nicht empfohlen.
2 Die Bearbeitung im Portal ist deaktiviert, wenn Code von außerhalb des Portals in Ihrer Funktions-App bereitgestellt wird. Weitere Informationen, einschließlich Details zur Sprachunterstützung für die Bearbeitung im Portal, finden Sie unter Sprachunterstützungsdetails.

Wichtige Begriffe

Einige wichtige Konzepte sind wichtig, um zu verstehen, wie Bereitstellungen in Azure Functions funktionieren.

Triggersynchronisierung

Wenn Sie einen Trigger ändern, muss die Infrastruktur von Functions über die vorgenommenen Änderungen informiert werden. Die Synchronisierung erfolgt bei vielen Bereitstellungstechnologien automatisch. Manchmal müssen die Trigger jedoch manuell synchronisiert werden.

Sie müssen Trigger immer manuell synchronisieren, wenn Sie diese Bereitstellungsoptionen verwenden:

Sie können Trigger auf eine der folgenden Arten manuell synchronisieren:

  • Starten Sie ihre Funktions-App im Azure-Portal neu. Der Functions-Host führt eine Synchronisierung des Hintergrundtriggers aus, nachdem die Anwendung gestartet wurde.

  • Verwenden Sie den Befehl az rest, um eine HTTP POST-Anforderung zu senden, die die syncfunctiontriggers-API aufruft, wie im folgenden Beispiel gezeigt:

    az rest --method post --url https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>/syncfunctiontriggers?api-version=2016-08-01

Beachten Sie diese Überlegungen für den Synchronisierungsauslöservorgang:

  • Sie müssen Ihre Funktions-App jedes Mal manuell neu starten, wenn Sie eine aktualisierte Version des Bereitstellungspakets mithilfe derselben externen Paket-URL bereitstellen.
  • Für Apps, die in einem Verbrauchs- oder Elastic Premium-Plan ausgeführt werden, müssen Sie in diesen Szenarien auch trigger manuell synchronisieren :
    • Wenn Bereitstellungen eine externe Paket-URL in einer durch den Ressourcen-Manager gesteuerten Bereitstellung unter Verwendung von ARM-Vorlagen, Bicep-Dateien oder Terraform-Dateien nutzen.
    • Wenn Sie das Paket für die Bereitstellung in-Place aktualisieren, indem Sie dieselbe externe Paket-URL verwenden.
  • Wenn Sie einer vorhandenen Funktions-App Netzwerkeinschränkungen hinzufügen, müssen Sie die Konnektivität mit dem standardmäßigen Hostspeicherkonto garantieren, das in der AzureWebJobsStorage App-Einstellung festgelegt ist. Weitere Informationen finden Sie unter How to use a secured storage account with Azure Functions.

Remotebuild

Sie können veranlassen, dass Azure Functions während der Bereitstellung einen Remotebuild Ihres Codeprojekts ausführt. Fordern Sie in diesen Szenarien einen Remotebuild an, anstatt lokal zu erstellen:

  • Sie stellen eine App in einer Linux-basierten Funktionsanwendung bereit, die Sie auf einem Windows-Computer entwickelt haben. Diese Situation ist in der Regel bei Python App-Entwicklung der Fall. Wenn Sie das Bereitstellungspaket lokal unter Windows erstellen, können dabei falsche Bibliotheken verwendet werden.
  • Ihr Projekt verfügt über Abhängigkeiten zu einem benutzerdefinierten Paketindex.
  • Sie möchten die Größe Ihres Bereitstellungspakets verringern.

Wie Sie einen Remotebuild anfordern, hängt davon ab, ob Ihre App in Azure auf Windows oder Linux ausgeführt wird.

Alle auf Windows ausgeführten Funktions-Apps verfügen über eine kleine Verwaltungs-App, die scm-Website, die von Kudu bereitgestellt wird. Diese Website behandelt einen Großteil der Bereitstellungs- und Buildlogik für Azure Functions.

Wenn Sie eine App für Windows bereitstellen, führt der Bereitstellungsprozess sprachspezifische Befehle aus, z. B. dotnet restore (C#) oder npm install (JavaScript).

Die folgenden Überlegungen gelten für die Verwendung von Remotebuilds während der Bereitstellung:

  • Remotebuilds werden für Funktions-Apps unterstützt, die unter Linux im Verbrauchsplan ausgeführt werden. Die Bereitstellungsoptionen sind jedoch für diese Apps eingeschränkt, da sie keine (Kudu)-Website haben scm.
  • Funktions-Apps, die unter Linux in einem Premium-Plan oder in einem Dedicated (App Service)-Plan ausgeführt werden, verfügen über eine scm (Kudu)-Site, sind jedoch im Vergleich zu Windows eingeschränkt.
  • Remote-Builds werden nicht ausgeführt, wenn eine App run-from-package verwendet. Wie Sie in diesen Fällen Remotebuilds verwenden können, erfahren Sie unter Zip-Bereitstellung.
  • Möglicherweise treten Probleme mit dem Remotebuild auf, wenn Ihre App erstellt wurde, bevor das Feature verfügbar gemacht wurde (1. August 2019). Erstellen Sie für ältere Apps entweder eine neue Funktions-App, oder führen Sie az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> aus, um Ihre Funktions-App zu aktualisieren. Dieser Befehl kann zwei Versuche in Anspruch nehmen, bis er erfolgreich ist.

App-Inhaltsspeicher

Paketbasierte Bereitstellungsmethoden speichern das Paket im Speicherkonto, das der Funktions-App zugeordnet ist, die von der AzureWebJobsStorage-Einstellung definiert wird. Wenn verfügbar, versuchen Verbrauchstarif- und Elastic Premium-Plan Apps, die Inhaltsfreigabe von Azure Files über dieses Konto zu verwenden; Sie können das Paket jedoch auch an einem anderen Speicherort verwalten. Flex-Verbrauchsplan-Apps verwenden einen Speichercontainer im Standardspeicherkonto, es sei denn, Sie konfigurieren ein anderes Speicherkonto für die Bereitstellung. Weitere Informationen finden Sie unter Speicherort von App-Inhalten zu den einzelnen Bereitstellungstechnologien, die im nächsten Abschnitt behandelt werden.

Wichtig

Das Speicherkonto wird verwendet, um wichtige App-Daten zu speichern, manchmal einschließlich des Anwendungscodes. Sie sollten den Zugriff von anderen Anwendungen und benutzenden Personen auf das Speicherkonto einschränken.

Gesicherte virtuelle Netzwerke

Wenn Ihre Funktions-App private Endpunkte aktiviert hat und der Zugriff auf öffentliche Netzwerke deaktiviert ist, ist die scm (Kudu)-Bereitstellungswebsite nicht öffentlich erreichbar. Wenn das von der Funktions-App verwendete Speicherkonto auch hinter privaten Endpunkten gesichert ist, werden Technologien, die auf den Speicher zugreifen müssen, ähnlich blockiert. Aufgrund dieser Einschränkungen können die in diesem Artikel beschriebenen Bereitstellungstechnologien keine vollständig netzwerkgeschützte Funktions-App außerhalb des virtuellen Netzwerks erreichen.

Um Code in einer netzwerksicherten Funktions-App bereitzustellen, muss Ihre Bereitstellungs-Tools über eine Konnektivität mit dem virtuellen Netzwerk verfügen. Sie können diese Konnektivität auf folgende Weise erreichen:

Weitere Informationen zum Konfigurieren Ihrer Funktions-App in einem virtuellen Netzwerk finden Sie unter Wie sie Azure Functions mit einem virtuellen Netzwerk konfigurieren.

Bereitstellungstechnologie: Details

Die folgenden Bereitstellungsmethoden sind in Azure Functions verfügbar. Informationen dazu, welche Technologien jeder Hostingplan unterstützt, finden Sie in der Bereitstellungstechnologieverfügbarkeitstabelle .

OneDeploy

OneDeploy (eine Bereitstellung) ist die einzige Bereitstellungstechnologie, die für Apps mit Flex-Verbrauchs-Plan unterstützt wird. Das Endergebnis ist ein ausführungsbereites ZIP-Paket, in dem Ihre Funktions-App ausgeführt wird.

So verwenden Sie es: Bereitstellen durch Nutzung der Veröffentlichungsfunktion von Visual Studio Code, oder von der Befehlszeile aus mithilfe der Azure Functions Core Tools oder des Azure CLI. Unsere Azure Dev Ops Task und GitHub Action nutzen eine ähnliche Bereitstellung, wenn sie erkennen, dass eine Flex Consumption App bereitgestellt wird.

Wenn Sie eine Flex-Verbrauchs-App erstellen, müssen Sie einen Speichercontainer (Blob) für die Bereitstellung sowie eine Authentifizierungsmethode angeben. Standardmäßig wird dasselbe Speicherkonto wie die AzureWebJobsStorage-Verbindung verwendet, wobei eine Verbindungszeichenfolge als Authentifizierungsmethode verwendet wird. Daher werden Ihre Bereitstellungseinstellungen während der App-Erstellung konfiguriert, ohne dass Anwendungseinstellungen erforderlich sind.

Anwendungsfälle: OneDeploy ist die einzige Bereitstellungstechnologie, die für Funktions-Apps verfügbar ist, die mit einem Flex-Verbrauchs-Plan ausgeführt werden.

Speicherort von App-Inhalten: Wenn Sie eine Funktions-App mit Flex-Verbrauchs-Plan erstellen, geben Sie einen Speichercontainer für die Bereitstellung an. In diesem BLOB-Container laden Ihre Tools den bereitgestellten App-Inhalt hoch. Um den Standort zu ändern, können Sie das Blatt "Bereitstellungseinstellungen" im Azure-Portal besuchen oder das Azure CLI verwenden.

Tipp

Ein Flex Consumption Deployment Diagnosetool ist im Azure-Portal verfügbar. Öffnen Sie Ihre Flex Consumption-App, wählen Sie "Diagnostizieren und Lösen von Problemen" aus, und suchen Sie nach Flex Consumption Deployment. Dieses Tool zeigt detaillierte Informationen zu Ihren Bereitstellungen an, einschließlich Bereitstellungsverlauf, Paketstatus und Problembehandlungsempfehlungen.

ZIP-Bereitstellung

Die ZIP-Bereitstellung ist die empfohlene Bereitstellungstechnologie und die Standardtechnologie für Funktions-Apps mit Verbrauchs-, Elastic Premium- und App Service-Plan (Dedicated). Das Endergebnis ist ein ausführungsbereites ZIP-Paket, in dem Ihre Funktions-App ausgeführt wird. Es unterscheidet sich von der externen Paket-URL darin, dass die Plattform für die Remoteerstellung und das Speichern Von App-Inhalten verantwortlich ist.

So verwenden Sie es: Bereitstellen mithilfe Ihres bevorzugten Clienttools: Visual Studio Code, Visual Studio oder über die Befehlszeile mit Azure Functions Core Tools oder dem Azure CLI. Unsere Azure Dev Ops Task und GitHub Action nutzen ebenso zip deploy.

Wenn die Bereitstellung mithilfe der ZIP-Bereitstellung erfolgt, können Sie die App auf Run from Package (Aus Paket ausführen) festlegen. Zur Ausführung über ein Paket legen Sie den Wert der Anwendungseinstellung WEBSITE_RUN_FROM_PACKAGE auf 1 fest. Wir empfehlen die ZIP-Bereitstellung. Es führt zu schnelleren Ladezeiten für Ihre Anwendungen, und es ist die Standardeinstellung für VS Code, Visual Studio und die Azure CLI.

Wann es verwendet werden sollte: Zip-Bereitstellung ist die Standard- und empfohlene Bereitstellungstechnologie für Funktions-Apps in den Windows Consumption- und den Windows- und Linux Elastic Premium- sowie Windows- und Linux App Service (dedizierten) Plänen.

Wo App-Inhalt gespeichert wird: App-Inhalt aus einer ZIP-Bereitstellung wird standardmäßig im Dateisystem gespeichert, das Azure möglicherweise von Azure Files aus dem Speicherkonto zurückgibt, das Sie beim Erstellen der Funktions-App angeben. In Linux-Verbrauch wird der App-Inhalt stattdessen auf einem Blob in dem Storage-Konto persistiert, das durch die AzureWebJobsStorage App-Einstellung festgelegt wurde, und die App-Einstellung WEBSITE_RUN_FROM_PACKAGE übernimmt den Wert der Blob-URL.

Externe Paket-URL

Die URL des externen Pakets ist eine Option, wenn Sie manuell steuern möchten, wie Bereitstellungen ausgeführt werden. Sie sind verantwortlich für das Hochladen eines ausführungsbereiten ZIP-Pakets mit Ihren erstellten App-Inhalten in Blob Storage und müssen auf diese externe URL in einer Anwendungseinstellung Ihrer Funktions-App verweisen. Wenn Ihre App neu gestartet wird, ruft sie jedes Mal das Paket ab, bindet es ein und führt es im Modus Aus Paket ausführen aus.

Verwendung: Fügen Sie Ihren Anwendungseinstellungen WEBSITE_RUN_FROM_PACKAGE hinzu. Der Wert dieser Einstellung sollte eine Blob-URL sein, die auf den Speicherort des spezifischen Pakets zeigt, das Ihre App ausführen soll. Sie können Einstellungen entweder im Portal hinzufügen oder mithilfe der Azure CLI hinzufügen.

Wenn Sie Azure Blob Storage verwenden, kann Ihre Funktions-App entweder über eine verwaltete identitätsbasierte Verbindung oder mit einer shared access signature (SAS) auf den Container zugreifen. Die von Ihnen ausgewählte Option wirkt sich darauf aus, welche Art von URL Sie als Wert für WEBSITE_RUN_FROM_PACKAGE verwenden. Verwaltete Identitäten werden für die allgemeine Sicherheit empfohlen. Außerdem müssen SAS-Token, da sie ablaufen, manuell verwaltet werden.

Wenn Sie die Paketdatei bereitstellen, auf die eine Funktions-App verweist, müssen Sie Auslöser manuell synchronisieren, einschließlich der ersten Bereitstellung. Wenn Sie den Inhalt der Paketdatei ändern und nicht die URL selbst, müssen Sie auch Ihre Funktions-App neu starten, um die Auslöser zu synchronisieren. Weitere Informationen zum Konfigurieren dieser Bereitstellungstechnologie finden Sie in der Schrittanleitung.

Anwendungsfälle: Die URL des externen Pakets ist die einzige unterstützte Bereitstellungsmethode für Apps, die unter Linux mit Verbrauchs-Plan ausgeführt werden, wenn kein Remotebuild ausgeführt werden soll. Diese Methode ist auch die empfohlene Bereitstellungstechnologie, wenn Sie Ihre App create your app ohne Azure Files erstellen. Für skalierbare Apps, die unter Linux ausgeführt werden, sollten Sie stattdessen für das Hosting den Flex-Verbrauchs-Plans in Betracht ziehen.

Speicherort von App-Inhalten: Sie sind für das Hochladen von App-Inhalten in Blob Storage verantwortlich. Sie können jedes BLOB-Speicherkonto verwenden, obwohl Azure Blob Storage empfohlen wird.

Docker-Container

Sie können eine Funktions-App bereitstellen, die in einem Linux-Container ausgeführt wird.

Wie sie verwendet werden kann: Erstellen Sie Ihre Funktionen in einem Linux-Container stellen Sie dann den Container in einem Premium- oder Dedizierten Plan in Azure Functions oder einem anderen Containerhost bereit. Verwenden Sie die Azure Functions Core Tools, um eine benutzerdefinierte Dockerfile-Datei für Ihr Projekt zu erstellen, die Sie zum Erstellen einer containerisierten Funktions-App verwenden. Sie können den Container in den folgenden Bereitstellungen verwenden:

Einsatzgebiete: Verwenden Sie die Option „Docker-Container“, wenn Sie mehr Kontrolle über die Linux-Umgebung benötigen, in der Ihre Funktions-App ausgeführt wird und in der der Container gehostet ist. Dieser Bereitstellungsmechanismus steht nur für Funktionen unter Linux zur Verfügung.

Wo App-Inhalte gespeichert werden: Sie speichern App-Inhalte in der angegebenen Containerregistrierung als Teil des Images.

Quellcodeverwaltung

Sie können die kontinuierliche Integration zwischen Ihrer Funktions-App und einem Quellcode-Repository aktivieren. Wenn Sie die Quellcodeverwaltung aktivieren, löst eine Aktualisierung des Codes im verbundenen Quell-Repository die Bereitstellung des neuesten Codes aus dem Repository aus. Weitere Informationen finden Sie in der kontinuierlichen Bereitstellung für Azure Functions.

Verwendung : Die einfachste Möglichkeit zum Einrichten der Veröffentlichung aus der Quellcodeverwaltung stammt aus dem Bereitstellungscenter im Bereich "Funktionen" des Portals. Weitere Informationen finden Sie unter Continuous deployment for Azure Functions.

Einsatzgebiete: Die Verwendung von Quellcodeverwaltung ist die bewährte Methode für Teams, die an ihren Funktions-Apps zusammenarbeiten. Quellcodeverwaltung ist eine gute Bereitstellungsoption, die anspruchsvollere Bereitstellungspipelines ermöglicht. In der Regel aktivieren Sie die Quellcodeverwaltung auf einem Stagingplatz, den Sie nach der Überprüfung von Updates aus dem Repository in die Produktion tauschen können. Weitere Informationen finden Sie unter Azure Functions Deployment Slots.

Wo App-Inhalte gespeichert werden: Das Quellcodeverwaltungssystem speichert den App-Inhalt. Das App-Dateisystem speichert lokal geklonte und erstellte App-Inhalte, die möglicherweise von Azure Files aus dem bei der Erstellung der Funktions-App angegebenen Speicherkonto unterstützt werden.

Lokales Git

Verwenden Sie lokale Git, um Code von Ihrem lokalen Computer mithilfe von Git an Azure Functions zu übertragen.

Wie verwenden Sie es: Befolgen Sie die Anweisungen unter Lokale Git-Bereitstellung zu Azure App Service.

Wann sie verwendet werden soll: Um die Wahrscheinlichkeit von Fehlern zu verringern, vermeiden Sie die Verwendung von Bereitstellungsmethoden, die den zusätzlichen Schritt der manuellen Synchronisierung von Triggern erfordern. Verwenden Sie nach Möglichkeit die ZIP-Bereitstellung.

Wo App-Inhalte gespeichert sind: App-Inhalte werden im Dateisystem gespeichert, die möglicherweise von Azure Files aus dem Speicherkonto gesichert werden, das Sie beim Erstellen der Funktions-App angeben.

FTP/S

Sie können FTP/S verwenden, um Dateien direkt an Azure Functions zu übertragen, aber verwenden Sie diese Bereitstellungsmethode nicht. Wenn Sie nicht planen, FTP zu verwenden, deaktivieren Sie sie. Wenn Sie FTP verwenden möchten, erzwingen Sie FTPS. Informationen dazu finden Sie im Azure-Portal unter Enforce FTPS.

So verwenden Sie sie: Befolgen Sie die Anweisungen in den FTPS-Bereitstellungseinstellungen , um die URL und Anmeldeinformationen abzurufen, die Sie für die Bereitstellung in Ihrer Funktions-App mithilfe von FTPS verwenden können.

Wann sie verwendet werden soll: Um die Wahrscheinlichkeit von Fehlern zu verringern, vermeiden Sie die Verwendung von Bereitstellungsmethoden, die den zusätzlichen Schritt der manuellen Synchronisierung von Triggern erfordern. Verwenden Sie nach Möglichkeit die ZIP-Bereitstellung.

Wo App-Inhalte gespeichert werden: App-Inhalte werden im Dateisystem gespeichert. FTP/FTPS-Bereitstellungen schlagen fehl, wenn das Dateisystem Ihrer App durch Azure Files im Standardspeicherkonto des Host unterstützt wird. FTP/FTPS schlägt mit Azure Files als eingehängtem Speicher aufgrund von FTP-Einschränkungen fehl.

Portalbearbeitung

Im portalbasierten Editor können Sie die Dateien, die sich in ihrer Funktions-App befinden, direkt bearbeiten (im Wesentlichen erfolgt die Bereitstellung bei jedem Speichern der Änderungen).

Wie Sie es verwenden: Um Ihre Funktionen im Azure-Portal zu bearbeiten, müssen Sie Ihre Funktionen im Portal erstellen. Bei Verwendung einer anderen Bereitstellungsmethode wird Ihre Funktion schreibgeschützt und kann nicht mehr über das Portal bearbeitet werden, um eine zentrale zuverlässige Datenquelle (Single Source Of Truth, SSOT) zu gewährleisten. Um zu einem Zustand zurückzukehren, in dem Sie Ihre Dateien im Azure-Portal bearbeiten können, können Sie den Bearbeitungsmodus manuell auf Read/Write zurücksetzen und alle bereitstellungsbezogenen Anwendungseinstellungen (z. B. WEBSITE_RUN_FROM_PACKAGE) entfernen.

Wann verwenden: Das Portal ist eine gute Möglichkeit, um mit Azure Functions zu beginnen. Aufgrund Entwicklungseinschränkungen im Azure Portal sollten Sie eines der folgenden Clienttools verwenden, um erweiterte Entwicklungsaufgaben zu erledigen:

Wo App-Inhalte gespeichert sind: App-Inhalte werden im Dateisystem gespeichert, die möglicherweise von Azure Files aus dem Speicherkonto gesichert werden, das Sie beim Erstellen der Funktions-App angeben.

Bereitstellungsverhalten

Wenn Sie Updates für Ihren Funktions-App-Code bereitstellen, hängt das Bereitstellungsverhalten von Ihrem Hostingplan ab:

Verbrauch, Elastic Premium und dedizierte Pläne: Derzeit werden ausgeführte Funktionen beendet, wenn neuer Code bereitgestellt wird. Nach Abschluss der Bereitstellung wird der neue Code geladen, um mit der Verarbeitung von Anforderungen zu beginnen. Dieses erzwungene Beendigungsverhalten wird als Strategie zur Neuerstellung bezeichnet. Verwenden Sie Deployment Slots für nahezu keine Ausfallzeiten bei Verbrauchs-, Elastic Premium- und dedizierten Plänen.

Lesen Sie Verbessern Sie die Leistung und Zuverlässigkeit von Azure Functions, um zu lernen, wie man zustandslose und defensive Funktionen schreibt.

Flex-Verbrauchsplan: Das Standardverhalten verwendet auch die Neuerstellungsstrategie, wobei die derzeit ausgeführten Funktionen während der Bereitstellung beendet werden. Flex Consumption unterstützt jedoch eindeutig zwei verschiedene Websiteupdatestrategien. Sie können rollierende Updates für Bereitstellungen ohne Ausfallzeiten konfigurieren.

Bereitstellungsslots

Wenn Sie Ihre Funktions-App für Azure bereitstellen, können Sie anstelle der direkten Produktion auf einem separaten Bereitstellungsplatz bereitstellen. Die Bereitstellung auf einem Bereitstellungsplatz und das anschließende Austauschen in die Produktion nach der Überprüfung ist die empfohlene Methode zum Konfigurieren der kontinuierlichen Bereitstellung.

Die Art und Weise, wie Sie auf einem Slot bereitstellen, hängt von dem jeweiligen Bereitstellungstool ab, das Sie verwenden. Wenn Sie z. B. Azure Functions Core Tools verwenden, fügen Sie die Option --slot ein, um den Namen eines bestimmten Steckplatzes für den Befehl func azure functionapp publish anzugeben.

Weitere Informationen zu Bereitstellungsplätzen finden Sie in der Dokumentation Azure Functions Deployment Slots.

Nächste Schritte

Weitere Informationen zum Bereitstellen von Funktions-Apps finden Sie in den folgenden Artikeln:

  • Last updated on