Teilen über

Automatisieren der Ressourcenbereitstellung für Ihre Funktions-App in Azure Functions

  • Artikel

Sie können eine Bicep-Datei oder eine ARM-Vorlage (Azure Resource Manager) verwenden, um die Bereitstellung Ihrer Funktions-App zu automatisieren. Im Rahmen der Bereitstellung können Sie bereits vorhandene Azure-Ressourcen verwenden oder neue erstellen. Die Automatisierung ist in diesen Szenarien hilfreich:

  • Integrieren Ihrer Ressourcenbereitstellungen in Ihren Quellcode in Azure Pipelines und GitHub Actions-basierten Bereitstellungen
  • Wiederherstellen einer Funktions-App und der zugehörigen Ressourcen aus einer Sicherung
  • Mehrfaches Bereitstellen einer App-Topologie

In diesem Artikel erfahren Sie, wie Sie die Erstellung von Ressourcen und die Bereitstellung für Azure Functions automatisieren können. Je nach den von Ihren Funktionen verwendeten Triggern und Bindungen müssen Sie möglicherweise weitere Ressourcen bereitstellen. Dies ist jedoch nicht Gegenstand dieses Artikels.

Der erforderliche Vorlagencode hängt von den gewünschten Hostingoptionen für Ihre Funktions-App ab. Dieser Artikel unterstützt die folgenden Hosting-Optionen:

Hostingoption Bereitstellungstyp Weitere Informationen finden Sie unter...
Azure Functions-Nutzungsplan Nur Code Verbrauchstarif
Azure Functions-Flex-Verbrauchsplan Nur Code Flex-Verbrauchstarif
Azure Functions Elastic Premium Plan Code | Container Premium-Plan
Azure Functions Dedicated (App Service) Plan Code | Container Dedizierter Plan
Azure Container Apps Nur Container Container Apps-Hosting von Azure Functions
Azure Arc Code | Container App Service, Funktionen und Logic Apps in Azure Arc (Vorschau)

Wichtig

Der Flex-Verbrauchstarif befindet sich derzeit in der Vorschau.

Berücksichtigen Sie bei der Verwendung dieses Artikels Folgendes:

  • Beispiele werden als einzelne Abschnitte für bestimmte Ressourcen gezeigt.

Erforderliche Ressourcen

Für eine von Azure Functions gehostete Bereitstellung müssen folgende Ressourcen erstellt oder konfiguriert werden:

Resource Anforderung Syntax- und Eigenschaftenverweis
Ein Speicherkonto Erforderlich Microsoft.Storage/storageAccounts
Eine Application Insights-Komponente Empfohlen Microsoft.Insights/components*
Hostingplan Erforderlich Microsoft.Web/serverfarms
Eine Funktions-App Erforderlich Microsoft.Web/sites

Für eine von Azure Functions gehostete Bereitstellung müssen folgende Ressourcen erstellt oder konfiguriert werden:

Resource Anforderung Syntax- und Eigenschaftenverweis
Ein Speicherkonto Erforderlich Microsoft.Storage/storageAccounts
Eine Application Insights-Komponente Empfohlen Microsoft.Insights/components*
Eine Funktions-App Erforderlich Microsoft.Web/sites

Eine gehostete Azure Container Apps-Bereitstellung besteht in der Regel aus diesen Ressourcen:

Resource Anforderung Syntax- und Eigenschaftenverweis
Ein Speicherkonto Erforderlich Microsoft.Storage/storageAccounts
Eine Application Insights-Komponente Empfohlen Microsoft.Insights/components*
Eine verwaltete Umgebung Erforderlich Microsoft.App/managedEnvironments
Eine Funktions-App Erforderlich Microsoft.Web/sites

Eine gehostete Azure Arc-Bereitstellung besteht in der Regel aus diesen Ressourcen:

Resource Anforderung Syntax- und Eigenschaftenverweis
Ein Speicherkonto Erforderlich Microsoft.Storage/storageAccounts
Eine Application Insights-Komponente Empfohlen Microsoft.Insights/components1
Eine App Service Kubernetes-Umgebung Erforderlich Microsoft.ExtendedLocation/customLocations
Eine Funktions-App Erforderlich Microsoft.Web/sites

* Wenn Sie noch nicht über einen Log Analytics-Arbeitsbereich verfügen, der von Ihrer Application Insights-Instanz verwendet werden kann, muss diese Ressource ebenfalls erstellt werden.

Wenn Sie mehrere Ressourcen in einer einzigen Bicep-Datei oder ARM-Vorlage bereitstellen, ist die Reihenfolge, in der die Ressourcen erstellt werden, wichtig. Diese Anforderung ergibt sich aus den Abhängigkeiten zwischen den Ressourcen. Stellen Sie bei solchen Abhängigkeiten sicher, dass Sie das Element dependsOn verwenden, um die Abhängigkeit in der abhängigen Ressource zu definieren. Weitere Informationen finden Sie unter Definieren der Reihenfolge für die Bereitstellung von Ressourcen in ARM-Vorlagen oder Ressourcenabhängigkeiten in Bicep.

Voraussetzungen

  • Die Beispiele sind für die Ausführung im Kontext einer bereits vorhandenen Ressourcengruppe konzipiert.
  • Sowohl für Application Insights als auch für Speicherprotokolle muss ein Azure Log Analytics-Arbeitsbereich vorhanden sein. Arbeitsbereiche können von Diensten gemeinsam genutzt werden, und es empfiehlt sich, in jeder geografischen Region einen Arbeitsbereich zu erstellen, um die Leistung zu verbessern. Ein Beispiel für die Erstellung eines Log Analytics-Arbeitsbereichs finden Sie unter Erstellen eines Arbeitsbereichs. Die vollqualifizierte Ressourcen-ID des Arbeitsbereichs befindet sich auf einer Arbeitsbereichsseite im Azure-Portal unter Einstellungen>Eigenschaften>Ressourcen-ID.
  • Dieser Artikel geht davon aus, dass Sie bereits eine verwaltete Umgebung in Azure Container Apps erstellt haben. Sie benötigen sowohl den Namen als auch die ID der verwalteten Umgebung, um eine auf Container Apps gehostete Funktions-App zu erstellen.

Speicherkonto erstellen

Alle Funktions-Apps benötigen ein Azure-Speicherkonto. Sie benötigen ein Konto für allgemeine Zwecke, das Blobs, Tabellen, Warteschlangen und Dateien unterstützt. Weitere Informationen finden Sie unter Anforderungen an das Speicherkonto.

Wichtig

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

In diesem Beispielabschnitt wird ein universelles Standardspeicherkonto der Version 2 erstellt:

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    supportsHttpsTrafficOnly: true
    defaultToOAuthAuthentication: true
    allowBlobPublicAccess: false
  }
}

Näheres dazu finden Sie in der vollständigen Datei main.bicep im Vorlagen-Repository.

Mehr Kontext finden Sie im Beispielrepository in der vollständigen Datei storage-account.bicep.

Sie müssen die Verbindungszeichenfolge dieses Speicherkontos als App-Einstellung AzureWebJobsStorage festlegen, die Functions benötigt. Die Vorlagen in diesem Artikel konstruieren diese Verbindungszeichenfolge auf der Grundlage des erstellten Speicherkontos. Dies ist eine bewährte Methode. Weitere Informationen finden Sie unter Konfiguration der Anwendung.

Bereitstellungscontainer

Bereitstellungen für eine App, die im Flex-Verbrauchsplan ausgeführt wird, erfordern einen Container in Azure Blob Storage als Bereitstellungsquelle. Sie können entweder das Standardspeicherkonto verwenden oder ein separates Speicherkonto angeben. Weitere Informationen finden Sie unter Konfigurieren von Bereitstellungseinstellungen.

Dieses Bereitstellungskonto muss bereits konfiguriert sein, wenn Sie Ihre App erstellen – einschließlich des spezifischen Containers, der für Bereitstellungen verwendet wird. Weitere Informationen zum Konfigurieren von Bereitstellungen finden Sie unter Bereitstellungsquellen.

In diesem Beispiel wird das Erstellen eines Containers im Speicherkonto gezeigt:

resource blobServices 'blobServices' = if (!empty(containers)) {
  name: 'default'
  properties: {
    deleteRetentionPolicy: deleteRetentionPolicy
  }
  resource container 'containers' = [for container in containers: {
    name: container.name
    properties: {
      publicAccess: contains(container, 'publicAccess') ? container.publicAccess : 'None'
    }
  }]
}

In diesem Bereitstellungsbeispiel können Sie sich den Codeschnipsel im Kontext ansehen.

Andere Bereitstellungseinstellungen werden mit der App selbst konfiguriert.

Aktivieren von Speicherprotokollen

Da das Speicherkonto für wichtige Daten der Funktions-App verwendet wird, sollten Sie das Konto auf Änderungen an diesen Inhalten überwachen. Um Ihr Speicherkonto zu überwachen, müssen Sie die Ressourcenprotokolle von Azure Monitor für Azure Storage konfigurieren. In diesem Beispielabschnitt wird ein Log Analytics-Arbeitsbereich mit dem Namen myLogAnalytics als Ziel für diese Protokolle verwendet.

resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' existing = {
  name:'default'
  parent:storageAccountName
}

resource storageDataPlaneLogs 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: '${storageAccountName}-logs'
  scope: blobService
  properties: {
    workspaceId: myLogAnalytics.id
    logs: [
      {
        category: 'StorageWrite'
        enabled: true
      }
    ]
    metrics: [
      {
        category: 'Transaction'
        enabled: true
      }
    ]
  }
}

Derselbe Arbeitsbereich kann für die später definierte Application Insights-Ressource verwendet werden. Weitere Informationen und wie Sie mit diesen Protokollen arbeiten können, finden Sie unter Überwachen von Azure Storage.

Erstellen von Application Insights

Es empfiehlt sich, Application Insights für die Überwachung der Ausführungen Ihrer Funktions-App zu verwenden. Für Application Insights ist jetzt ein Azure Log Analytics-Arbeitsbereich erforderlich. Dieser kann gemeinsam genutzt werden. In diesen Beispielen wird davon ausgegangen, dass Sie einen bereits vorhandenen Arbeitsbereich verwenden und über die vollqualifizierte Ressourcen-ID für den Arbeitsbereich verfügen. Weitere Informationen finden Sie in der Übersicht über Log Analytics in Azure Monitor.

In diesem Beispielabschnitt wird die Ressource Application Insights mit dem Typ Microsoft.Insights/components und der Art web definiert:

resource applicationInsight 'Microsoft.Insights/components@2020-02-02' = {
  name: applicationInsightsName
  location: appInsightsLocation
  tags: tags
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: '<FULLY_QUALIFIED_RESOURCE_ID>'
  }
}

Näheres dazu finden Sie in der vollständigen Datei main.bicep im Vorlagen-Repository.

Die Verbindung muss der Funktions-App über die Anwendungseinstellung APPLICATIONINSIGHTS_CONNECTION_STRING zur Verfügung gestellt werden. Weitere Informationen finden Sie unter Konfiguration der Anwendung.

Die Beispiele in diesem Artikel liefern den Wert der Verbindungszeichenfolge für die erstellte Instanz. Ältere Versionen verwenden stattdessen möglicherweise APPINSIGHTS_INSTRUMENTATIONKEY, um den Instrumentierungsschlüssel festzulegen. Dies wird nicht mehr empfohlen.

Erstellen des Hostingplans

Bei Apps, die in einem Flex-Verbrauchsplan, Premium-Plan oder dedizierten Plan (App Service) für Azure Functions gehostet werden, muss der Hostingplan explizit definiert sein.

Flex-Verbrauch ist ein Linux-basierter Hostingplan, der auf dem serverlosen verbrauchsbasierten Abrechnungsmodell mit nutzungsabhängiger Bezahlung basiert. Der Plan bietet Unterstützung für private Netzwerke, die Auswahl der Speichergröße der Instanz und eine verbesserte Unterstützung verwalteter Identitäten.

Ein Flex-Verbrauchsplan ist eine besondere Art von serverfarm-Ressource. Sie können ihn angeben, indem Sie FC1 für den Name-Eigenschaftswert in der Eigenschaft sku und FlexConsumption für den tier-Wert verwenden.

In diesem Beispielabschnitt wird ein Flex-Verbrauchsplan erstellt:

resource flexFuncPlan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: planName
  location: location
  tags: tags
  kind: 'functionapp'
  sku: {
    tier: 'FlexConsumption'
    name: 'FC1'
  }
  properties: {
    reserved: true
  }
}

Mehr Kontext finden Sie im Beispielrepository für den Flex-Verbrauchsplan in der vollständigen Datei function.bicep.

Da der Flex-Verbrauchsplan derzeit nur Linux unterstützt, muss außerdem die Eigenschaft reserved auf true festgelegt werden.

Der Premium-Tarif bietet die gleiche Skalierung wie der Verbrauchstarif, umfasst jedoch dedizierte Ressourcen und zusätzliche Funktionen. Weitere Informationen finden Sie unter Premium-Tarif für Azure Functions.

Ein Premium-Plan ist eine besondere Art von serverfarm-Ressource. Sie können ihn angeben, indem Sie entweder EP1, EP2 oder EP3 für den Wert der Eigenschaft Name in der Eigenschaft sku verwenden. Die Art und Weise, wie Sie den Funktions-Hostingplan definieren, hängt davon ab, ob Ihre Funktions-App unter Windows oder unter Linux ausgeführt wird. In diesem Beispielabschnitt wird ein EP1 Plan erstellt:

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    name: 'EP1'
    tier: 'ElasticPremium'
    family: 'EP'
  }
  kind: 'elastic'
  properties: {
    maximumElasticWorkerCount: 20
  }
}

Näheres dazu finden Sie in der vollständigen Datei main.bicep im Vorlagen-Repository.

Weitere Informationen zum sku-Objekt finden Sie unter SkuDefinition oder sehen Sie sich die Beispielvorlagen an.

Im Dedicated (App Service) Plan läuft Ihre Funktions-App auf dedizierten VMs auf Basic, Standard und Premium SKUs in App Service Plänen, ähnlich wie bei Web-Apps. Weitere Informationen finden Sie unter Dedizierter Plan.

Ein Beispiel für eine Bicep-Datei/eine Azure Resource Manager-Vorlage finden Sie unter Funktions-App im Azure App Service Plan.

In Functions ist der Dedicated-Plan nur ein regulärer App Service-Plan, der von einer serverfarm-Ressource definiert wird. Sie müssen mindestens einen name-Wert angeben. Eine Liste der Namen der unterstützten Pläne finden Sie in der Einstellung --sku in az appservice plan create in der aktuellen Liste der unterstützten Werte für einen Dedicated Plan.

Die Art und Weise, wie Sie den Hostingplan definieren, hängt davon ab, ob Ihre Funktions-App unter Windows oder unter Linux läuft:

resource hostingPlanName 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    tier: 'Standard'
    name: 'S1'
    size: 'S1'
    family: 'S'
    capacity: 1
  }
}

Näheres dazu finden Sie in der vollständigen Datei main.bicep im Vorlagen-Repository.

Erstellen des Hostingplans

Für den Verbrauchhostingplan müssen Sie keine Ressource explizit definieren. Wenn Sie diese Ressourcendefinition überspringen, wird automatisch bei der Erstellung der Funktions-App-Ressource selbst ein Plan entweder erstellt oder für die jeweilige Region ausgewählt.

Sie können einen Verbrauchsplan explizit als einen speziellen Typ einer serverfarm-Ressource definieren, den Sie mithilfe des Werts Dynamic für die Eigenschaften computeMode und sku angeben. Dieser Beispielabschnitt zeigt Ihnen, wie Sie einen Verbrauchsplan explizit definieren können. Die Art und Weise, wie Sie einen Hostingplan definieren, hängt davon ab, ob Ihre Funktions-App unter Windows oder unter Linux läuft.

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    name: 'Y1'
    tier: 'Dynamic'
    size: 'Y1'
    family: 'Y'
    capacity: 0
  }
  properties: {
    computeMode: 'Dynamic'
  }
}

Näheres dazu finden Sie in der vollständigen Datei main.bicep im Vorlagen-Repository.

Kubernetes-Umgebung

Azure Functions kann in Azure Arc-fähigen Kubernetes bereitgestellt werden, entweder als Codeprojekt oder als containerisierte Funktions-App.

Um die App und Planressourcen zu erstellen, müssen Sie bereits eine App Service Kubernetes-Umgebung für einen für Azure Arc aktivierten Kubernetes-Cluster erstellt haben. Bei den Beispielen in diesem Artikel wird davon ausgegangen, dass Sie die Ressourcen-ID des benutzerdefinierten Standorts (customLocationId) und der App Service Kubernetes-Umgebung (kubeEnvironmentId), für die Sie die Bereitstellung vornehmen, bereits kennen:

param kubeEnvironmentId string
param customLocationId string

Sowohl Sites als auch Pläne müssen über ein extendedLocation-Feld auf den benutzerdefinierten Speicherort verweisen. Wie in diesem abgeschnittenen Beispiel gezeigt, befindet sich extendedLocation außerhalb von properties, als Peer zu kind und location:

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  ...
  {
    extendedLocation: {
      name: customLocationId
    }
  }
}

Die Planressource sollte den Kubernetes (K1) Wert für SKUverwenden, das Feld kind sollte linux,kubernetes sein, und die Eigenschaft reserved sollte true sein, da es sich um eine Linux-Bereitstellung handelt. Sie müssen auch extendedLocation und kubeEnvironmentProfile.id auf die benutzerdefinierte Standort-ID bzw. die Kubernetes-Umgebungs-ID festlegen, die wie in diesem Beispielabschnitt aussehen kann:

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  kind: 'linux,kubernetes'
  sku: {
    name: 'K1'
    tier: 'Kubernetes'
  }
  extendedLocation: {
    name: customLocationId
  }
  properties: {
    kubeEnvironmentProfile: {
      id: kubeEnvironmentId
    }
    reserved: true
  }
}

Erstellen der Funktionen-App

Die Funktions-App-Ressource wird durch eine Ressource vom Typ Microsoft.Web/sites und kind definiert, die mindestens functionapp enthält.

Die Art und Weise, wie Sie eine Funktions-App-Ressource definieren, hängt davon ab, ob Sie auf Windows oder unter Linux hosten:

Eine Liste der Anwendungseinstellungen, die für die Ausführung unter Windows erforderlich sind, finden Sie unter Anwendungskonfiguration. Ein Beispiel für eine Bicep-Datei/eine Azure Resource Manager-Vorlage finden Sie in der Vorlage für eine in einem Windows-Verbrauchsplan gehostete Funktions-App.

Eine Liste der Anwendungseinstellungen, die für die Ausführung unter Windows erforderlich sind, finden Sie unter Anwendungskonfiguration.

Flex-Verbrauch ersetzt viele der standardmäßigen Anwendungseinstellungen und Standortkonfigurationseigenschaften, die in Bicep- und ARM-Vorlagenbereitstellungen verwendet werden. Weitere Informationen finden Sie unter Konfiguration der Anwendung.

resource flexFuncApp 'Microsoft.Web/sites@2023-12-01' = {
  name: appName
  location: location
  tags: tags
  kind: 'functionapp,linux'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: flexFuncPlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'AzureWebJobsStorage__accountName'
          value: storage.name
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsights.properties.ConnectionString
        }
      ]
    }
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.properties.primaryEndpoints.blob}${deploymentStorageContainerName}'
          authentication: {
            type: 'SystemAssignedIdentity'
          }
        }
      }
      scaleAndConcurrency: {
        maximumInstanceCount: maximumInstanceCount
        instanceMemoryMB: instanceMemoryMB
      }
      runtime: { 
        name: functionAppRuntime
        version: functionAppRuntimeVersion
      }
    }
  }
}

Mehr Kontext finden Sie im Beispielrepository für den Flex-Verbrauchsplan in der vollständigen Datei function.bicep.

Hinweis

Wenn Sie sich dafür entscheiden, Ihren Verbrauchsplan optional zu definieren, müssen Sie die Eigenschaft serverFarmId der App so einstellen, dass sie auf die Ressourcen-ID des Plans zeigt. Stellen Sie sicher, dass die Funktions-App über eine dependsOn-Einstellung verfügt, die auch auf den Plan verweist. Wenn Sie nicht ausdrücklich einen Plan definiert haben, wird einer für Sie erstellt.

Legen Sie die Eigenschaft serverFarmId in der App so fest, dass sie auf die Ressourcen-ID des Plans zeigt. Stellen Sie sicher, dass die Funktions-App über eine dependsOn-Einstellung verfügt, die auch auf den Plan verweist.

resource functionAppName_resource 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTSHARE'
          value: toLower(functionAppName)
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~14'
        }
      ]
    }
  }
}

Ein vollständiges End-to-End-Beispiel finden Sie in dieser main.bicep-Datei.

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      alwaysOn: true
      appSettings: [
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~14'
        }
      ]
    }
  }
}

Ein vollständiges End-to-End-Beispiel finden Sie in dieser main.bicep-Datei.

Bereitstellungsquellen

Sie können die linuxFxVersion-Websiteeinstellung verwenden, um anzufordern, dass ein bestimmter Linux-Container bei der Erstellung in Ihrer App bereitgestellt wird. Für den Zugriff auf Bilder in einem privaten Repository sind weitere Einstellungen erforderlich. Weitere Informationen finden Sie unter Konfiguration der Anwendung.

Wichtig

Wenn Sie eigene Container erstellen, müssen Sie das Basisimage Ihres Containers auf das neueste unterstützte Basisimage aktualisieren. Unterstützte Basisimages für Azure Functions sind sprachspezifisch und sind unter Repositorys für Azure Functions-Basisimages verfügbar.

Das Functions-Team ist bestrebt, monatliche Updates für diese Basisimages zu veröffentlichen. Regelmäßige Updates umfassen die neuesten Updates der Nebenversion und Sicherheitskorrekturen für Functions-Runtime und -Sprachen. Sie sollten Ihren Container regelmäßig aus dem neuesten Basisimage aktualisieren und die aktualisierte Version Ihres Containers erneut bereitstellen.

Ihre Bicep-Datei oder ARM-Vorlage kann optional auch eine Bereitstellung für Ihren Funktionscode definieren, der diese Methoden enthalten könnte:

Im Flex-Verbrauchsplan wird Ihr Projektcode über ein komprimiertes ZIP-Paket bereitgestellt, das in einem Blobspeichercontainer veröffentlicht wird. Weitere Informationen finden Sie unter Bereitstellung. Das spezifische Speicherkonto und der spezifische Container für Bereitstellungen, die Authentifizierungsmethode und die Anmeldeinformationen werden im functionAppConfig.deployment.storage-Element der Eigenschaften (properties) für die Site festgelegt. Der Container und die gewünschten Anwendungseinstellungen müssen vorhanden sein, wenn die App erstellt wird. Ein Beispiel für die Erstellung des Speichercontainers finden Sie unter Bereitstellungscontainer.

In diesem Beispiel wird eine systemseitig zugewiesene verwaltete Identität verwendet, um auf den angegebenen Blobspeichercontainer zuzugreifen (wird an anderer Stelle in der Bereitstellung erstellt):

deployment: {
  storage: {
    type: 'blobContainer'
    value: '${storage.properties.primaryEndpoints.blob}${deploymentStorageContainerName}'
    authentication: {
      type: 'SystemAssignedIdentity'
    }
  }
}

Wenn Sie verwaltete Identitäten verwenden, müssen Sie es der Funktions-App auch ermöglichen, mithilfe der Identität auf das Speicherkonto zuzugreifen, wie in diesem Beispiel gezeigt:

// Allow access from function app to storage account using a managed identity
resource storageRoleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
  name: guid(storage.id, storageRoleDefinitionId)
  scope: storage
  properties: {
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', storageRoleDefinitionId)
    principalId: flexFuncApp.identity.principalId
    principalType: 'ServicePrincipal'
  }
}

Ein vollständiges Referenzbeispiel finden Sie in dieser Bicep-Datei.

Wenn Sie anstelle von verwalteten Identitäten eine Verbindungszeichenfolge verwenden, müssen Sie stattdessen authentication.type auf StorageAccountConnectionString und authentication.storageAccountConnectionStringName auf den Namen der Anwendungseinstellung festlegen, die die Verbindungszeichenfolge für das Bereitstellungsspeicherkonto enthält.

Ihre Bicep-Datei oder ARM-Vorlage kann optional auch eine Bereitstellung für Ihren Funktionscode definieren, indem Sie ein zip-Bereitstellungspaket verwenden.

Um Ihre Anwendung erfolgreich mithilfe von Azure Resource Manager bereitzustellen, müssen Sie mit der Bereitstellung von Ressourcen in Azure vertraut sein. In den meisten Beispielen werden Konfigurationen auf oberster Ebene mithilfe von siteConfig angewendet. Diese Konfigurationen müssen auf der obersten Ebene festgelegt werden, da sie Informationen für die Laufzeit- und Azure CLI 2.0 Preview von Functions bereitstellen. Informationen auf oberster Ebene werden benötigt, bevor die untergeordnete Ressource sourcecontrols/web angewendet wird. Die Einstellungen können zwar auch in der untergeordneten Ressource config/appSettings konfiguriert werden, in bestimmten Fällen muss Ihre Funktions-App jedoch bereitgestellt werden, bevor config/appSettings angewendet wird.

zip-Bereitstellungspaket

Die zip-Bereitstellung ist eine empfohlene Methode zum Bereitstellen des Funktions-App-Codes. Standardmäßig werden Funktionen, die zip-Bereitstellung verwenden, im Bereitstellungspaket selbst ausgeführt. Weitere Informationen, einschließlich der Anforderungen für ein Bereitstellungspaket, finden Sie unter zip-Bereitstellung für Azure Functions. Wenn Sie die Automatisierung der Ressourcenbereitstellung verwenden, können Sie auf das zip-Bereitstellungspaket in Ihrer Bicep- oder ARM-Vorlage verweisen.

Wenn Sie die zip-Bereitstellung in Ihrer Vorlage verwenden möchten, legen Sie die Einstellung WEBSITE_RUN_FROM_PACKAGE in der App auf 1 fest und fügen Sie die Ressourcendefinition /zipDeploy ein.

Für einen Verbrauchsplan unter Linux legen Sie stattdessen den URI des Bereitstellungspakets direkt in der Einstellung WEBSITE_RUN_FROM_PACKAGE fest, wie in dieser Beispielvorlagedargestellt.

In diesem Beispiel wird einer vorhandenen App eine zip-Bereitstellungsquelle hinzugefügt:

@description('The name of the function app.')
param functionAppName string

@description('The location into which the resources should be deployed.')
param location string = resourceGroup().location

@description('The zip content url.')
param packageUri string

resource functionAppName_ZipDeploy 'Microsoft.Web/sites/extensions@2021-02-01' = {
  name: '${functionAppName}/ZipDeploy'
  location: location
  properties: {
    packageUri: packageUri
  }
}

Beachten Sie folgendes, wenn Sie zip-Bereitstellungsressourcen in Ihre Vorlage einschließen:

  • packageUri muss ein Speicherort sein, auf den Functions zugreifen kann. Erwägen Sie die Festlegung von Azure Blob Storage mit einer Shared Access Signature (SAS). Nachdem die SAS abgelaufen ist, kann Functions nicht mehr auf die Freigabe für Bereitstellungen zugreifen. Wenn Sie Ihre SAS neu generieren, denken Sie daran, die Einstellung WEBSITE_RUN_FROM_PACKAGE mit dem neuen URI-Wert zu aktualisieren.

  • Beim Festlegen WEBSITE_RUN_FROM_PACKAGE auf einen URI müssen Sie Auslöser manuell synchronisieren.

  • Stellen Sie beim Hinzufügen oder Aktualisieren von Einstellungen immer alle erforderlichen Anwendungseinstellungen in der Sammlung appSettings fest. Vorhandene Einstellungen, die nicht explizit festgelegt wurden, werden durch das Update entfernt. Weitere Informationen finden Sie unter Konfiguration der Anwendung.

  • Functions unterstützt Web Deploy (msdeploy) für Paketbereitstellungen nicht. Stattdessen müssen Sie die zip-Bereitstellung in Ihren Bereitstellungspipelines und der Automatisierung verwenden. Weitere Informationen finden Sie unter ZIP-Bereitstellung für Azure Functions.

Remotebuilds

Der Bereitstellungsprozess geht von der Annahme aus, dass die zip-Datei, die Sie benutzen, oder eine zip-Bereitstellung eine ausführbare App enthält. Das bedeutet, dass standardmäßig keine Anpassungen ausgeführt werden.

Es gibt Szenarien, in denen Sie Ihre App remote neu erstellen müssen. Dies ist beispielsweise der Fall, wenn Sie Linux-spezifische Pakete in Python- oder Node.js-Apps einschließen müssen, die Sie auf einem Windows-Computer entwickelt haben. In diesem Fall können Sie Functions so konfigurieren, dass nach der zip-Bereitstellung ein Remotebuild auf Ihrem Code ausgeführt wird.

Die Vorgehensweise zum Anfordern eines Remotebuilds hängt vom Zielbetriebssystem für die Bereitstellung ab:

Bei der Bereitstellung einer App unter Windows werden sprachspezifische Befehle ausgeführt (z. B. dotnet restore für C#-Apps oder npm install für Node.js-Apps).

Um die gleichen Build-Prozesse wie bei der kontinuierlichen Integration zu aktivieren, fügen Sie SCM_DO_BUILD_DURING_DEPLOYMENT=true zu den Anwendungseinstellungen in Ihrem Bereitstellungscode hinzu und entfernen WEBSITE_RUN_FROM_PACKAGE vollständig.

Linux-Container

Wenn Sie eine containerisierte Funktions-App in einem Azure Functions Premium oder Dedicated Plan bereitstellen, müssen Sie Folgendes tun:

Wenn einige Einstellungen fehlen, schlägt die Anwendungsbereitstellung möglicherweise mit diesem HTTP/500-Fehler fehl:

Function app provisioning failed.

Weitere Informationen finden Sie unter Konfiguration der Anwendung.

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~14'
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_URL'
          value: dockerRegistryUrl
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_USERNAME'
          value: dockerRegistryUsername
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_PASSWORD'
          value: dockerRegistryPassword
        }
        {
          name: 'WEBSITES_ENABLE_APP_SERVICE_STORAGE'
          value: 'false'
        }
      ]
      linuxFxVersion: 'DOCKER|myacr.azurecr.io/myimage:mytag'
    }
  }
  dependsOn: [
    storageAccount
  ]
}

Bei der Bereitstellung von containerisierten Funktionen in Azure Container Apps muss Ihre Vorlage Folgendes enthalten:

  • Legen Sie das Feld kind auf einen Wert von functionapp,linux,container,azurecontainerapps fest.
  • Legen Sie die Websiteeigenschaft managedEnvironmentId auf den vollqualifizierten URI der Container Apps-Umgebung fest.
  • Fügen Sie eine Ressourcenverknüpfung in der dependsOn-Sammlung der Website hinzu, wenn Sie gleichzeitig mit der Website eine Microsoft.App/managedEnvironments-Ressource erstellen.

Die Definition einer containerisierten Funktions-App, die von einer privaten Container-Registrierung in einer bestehenden Container-Apps-Umgebung bereitgestellt wird, könnte wie folgt aussehen:

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  kind: 'functionapp,linux,container,azurecontainerapps'
  location: location
  properties: {
    serverFarmId: hostingPlanName
    siteConfig: {
      linuxFxVersion: 'DOCKER|myacr.azurecr.io/myimage:mytag'
      appSettings: [
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
      ]
    }
    managedEnvironmentId: managedEnvironmentId
  }
  dependsOn: [
    storageAccount
    hostingPlan
  ]
}

Bei der Bereitstellung von Funktionen in Azure Arc hängt der Wert, den Sie für das Feld kind der Funktions-App-Ressource festlegen, von der Art der Bereitstellung ab:

Bereitstellungstyp Wert des Felds kind
Reine Codebereitstellung functionapp,linux,kubernetes
Containerbereitstellung functionapp,linux,kubernetes,container

Sie müssen auch die customLocationId wie für die Hostingplanressource festlegen.

Die Definition einer containerisierten Funktions-App unter Verwendung eines .NET 6 Schnellstartimages könnte wie folgt aussehen:

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  kind: 'kubernetes,functionapp,linux,container'
  location: location
  extendedLocation: {
    name: customLocationId
  }
  properties: {
    serverFarmId: hostingPlanName
    siteConfig: {
      linuxFxVersion: 'DOCKER|mcr.microsoft.com/azure-functions/4-dotnet-isolated6.0-appservice-quickstart'
      appSettings: [
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
      ]
      alwaysOn: true
    }
  }
  dependsOn: [
    storageAccount
    hostingPlan
  ]
}

Anwendungskonfiguration

In einem Flex-Verbrauchsplan konfigurieren Sie Ihre Funktions-App in Azure mit zwei Arten von Eigenschaften:

Konfiguration Microsoft.Web/sites-Eigenschaft
Anwendungskonfiguration functionAppConfig
Anwendungseinstellungen siteConfig.appSettings-Sammlung

Diese Anwendungskonfigurationen werden in functionAppConfig verwaltet:

Behavior Einstellung in functionAppConfig
Jederzeit bereite Instanzen scaleAndConcurrency.alwaysReady
Bereitstellungsquelle deployment
Größe des Instanzarbeitsspeichers scaleAndConcurrency.instanceMemoryMB
HTTP-Triggerparallelität scaleAndConcurrency.triggers.http.perInstanceConcurrency
Sprachruntime runtime.name
Sprachversion runtime.version
Maximale Anzahl von Instanzen scaleAndConcurrency.maximumInstanceCount

Der Flex-Verbrauchsplan unterstützt auch folgende Anwendungseinstellungen:

Functions bietet die folgenden Optionen für die Konfiguration Ihrer Funktions-App in Azure:

Konfiguration Microsoft.Web/sites-Eigenschaft
Websiteeinstellungen siteConfig
Anwendungseinstellungen siteConfig.appSettings-Sammlung

Für die Eigenschaft siteConfig sind folgende Siteeinstellungen erforderlich:

Diese Websiteeinstellungen sind nur erforderlich, wenn verwaltete Identitäten zum Abrufen des Bildes aus einer Azure Container Registry-Instanz verwendet werden:

Diese Anwendungseinstellungen sind für ein bestimmtes Betriebssystem und eine bestimmte Hosting-Option erforderlich (oder empfohlen):

Diese Anwendungseinstellungen sind für die Bereitstellung von Containern erforderlich:

Diese Einstellungen sind nur erforderlich, wenn die Bereitstellung von einer privaten Container-Registrierung aus erfolgt:

Denken Sie an diese Überlegungen, wenn Sie mit Website- und Anwendungseinstellungen unter Verwendung von Bicep-Dateien oder ARM-Vorlagen arbeiten:

  • Die optionale alwaysReady-Einstellung enthält ein Array von mindestens einem {name,instanceCount}-Objekt mit einer für jede Skalierungsgruppe pro Funktion. Dies sind die Skalierungsgruppen, die verwendet werden, um immer einsatzbereite Skalierungsentscheidungen zu treffen. In diesem Beispiel wird sowohl für die http-Gruppe als auch für eine einzelne Funktion namens „helloworld“ „Immer bereit“ festgelegt, die einen nicht gruppierten Triggertyp aufweist:
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • Es gibt wichtige Überlegungen, wann Sie in einer automatisierten Bereitstellung WEBSITE_CONTENTSHARE festlegen sollten. Ausführliche Anleitungen finden Sie in der WEBSITE_CONTENTSHARE-Referenz.
  • Bei der Bereitstellung von Containern setzen Sie WEBSITES_ENABLE_APP_SERVICE_STORAGE ebenfalls auf false, da der Inhalt Ihrer Anwendung im Container selbst bereitgestellt wird.

  • Sie sollten Ihre Anwendungseinstellungen immer als siteConfig/appSettings-Sammlung der zu erstellenden Microsoft.Web/sites-Ressource definieren, wie es in den Beispielen in diesem Artikel geschieht. Durch diese Definition wird sichergestellt, dass die Einstellungen, die Ihre Funktions-App zur Ausführung benötigt, beim ersten Start verfügbar sind.

  • Wenn Sie Anwendungseinstellungen mithilfe von Vorlagen hinzufügen oder aktualisieren, stellen Sie sicher, dass Sie alle vorhandenen Einstellungen in die Aktualisierung einbeziehen. Sie müssen dies tun, weil die zugrunde liegenden REST-API-Aufrufe zur Aktualisierung die gesamte /config/appsettings-Ressource ersetzen. Wenn Sie die vorhandenen Einstellungen entfernen, kann Ihre Funktions-App nicht mehr ausgeführt werden. Einzelne Anwendungseinstellungen können Sie stattdessen programmgesteuert über die Azure CLI, Azure PowerShell oder das Azure-Portal aktualisieren. Weitere Informationen finden Sie unter Verwenden von Anwendungseinstellungen.

Slotbereitstellung

Mit Functions können Sie verschiedene Versionen Ihres Codes für eindeutige Endpunkte in Ihrer Funktions-App bereitstellen. Diese Option erleichtert die Entwicklung, Überprüfung und Bereitstellung von Funktionsaktualisierungen, ohne in der Produktion laufende Funktionen zu beeinträchtigen. Bereitstellungsslots sind eine Funktion von Azure App Service. Die Anzahl der verfügbaren Slots hängt von Ihrem Hostingplan ab. Weitere Informationen finden Sie unter Funktionen der Azure Functions Bereitstellungsslots.

Eine Slot-Ressource wird auf die gleiche Weise definiert wie eine Funktions-App-Ressource (Microsoft.Web/sites), allerdings verwenden Sie stattdessen den Ressourcenbezeichner Microsoft.Web/sites/slots. Ein Beispiel für eine Bereitstellung (sowohl in Bicep- als auch in ARM-Vorlagen), bei der sowohl ein Produktions- als auch ein Staging-Slot in einem Premium-Plan erstellt wird, finden Sie unter Azure Funktions-App mit einem Bereitstellungsslot.

Informationen zum Austauschen von Slots mithilfe von Vorlagen finden Sie unter Automatisieren mit Resource Manager-Vorlagen.

Denken Sie an die folgenden Punkte, wenn Sie mit der Slotbereitstellung arbeiten:

  • Legen Sie die Einstellung WEBSITE_CONTENTSHARE in der Definition des Bereitstellungsslots nicht explizit fest. Diese Einstellung wird beim Erstellen der App im Bereitstellungsslot für Sie generiert.

  • Wenn Sie Slots austauschen, gelten einige Anwendungseinstellungen als „permanent“, d.h. sie bleiben auf dem Slot und nicht auf dem Code, der ausgetauscht wird. Sie können eine solche Sloteinstellung definieren, indem Sie "slotSetting":true in die spezifische Anwendungseinstellungsdefinition in Ihrer Vorlage einschließen. Weitere Informationen finden Sie unter Einstellungen verwalten.

Gesicherte Bereitstellungen

Sie können Ihre Funktions-App in einer Bereitstellung erstellen, in der eine oder mehrere der Ressourcen durch die Integration mit virtuellen Netzwerken gesichert wurden. Die virtuelle Netzwerkintegration für Ihre Funktions-App wird durch eine Microsoft.Web/sites/networkConfig-Ressource definiert. Diese Integration hängt sowohl von der referenzierten Funktions-App als auch von den virtuellen Netzwerkressourcen ab. Ihre Funktions-App kann auch von anderen privaten Netzwerkressourcen abhängen, z. B. von privaten Endpunkten und Routen. Weitere Informationen finden Sie unter Netzwerkoptionen von Azure Functions.

Diese Projekte bieten Bicep-basierte Beispiele für die Bereitstellung Ihrer Funktions-Apps in einem virtuellen Netzwerk, auch mit Einschränkungen beim Netzwerkzugang:

Beim Erstellen einer Bereitstellung, die ein gesichertes Speicherkonto verwendet, müssen Sie die WEBSITE_CONTENTSHARE-Einstellung explizit festlegen und die Dateifreigaberessource erstellen, die in dieser Einstellung genannt ist. Stellen Sie sicher, dass Sie eine Microsoft.Storage/storageAccounts/fileServices/shares Ressource mit dem Wert von WEBSITE_CONTENTSHARE, wie in diesem Beispiel gezeigt (ARM-Vorlage|Bicep-Datei) erstellen. Außerdem müssen Sie die Siteeigenschaft vnetContentShareEnabled auf „true“ festlegen.

Hinweis

Wenn diese Einstellungen nicht Teil einer Bereitstellung sind, die ein gesichertes Speicherkonto verwendet, wird während der Bereitstellungsüberprüfung dieser Fehler angezeigt: Could not access storage account using provided connection string.

Diese Projekte bieten sowohl Bicep- als auch ARM-Vorlagenbeispiele für die Bereitstellung Ihrer Funktions-Apps in einem virtuellen Netzwerk, auch mit Einschränkungen beim Netzwerkzugang:

Eingeschränktes Szenario Beschreibung
Erstellen einer Funktions-App mit Virtual Network-Integration Ihre Funktions-App wird in einem virtuellen Netzwerk mit vollem Zugriff auf die Ressourcen dieses Netzwerks erstellt. Der ein- und ausgehende Zugriff auf Ihre Funktions-App ist nicht eingeschränkt. Weitere Informationen finden Sie unter Integration des virtuellen Netzwerks.
Erstellen einer Funktions-App, die auf ein gesichertes Speicherkonto zugreift Ihre erstellte Funktions-App verwendet ein gesichertes Speicherkonto, auf das Functions mit Hilfe privater Endpunkte zugreift. Weitere Informationen finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.
Erstellen einer Funktions-App und eines Speicherkontos, die beide private Endpunkte verwenden Auf Ihre erstellte Funktions-App kann nur über private Endpunkte zugegriffen werden, und sie verwendet private Endpunkte für den Zugriff auf Speicherressourcen. Weitere Informationen finden Sie unter Private Endpunkte.

Einstellungen für eingeschränkte Netzwerke

Möglicherweise müssen Sie diese Einstellungen auch verwenden, wenn Ihre Funktions-App Netzwerkbeschränkungen unterliegt:

Einstellung Wert Beschreibung
WEBSITE_CONTENTOVERVNET 1 Anwendungseinstellung, die es Ihrer Funktions-App ermöglicht, zu skalieren, wenn das Speicherkonto auf ein virtuelles Netzwerk beschränkt ist. Weitere Informationen finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.
vnetrouteallenabled 1 Website-Einstellung, die den gesamten Datenverkehr der Funktions-App zur Verwendung des virtuellen Netzwerks zwingt. Weitere Informationen finden Sie unter Integration des regionalen virtuellen Netzwerks. Diese Websiteeinstellung ersetzt die Anwendungseinstellung WEBSITE_VNET_ROUTE_ALL.

Überlegungen zu Netzwerkeinschränkungen

Wenn Sie den Zugriff auf das Speicherkonto über die privaten Endpunkte beschränken, können Sie nicht über das Portal oder ein Gerät außerhalb des virtuellen Netzwerks auf das Speicherkonto zugreifen. Sie können den Zugriff auf Ihre gesicherte IP-Adresse oder Ihr virtuelles Netzwerk im Speicherkonto ermöglichen, indem Sie die Standard-Netzwerkzugriffsregel verwalten.

Funktionszugriffsschlüssel

Funktionszugriffsschlüssel auf Hostebene werden als Azure-Ressourcen definiert. Das bedeutet, dass Sie Hostschlüssel in Ihren ARM-Vorlagen und Bicep-Dateien erstellen und verwalten können. Ein Hostschlüssel wird als Ressource vom Typ Microsoft.Web/sites/host/functionKeys definiert. In diesem Beispiel wird ein Zugriffsschlüssel namens my_custom_key auf der Hostebene erstellt, wenn die Funktions-App erstellt wird:

resource functionKey 'Microsoft.Web/sites/host/functionKeys@2022-09-01' = {
  name: '${parameters('name')}/default/my_custom_key'
  properties: {
    name: 'my_custom_key'
  }
  dependsOn: [
    resourceId('Microsoft.Web/Sites', parameters('name'))
  ]
}

In diesem Beispiel ist der Parameter name der Name der neuen Funktions-App. Sie müssen eine dependsOn-Einstellung einschließen, um sicherzustellen, dass der Schlüssel mit der neuen Funktions-App erstellt wird. Das properties-Objekt des Hostschlüssels kann auch eine value-Eigenschaft enthalten, die zum Festlegen eines bestimmten Schlüssels verwendet werden kann.

Wenn Sie die value-Eigenschaft nicht festlegen, generiert Functions automatisch einen neuen Schlüssel für Sie, wenn die Ressource erstellt wird. Dies wird empfohlen. Weitere Informationen zu Zugriffsschlüsseln (einschließlich Informationen zu bewährten Methoden für die Verwendung von Zugriffsschlüsseln) finden Sie unter Verwenden von Zugriffsschlüsseln in Azure Functions.

Erstellen der Vorlage

Expert*innen im Umgang mit Bicep- oder ARM-Vorlagen können ihre Bereitstellungen mit einem einfachen Texteditor manuell codieren. Für den Rest von uns gibt es mehrere Möglichkeiten, den Entwicklungsprozess zu vereinfachen:

  • Visual Studio Code: Es gibt Erweiterungen, die Ihnen helfen, sowohl mit Bicep-Dateien als auch mit ARM-Vorlagen zu arbeiten. Sie können diese Tools verwenden, um sicherzustellen, dass Ihr Code korrekt ist, und sie bieten einige grundlegende Validierungsfunktionen.

  • Azure-Portal: Wenn Sie Ihre Funktions-App und die zugehörigen Ressourcen im Portal erstellen, finden Sie auf dem letzten Bildschirm Überprüfen + Erstellen einen Link Vorlage für Automatisierung herunterladen.

    Laden Sie den Vorlagenlink aus dem Azure Functions-Erstellungsprozess im Azure-Portal herunter.

    Dieser Link zeigt Ihnen die ARM-Vorlage, die auf der Grundlage der von Ihnen im Portal gewählten Optionen erstellt wurde. Diese Vorlage kann etwas komplex erscheinen, wenn Sie eine Funktions-App mit vielen neuen Ressourcen erstellen. Sie ist jedoch eine gute Referenz dafür, wie Ihre ARM-Vorlage aussehen kann.

Überprüfen der Vorlage

Wenn Sie Ihre Bereitstellungsvorlagendatei manuell erstellen, ist es wichtig, dass Sie Ihre Vorlage vor der Bereitstellung überprüfen. Alle Bereitstellungsmethoden überprüfen die Syntax Ihrer Vorlage und geben eine validation failed-Fehlermeldung aus, wie im folgenden JSON-formatierten Beispiel gezeigt:

{"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The resource 'Microsoft.Web/sites/func-xyz' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'.","additionalInfo":[{"type":"TemplateViolation","info":{"lineNumber":0,"linePosition":0,"path":""}}]}}

Mit den folgenden Methoden können Sie Ihre Vorlage vor der Bereitstellung überprüfen:

Die folgende Aufgabe zur Bereitstellung von Azure-Ressourcengruppen v2 mit deploymentMode: 'Validation' weist Azure Pipelines an, die Vorlage zu validieren.

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: 'Resource Group'
    subscriptionId: # Required subscription ID
    action: 'Create Or Update Resource Group'
    resourceGroupName: # Required resource group name
    location: # Required when action == Create Or Update Resource Group
    templateLocation: 'Linked artifact'
    csmFile: # Required when  TemplateLocation == Linked Artifact
    csmParametersFile: # Optional
    deploymentMode: 'Validation'

Sie können auch eine Testressourcengruppe erstellen, um Preflight- und Bereitstellungsfehler zu finden.

Bereitstellen der Vorlage

Sie können Ihre Bicep-Datei und -Vorlage mit einer der folgenden Methoden bereitstellen:

Schaltfläche zum Bereitstellen in Azure

Hinweis

Diese Methode bietet zurzeit keine Unterstützung für die Bereitstellung von Bicep-Dateien.

Ersetzen Sie <url-encoded-path-to-azuredeploy-json> durch eine URL-codierte Version des Rohpfads Ihrer Datei azuredeploy.json in GitHub.

Hier ist ein Beispiel unter Verwendung von Markdown:

[![Deploy to Azure](https://azuredeploy.net/deploybutton.png)](https://portal.azure.com/#create/Microsoft.Template/uri/<url-encoded-path-to-azuredeploy-json>)

Hier ist ein Beispiel unter Verwendung von HTML:

<a href="https://portal.azure.com/#create/Microsoft.Template/uri/<url-encoded-path-to-azuredeploy-json>" target="_blank"><img src="https://azuredeploy.net/deploybutton.png"></a>

Bereitstellen mit PowerShell

Mit den folgenden PowerShell-Befehlen wird eine Ressourcengruppe erstellt und eine Bicep-Datei oder ARM-Vorlage bereitgestellt, über die eine Funktions-App mit ihren erforderlichen Ressourcen erstellt wird. Um diese Befehle lokal ausführen zu können, müssen Sie Azure PowerShell installiert haben. Führen Sie Connect-AzAccount aus, um sich anzumelden.

# Register Resource Providers if they're not already registered
Register-AzResourceProvider -ProviderNamespace "microsoft.web"
Register-AzResourceProvider -ProviderNamespace "microsoft.storage"

# Create a resource group for the function app
New-AzResourceGroup -Name "MyResourceGroup" -Location 'West Europe'

# Deploy the template
New-AzResourceGroupDeployment -ResourceGroupName "MyResourceGroup" -TemplateFile main.bicep  -Verbose

Um diese Bereitstellung zu testen, können Sie eine Vorlage wie die folgende verwenden, mit der eine Funktions-App unter Windows in einem Verbrauchsplan erstellt wird.

Nächste Schritte

Machen Sie sich näher mit dem Entwickeln und Konfigurieren von Azure Functions vertraut.