Bereitstellen für Azure Functions mit Azure Developer CLI

Azure Developer CLI (azd) unterstützt Code- und Containerbereitstellungen für Azure Functions. Verwenden Sie den dedizierten function Host in azure.yaml für beide Modi:

  • Die Codebereitstellung verpackt den erstellten Funktionscode als ZIP-Archiv und lädt ihn in die Funktions-App hoch.
  • Containerbereitstellung erstellt oder löst ein Containerimage auf, veröffentlicht es bei Bedarf in Azure Container Registry (ACR) und aktualisiert die Function App, damit sie das Image ausführt.

Azure Functions und Azure App Service verwenden beide den Microsoft.Web/sites Ressourcenanbieter, und ihre Containerbereitstellungsabläufe teilen einige interne Mechanismen. Sie sind jedoch nicht dieselben azd Hosts. Funktionen verwenden host: function, verfügen über funktionenspezifisches Paket- und Remotebuildverhalten und verwenden nicht den App Service-Bereitstellungsplatzworkflow.

Bereitstellungsmodus auswählen

azd wählt den Bereitstellungsmodus aus der Dienstkonfiguration aus:

Configuration Bereitstellungsmodus
Eine Quelle project mit einer unterstützten Nicht-Docker-languageDatei und ohne docker.path Codebereitstellung
language: docker Containerbereitstellung
Ein docker.path Wert mit einer Quellsprache Containerbereitstellung
Vorgefertigt image Containerbereitstellung

Die bereitgestellte Function App muss den gleichen Modus wie die Dienstkonfiguration verwenden. Wenn die Funktions-App für Container konfiguriert ist, aber azure.yaml die Codebereitstellung auswählt oder umgekehrt, stoppt azd deploy vor dem Hochladen und meldet den Konflikt.

Funktionscode bereitstellen

Konfigurieren Sie einen codebasierten Funktionsdienst mit einem Quellprojekt, einer unterstützten Sprache und host: function:

services:
  api:
    project: ./src/api
    language: ts
    host: function

Während azd deployazd das Projekt erstellt, .funcignore-Ausschlüsse anwendet, ein ZIP-Archiv erstellt und das Paket über die Azure Functions-Bereitstellungs-API hochlädt.

Ihr Bicep oder Terraform muss eine codebasierte Funktions-App bereitstellen und mit azd-service-name kennzeichnen, das auf den Dienstnamen festgelegt ist, es sei denn, Sie identifizieren die Ressource mithilfe von azure.yaml in resourceName. Konfigurieren Sie den Hostingplan, die Laufzeit, den Speicher, die Identitäten, das Netzwerk und die Anwendungseinstellungen mithilfe von Infrastructure as Code.

Remote-Builds für Codebereitstellungen konfigurieren

Die Diensteigenschaft remoteBuild der obersten Ebene gilt nur für codebasierte Function Apps im Flex Consumption plan. Es steuert, ob Azure Functions Oryx zum Erstellen des hochgeladenen Pakets verwendet:

services:
  api:
    project: ./src/api
    language: python
    host: function
    remoteBuild: true

Wenn Sie bei Flex Consumption remoteBuild weglassen, wählt azd basierend auf der Sprache und dem Paketinhalt einen Standard aus:

Language Standardverhalten
JavaScript oder TypeScript Verwendet remote build, wenn .funcignorenode_modules ausschließt oder wenn keine .funcignore-Datei vorhanden ist. Andernfalls wird das lokal erstellte Paket verwendet.
Python Verwendet Remote-Build.
Go Lokal erstellen. Go Function Apps unterstützen keine Remotebuilds.
Andere unterstützte Sprachen Verwendet das lokal erstellte Paket.

Für JavaScript und TypeScript muss ein explizit konfigurierter remoteBuild Wert mit .funcignore übereinstimmen, wenn diese Datei vorhanden ist. Festlegen remoteBuild: true, wenn .funcignorenode_modules ausschließt. Legen Sie remoteBuild: false fest, wenn .funcignorenode_modules im Paket enthält.

Legen Sie die remoteBuild-Eigenschaft auf oberster Ebene für Nicht-Flex-Pläne nicht fest. Um einen Oryx-Build auf einem anderen unterstützten Plan zu aktivieren, konfigurieren Sie ENABLE_ORYX_BUILD=true und SCM_DO_BUILD_DURING_DEPLOYMENT=true als Funktions-App-Einstellungen in Ihrer Infrastruktur.

Bereitstellen einer containerisierten Funktion

Legen Sie für ein Quellprojekt mit einer Dockerfile-Datei language: docker fest, oder behalten Sie die Quellsprache bei und geben Sie docker.path an.

Im folgenden Beispiel wird ein TypeScript-Projekt mit einer Dockerfile-Datei verwendet:

services:
  api:
    project: ./src/api
    language: ts
    host: function
    docker:
      path: ./Dockerfile

Sie können auch ein vordefiniertes Image ohne ein lokales Projekt bereitstellen:

services:
  api:
    host: function
    image: myregistry.azurecr.io/functions/api:1.0

Lassen Sie language für ein vorgefertigtes Image weg oder legen Sie es auf docker fest. Kombinieren Sie nicht image mit project.

Während einer Containerbereitstellung: azd

  1. Erstellt das Image lokal oder remote oder verwendet das konfigurierte vorgefertigte Image.
  2. Veröffentlicht das Bild in die ACR-Instanz, die für das Projekt konfiguriert ist, wenn die Veröffentlichung erforderlich ist.
  3. Aktualisiert die Funktions-App linuxFxVersion auf DOCKER|<image>.
  4. Stellt auf der Hauptwebsite der Function App bereit.

Die Diensteigenschaft remoteBuild der obersten Ebene gilt nicht für Container. Verwenden Sie docker.remoteBuildfolgendes, um ein Containerimage mit ACR-Aufgaben zu erstellen:

services:
  api:
    project: ./src/api
    language: docker
    host: function
    docker:
      path: ./Dockerfile
      remoteBuild: true

Bereitstellen einer containerfähigen Funktions-App

azd deploy aktualisiert den Imageverweis, konvertiert jedoch keine codebasierte Funktions-App in eine containerbasierte Funktions-App. Ihre Infrastruktur muss vor der Bereitstellung eine kompatible Site bereitstellen.

Requirement Details
Linux Function App Stellen Sie eine Linux Function App für einen Azure Functions Premium- oder dedizierten Plan (App Service) bereit. Flex Consumption unterstützt keine benutzerdefinierten Container. Dieser host: function Workflow zielt auf Microsoft.Web/sites ab, nicht auf Azure Functions, die auf Azure Container Apps gehostet werden.
Konfiguration des Containerstandorts Legen Sie die Websiteart so fest, dass sie einschließt functionapp, linuxund container. Initialisieren linuxFxVersion Sie mit einem DOCKER\|<image> Wert. Ein Platzhalterbild ist ausreichend, da azd deploy es ersetzt.
Containerregistrierung Stellen Sie für Quellbuilds eine ACR-Instanz bereit und machen Sie ihren Anmeldeserver über die AZURE_CONTAINER_REGISTRY_ENDPOINT-Infrastrukturausgabe verfügbar oder konfigurieren Sie sie docker.registry für den Dienst. Ein vollqualifiziertes vorgefertigtes Build image kann direkt ohne separate Publishing-Registry verwendet werden.
Zugriff auf die Registrierung Erteilen Sie der Identität, die das Image veröffentlicht, die Berechtigung, in die Zielregistrierung zu pushen, wenn die Veröffentlichung erforderlich ist. Konfigurieren Sie die Funktions-App separat, um das bereitgestellte Image abzurufen. Gewähren Sie für private ACR-Bilder der verwalteten Identität der Funktions-App Pullzugriff, und konfigurieren Sie die Website so, dass verwaltete Identitätsanmeldeinformationen verwendet werden. Konfigurieren Sie für eine andere private Registry die entsprechenden Pull-Anmeldeinformationen in Ihrer Infrastruktur.
Funktionseinstellungen Konfigurieren Sie erforderliche Einstellungen wie FUNCTIONS_EXTENSION_VERSION, FUNCTIONS_WORKER_RUNTIMEund AzureWebJobsStorage über Bicep oder Terraform.
Ressourcenermittlung Wenden Sie ein azd-service-name-Tag an, dessen Wert dem Dienstnamen in azure.yaml entspricht, oder setzen Sie resourceName explizit.

Einstellungen auf Dienstebene env werden für den function Host nicht unterstützt. Definieren Sie stattdessen die Function App-Einstellungen in Ihrer Infrastruktur.

Bereitstellungsslots verstehen

azd stellt immer einen function Dienst auf der Hauptwebsite der Function App bereit. Sie erkennt keine Function App-Slots, fordert nicht dazu auf und stellt auch nicht darin bereit. Slot-Einstellungen des App Service, wie z. B. AZD_DEPLOY_{SERVICE}_SLOT_NAME, haben keine Auswirkungen auf eine Function App-Bereitstellung.

Wenn Sie einen slotbasierten Functions-Freigabeprozess benötigen, verwalten Sie den Slot und die Bereitstellung außerhalb des integrierten host: function Workflows.

Vergleichen von Funktionen und App Service-Hosts

Funktionen und App Service teilen sich den Microsoft.Web/sites Ressourcentyp, wählen Sie jedoch den Host aus, der der Workload entspricht:

Behavior function Host appservice Host
Arbeitsbelastung Ereignisgesteuerte Azure Functions Web-Apps und APIs
Codebereitstellung Verwendet den Azure Functions ZIP-Bereitstellungsfluss. Verwendet den App Service-Bereitstellungsablauf.
Containerbereitstellung Aktualisiert das Function App-Image nach der Überprüfung, ob die Website containerbasiert ist. Aktualisiert das Web App-Image nach der Überprüfung, ob die Website containerbereit ist.
Remote-Code-Build Unterstützt die Option auf Serviceebene remoteBuild für Flex Consumption Function Apps Verwendet die Option „Funktionen“ nicht remoteBuild
Bereitstellungsslots Stellt immer auf der Hauptwebsite bereit Unterstützt den Workflow für den azd App Service-Slot
Service-Level env Nicht unterstützt; verwenden Sie die Einstellungen der Funktions-App in der Infrastruktur Konfigurieren von App-Einstellungen in der Infrastruktur

Verwandte Inhalte

  • Zuletzt aktualisiert um