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

Um die Bereitstellung Ihrer Funktions-App zu automatisieren, verwenden Sie eine Bicep-Datei oder eine Azure Resource Manager-Vorlage (ARM-Vorlage). Während der Bereitstellung können Sie vorhandene Azure-Ressourcen verwenden oder neue erstellen.

Mithilfe der Bereitstellungsautomatisierung können Sie sowohl die Infrastruktur als Code (IaC) als auch die kontinuierliche Integration und Bereitstellung (CI/CD) für Ihre Produktions-Apps nutzen:

  • Konsistenz: Definieren Sie Ihre Infrastruktur im Code, um konsistente Bereitstellungen in allen Umgebungen sicherzustellen.
  • Versionssteuerung: Verfolgen Sie Änderungen an Ihrer Infrastruktur und Anwendungskonfigurationen in der Quellcodeverwaltung zusammen mit Dem Projektcode.
  • Automatisierung: Automatisieren Sie die Bereitstellung, wodurch manuelle Fehler reduziert und der Veröffentlichungsprozess verkürzt wird.
  • Skalierbarkeit: Einfache Replikation der Infrastruktur für mehrere Umgebungen, z. B. Entwicklung, Tests und Produktion.
  • Notfallwiederherstellung: Erstellen Sie die Infrastruktur nach Fehlern oder während der Migration schnell neu.

In diesem Artikel erfahren Sie, wie Sie die Erstellung von Azure Ressourcen und Bereitstellungskonfigurationen für Azure Functions automatisieren. Weitere Informationen zur kontinuierlichen Bereitstellung ihres Projektcodes finden Sie unter Continuous deployment for Azure Functions.

Der Vorlagencode zum Erstellen der erforderlichen Azure Ressourcen hängt von den gewünschten Hostingoptionen für Ihre Funktions-App ab. Dieser Artikel unterstützt die folgenden Hostingoptionen:

Hostingoption Bereitstellungstyp Beispielvorlagen
Flex-Verbrauchsplan Code-only Bicep
ARM-Vorlage
Terraform
Premium-Plan Code | Container Bicep
ARM-Vorlage
Dedizierter Plan Code | Container Bicep
ARM-Vorlage
Azure-Container-Apps Container-only Bicep
Verbrauchsplan(veraltet) Code-only Bicep
ARM-Vorlage

Verwenden Sie für neue serverlose Funktions-Apps den Flex-Verbrauchsplan.
Der Verbrauchsplan ist ein veralteter Hostingplan. Migrieren Sie für vorhandene Apps zum Flex Consumption-Plan.

Stellen Sie sicher, dass Sie Ihren Hostingplan oben im Artikel auswählen.

Important

Funktions-Apps, die weiterhin die Version 3 Laufzeitumgebung, die das Ende des Lebenszyklus erreicht hat, unter Linux in einem Verbrauchsplan ausführen, stoppen ihren Betrieb nach dem 30. September 2026. Um Dienstunterbrechungen zu vermeiden, migrieren Sie Ihre App zur v4-Laufzeit.

Die Option zum Hosten von Funktions-Apps unter Linux in einem Verbrauchsplan wird am 30. September 2028 eingestellt. Der Linux-Verbrauchsplan erhält keine neuen Features oder Sprachversionen. Apps, die auf Windows in einem Verbrauchsplan ausgeführt werden, sind derzeit nicht betroffen. Migrieren Sie Ihre Apps zum Flex-Nutzungsplan vor dem Deaktivierungsdatum.

Berücksichtigen Sie bei der Verwendung dieses Artikels Folgendes:

  • Beispiele werden als einzelne Abschnitte für bestimmte Ressourcen gezeigt. Eine Vielzahl umfassender Beispiele für vollständige Bicep-Dateien und ARM-Vorlagen finden Sie im Abschnitt diese Bereitstellung von Funktionsanwendungen.
  • Beispiele werden als einzelne Abschnitte für bestimmte Ressourcen gezeigt.

Erforderliche Ressourcen

Sie müssen diese Ressourcen für eine Azure Functions gehostete Bereitstellung erstellen oder konfigurieren:

Resource Requirement Syntax- und Eigenschaftenreferenz
Ein Speicherkonto Required Microsoft. Storage/storageAccounts
Eine Application Insights-Komponente Recommended Microsoft. Insights/components*
Ein Hostingplan Required Microsoft.Web/Serverfarmen
Eine Funktions-App Required Microsoft.Web/sites

Sie müssen diese Ressourcen für eine Azure Functions gehostete Bereitstellung erstellen oder konfigurieren:

Resource Requirement Syntax- und Eigenschaftenreferenz
Ein Speicherkonto Required Microsoft. Storage/storageAccounts
Eine Application Insights-Komponente Recommended Microsoft. Insights/components*
Eine Funktions-App Required Microsoft.Web/sites

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

Resource Requirement Syntax- und Eigenschaftenreferenz
Ein Speicherkonto Required Microsoft. Storage/storageAccounts
Eine Application Insights-Komponente Recommended Microsoft. Insights/components*
Eine verwaltete Umgebung Required Microsoft.App/managedEnvironments
Eine Funktions-App Required Microsoft.Web/sites

*Wenn Sie noch nicht über einen Log Analytics-Arbeitsbereich verfügen, den Ihre Application Insights-Instanz verwenden kann, müssen Sie diese Ressource auch erstellen.

Wenn Sie mehrere Ressourcen in einer einzelnen Bicep Datei oder ARM-Vorlage bereitstellen, ist die Reihenfolge, in der Ressourcen erstellt werden, wichtig. Diese Anforderung ergibt sich aus Abhängigkeiten zwischen 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 Sie die Reihenfolge für die Bereitstellung von Ressourcen in ARM-Vorlagen oder Resource-Abhängigkeiten in Bicep.

Prerequisites

  • Diese Beispiele funktionieren im Kontext einer vorhandenen Ressourcengruppe.
  • Sowohl Application Insights als auch Speicherprotokolle erfordern einen vorhandenen Azure Log Analytics-Arbeitsbereich. Sie können Arbeitsbereiche zwischen Diensten freigeben. Um die Leistung zu verbessern, erstellen Sie einen Arbeitsbereich in jeder geografischen Region. Ein Beispiel zum Erstellen eines Log Analytics Arbeitsbereichs finden Sie unter Create a Log Analytics workspace. Die vollqualifizierte Arbeitsbereichsressourcen-ID finden Sie auf einer Arbeitsbereichsseite im Azure-Portal unter Einstellungen>Eigenschaften>Ressourcen-ID.
  • In diesem Artikel wird davon ausgegangen, 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.

Erstellen eines Speicherkontos

Für alle Funktions-Apps ist ein Azure Speicherkonto erforderlich. Sie benötigen ein allgemeines Konto, das Blobs, Tabellen, Warteschlangen und Dateien unterstützt. Weitere Informationen finden Sie unter Azure Functions Speicherkontoanforderungen.

Important

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.

In diesem Beispielabschnitt wird ein Standard-v2-Speicherkonto 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
    minimumTlsVersion: 'TLS1_2'
  }
}

Weitere Informationen finden Sie in der kompletten main.bicep Datei im Vorlagenrepository.

Weitere Informationen finden Sie in der vollständigen storage-PrivateEndpoint.bicep Datei im Beispielrepository.

Die Funktions-App benötigt eine Verbindung mit diesem Speicherkonto. Konfigurieren Sie diese Verbindung mithilfe der AzureWebJobsStorage Einstellung. Weitere Informationen finden Sie unter Anwendungskonfiguration.

Tip

Um eine bessere Sicherheit zu gewährleisten, fügen Sie allowSharedKeyAccess: false Ihren Speicherkontoeigenschaften hinzu, und verwenden Sie verwaltete identitätsbasierte Verbindungen anstelle von Verbindungszeichenfolgen. Die Beispiele für den Flex-Verbrauch-Plan in diesem Artikel verwenden diesen Ansatz, einschließlich der AzureWebJobsStorage__* identitätsbasierten Einstellungen und einer vom System zugewiesenen verwalteten Identität. Weitere Informationen finden Sie unter Verbindung mit dem Host-Speicher mit einer Identität.

Tip

Legen Sie für eine bessere Sicherheit für Ihr Speicherkonto fest allowSharedKeyAccessfalse , und verwenden Sie verwaltete identitätsbasierte Verbindungen anstelle von Verbindungszeichenfolgen. Weitere Informationen finden Sie unter Verbinden mit Host-Speicher mit einer Identität.

Important

Die Pläne "Elastic Premium" und "Verbrauch" verwenden Azure Files für die Inhaltsfreigabe, und Azure Files unterstützt derzeit keine auf verwalteten Identitäten basierenden Verbindungen. Diese Einschränkung bedeutet, dass für diese Pläne ein gemeinsam genutzter Schlüsselzugriff auf das Speicherkonto erforderlich ist. Daher sollte allowSharedKeyAccess nicht auf false gesetzt werden. Wenn Sie Verbindungszeichenfolgen verwenden müssen, speichern Sie sie in Azure Key Vault, und verwenden Sie Key Vault-Verweise in Ihren App-Einstellungen, anstatt Schlüssel direkt zu speichern. Wenn Sie die Azure Files-Abhängigkeit entfernen möchten, lesen Sie " Erstellen einer App ohne Azure Files".

Bereitstellungscontainer

Um eine App bereitzustellen, die im Flex-Verbrauchsplan ausgeführt wird, benötigen Sie 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.

Sie müssen dieses Bereitstellungskonto konfigurieren, 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:

}

// Azure Functions Flex Consumption
module functionApp 'br/public:avm/res/web/site:0.16.0' = {
  name: 'functionapp'
  scope: rg
  params: {
    kind: 'functionapp,linux'
    name: functionAppName_resolved
    location: location
    tags: union(tags, { 'azd-service-name': 'api' })
    serverFarmResourceId: appServicePlan.outputs.resourceId
    managedIdentities: {
      systemAssigned: true
    }
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.outputs.primaryBlobEndpoint}${deploymentStorageContainerName}'
          authentication: {
            type: 'SystemAssignedIdentity'
          }

In diesem Beispiel wird gezeigt, wie Sie das AVM für Speicherkonten verwenden, um den BLOB-Speichercontainer zusammen mit dem Speicherkonto zu erstellen. Den Codeausschnitt im Kontext finden Sie unter dieses Bereitstellungsbeispiel.

Konfigurieren Sie andere Bereitstellungseinstellungen mit der App selbst.

Aktivieren von Speicherprotokollen

Da das Speicherkonto für wichtige Funktions-App-Daten verwendet wird, überwachen Sie das Konto auf Änderungen dieser Inhalte. Um Ihr Speicherkonto zu überwachen, konfigurieren Sie Azure Monitor-Ressourcenprotokolle für Azure Storage. 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@2023-05-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
      }
    ]
  }
}

Sie können denselben Arbeitsbereich für die später definierte Application Insights-Ressource verwenden. Weitere Informationen, einschließlich der Verwendung dieser Protokolle, finden Sie unter Monitoring Azure Storage.

Erstellen einer Application Insights-Ressource

Verwenden Sie Application Insights, um Die Ausführung Ihrer Funktions-App zu überwachen. Application Insights erfordert jetzt einen Azure Log Analytics Arbeitsbereich, der freigegeben werden kann. 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 unter Azure Log Analytics Workspace.

Definieren Sie in diesem Beispielabschnitt die Application Insights-Ressource mit dem Typ Microsoft.Insights/components und der Art web:

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>'
  }
}

Weitere Informationen finden Sie in der kompletten main.bicep Datei im Vorlagenrepository.

Sie müssen die Verbindung zur Funktions-App mithilfe der APPLICATIONINSIGHTS_CONNECTION_STRING Anwendungseinstellung herstellen. Weitere Informationen finden Sie unter Anwendungskonfiguration.

Die Beispiele in diesem Artikel ermitteln 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

Sie müssen explizit den Hostingplan für Apps definieren, die in einem Azure Functions Flex-Verbrauchsplan, Premium-Plan oder dedizierten Plan (App Service) gehostet werden.

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 tier für den FlexConsumption-Wert verwenden.

In diesem Beispielabschnitt wird ein Flex-Verbrauchsplan erstellt:

  scaleAndConcurrency: {
    maximumInstanceCount: maximumInstanceCount
    instanceMemoryMB: instanceMemoryMB
  }
  runtime: { 
    name: functionAppRuntime
    version: functionAppRuntimeVersion
  }
}
siteConfig: {
  alwaysOn: false
}
configs: [{
  name: 'appsettings'
  properties:{

In diesem Beispiel werden die AVM für App Service-Pläne verwendet. Den Codeausschnitt im Kontext finden Sie unter dieses Bereitstellungsbeispiel.

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

Der Premium-Plan bietet die gleiche Skalierung wie der Verbrauchsplan, umfasst jedoch dedizierte Ressourcen und zusätzliche Funktionen. Weitere Informationen finden Sie unter Azure Functions Premium-Plan.

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 Hostingplan für Funktionen definieren, hängt davon ab, ob Ihre Funktions-App auf Windows oder auf Linux ausgeführt wird. In diesem Beispielabschnitt wird ein EP1 Plan erstellt:

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

Weitere Informationen finden Sie in der kompletten main.bicep Datei im Vorlagenrepository.

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

Im dedizierten Dienst (App Service) Plan wird Ihre Function-App auf dedizierten virtuellen Computern auf Basis-, Standard- und Premium-SKUs in App Service-Plänen ausgeführt, ähnlich wie Web-Apps. Weitere Informationen finden Sie unter "Dedizierter Plan".

Eine Beispiel-Bicep-Datei oder Azure Resource Manager-Vorlage finden Sie unter Function app auf 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 auf Windows oder unter Linux ausgeführt wird:

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

Weitere Informationen finden Sie in der kompletten main.bicep Datei im Vorlagenrepository.

Erstellen des Hostingplans

Für den Verbrauchhostingplan müssen Sie keine Ressource explizit definieren. Wenn Sie diese Ressourcendefinition überspringen, erstellt oder wählt das Portal automatisch einen Plan pro Region aus, wenn Sie die Funktions-App-Ressource selbst erstellen.

Sie können einen Verbrauchsplan explizit als einen speziellen serverfarm Ressourcentyp definieren. Legen Sie die Eigenschaften computeMode und sku auf Dynamic fest. 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 auf Windows oder auf Linux ausgeführt wird.

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

Weitere Informationen finden Sie in der kompletten main.bicep Datei im Vorlagenrepository.

Erstellen der Funktions-App

Definieren Sie die Funktions-App-Ressource als Ressource vom Typ Microsoft.Web/sites mit einer kind Eigenschaft, die enthält functionapp.

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

Eine Liste der Anwendungseinstellungen, die für die Ausführung auf Windows erforderlich sind, finden Sie unter Application configuration. Eine Bicep-Beispieldatei oder azure Resource Manager-Vorlage finden Sie in der Funktions-App, die unter Windows in einer Verbrauchsplanvorlage gehostet wird .

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

Flex Consumption ersetzt viele der standardanwendungseinstellungen und Standortkonfigurationseigenschaften, die in Bicep- und ARM-Vorlagenbereitstellungen verwendet werden. Weitere Informationen finden Sie unter Anwendungskonfiguration.

        AzureWebJobsStorage__blobServiceUri: 'https://${storage.outputs.name}.blob.${environment().suffixes.storage}'
        AzureWebJobsStorage__queueServiceUri: 'https://${storage.outputs.name}.queue.${environment().suffixes.storage}'
        AzureWebJobsStorage__tableServiceUri: 'https://${storage.outputs.name}.table.${environment().suffixes.storage}'

        // Application Insights settings are always included
        APPLICATIONINSIGHTS_CONNECTION_STRING: applicationInsights.outputs.connectionString
        APPLICATIONINSIGHTS_AUTHENTICATION_STRING: 'Authorization=AAD'
    }
    }]
  }
}

// Consolidated Role Assignments
module rbacAssignments 'rbac.bicep' = {
  name: 'rbacAssignments'
  scope: rg
  params: {
    storageAccountName: storage.outputs.name
    appInsightsName: applicationInsights.outputs.name
    managedIdentityPrincipalId: functionApp.outputs.?systemAssignedMIPrincipalId ?? ''
    userIdentityPrincipalId: principalId
    allowUserIdentityPrincipal: !empty(principalId)
  }
}

// Outputs
output AZURE_LOCATION string = location
output AZURE_TENANT_ID string = tenant().tenantId
output AZURE_FUNCTION_NAME string = functionApp.outputs.name
output APPLICATIONINSIGHTS_CONNECTION_STRING string = applicationInsights.outputs.connectionString

In diesem Beispiel wird das AVM für Funktions-Apps verwendet. Den Codeausschnitt im Kontext finden Sie unter dieses Bereitstellungsbeispiel.

Note

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@2024-04-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: '~20'
        }
      ]
    }
  }
}

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

resource functionApp 'Microsoft.Web/sites@2024-04-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: '~20'
        }
      ]
    }
  }
}

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

Bereitstellungsquellen

Verwenden Sie die linuxFxVersion Websiteeinstellung, um einen bestimmten Linux-Container anzufordern, der bei der Erstellung für Ihre App bereitgestellt werden soll. Für den Zugriff auf Bilder in einem privaten Repository benötigen Sie weitere Einstellungen. Weitere Informationen finden Sie unter Anwendungskonfiguration.

Important

Wenn Sie eigene Container erstellen, müssen Sie das Basisimage Ihres Containers auf das neueste unterstützte Basisimage aktualisieren. Unterstützte Basisbilder für Azure Functions sind sprachspezifisch. Siehe Azure Functions Basisimage-Repositories.

Das Functions-Team ist bestrebt, monatliche Updates für diese Basisimages zu veröffentlichen. Regelmäßige Updates umfassen die aktuellen Updates der Nebenversion und Sicherheitsfixes für Functions-Runtime und -Sprachen. Sie sollten Ihren Container regelmäßig anhand des neuesten Basisimages aktualisieren und die aktualisierte Version Ihres Containers erneut bereitstellen. Weitere Informationen finden Sie unter Verwalten von benutzerdefinierten Containern.

Ihre Bicep-Datei oder ARM-Vorlage kann optional auch eine Bereitstellung für Ihren Funktionscode definieren. Diese Bereitstellung kann folgende Methoden umfassen:

Der Flex-Verbrauchsplan verwaltet Ihren Projektcode in einer ZIP-komprimierten Paketdatei in einem Blob-Speichercontainer, der als Bereitstellungscontainer bezeichnet wird. Sie können sowohl das Speicherkonto als auch den Container konfigurieren, das bzw. der für die Bereitstellung verwendet wird. Weitere Informationen finden Sie unter "Bereitstellung".

Sie müssen OneDeploy verwenden, um Ihr Codepaket im Bereitstellungscontainer zu veröffentlichen. Während einer ARM-Vorlage oder Bicep-Bereitstellung können Sie diesen Schritt ausführen, indem Sie eine Paketquelle definieren , die die /onedeploy Erweiterung verwendet. Wenn Sie stattdessen ihr Paket direkt in den Container hochladen möchten, wird das Paket nicht automatisch bereitgestellt.

Bereitstellungscontainer

Legen Sie das spezifische Speicherkonto und den für Bereitstellungen verwendeten Container, die Authentifizierungsmethode und die Anmeldeinformationen im functionAppConfig.deployment.storage Element der properties Website fest. Der Container und alle Anwendungseinstellungen müssen vorhanden sein, wenn Sie die App erstellen. Ein Beispiel zum Erstellen 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):

// Consolidated Role Assignments
module rbacAssignments 'rbac.bicep' = {
  name: 'rbacAssignments'
  scope: rg
  params: {
    storageAccountName: storage.outputs.name
    appInsightsName: applicationInsights.outputs.name
    managedIdentityPrincipalId: functionApp.outputs.?systemAssignedMIPrincipalId ?? ''
    userIdentityPrincipalId: principalId
    allowUserIdentityPrincipal: !empty(principalId)
  }
}

// Outputs
output AZURE_LOCATION string = location
output AZURE_TENANT_ID string = tenant().tenantId
output AZURE_FUNCTION_NAME string = functionApp.outputs.name
output APPLICATIONINSIGHTS_CONNECTION_STRING string = applicationInsights.outputs.connectionString

In diesem Beispiel wird das AVM für Funktions-Apps verwendet. Den Codeausschnitt im Kontext finden Sie unter dieses Bereitstellungsbeispiel.

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

module storageRoleAssignment_User 'br/public:avm/ptn/authorization/resource-role-assignment:0.1.2' = if (allowUserIdentityPrincipal && !empty(userIdentityPrincipalId)) {
  name: 'storageRoleAssignment-User-${uniqueString(storageAccount.id, userIdentityPrincipalId)}'
  params: {
    resourceId: storageAccount.id
    roleDefinitionId: roleDefinitions.storageBlobDataOwner
    principalId: userIdentityPrincipalId
    principalType: 'User'
    description: 'Storage Blob Data Owner role for user identity (development/testing)'
    roleName: 'Storage Blob Data Owner'
  }
}

In diesem Beispiel wird das AVM für die Rollenzuordnung mit Ressourcenbereich verwendet. Den Codeausschnitt im Kontext finden Sie unter dieses Bereitstellungsbeispiel.

In diesem Beispiel müssen Sie den GUID-Wert für die Rolle kennen, die Sie zuweisen. Um diesen ID-Wert für einen schönen Rollennamen zu erhalten, verwenden Sie den Befehl "az role definition list", wie im folgenden Beispiel gezeigt:

az role definition list --output tsv --query "[?roleName=='Storage Blob Data Owner'].{name:name}"

Wenn Sie eine Verbindungszeichenfolge anstelle von verwalteten Identitäten verwenden, legen Sie `authentication.type` auf `StorageAccountConnectionString` fest und setzen Sie `authentication.storageAccountConnectionStringName` auf den Namen der Anwendungseinstellung, die die Verbindungszeichenfolge für das Bereitstellungsspeicherkonto enthält.

Bereitstellungspaket

Im Flex-Verbrauchsplan wird OneDeploy für die Bereitstellung Ihres Codeprojekts verwendet. Das Codepaket selbst ist identisch mit dem Paket, das Sie für die Zip-Bereitstellung in anderen Funktionen-Hostingplänen verwenden. Der Name der Paketdatei muss jedoch sein released-package.zip.

Verwenden Sie die Ressourcendefinition /onedeploy für die Remote-URL, die das Bereitstellungspaket enthält, um ein OneDeploy-Paket in Ihre Vorlage einzuschließen. Der Functions-Host muss sowohl auf diese Remotepaketquelle als auch auf den Bereitstellungscontainer Zugriff haben.

In diesem Beispiel wird einer vorhandenen App eine OneDeploy-Quelle 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 for released-package.zip.')
param packageUri string

resource functionAppName_OneDeploy 'Microsoft.Web/sites/extensions@2022-09-01' = {
  name: '${functionAppName}/onedeploy'
  location: location
  properties: {
    packageUri: packageUri
    remoteBuild: false 
  }
}

Ihre Bicep-Datei oder ARM-Vorlage kann optional auch eine Bereitstellung für Ihren Funktionscode mithilfe eines ZIP-Bereitstellungspakets definieren.

Um Ihre Anwendung mithilfe von Azure Resource Manager erfolgreich bereitzustellen, müssen Sie verstehen, wie Ressourcen in Azure bereitgestellt werden. In den meisten Beispielen wenden Sie Konfigurationen auf oberster Ebene mithilfe von siteConfig an. Legen Sie diese Konfigurationen auf oberster Ebene fest, da sie Informationen an das Funktionslaufzeit- und Bereitstellungsmodul übermitteln. Die Bereitstellungs-Engine benötigt Informationen auf höchster Ebene, bevor die untergeordnete sourcecontrols/web Ressource angewendet wird. Obwohl Sie diese Einstellungen in der Ressource auf untergeordneter Ebene config/appSettings konfigurieren können, muss Ihre Funktions-App in einigen Fällen bereitgestellt werden, bevorconfig/appSettings sie angewendet wird.

zip-Bereitstellungspaket

Die Zip-Bereitstellung ist die empfohlene Methode, um den Code Ihrer Funktions-App bereitzustellen. 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. Bei Verwendung der Ressourcenbereitstellungsautomatisierung 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.

Legen Sie für einen Verbrauchsplan unter Linux stattdessen den URI des Bereitstellungspakets direkt in der Einstellung WEBSITE_RUN_FROM_PACKAGE fest, wie in dieser Beispielvorlage gezeigt.

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@2024-04-01' = {
  name: '${functionAppName}/ZipDeploy'
  location: location
  properties: {
    packageUri: packageUri
  }
}

Beachten Sie die folgenden Überlegungen beim Einschließen von ZIP-Bereitstellungsressourcen in Ihre Vorlage:

  • Dies packageUri muss ein Speicherort sein, auf den Funktionen zugreifen können. Erwägen Sie die Verwendung von Azure Blob Storage mit einer freigegebenen Zugriffssignatur (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.

  • Wenn Sie WEBSITE_RUN_FROM_PACKAGE auf einen URI festlegen, müssen Sie Trigger manuell synchronisieren.

  • Legen Sie beim Hinzufügen oder Aktualisieren von Einstellungen immer alle erforderlichen Anwendungseinstellungen in der appSettings Auflistung fest. Das Update entfernt vorhandene Einstellungen, die Sie nicht explizit festlegen. Weitere Informationen finden Sie unter Anwendungskonfiguration.

  • Funktionen unterstützen 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 deployment for Azure Functions.

Remotebuilds

Bei dem Bereitstellungsprozess wird davon ausgegangen, dass die .zip Datei, die Sie verwenden, oder eine ZIP-Bereitstellung eine einsatzbereite App enthält. Diese Annahme bedeutet, dass standardmäßig keine Anpassungen ausgeführt werden.

In einigen Szenarien müssen Sie Ihre App remote neu erstellen. Ein Beispiel ist, 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:

Wenn Sie eine App für Windows bereitstellen, führt der Bereitstellungsprozess sprachspezifische Befehle aus, z dotnet restore . B. für C#-Apps oder npm install für Node.js-Apps.

Um dieselben Buildprozesse zu aktivieren, die Sie mit kontinuierlicher Integration erhalten, fügen Sie SCM_DO_BUILD_DURING_DEPLOYMENT=true zu Ihren Anwendungseinstellungen in Ihrem Bereitstellungscode hinzu und entfernen Sie die WEBSITE_RUN_FROM_PACKAGE-Einstellung vollständig.

Linux-Container

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

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 Anwendungskonfiguration.

resource functionApp 'Microsoft.Web/sites@2024-04-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: '~20'
        }
        {
          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
  ]
}

Beim Bereitstellen von containerisierten Funktionen in Azure Container Apps muss Ihre Vorlage folgendes ausführen:

  • 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-Auflistung der Website hinzu, wenn Sie eine Microsoft.App/managedEnvironments Ressource gleichzeitig mit der Website erstellen.

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

resource functionApp 'Microsoft.Web/sites@2024-04-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
  ]
}

Anwendungskonfiguration

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

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

Sie verwalten diese Anwendungskonfigurationen in functionAppConfig:

Behavior Einstellung in functionAppConfig
Jederzeit bereite Instanzen scaleAndConcurrency.alwaysReady
Bereitstellungsquelle deployment
Instanzgröße scaleAndConcurrency.instanceMemoryMB
HTTP-Triggerparallelität scaleAndConcurrency.triggers.http.perInstanceConcurrency
Sprachlaufzeit runtime.name
Sprachversion runtime.version
Maximale Anzahl von Instanzen scaleAndConcurrency.maximumInstanceCount
Strategie für Websiteupdates siteUpdateStrategy.type

Der Flex-Verbrauchsplan unterstützt auch folgende Anwendungseinstellungen:

Funktionen bieten die folgenden Optionen zum Konfigurieren ihrer Funktions-App in Azure:

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

Für die Eigenschaft siteConfig sind folgende Websiteeinstellungen erforderlich:

Diese Websiteeinstellungen sind nur erforderlich, wenn verwaltete Identitäten verwendet werden, um das Image aus einer Azure Container Registry-Instanz abzurufen:

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

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

Diese Einstellungen sind nur erforderlich, wenn die Bereitstellung aus einer privaten Containerregistrierung aus erfolgt:

Beachten Sie diese Überlegungen beim Arbeiten mit Website- und Anwendungseinstellungen mithilfe von Bicep Dateien oder ARM-Vorlagen:

  • Die optionale alwaysReady-Einstellung enthält ein Array von mindestens einem {name,instanceCount}-Objekt, eines für jede Skalierungsgruppe pro Funktion. Diese Skalierungsgruppen treffen immer einsatzbereite Skalierungsentscheidungen. In diesem Beispiel wird die Anzahl der stets verfügbaren Instanzen sowohl für die http-Gruppe als auch für eine einzelne Funktion namens helloworld, die einen nicht gruppierten Triggertyp aufweist, festgelegt:
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • Überlegen Sie, wann WEBSITE_CONTENTSHARE in einer automatisierten Bereitstellung festgelegt werden soll. Einen ausführlichen Leitfaden finden Sie in der WEBSITE_CONTENTSHARE-Referenz.
  • Bei der Bereitstellung von Containern legen Sie WEBSITES_ENABLE_APP_SERVICE_STORAGE ebenfalls auf false fest, da der Inhalt Ihrer App im Container selbst bereitgestellt wird.

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

  • Stellen Sie beim Hinzufügen oder Aktualisieren von Anwendungseinstellungen mithilfe von Vorlagen sicher, dass Sie alle vorhandenen Einstellungen in das Update einschließen. 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. Um einzelne Anwendungseinstellungen programmgesteuert zu aktualisieren, können Sie stattdessen die Azure CLI, Azure PowerShell oder das Azure Portal verwenden, um diese Änderungen vorzunehmen. Weitere Informationen finden Sie unter Verwenden von Anwendungseinstellungen.

  • Verwenden Sie nach Möglichkeit verwaltete identitätsbasierte Verbindungen zu anderen Azure-Diensten, einschließlich der AzureWebJobsStorage Verbindung. Weitere Informationen finden Sie unter Konfigurieren einer identitätsbasierten Verbindung.

Bereitstellungen von Slots

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 ausgeführte 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 Azure Functions Deployment Slots.

Sie definieren eine Slotressource auf die gleiche Weise wie eine Funktions-App-Ressource (Microsoft.Web/sites), verwenden aber stattdessen den Microsoft.Web/sites/slots Ressourcenbezeichner. Unter Azure Function App with a Deployment Slot finden Sie ein Beispiel für eine Deployment (in Bicep- und ARM-Vorlagen), die sowohl einen Produktions- als auch einen Staging-Slot in einem Premium-Plan erstellt.

Informationen zum Austauschen von Slots mithilfe von Vorlagen finden Sie unter Automate 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. Der App-Erstellungsprozess im Bereitstellungs-Slot erzeugt diese Einstellung für Sie.

  • Wenn Sie Slots austauschen, gelten einige Anwendungseinstellungen als „permanent“, d. h. sie verbleiben im Slot und nicht im 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 Verwalten von Einstellungen.

Gesicherte Bereitstellungen

Sie können Ihre Funktions-App in einer Bereitstellung erstellen, in der Sie eine oder mehrere der Ressourcen sichern, indem Sie in virtuelle Netzwerke integrieren. Eine Microsoft.Web/sites/networkConfig Ressource definiert die Integration des virtuellen Netzwerks für Ihre Funktions-App. 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 Azure Functions Netzwerkoptionen.

Diese Projekte bieten Bicep-basierte Beispiele für die Bereitstellung Ihrer Funktions-Apps in einem virtuellen Netzwerk, einschließlich Netzwerkzugriffsbeschränkungen:

Wenn Sie eine Bereitstellung erstellen, die ein gesichertes Speicherkonto verwendet, müssen Sie sowohl die WEBSITE_CONTENTSHARE-Einstellung explizit festlegen als auch die in dieser Einstellung benannte Dateifreigaberessource erstellen. Stellen Sie sicher, dass Sie eine Microsoft.Storage/storageAccounts/fileServices/shares Ressource mithilfe des Werts von WEBSITE_CONTENTSHARE, wie in diesem Beispiel gezeigt (ARM-Vorlage|Bicep-Datei) erstellen. Außerdem müssen Sie die Websiteeigenschaft vnetContentShareEnabled auf "true" festlegen.

Note

Wenn diese Einstellungen nicht Teil einer Bereitstellung sind, die ein gesichertes Speicherkonto verwendet, wird dieser Fehler während der Bereitstellungsüberprüfung 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, einschließlich Netzwerkzugriffsbeschränkungen.

Eingeschränktes Szenario Description
Erstellen einer Funktions-App mit virtual network integration Sie erstellen Ihre Funktions-App in einem virtuellen Netzwerk mit vollständigem Zugriff auf Ressourcen in diesem Netzwerk. Der ein- und ausgehende Zugriff auf Ihre Funktions-App ist nicht eingeschränkt. Weitere Informationen finden Sie unter Integration des virtuellen Netzwerks.
Funktions-App erstellen, die auf ein gesichertes Speicherkonto zugreift Ihre erstellte Funktions-App verwendet ein gesichertes Speicherkonto, auf das Functions mithilfe 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 Netzwerkeinschränkungen unterliegt:

Setting Value Description
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 Websiteeinstellung, die für den gesamten Datenverkehr der Funktions-App die Verwendung des virtuellen Netzwerks erzwingt. 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 einschränken, können Sie nicht über das Portal oder ein beliebiges 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

Definieren Sie Funktionszugriffsschlüssel auf Hostebene als Azure-Ressourcen. Mit diesem Ansatz können Sie Hostschlüssel in Ihren ARM-Vorlagen und Bicep-Dateien erstellen und verwalten. Ein Hostschlüssel wird als Ressource vom Typ Microsoft.Web/sites/host/functionKeys definiert. Im folgenden Beispiel wird beim Erstellen der Funktions-App eine Zugriffstaste auf Hostebene mit dem Namen my_custom_key erstellt.

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. Schließlich kann das properties Objekt des Hostschlüssels auch eine value Eigenschaft enthalten, mit der Sie einen bestimmten Schlüssel festlegen können.

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 Zugriffstasten, einschließlich bewährter Sicherheitsmethoden für das Arbeiten mit Zugriffstasten, finden Sie unter Work with access keys in Azure Functions.

Erstellen der Vorlage

Experten mit Bicep- oder ARM-Vorlagen können ihre Bereitstellungen mithilfe eines einfachen Text-Editors manuell codieren. Für den Rest von uns erleichtern mehrere Optionen den Entwicklungsprozess:

  • Visual Studio Code: Erweiterungen stehen zur Verfügung, die Ihnen bei der Arbeit mit Bicep-Dateien und ARM-Vorlagen helfen. Verwenden Sie diese Tools, um sicherzustellen, dass Ihr Code korrekt ist. Sie bieten eine grundlegende Überprüfung.

  • Azure Portal: Wenn Sie Ihre Funktions-App und zugehörige Ressourcen im Portal erstellen, gibt es im letzten Bildschirm Überprüfen + Erstellen einen Link zum Vorlage für die 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":""}}]}}

Verwenden Sie die folgenden Methoden, um Ihre Vorlage vor der Bereitstellung zu überprüfen:

Der folgende Azure Ressourcengruppenbereitstellung v2-Vorgang mit deploymentMode: 'Validation' weist Azure Pipelines an, die Vorlage zu überprüfen.

- 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

Verwenden Sie eine der folgenden Methoden, um Ihre Bicep-Datei und -Vorlage bereitzustellen:

Schaltfläche "Bereitstellen auf Azure"

Note

Diese Methode unterstützt derzeit die Bereitstellung von Bicep-Dateien nicht.

Ersetzen Sie <url-encoded-path-to-azuredeploy-json> durch eine URL-codierte Version des Rohpfads der azuredeploy.json-Datei 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 mithilfe von PowerShell

Die folgenden PowerShell-Befehle erstellen eine Ressourcengruppe und stellen eine Bicep Datei oder ARM-Vorlage bereit, die eine Funktions-App mit den erforderlichen Ressourcen erstellt. Um die Befehle lokal auszuführen, müssen Sie Azure PowerShell installiert haben. Um sich bei Azure anzumelden, führen Sie zuerst Connect-AzAccount aus.

# 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

Verwenden Sie zum Testen dieser Bereitstellung eine Vorlage wie diese, die eine Funktions-App unter Windows in einem Verbrauchsplan erstellt.

Nächste Schritte

Erfahren Sie mehr darüber, wie Sie Azure Functions entwickeln und konfigurieren.

  • Last updated on