Delen via

Resource-implementatie automatiseren voor uw functie-app in Azure Functions

  • Artikel

U kunt een Bicep-bestand of een ARM-sjabloon (Azure Resource Manager) gebruiken om het proces voor het implementeren van uw functie-app te automatiseren. Tijdens de implementatie kunt u bestaande Azure-resources gebruiken of nieuwe resources maken. Automatisering helpt u bij deze scenario's:

  • Uw resource-implementaties integreren met uw broncode in Azure Pipelines en gitHub Actions-implementaties.
  • Een functie-app en gerelateerde resources herstellen vanuit een back-up.
  • Een app-topologie meerdere keren implementeren.

In dit artikel leest u hoe u het maken van resources en implementatie voor Azure Functions automatiseert. Afhankelijk van de triggers en bindingen die door uw functies worden gebruikt, moet u mogelijk andere resources implementeren, die buiten het bereik van dit artikel vallen.

De vereiste sjablooncode is afhankelijk van de gewenste hostingopties voor uw functie-app. Dit artikel ondersteunt de volgende hostingopties:

Hostingoptie Implementatietype Zie voor meer informatie...
Azure Functions Consumption-abonnement Alleen code Verbruiksabonnement
Azure Functions Flex Consumption-abonnement Alleen code Flex Consumption-abonnement
Azure Functions Elastic Premium-abonnement Code | Container Premium-abonnement
Toegewezen Azure Functions-plan (App Service) Code | Container Toegewezen abonnement
Azure Container Apps Alleen container Container Apps hosten van Azure Functions
Azure Arc Code | Container App Service, Functions en Logic Apps in Azure Arc (preview)

Houd bij het gebruik van dit artikel rekening met de volgende overwegingen:

  • Voorbeelden worden weergegeven als afzonderlijke secties voor specifieke resources. Zie deze voorbeelden van de implementatie van functie-apps voor een breed scala aan complete Bicep-bestanden en ARM-sjablonen.
  • Voorbeelden worden weergegeven als afzonderlijke secties voor specifieke resources.

Vereiste resources

U moet deze resources maken of configureren voor een door Azure Functions gehoste implementatie:

Bron Vereiste Naslaginformatie over syntaxis en eigenschappen
Een opslagaccount Vereist Microsoft.Storage/storageAccounts
Een Application Insights-onderdeel Aanbevolen Microsoft.Insights/components*
Een hostingabonnement Vereist Microsoft.Web/serverfarms
Een functie-app Vereist Microsoft.Web/sites

U moet deze resources maken of configureren voor een door Azure Functions gehoste implementatie:

Bron Vereiste Naslaginformatie over syntaxis en eigenschappen
Een opslagaccount Vereist Microsoft.Storage/storageAccounts
Een Application Insights-onderdeel Aanbevolen Microsoft.Insights/components*
Een functie-app Vereist Microsoft.Web/sites

Een door Azure Container Apps gehoste implementatie bestaat doorgaans uit deze resources:

Bron Vereiste Naslaginformatie over syntaxis en eigenschappen
Een opslagaccount Vereist Microsoft.Storage/storageAccounts
Een Application Insights-onderdeel Aanbevolen Microsoft.Insights/components*
Een beheerde omgeving Vereist Microsoft.App/managedEnvironments
Een functie-app Vereist Microsoft.Web/sites

Een door Azure Arc gehoste implementatie bestaat doorgaans uit deze resources:

Bron Vereiste Naslaginformatie over syntaxis en eigenschappen
Een opslagaccount Vereist Microsoft.Storage/storageAccounts
Een Application Insights-onderdeel Aanbevolen Microsoft.Insights/components1
Een App Service Kubernetes-omgeving Vereist Microsoft.ExtendedLocation/customLocations
Een functie-app Vereist Microsoft.Web/sites

*Als u nog geen Log Analytics-werkruimte hebt die kan worden gebruikt door uw Application Insights-exemplaar, moet u deze resource ook maken.

Wanneer u meerdere resources in één Bicep-bestand of ARM-sjabloon implementeert, is de volgorde waarin resources worden gemaakt belangrijk. Deze vereiste is het gevolg van afhankelijkheden tussen resources. Zorg ervoor dat u voor dergelijke afhankelijkheden het dependsOn element gebruikt om de afhankelijkheid in de afhankelijke resource te definiëren. Zie de volgorde voor het implementeren van resources in ARM-sjablonen of resourceafhankelijkheden in Bicep voor meer informatie.

Vereisten

  • De voorbeelden zijn ontworpen om uit te voeren in de context van een bestaande resourcegroep.
  • Voor zowel Application Insights als opslaglogboeken moet u een bestaande Azure Log Analytics-werkruimte hebben. Werkruimten kunnen worden gedeeld tussen services. Als vuistregel moet u in elke geografische regio een werkruimte maken om de prestaties te verbeteren. Zie Een Log Analytics-werkruimte maken voor een voorbeeld van het maken van een Log Analytics-werkruimte. U vindt de volledig gekwalificeerde werkruimteresource-id op een werkruimtepagina in De Azure-portal onder Resource-id Instellingeneigenschappen>>.
  • In dit artikel wordt ervan uitgegaan dat u al een beheerde omgeving hebt gemaakt in Azure Container Apps. U hebt zowel de naam als de id van de beheerde omgeving nodig om een functie-app te maken die wordt gehost in Container Apps.
  • In dit artikel wordt ervan uitgegaan dat u al een aangepaste locatie met App Service hebt gemaakt in een Kubernetes-cluster met Azure Arc. U hebt zowel de aangepaste locatie-id als de Kubernetes-omgevings-id nodig om een functie-app te maken die wordt gehost op een aangepaste Azure Arc-locatie.

Een opslagaccount maken

Voor alle functie-apps is een Azure-opslagaccount vereist. U hebt een account voor algemeen gebruik nodig dat ondersteuning biedt voor blobs, tabellen, wachtrijen en bestanden. Zie de vereisten voor azure Functions-opslagaccounts voor meer informatie.

Belangrijk

Het opslagaccount wordt gebruikt voor het opslaan van belangrijke app-gegevens, soms inclusief de toepassingscode zelf. U moet de toegang van andere apps en gebruikers tot het opslagaccount beperken.

In deze voorbeeldsectie wordt een standaard v2-opslagaccount voor algemeen gebruik gemaakt:

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

Zie het volledige main.bicep-bestand in de sjablonenopslagplaats voor meer context.

Zie het volledige opslagaccount.bicep-bestand in de voorbeeldopslagplaats voor meer context.

U moet de verbindingsreeks van dit opslagaccount instellen als de AzureWebJobsStorage app-instelling, waarvoor Functions vereist is. De sjablonen in dit artikel maken deze verbindingsreeks waarde op basis van het gemaakte opslagaccount. Dit is een best practice. Zie Toepassingsconfiguratie voor meer informatie.

Implementatiecontainer

Implementaties voor een app die wordt uitgevoerd in het Flex Consumption-abonnement, vereisen een container in Azure Blob Storage als de implementatiebron. U kunt het standaardopslagaccount gebruiken of u kunt een afzonderlijk opslagaccount opgeven. Zie Implementatie-instellingen configureren voor meer informatie.

Dit implementatieaccount moet al worden geconfigureerd wanneer u uw app maakt, inclusief de specifieke container die wordt gebruikt voor implementaties. Zie Implementatiebronnen voor meer informatie over het configureren van implementaties.

In dit voorbeeld ziet u hoe u een container maakt in het opslagaccount:

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

Zie dit implementatievoorbeeld voor het fragment in context.

Andere implementatie-instellingen worden geconfigureerd met de app zelf.

Opslaglogboeken inschakelen

Omdat het opslagaccount wordt gebruikt voor belangrijke functie-app-gegevens, moet u het account controleren op wijziging van die inhoud. Als u uw opslagaccount wilt bewaken, moet u Azure Monitor-resourcelogboeken configureren voor Azure Storage. In deze voorbeeldsectie wordt een Log Analytics-werkruimte met de naam myLogAnalytics gebruikt als de bestemming voor deze logboeken.

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

Dezelfde werkruimte kan later worden gebruikt voor de Application Insights-resource die is gedefinieerd. Zie Bewaking van Azure Storage voor meer informatie, waaronder het werken met deze logboeken.

Application Insights maken

U moet Application Insights gebruiken om de uitvoeringen van uw functie-app te controleren. Application Insights vereist nu een Azure Log Analytics-werkruimte die kan worden gedeeld. In deze voorbeelden wordt ervan uitgegaan dat u een bestaande werkruimte gebruikt en de volledig gekwalificeerde resource-id voor de werkruimte hebt. Zie de Azure Log Analytics-werkruimte voor meer informatie.

In dit voorbeeldgedeelte wordt de Application Insights-resource gedefinieerd met het type Microsoft.Insights/components en het type 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>'
  }
}

Zie het volledige main.bicep-bestand in de sjablonenopslagplaats voor meer context.

De verbinding moet worden opgegeven voor de functie-app met behulp van de APPLICATIONINSIGHTS_CONNECTION_STRING toepassingsinstelling. Zie Toepassingsconfiguratie voor meer informatie.

De voorbeelden in dit artikel verkrijgen de verbindingsreeks waarde voor het gemaakte exemplaar. Oudere versies kunnen in plaats daarvan de APPINSIGHTS_INSTRUMENTATIONKEY instrumentatiesleutel instellen, wat niet meer wordt aanbevolen.

Het hostingabonnement maken

Apps die worden gehost in een Azure Functions Flex Consumption-abonnement, Premium-abonnement of Toegewezen (App Service)-abonnement, moeten expliciet het hostingabonnement hebben gedefinieerd.

Flex Consumption is een hostingabonnement op basis van Linux dat voortbouwt op het verbruik voor wat u serverloos factureringsmodel gebruikt . Het plan biedt ondersteuning voor privénetwerken, de selectie van de geheugengrootte van exemplaren en verbeterde ondersteuning voor beheerde identiteiten.

Een Flex Consumption-abonnement is een speciaal type serverfarm resource. U kunt deze opgeven met behulp van FC1 de Name eigenschapswaarde in de sku eigenschap met een tier waarde van FlexConsumption.

In dit voorbeeldgedeelte maakt u een Flex Consumption-abonnement:

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

Zie het volledige bestand function.bicep in de voorbeeldopslagplaats van het Flex Consumption-abonnement voor meer context.

Omdat het Flex Consumption-abonnement momenteel alleen Linux ondersteunt, moet u de reserved eigenschap ook instellen op true.

Het Premium-abonnement biedt dezelfde schaalaanpassing als het Verbruiksabonnement, maar bevat toegewezen resources en extra mogelijkheden. Zie Het Azure Functions Premium-abonnement voor meer informatie.

Een Premium-abonnement is een speciaal type serverfarm resource. U kunt deze opgeven met behulp van EP1, EP2of EP3 voor de Name eigenschapswaarde in de sku eigenschap. De manier waarop u het Functions-hostingabonnement definieert, is afhankelijk van of uw functie-app wordt uitgevoerd in Windows of linux. In deze voorbeeldsectie wordt een EP1 plan gemaakt:

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

Zie het volledige main.bicep-bestand in de sjablonenopslagplaats voor meer context.

Zie of bekijk de voorbeeldsjablonen voor meer informatie over het sku object SkuDefinition .

In het Toegewezen (App Service)-plan wordt uw functie-app uitgevoerd op toegewezen VM's op Basic-, Standard- en Premium-SKU's in App Service-abonnementen, vergelijkbaar met web-apps. Zie Dedicated-abonnement voor meer informatie.

Zie Functie-app in Azure-app Service-plan voor een voorbeeld van een Bicep-bestand/Azure Resource Manager-sjabloon.

In Functions is het Dedicated-plan slechts een gewoon App Service-plan, dat wordt gedefinieerd door een serverfarm resource. U moet ten minste de name waarde opgeven. Zie de instelling az appservice plan create voor de --sku huidige lijst met ondersteunde waarden voor een Dedicated-plan voor een lijst met ondersteunde abonnementsnamen.

De manier waarop u het hostingabonnement definieert, is afhankelijk van of uw functie-app wordt uitgevoerd in Windows of linux:

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

Zie het volledige main.bicep-bestand in de sjablonenopslagplaats voor meer context.

Het hostingabonnement maken

U hoeft geen resource voor het hostingabonnement Verbruik expliciet te definiëren. Wanneer u deze resourcedefinitie overslaat, wordt er automatisch een plan gemaakt of geselecteerd per regio wanneer u de resource van de functie-app zelf maakt.

U kunt een verbruiksabonnement expliciet definiëren als een speciaal type resource, dat u opgeeft met behulp van serverfarm de waarde Dynamic voor de computeMode en sku eigenschappen. In deze voorbeeldsectie ziet u hoe u expliciet een verbruiksabonnement definieert. De manier waarop u een hostingabonnement definieert, is afhankelijk van of uw functie-app wordt uitgevoerd in Windows of linux.

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

Zie het volledige main.bicep-bestand in de sjablonenopslagplaats voor meer context.

Kubernetes-omgeving

Azure Functions kan worden geïmplementeerd in Kubernetes met Azure Arc als een codeproject of een containerfunctie-app.

Als u de app- en planbronnen wilt maken, moet u al een App Service Kubernetes-omgeving hebben gemaakt voor een Kubernetes-cluster met Azure Arc. In de voorbeelden in dit artikel wordt ervan uitgegaan dat u de resource-id hebt van de aangepaste locatie (customLocationId) en de App Service Kubernetes-omgeving (kubeEnvironmentId) waarop u implementeert, die in dit voorbeeld zijn ingesteld:

param kubeEnvironmentId string
param customLocationId string

Zowel sites als plannen moeten verwijzen naar de aangepaste locatie via een extendedLocation veld. Zoals wordt weergegeven in dit afgekapte voorbeeld, bevindt zich buiten properties, extendedLocation als peer-to kind en location:

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

De planresource moet de Kubernetes-waarde (K1) gebruiken voor SKU, het kind veld moet zijn linux,kubernetesen de reserved eigenschap moet zijn true, omdat het een Linux-implementatie is. U moet ook de extendedLocation en kubeEnvironmentProfile.id de aangepaste locatie-id en de Kubernetes-omgevings-id instellen, die er als volgt uit kunnen zien in deze voorbeeldsectie:

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

De functie-app maken

De functie-app-resource wordt gedefinieerd door een resource van het type Microsoft.Web/sites en kind die minimaal , inclusief functionapp.

De manier waarop u een functie-app-resource definieert, is afhankelijk van of u host op Linux of in Windows:

Zie Toepassingsconfiguratie voor een lijst met toepassingsinstellingen die vereist zijn bij het uitvoeren in Windows. Zie voor een voorbeeld van een Bicep-bestand/Azure Resource Manager-sjabloon de functie-app die wordt gehost in Windows in een sjabloon voor een verbruiksabonnement .

Zie Toepassingsconfiguratie voor een lijst met toepassingsinstellingen die vereist zijn bij het uitvoeren in Windows.

Flex Consumption vervangt veel van de standaardtoepassingsinstellingen en siteconfiguratie-eigenschappen die worden gebruikt in bicep- en ARM-sjabloonimplementaties. Zie Toepassingsconfiguratie voor meer informatie.

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

Zie het volledige bestand function.bicep in de voorbeeldopslagplaats van het Flex Consumption-abonnement voor meer context.

Notitie

Als u ervoor kiest om uw verbruiksabonnement optioneel te definiëren, moet u de serverFarmId eigenschap voor de app instellen zodat deze verwijst naar de resource-id van het abonnement. Zorg ervoor dat de functie-app een dependsOn instelling heeft die ook verwijst naar het plan. Als u een plan niet expliciet hebt gedefinieerd, wordt er een voor u gemaakt.

Stel de serverFarmId eigenschap in de app in zodat deze verwijst naar de resource-id van het plan. Zorg ervoor dat de functie-app een dependsOn instelling heeft die ook verwijst naar het plan.

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

Zie dit bestand main.bicep voor een volledig end-to-end-voorbeeld.

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

Zie dit bestand main.bicep voor een volledig end-to-end-voorbeeld.

Implementatiebronnen

U kunt de linuxFxVersion site-instelling gebruiken om aan te vragen dat een specifieke Linux-container wordt geïmplementeerd in uw app wanneer deze wordt gemaakt. Er zijn meer instellingen vereist voor toegang tot installatiekopieën in een privéopslagplaats. Zie Toepassingsconfiguratie voor meer informatie.

Belangrijk

Wanneer u uw eigen containers maakt, moet u de basisinstallatiekopieën van uw container bijwerken naar de meest recente ondersteunde basisinstallatiekopieën. Ondersteunde basisinstallatiekopieën voor Azure Functions zijn taalspecifiek en bevinden zich in de basisinstallatiekopieën van Azure Functions.

Het Functions-team zet zich in voor het publiceren van maandelijkse updates voor deze basisinstallatiekopieën. Regelmatige updates bevatten de meest recente secundaire versie-updates en beveiligingscorrecties voor zowel de Functions-runtime als de talen. Werk uw container regelmatig bij vanaf de meest recente basisinstallatiekopie en implementeer de bijgewerkte versie van uw container opnieuw.

Uw Bicep-bestand of ARM-sjabloon kan eventueel ook een implementatie definiëren voor uw functiecode, waaronder deze methoden:

Het Flex Consumption-plan onderhoudt uw projectcode in een zip-gecomprimeerd pakketbestand in een blobopslagcontainer die de implementatiecontainer wordt genoemd. U kunt zowel het opslagaccount als de container configureren die wordt gebruikt voor implementatie. Raadpleeg Implementatie voor meer informatie.

U moet één implementatie gebruiken om uw codepakket te publiceren naar de implementatiecontainer. Tijdens een ARM- of Bicep-implementatie kunt u dit doen door een pakketbron te definiëren die gebruikmaakt van de /onedeploy extensie. Als u ervoor kiest om uw pakket rechtstreeks naar de container te uploaden, wordt het pakket niet automatisch geïmplementeerd.

Implementatiecontainer

Het specifieke opslagaccount en de container die worden gebruikt voor implementaties, de verificatiemethode en referenties worden ingesteld in het functionAppConfig.deployment.storage element van de properties site. De container en eventuele toepassingsinstellingen moeten bestaan wanneer de app wordt gemaakt. Zie Implementatiecontainer voor een voorbeeld van het maken van de opslagcontainer.

In dit voorbeeld wordt een door het systeem toegewezen beheerde identiteit gebruikt voor toegang tot de opgegeven blobopslagcontainer, die elders in de implementatie wordt gemaakt:

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

Wanneer u beheerde identiteiten gebruikt, moet u de functie-app ook inschakelen voor toegang tot het opslagaccount met behulp van de identiteit, zoals wordt weergegeven in dit voorbeeld:

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

Zie dit Bicep-bestand voor een volledig referentievoorbeeld.

In dit voorbeeld moet u de GUID-waarde weten voor de rol die wordt toegewezen. U kunt deze id-waarde ophalen voor elke beschrijvende rolnaam met behulp van de opdracht az role definition list , zoals in dit voorbeeld:

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

Wanneer u een verbindingsreeks gebruikt in plaats van beheerde identiteiten, moet u in plaats daarvan de authentication.type instelling StorageAccountConnectionString instellen op en instellen authentication.storageAccountConnectionStringName op de naam van de toepassingsinstelling die het opslagaccount voor de implementatie bevat verbindingsreeks.

Implementatiepakket

Het Flex Consumption-abonnement maakt gebruik van één implementatie voor het implementeren van uw codeproject. Het codepakket zelf is hetzelfde als u zou gebruiken voor zip-implementatie in andere Functions-hostingabonnementen. De naam van het pakketbestand zelf moet echter zijn released-package.zip.

Als u één implementatiepakket in uw sjabloon wilt opnemen, gebruikt u de /onedeploy resourcedefinitie voor de externe URL die het implementatiepakket bevat. De Functions-host moet toegang hebben tot zowel deze externe pakketbron als de implementatiecontainer.

In dit voorbeeld wordt een implementatiebron toegevoegd aan een bestaande app:

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

Uw Bicep-bestand of ARM-sjabloon kan eventueel ook een implementatie voor uw functiecode definiëren met behulp van een zip-implementatiepakket.

Als u uw toepassing wilt implementeren met behulp van Azure Resource Manager, is het belangrijk om te begrijpen hoe resources worden geïmplementeerd in Azure. In de meeste voorbeelden worden configuraties op het hoogste niveau toegepast met behulp van siteConfig. Het is belangrijk om deze configuraties op het hoogste niveau in te stellen, omdat ze informatie overbrengen naar de Functions-runtime en -implementatie-engine. Informatie op het hoogste niveau is vereist voordat de onderliggende sourcecontrols/web resource wordt toegepast. Hoewel het mogelijk is om deze instellingen te configureren in de resource op onderliggend niveau config/appSettings , moet uw functie-app in sommige gevallen worden geïmplementeerd voordat config/appSettings deze wordt toegepast.

Zip-implementatiepakket

Zip-implementatie is een aanbevolen manier om uw functie-app-code te implementeren. Standaard worden functies die gebruikmaken van zip-implementatie uitgevoerd in het implementatiepakket zelf. Zie Zip-implementatie voor Azure Functions voor meer informatie, waaronder de vereisten voor een implementatiepakket. Wanneer u resource-implementatieautomatisering gebruikt, kunt u verwijzen naar het .zip-implementatiepakket in uw Bicep- of ARM-sjabloon.

Als u zip-implementatie in uw sjabloon wilt gebruiken, stelt u de WEBSITE_RUN_FROM_PACKAGE instelling in de app 1 in op en neemt u de /zipDeploy resourcedefinitie op.

Voor een verbruiksabonnement in Linux stelt u in plaats daarvan de URI van het implementatiepakket rechtstreeks in de WEBSITE_RUN_FROM_PACKAGE instelling in, zoals wordt weergegeven in deze voorbeeldsjabloon.

In dit voorbeeld wordt een zip-implementatiebron toegevoegd aan een bestaande app:

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

Houd rekening met het volgende bij het opnemen van zip-implementatiebronnen in uw sjabloon:

  • De packageUri locatie moet een locatie zijn die toegankelijk is voor Functions. Overweeg om Azure Blob Storage te gebruiken met een Shared Access Signature (SAS). Nadat de SAS is verlopen, heeft Functions geen toegang meer tot de share voor implementaties. Wanneer u de SAS opnieuw genereert, moet u de WEBSITE_RUN_FROM_PACKAGE instelling bijwerken met de nieuwe URI-waarde.

  • Wanneer u een WEBSITE_RUN_FROM_PACKAGE URI instelt, moet u triggers handmatig synchroniseren.

  • Zorg ervoor dat u altijd alle vereiste toepassingsinstellingen in de appSettings verzameling instelt wanneer u instellingen toevoegt of bijwerkt. Bestaande instellingen die niet expliciet zijn ingesteld, worden verwijderd door de update. Zie Toepassingsconfiguratie voor meer informatie.

  • Functions biedt geen ondersteuning voor Web Deploy (msdeploy) voor pakketimplementaties. U moet in plaats daarvan zip-implementatie gebruiken in uw implementatiepijplijnen en automatisering. Zie Zip-implementatie voor Azure Functions voor meer informatie.

Externe builds

Bij het implementatieproces wordt ervan uitgegaan dat het .zip-bestand dat u gebruikt of een zip-implementatie een kant-en-klare app bevat. Dit betekent dat standaard geen aanpassingen worden uitgevoerd.

Er zijn scenario's waarbij u uw app op afstand opnieuw moet bouwen. Een dergelijk voorbeeld is wanneer u Linux-specifieke pakketten moet opnemen in Python of Node.js-apps die u hebt ontwikkeld op een Windows-computer. In dit geval kunt u Functions configureren voor het uitvoeren van een externe build op uw code na de zip-implementatie.

De manier waarop u een externe build aanvraagt, is afhankelijk van het besturingssysteem waarop u implementeert:

Wanneer een app wordt geïmplementeerd in Windows, worden taalspecifieke opdrachten (zoals dotnet restore voor C#-apps of npm install voor Node.js-apps) uitgevoerd.

Als u dezelfde buildprocessen wilt inschakelen die u krijgt met continue integratie, voegt SCM_DO_BUILD_DURING_DEPLOYMENT=true u de toepassingsinstellingen toe aan uw implementatiecode en verwijdert u de WEBSITE_RUN_FROM_PACKAGE volledige procedure.

Linux-containers

Als u een containerfunctie-app implementeert in een Azure Functions Premium- of Dedicated-abonnement, moet u het volgende doen:

Als sommige instellingen ontbreken, kan het inrichten van de toepassing mislukken met deze HTTP/500-fout:

Function app provisioning failed.

Zie Toepassingsconfiguratie voor meer informatie.

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

Bij het implementeren van containerfuncties in Azure Container Apps moet uw sjabloon het volgende doen:

  • Stel het kind veld in op een waarde van functionapp,linux,container,azurecontainerapps.
  • Stel de managedEnvironmentId site-eigenschap in op de volledig gekwalificeerde URI van de Container Apps-omgeving.
  • Voeg een resourcekoppeling toe aan de verzameling van dependsOn de site bij het maken van een Microsoft.App/managedEnvironments resource op hetzelfde moment als de site.

De definitie van een containerfunctie-app die is geïmplementeerd vanuit een privécontainerregister naar een bestaande Container Apps-omgeving, kan er als volgt uitzien:

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

Bij het implementeren van functies in Azure Arc is de waarde die u hebt ingesteld voor het kind veld van de functie-app-resource afhankelijk van het type implementatie:

Implementatietype kind veldwaarde
Implementatie met alleen code functionapp,linux,kubernetes
Containerimplementatie functionapp,linux,kubernetes,container

U moet ook de customLocationId instellingen instellen zoals u hebt gedaan voor de resource van het hostingplan.

De definitie van een containerfunctie-app, met behulp van een quickstart-installatiekopieën van .NET 6, kan er als volgt uitzien:

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

Toepassingsconfiguratie

In een Flex Consumption-abonnement configureert u uw functie-app in Azure met twee typen eigenschappen:

Configuratie Microsoft.Web/sites eigenschap
Toepassingsconfiguratie functionAppConfig
Toepassingsinstellingen siteConfig.appSettings collectie

Deze toepassingsconfiguraties worden onderhouden in functionAppConfig:

Gedrag Instelling in functionAppConfig
Altijd gereede exemplaren scaleAndConcurrency.alwaysReady
Implementatiebron deployment
Grootte van exemplaargeheugen scaleAndConcurrency.instanceMemoryMB
Gelijktijdigheid van HTTP-trigger scaleAndConcurrency.triggers.http.perInstanceConcurrency
Taalruntime runtime.name
Taalversie runtime.version
Maximumaantal exemplaren scaleAndConcurrency.maximumInstanceCount

Het Flex Consumption-abonnement ondersteunt ook deze toepassingsinstellingen:

Functions biedt de volgende opties voor het configureren van uw functie-app in Azure:

Configuratie Microsoft.Web/sites eigenschap
Site-instellingen siteConfig
Toepassingsinstellingen siteConfig.appSettings collectie

Deze site-instellingen zijn vereist voor de siteConfig eigenschap:

Deze site-instellingen zijn alleen vereist wanneer u beheerde identiteiten gebruikt om de installatiekopieën te verkrijgen van een Azure Container Registry-exemplaar:

Deze toepassingsinstellingen zijn vereist (of aanbevolen) voor een specifiek besturingssysteem en hostingoptie:

Deze toepassingsinstellingen zijn vereist voor containerimplementaties:

Deze instellingen zijn alleen vereist bij het implementeren vanuit een privécontainerregister:

Houd rekening met deze overwegingen bij het werken met site- en toepassingsinstellingen met bicep-bestanden of ARM-sjablonen:

  • De optionele alwaysReady instelling bevat een matrix van een of meer {name,instanceCount} objecten, met één voor elke schaalgroep per functie. Dit zijn de schaalgroepen die worden gebruikt om altijd kant-en-klare schaalbeslissingen te nemen. In dit voorbeeld worden altijd gereede tellingen ingesteld voor zowel de http groep als één functie met de naam helloworld, die van een niet-gegroepeerd triggertype is:
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • Er zijn belangrijke overwegingen voor wanneer u moet instellen WEBSITE_CONTENTSHARE in een geautomatiseerde implementatie. Zie de WEBSITE_CONTENTSHARE naslaginformatie voor gedetailleerde richtlijnen.

  • U moet altijd uw toepassingsinstellingen definiëren als een siteConfig/appSettings verzameling van de Microsoft.Web/sites resource die wordt gemaakt, zoals wordt gedaan in de voorbeelden in dit artikel. Deze definitie garandeert dat de instellingen die uw functie-app moet uitvoeren, beschikbaar zijn bij het eerste opstarten.

  • Wanneer u toepassingsinstellingen toevoegt of bijwerkt met behulp van sjablonen, moet u ervoor zorgen dat u alle bestaande instellingen bij de update opneemt. U moet dit doen omdat de onderliggende REST API-aanroepen van updates de volledige /config/appsettings resource vervangen. Als u de bestaande instellingen verwijdert, wordt uw functie-app niet uitgevoerd. Als u afzonderlijke toepassingsinstellingen programmatisch wilt bijwerken, kunt u in plaats daarvan de Azure CLI, Azure PowerShell of Azure Portal gebruiken om deze wijzigingen aan te brengen. Zie Werken met toepassingsinstellingen voor meer informatie.

Site-implementaties

Met Functions kunt u verschillende versies van uw code implementeren op unieke eindpunten in uw functie-app. Met deze optie kunt u eenvoudiger functiesupdates ontwikkelen, valideren en implementeren zonder dat dit van invloed is op functies die in productie worden uitgevoerd. Implementatiesites zijn een functie van Azure-app Service. Het aantal beschikbare sites is afhankelijk van uw hostingabonnement. Zie Functies voor Azure Functions-implementatiesites voor meer informatie.

Een siteresource wordt op dezelfde manier gedefinieerd als een functie-app-resource (Microsoft.Web/sites), maar in plaats daarvan gebruikt u de Microsoft.Web/sites/slots resource-id. Voor een voorbeeldimplementatie (in zowel Bicep- als ARM-sjablonen) waarmee zowel een productie- als een staging-site in een Premium-abonnement wordt gemaakt, raadpleegt u de Azure Function-app met een implementatiesite.

Zie Automatiseren met Resource Manager-sjablonen voor meer informatie over het wisselen van sites met behulp van sjablonen.

Houd rekening met de volgende overwegingen bij het werken met site-implementaties:

  • Stel de instelling niet expliciet in de definitie van de WEBSITE_CONTENTSHARE implementatiesite in. Deze instelling wordt voor u gegenereerd wanneer de app wordt gemaakt in de implementatiesite.

  • Wanneer u sites verwisselt, worden sommige toepassingsinstellingen beschouwd als 'plakkerig', omdat ze bij de site blijven en niet met de code die wordt gewisseld. U kunt een dergelijke site-instelling definiëren door deze op te slaan "slotSetting":true in de specifieke definitie van de toepassingsinstelling in uw sjabloon. Zie Instellingen beheren voor meer informatie.

Beveiligde implementaties

U kunt uw functie-app maken in een implementatie waarbij een of meer van de resources zijn beveiligd door integratie met virtuele netwerken. Integratie van virtuele netwerken voor uw functie-app wordt gedefinieerd door een Microsoft.Web/sites/networkConfig resource. Deze integratie is afhankelijk van zowel de functie-app waarnaar wordt verwezen als de resources van het virtuele netwerk. Uw functie-app is mogelijk ook afhankelijk van andere privénetwerkresources, zoals privé-eindpunten en routes. Zie Azure Functions-netwerkopties voor meer informatie.

Deze projecten bieden bicep-voorbeelden van het implementeren van uw functie-apps in een virtueel netwerk, met inbegrip van netwerktoegangsbeperkingen:

Wanneer u een implementatie maakt die gebruikmaakt van een beveiligd opslagaccount, moet u zowel de WEBSITE_CONTENTSHARE instelling expliciet instellen als de bestandsshareresource maken met de naam in deze instelling. Zorg ervoor dat u een Microsoft.Storage/storageAccounts/fileServices/shares resource maakt met de waarde van WEBSITE_CONTENTSHARE, zoals wordt weergegeven in dit voorbeeld (ARM-sjabloon|Bicep-bestand). U moet ook de site-eigenschap vnetContentShareEnabled instellen op waar.

Notitie

Wanneer deze instellingen geen deel uitmaken van een implementatie die gebruikmaakt van een beveiligd opslagaccount, ziet u deze fout tijdens de implementatievalidatie: Could not access storage account using provided connection string

Deze projecten bieden zowel Bicep- als ARM-sjabloonvoorbeelden voor het implementeren van uw functie-apps in een virtueel netwerk, waaronder beperkingen voor netwerktoegang:

Beperkt scenario Beschrijving
Een functie-app maken met integratie van virtuele netwerken Uw functie-app wordt gemaakt in een virtueel netwerk met volledige toegang tot resources in dat netwerk. Binnenkomende en uitgaande toegang tot uw functie-app is niet beperkt. Zie Integratie van virtueel netwerk voor meer informatie.
Een functie-app maken die toegang heeft tot een beveiligd opslagaccount Uw gemaakte functie-app maakt gebruik van een beveiligd opslagaccount, waartoe Functions toegang heeft met behulp van privé-eindpunten. Zie Uw opslagaccount beperken tot een virtueel netwerk voor meer informatie.
Een functie-app en opslagaccount maken die beide gebruikmaken van privé-eindpunten Uw gemaakte functie-app kan alleen worden geopend met behulp van privé-eindpunten en maakt gebruik van privé-eindpunten voor toegang tot opslagbronnen. Zie Privé-eindpunten voor meer informatie.

Instellingen voor beperkt netwerk

Mogelijk moet u deze instellingen ook gebruiken wanneer uw functie-app netwerkbeperkingen heeft:

Instelling Weergegeven als Beschrijving
WEBSITE_CONTENTOVERVNET 1 Toepassingsinstelling waarmee uw functie-app kan worden geschaald wanneer het opslagaccount wordt beperkt tot een virtueel netwerk. Zie Uw opslagaccount beperken tot een virtueel netwerk voor meer informatie.
vnetrouteallenabled 1 Site-instelling die alle verkeer van de functie-app dwingt om het virtuele netwerk te gebruiken. Zie Regionale integratie van virtueel netwerk voor meer informatie. Deze site-instelling vervangt de toepassingsinstelling WEBSITE_VNET_ROUTE_ALL.

Overwegingen voor netwerkbeperkingen

Wanneer u de toegang tot het opslagaccount beperkt via de privé-eindpunten, hebt u geen toegang tot het opslagaccount via de portal of een apparaat buiten het virtuele netwerk. U kunt toegang verlenen tot uw beveiligde IP-adres of virtueel netwerk in het opslagaccount door de standaardregel voor netwerktoegang te beheren.

Functietoegangssleutels

Functietoegangssleutels op hostniveau worden gedefinieerd als Azure-resources. Dit betekent dat u hostsleutels in uw ARM-sjablonen en Bicep-bestanden kunt maken en beheren. Een hostsleutel wordt gedefinieerd als een resource van het type Microsoft.Web/sites/host/functionKeys. In dit voorbeeld wordt een toegangssleutel op hostniveau gemaakt met de naam my_custom_key wanneer de functie-app wordt gemaakt:

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 dit voorbeeld is de name parameter de naam van de nieuwe functie-app. U moet een dependsOn instelling opnemen om te garanderen dat de sleutel wordt gemaakt met de nieuwe functie-app. Ten slotte kan het properties object van de hostsleutel ook een value eigenschap bevatten die kan worden gebruikt om een specifieke sleutel in te stellen.

Wanneer u de value eigenschap niet instelt, genereert Functions automatisch een nieuwe sleutel voor u wanneer de resource wordt gemaakt. Dit wordt aanbevolen. Zie Werken met toegangssleutels in Azure Functions voor meer informatie over toegangssleutels, inclusief aanbevolen beveiligingsprocedures voor het werken met toegangssleutels.

Uw sjabloon maken

Experts met Bicep- of ARM-sjablonen kunnen hun implementaties handmatig codeeren met behulp van een eenvoudige teksteditor. Voor de rest zijn er verschillende manieren om het ontwikkelingsproces eenvoudiger te maken:

  • Visual Studio Code: Er zijn extensies beschikbaar waarmee u kunt werken met zowel Bicep-bestanden als ARM-sjablonen. U kunt deze hulpprogramma's gebruiken om ervoor te zorgen dat uw code juist is en ze bieden enkele basisvalidaties.

  • Azure Portal: Wanneer u uw functie-app en gerelateerde resources in de portal maakt, bevat het laatste scherm Beoordelen en maken een sjabloon downloaden voor automatiseringskoppeling .

    Download de sjabloonkoppeling van het proces voor het maken van Azure Functions in Azure Portal.

    In deze koppeling ziet u de ARM-sjabloon die is gegenereerd op basis van de opties die u hebt gekozen in de portal. Deze sjabloon kan een beetje complex lijken wanneer u een functie-app maakt met veel nieuwe resources. Het kan echter een goede referentie bieden voor hoe uw ARM-sjabloon eruit kan zien.

Uw sjabloon valideren

Wanneer u uw implementatiesjabloonbestand handmatig maakt, is het belangrijk om uw sjabloon vóór de implementatie te valideren. Alle implementatiemethoden valideren de syntaxis van uw sjabloon en genereren een validation failed foutbericht, zoals wordt weergegeven in het volgende voorbeeld met JSON-indeling:

{"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":""}}]}}

De volgende methoden kunnen worden gebruikt om uw sjabloon vóór de implementatie te valideren:

De volgende azure-resourcegroepimplementatie v2-taak met deploymentMode: 'Validation' instrueert Azure Pipelines om de sjabloon te valideren.

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

U kunt ook een testresourcegroep maken om preflight- en implementatiefouten te vinden.

De sjabloon implementeren

U kunt een van de volgende manieren gebruiken om uw Bicep-bestand en -sjabloon te implementeren:

De knop Implementeren in Azure

Notitie

Deze methode biedt momenteel geen ondersteuning voor het implementeren van Bicep-bestanden.

Vervang <url-encoded-path-to-azuredeploy-json> door een door URL gecodeerde versie van het onbewerkte pad van uw azuredeploy.json bestand in GitHub.

Hier volgt een voorbeeld waarin markdown wordt gebruikt:

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

Hier volgt een voorbeeld waarin HTML wordt gebruikt:

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

Implementeren met PowerShell

Met de volgende PowerShell-opdrachten maakt u een resourcegroep en implementeert u een Bicep-bestand of ARM-sjabloon waarmee een functie-app met de vereiste resources wordt gemaakt. Als u lokaal wilt uitvoeren, moet Azure PowerShell zijn geïnstalleerd. Als u zich wilt aanmelden bij Azure, moet u eerst uitvoeren Connect-AzAccount.

# 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

Als u deze implementatie wilt testen, kunt u een sjabloon zoals deze gebruiken om een functie-app in Windows te maken in een verbruiksabonnement.

Volgende stappen

Meer informatie over het ontwikkelen en configureren van Azure Functions.