Dela via


Automatisera resursdistributionen för funktionsappen i Azure Functions

Du kan använda en Bicep-fil eller en ARM-mall (Azure Resource Manager) för att automatisera distributionen av funktionsappen. Under distributionen kan du använda befintliga Azure-resurser eller skapa nya. Automation hjälper dig med följande scenarier:

  • Integrera dina resursdistributioner med källkoden i Azure Pipelines och GitHub Actions-baserade distributioner.
  • Återställa en funktionsapp och relaterade resurser från en säkerhetskopia.
  • Distribuera en apptopologi flera gånger.

Den här artikeln visar hur du automatiserar skapandet av resurser och distribution för Azure Functions. Beroende på vilka utlösare och bindningar som används av dina funktioner kan du behöva distribuera andra resurser som ligger utanför omfånget för den här artikeln.

Vilken mallkod som krävs beror på önskade värdalternativ för funktionsappen. Den här artikeln stöder följande värdalternativ:

Värdalternativ Distributionstyp Mer information finns i...
Förbrukningsplan för Azure Functions Endast kod Förbrukningsplan
Azure Functions Flex Consumption Plan Endast kod Flex-förbrukningsplan
Azure Functions Elastic Premium-plan Kod | Behållare Premium-plan
Azure Functions Dedicated-plan (App Service) Kod | Behållare Dedikerad plan
Azure Container Apps Endast container Container Apps-värd för Azure Functions
Azure Arc Kod | Behållare App Service, Functions och Logic Apps i Azure Arc (förhandsversion)

Tänk på följande när du använder den här artikeln:

  • Exempel visas som enskilda avsnitt för specifika resurser. En bred uppsättning kompletta exempel på Bicep-filer och ARM-mallar finns i dessa exempel på distribution av Flex Consumption-appar.
  • Exempel visas som enskilda avsnitt för specifika resurser.

Nödvändiga resurser

Du måste skapa eller konfigurera dessa resurser för en Azure Functions-värdbaserad distribution:

Resurs Krav Referens för syntax och egenskaper
Ett lagringskonto Obligatoriskt Microsoft.Storage/storageAccounts
En Application Insights-komponent Rekommenderat Microsoft.Insights/components*
En värdplan Obligatoriskt Microsoft.Web/serverfarms
En funktionsapp Obligatoriskt Microsoft.Web/sites

Du måste skapa eller konfigurera dessa resurser för en Azure Functions-värdbaserad distribution:

Resurs Krav Referens för syntax och egenskaper
Ett lagringskonto Obligatoriskt Microsoft.Storage/storageAccounts
En Application Insights-komponent Rekommenderat Microsoft.Insights/components*
En funktionsapp Obligatoriskt Microsoft.Web/sites

En Azure Container Apps-värdbaserad distribution består vanligtvis av följande resurser:

Resurs Krav Referens för syntax och egenskaper
Ett lagringskonto Obligatoriskt Microsoft.Storage/storageAccounts
En Application Insights-komponent Rekommenderat Microsoft.Insights/components*
En hanterad miljö Obligatoriskt Microsoft.App/managedEnvironments
En funktionsapp Obligatoriskt Microsoft.Web/sites

En Azure Arc-värdbaserad distribution består vanligtvis av följande resurser:

Resurs Krav Referens för syntax och egenskaper
Ett lagringskonto Obligatoriskt Microsoft.Storage/storageAccounts
En Application Insights-komponent Rekommenderat Microsoft.Insights/components1
En App Service Kubernetes-miljö Obligatoriskt Microsoft.ExtendedLocation/customLocations
En funktionsapp Obligatoriskt Microsoft.Web/sites

*Om du inte redan har en Log Analytics-arbetsyta som kan användas av Application Insights-instansen måste du också skapa den här resursen.

När du distribuerar flera resurser i en enda Bicep-fil eller ARM-mall är det viktigt i vilken ordning resurserna skapas. Det här kravet är ett resultat av beroenden mellan resurser. För sådana beroenden måste du använda elementet dependsOn för att definiera beroendet i den beroende resursen. Mer information finns i Definiera ordningen för att distribuera resurser i ARM-mallar eller Resursberoenden i Bicep.

Förutsättningar

  • Exemplen är utformade för att köras i kontexten för en befintlig resursgrupp.
  • Både Application Insights och lagringsloggar kräver att du har en befintlig Azure Log Analytics-arbetsyta. Arbetsytor kan delas mellan tjänster, och som tumregel bör du skapa en arbetsyta i varje geografisk region för att förbättra prestandan. Ett exempel på hur du skapar en Log Analytics-arbetsyta finns i Skapa en Log Analytics-arbetsyta. Du hittar det fullständigt kvalificerade resurs-ID:t för arbetsytan på en arbetsytesida i Azure Portal under Inställningar Egenskaper>>Resurs-ID.
  • Den här artikeln förutsätter att du redan har skapat en hanterad miljö i Azure Container Apps. Du behöver både namnet och ID:t för den hanterade miljön för att skapa en funktionsapp som finns i Container Apps.

Skapa lagringskonto

Alla funktionsappar kräver ett Azure-lagringskonto. Du behöver ett konto för generell användning som stöder blobar, tabeller, köer och filer. Mer information finns i Krav för Azure Functions-lagringskonto.

Viktigt!

Lagringskontot används för att lagra viktiga appdata, ibland inklusive själva programkoden. Du bör begränsa åtkomsten från andra appar och användare till lagringskontot.

I det här exempelavsnittet skapas ett standardlagringskonto för generell användning v2:

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

Mer kontext finns i den fullständiga filen main.bicep i malllagringsplatsen.

Mer kontext finns i den fullständiga filen storage-account.bicep på exempellagringsplatsen.

Du måste ange anslutningssträng för det här lagringskontot som AzureWebJobsStorage appinställning, som Functions kräver. Mallarna i den här artikeln konstruerar det här anslutningssträng värdet baserat på det skapade lagringskontot, vilket är bästa praxis. Mer information finns i Programkonfiguration.

Distributionscontainer

Distributioner till en app som körs i Flex Consumption-planen kräver en container i Azure Blob Storage som distributionskälla. Du kan använda antingen standardlagringskontot eller så kan du ange ett separat lagringskonto. Mer information finns i Konfigurera distributionsinställningar.

Det här distributionskontot måste redan konfigureras när du skapar din app, inklusive den specifika container som används för distributioner. Mer information om hur du konfigurerar distributioner finns i Distributionskällor.

Det här exemplet visar hur du skapar en container i lagringskontot:

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

Information om kodfragmentet i kontexten finns i det här distributionsexemplet.

Andra distributionsinställningar konfigureras med själva appen.

Aktivera lagringsloggar

Eftersom lagringskontot används för viktiga funktionsappdata bör du övervaka kontot för ändring av innehållet. Om du vill övervaka ditt lagringskonto måste du konfigurera Azure Monitor-resursloggar för Azure Storage. I det här exempelavsnittet används en Log Analytics-arbetsyta med namnet myLogAnalytics som mål för dessa loggar.

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

Samma arbetsyta kan användas för Application Insights-resursen som definieras senare. Mer information, inklusive hur du arbetar med dessa loggar, finns i Övervaka Azure Storage.

Skapa Application Insights

Du bör använda Application Insights för att övervaka körningen av funktionsappen. Application Insights kräver nu en Azure Log Analytics-arbetsyta som kan delas. Dessa exempel förutsätter att du använder en befintlig arbetsyta och har det fullständigt kvalificerade resurs-ID:t för arbetsytan. Mer information finns i Azure Log Analytics-arbetsytan.

I det här exempelavsnittet definieras Application Insights-resursen med typen Microsoft.Insights/components och typen 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>'
  }
}

Mer kontext finns i den fullständiga filen main.bicep i malllagringsplatsen.

Anslutningen måste anges till funktionsappen med hjälp av programinställningen APPLICATIONINSIGHTS_CONNECTION_STRING . Mer information finns i Programkonfiguration.

Exemplen i den här artikeln hämtar värdet anslutningssträng för den skapade instansen. Äldre versioner kan i stället använda APPINSIGHTS_INSTRUMENTATIONKEY för att ange instrumentationsnyckeln, vilket inte längre rekommenderas.

Skapa värdplanen

Appar som finns i en Azure Functions Flex Consumption-plan, Premium-plan eller dedikerad (App Service)-plan måste ha värdplanen explicit definierad.

Flex Consumption är en Linux-baserad värdplan som bygger på förbrukningslönen för det du använder en serverlös faktureringsmodell. Planen har stöd för privata nätverk, val av minnesstorlek för instanser och förbättrat stöd för hanterad identitet.

En Flex Consumption-plan är en särskild typ av serverfarm resurs. Du kan ange det med hjälp FC1 av för egenskapsvärdet Name i sku egenskapen med värdet tier FlexConsumption.

I det här exempelavsnittet skapas en Flex Consumption-plan:

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

Mer kontext finns i den fullständiga filen function.bicep i exempellagringsplatsen flexförbrukningsplan.

Eftersom Flex Consumption-planen för närvarande endast stöder Linux måste du också ange reserved egenskapen till true.

Premium-planen erbjuder samma skalning som förbrukningsplanen, men innehåller dedikerade resurser och extra funktioner. Mer information finns i Azure Functions Premium-plan.

En Premium-plan är en särskild typ av serverfarm resurs. Du kan ange det med antingen EP1, EP2eller EP3 för egenskapsvärdet Name i sku egenskapen. Hur du definierar functions-värdplanen beror på om din funktionsapp körs i Windows eller i Linux. I det här exempelavsnittet skapas en EP1 plan:

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

Mer kontext finns i den fullständiga filen main.bicep i malllagringsplatsen.

Mer information om objektet SkuDefinition finns i sku eller granska exempelmallarna.

I den dedikerade planen (App Service) körs din funktionsapp på dedikerade virtuella datorer på Basic-, Standard- och Premium-SKU:er i App Service-planer, liknande webbappar. Mer information finns i Dedikerad plan.

Ett exempel på en Bicep-fil/Azure Resource Manager-mall finns i Funktionsapp i Azure App Service-plan.

I Functions är den dedikerade planen bara en vanlig App Service-plan, som definieras av en serverfarm resurs. Du måste ange minst värdet name . En lista över plannamn --sku som stöds finns i inställningen i az appservice plan create för den aktuella listan över värden som stöds för en dedikerad plan.

Hur du definierar värdplanen beror på om din funktionsapp körs i Windows eller i Linux:

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

Mer kontext finns i den fullständiga filen main.bicep i malllagringsplatsen.

Skapa värdplanen

Du behöver inte uttryckligen definiera en förbrukningsvärdplansresurs. När du hoppar över den här resursdefinitionen skapas eller väljs en plan automatiskt per region när du skapar själva funktionsappresursen.

Du kan uttryckligen definiera en förbrukningsplan som en särskild typ av resurs, som du anger med hjälp av serverfarm värdet Dynamic för computeMode egenskaperna och sku . Det här exempelavsnittet visar hur du uttryckligen definierar en förbrukningsplan. Hur du definierar en värdplan beror på om din funktionsapp körs i Windows eller i 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'
  }
}

Mer kontext finns i den fullständiga filen main.bicep i malllagringsplatsen.

Kubernetes-miljö

Azure Functions kan distribueras till Azure Arc-aktiverade Kubernetes antingen som ett kodprojekt eller en containerbaserad funktionsapp.

Om du vill skapa app- och planresurserna måste du redan ha skapat en App Service Kubernetes-miljö för ett Azure Arc-aktiverat Kubernetes-kluster. Exemplen i den här artikeln förutsätter att du har resurs-ID för den anpassade platsen (customLocationId) och App Service Kubernetes-miljön (kubeEnvironmentId) som du distribuerar till, som anges i det här exemplet:

param kubeEnvironmentId string
param customLocationId string

Både platser och planer måste referera till den anpassade platsen via ett extendedLocation fält. Som du ser i det här trunkerade exemplet extendedLocation ligger utanför properties, som en peer till kind och location:

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

Planresursen bör använda Kubernetes-värdet (K1) för SKU, kind fältet ska vara linux,kubernetes, och reserved egenskapen ska vara true, eftersom det är en Linux-distribution. Du måste också ange extendedLocation och kubeEnvironmentProfile.id till det anpassade plats-ID:t respektive Kubernetes-miljö-ID:t, vilket kan se ut som i det här exempelavsnittet:

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

Skapa funktionsappen

Funktionsappresursen definieras av en resurs av typen Microsoft.Web/sites och kind som innehåller functionapp, som minst.

Hur du definierar en funktionsappresurs beror på om du är värd för Linux eller Windows:

En lista över programinställningar som krävs vid körning i Windows finns i Programkonfiguration. En Bicep-exempelfil/Azure Resource Manager-mall finns i funktionsappen som finns i Windows i en mall för förbrukningsplan .

En lista över programinställningar som krävs vid körning i Windows finns i Programkonfiguration.

Flex Consumption ersätter många av de standardprograminställningar och platskonfigurationsegenskaper som används i distributioner av Bicep- och ARM-mallar. Mer information finns i Programkonfiguration.

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

Mer kontext finns i den fullständiga filen function.bicep i exempellagringsplatsen flexförbrukningsplan.

Kommentar

Om du väljer att definiera din förbrukningsplan måste du ange serverFarmId egenskapen i appen så att den pekar på resurs-ID:t för planen. Kontrollera att funktionsappen har en dependsOn inställning som även refererar till planen. Om du inte uttryckligen har definierat en plan skapas en åt dig.

serverFarmId Ange egenskapen i appen så att den pekar på resurs-ID:t för planen. Kontrollera att funktionsappen har en dependsOn inställning som även refererar till planen.

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

Ett fullständigt exempel från slutpunkt till slutpunkt finns i den här main.bicep-filen.

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

Ett fullständigt exempel från slutpunkt till slutpunkt finns i den här main.bicep-filen.

Distributionskällor

Du kan använda webbplatsinställningen linuxFxVersion för att begära att en specifik Linux-container ska distribueras till din app när den skapas. Fler inställningar krävs för att komma åt avbildningar på en privat lagringsplats. Mer information finns i Programkonfiguration.

Viktigt!

När du skapar egna containrar måste du hålla basavbildningen av containern uppdaterad till den senaste basavbildningen som stöds. Basavbildningar som stöds för Azure Functions är språkspecifika och finns i basavbildningslagringarna för Azure Functions.

Functions-teamet har åtagit sig att publicera månatliga uppdateringar för dessa basavbildningar. Regelbundna uppdateringar omfattar de senaste delversionsuppdateringarna och säkerhetskorrigeringarna för både Functions-körningen och språken. Du bör regelbundet uppdatera containern från den senaste basavbildningen och distribuera om den uppdaterade versionen av containern.

Din Bicep-fil eller ARM-mall kan också definiera en distribution för funktionskoden, som kan innehålla följande metoder:

Flex Consumption-planen underhåller projektkoden i en komprimerad paketfil i en bloblagringscontainer som kallas distributionscontainer. Du kan konfigurera både lagringskontot och containern som används för distribution. Mer information finns i Distribution

Du måste använda en distribution för att publicera kodpaketet till distributionscontainern. Under en ARM- eller Bicep-distribution kan du göra detta genom att definiera en paketkälla som använder /onedeploy tillägget. Om du i stället väljer att ladda upp paketet direkt till containern distribueras inte paketet automatiskt.

Distributionscontainer

Det specifika lagringskontot och containern som används för distributioner, autentiseringsmetoden och autentiseringsuppgifterna anges i elementet functionAppConfig.deployment.storage properties för platsen. Containern och eventuella programinställningar måste finnas när appen skapas. Ett exempel på hur du skapar lagringscontainern finns i Distributionscontainer.

I det här exemplet används en systemtilldelad hanterad identitet för att komma åt den angivna bloblagringscontainern, som skapas någon annanstans i distributionen:

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

När du använder hanterade identiteter måste du också aktivera funktionsappen för att få åtkomst till lagringskontot med hjälp av identiteten, vilket visas i det här exemplet:

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

Ett fullständigt referensexempel finns i den här Bicep-filen.

Det här exemplet kräver att du känner till GUID-värdet för rollen som tilldelas. Du kan hämta det här ID-värdet för valfritt eget rollnamn med kommandot az role definition list , som i det här exemplet:

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

När du använder en anslutningssträng i stället för hanterade identiteter måste du i stället ange authentication.type till StorageAccountConnectionString och ange authentication.storageAccountConnectionStringName namnet på den programinställning som innehåller distributionslagringskontot anslutningssträng.

Distributionspaket

Flex Consumption-planen använder en distribution för att distribuera ditt kodprojekt. Själva kodpaketet är samma som du skulle använda för zip-distribution i andra Functions-värdplaner. Namnet på själva paketfilen måste dock vara released-package.zip.

Om du vill inkludera ett distributionspaket i mallen använder du resursdefinitionen /onedeploy för fjärr-URL:en som innehåller distributionspaketet. Functions-värden måste kunna komma åt både den här fjärrpaketkällan och distributionscontainern.

I det här exemplet läggs en distributionskälla till i en befintlig 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 
  }
}

Din Bicep-fil eller ARM-mall kan också definiera en distribution för funktionskoden med hjälp av ett zip-distributionspaket.

För att distribuera ditt program med hjälp av Azure Resource Manager är det viktigt att förstå hur resurser distribueras i Azure. I de flesta exempel används konfigurationer på den översta nivån med hjälp siteConfigav . Det är viktigt att ställa in dessa konfigurationer på en toppnivå eftersom de förmedlar information till Functions-körnings- och distributionsmotorn. Information på den översta nivån krävs innan den underordnade sourcecontrols/web resursen tillämpas. Även om det är möjligt att konfigurera de här inställningarna i resursen på undernivå config/appSettings måste funktionsappen i vissa fall distribueras innan config/appSettings den tillämpas.

Zip-distributionspaket

Zip-distribution är ett rekommenderat sätt att distribuera funktionsappkoden. Som standard körs funktioner som använder zip-distribution i själva distributionspaketet. Mer information, inklusive kraven för ett distributionspaket, finns i Zip-distribution för Azure Functions. När du använder automatisering av resursdistribution kan du referera till .zip distributionspaketet i din Bicep- eller ARM-mall.

Om du vill använda zip-distribution i mallen WEBSITE_RUN_FROM_PACKAGE anger du inställningen i appen till 1 och inkluderar resursdefinitionen /zipDeploy .

För en förbrukningsplan i Linux anger du i stället URI för distributionspaketet direkt i WEBSITE_RUN_FROM_PACKAGE inställningen, som du ser i den här exempelmallen.

Det här exemplet lägger till en zip-distributionskälla i en befintlig 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
  }
}

Tänk på följande när du inkluderar zip-distributionsresurser i mallen:

  • packageUri Måste vara en plats som kan nås av Functions. Överväg att använda Azure Blob Storage med en signatur för delad åtkomst (SAS). När SAS upphör att gälla kan Functions inte längre komma åt resursen för distributioner. När du återskapar din SAS ska du komma ihåg att uppdatera WEBSITE_RUN_FROM_PACKAGE inställningen med det nya URI-värdet.

  • När du ställer in WEBSITE_RUN_FROM_PACKAGE på en URI måste du synkronisera utlösare manuellt.

  • Se till att alltid ange alla nödvändiga programinställningar i appSettings samlingen när du lägger till eller uppdaterar inställningar. Befintliga inställningar som inte uttryckligen anges tas bort av uppdateringen. Mer information finns i Programkonfiguration.

  • Functions stöder inte webbdistribution (msdeploy) för paketdistributioner. Du måste i stället använda zip-distribution i dina distributionspipelines och automatisering. Mer information finns i Zip-distribution för Azure Functions.

Fjärrversioner

Distributionsprocessen förutsätter att den .zip fil som du använder eller en zip-distribution innehåller en färdig app. Det innebär att inga anpassningar körs som standard.

Det finns scenarier som kräver att du återskapar appen via fjärranslutning. Ett sådant exempel är när du behöver inkludera Linux-specifika paket i Python eller Node.js appar som du har utvecklat på en Windows-dator. I det här fallet kan du konfigurera Functions för att utföra en fjärrversion av koden efter zip-distributionen.

Hur du begär en fjärrversion beror på vilket operativsystem du distribuerar:

När en app distribueras till Windows körs språkspecifika kommandon (till exempel dotnet restore för C#-appar eller npm install för Node.js appar).

Om du vill aktivera samma byggprocesser som du får med kontinuerlig integrering lägger du till SCM_DO_BUILD_DURING_DEPLOYMENT=true i dina programinställningar i distributionskoden och tar bort helt WEBSITE_RUN_FROM_PACKAGE och hållet.

Linux-containrar

Om du distribuerar en containerbaserad funktionsapp till en Azure Functions Premium- eller Dedicated-plan måste du:

Om vissa inställningar saknas kan programetablering misslyckas med det här HTTP/500-felet:

Function app provisioning failed.

Mer information finns i Programkonfiguration.

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

När du distribuerar containerbaserade funktioner till Azure Container Apps måste mallen:

  • Ange fältet kind till värdet functionapp,linux,container,azurecontainerapps.
  • Ange webbplatsegenskapen managedEnvironmentId till den fullständigt kvalificerade URI:n för Container Apps-miljön.
  • Lägg till en resurslänk i webbplatsens dependsOn samling när du skapar en Microsoft.App/managedEnvironments resurs samtidigt som webbplatsen.

Definitionen av en containerbaserad funktionsapp som distribueras från ett privat containerregister till en befintlig Container Apps-miljö kan se ut så här:

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

När du distribuerar funktioner till Azure Arc beror värdet som du anger för fältet för kind funktionsappresursen på typen av distribution:

Distributionstyp kind fältvärde
Kodbaserad distribution functionapp,linux,kubernetes
Containerdistribution functionapp,linux,kubernetes,container

Du måste också ange som customLocationId du gjorde för värdplansresursen.

Definitionen av en containerbaserad funktionsapp med hjälp av en .NET 6-snabbstartsavbildning kan se ut så här:

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

Tillämpningskonfiguration

I en Flex Consumption-plan konfigurerar du funktionsappen i Azure med två typer av egenskaper:

Konfiguration Microsoft.Web/sites egenskap
Tillämpningskonfiguration functionAppConfig
Programinställningar siteConfig.appSettings samling

Dessa programkonfigurationer underhålls i functionAppConfig:

Funktionssätt Ange i functionAppConfig
Alltid redo instanser scaleAndConcurrency.alwaysReady
Distributionskälla deployment
Minnesstorlek för instans scaleAndConcurrency.instanceMemoryMB
SAMTIDIGHET för HTTP-utlösare scaleAndConcurrency.triggers.http.perInstanceConcurrency
Språkkörning runtime.name
Språkversion runtime.version
Maximalt antal instanser scaleAndConcurrency.maximumInstanceCount

Flex Consumption-planen stöder även dessa programinställningar:

Functions innehåller följande alternativ för att konfigurera funktionsappen i Azure:

Konfiguration Microsoft.Web/sites egenskap
Webbplatsinställningar siteConfig
Programinställningar siteConfig.appSettings samling

De här webbplatsinställningarna krävs för egenskapen siteConfig :

De här webbplatsinställningarna krävs endast när hanterade identiteter används för att hämta avbildningen från en Azure Container Registry-instans:

Dessa programinställningar krävs (eller rekommenderas) för ett specifikt operativsystem och värdalternativ:

Dessa programinställningar krävs för containerdistributioner:

De här inställningarna krävs bara när du distribuerar från ett privat containerregister:

Tänk på följande när du arbetar med webbplats- och programinställningar med hjälp av Bicep-filer eller ARM-mallar:

  • Den valfria alwaysReady inställningen innehåller en matris med ett eller flera {name,instanceCount} objekt, med ett för varje skalningsgrupp per funktion. Det här är skalningsgrupperna som används för att fatta skalningsbeslut som alltid är klara. I det här exemplet anges alltid redo antal för både http gruppen och en enda funktion med namnet helloworld, som är av en icke-grupperad utlösartyp:
      alwaysReady: [
        {
          name: 'http'
          instanceCount: 2
        }
        {
          name: 'function:helloworld'
          instanceCount: 1
        }
      ]
    
  • Det finns viktiga saker att tänka på när du bör ange WEBSITE_CONTENTSHARE i en automatiserad distribution. Detaljerad vägledning finns i referensen WEBSITE_CONTENTSHARE .
  • Du bör alltid definiera dina programinställningar som en siteConfig/appSettings samling av resursen Microsoft.Web/sites som skapas, som du gör i exemplen i den här artikeln. Den här definitionen garanterar att de inställningar som funktionsappen behöver köra är tillgängliga vid den första starten.

  • När du lägger till eller uppdaterar programinställningar med hjälp av mallar måste du inkludera alla befintliga inställningar med uppdateringen. Du måste göra detta eftersom rest-API-anropen för den underliggande uppdateringen ersätter hela /config/appsettings resursen. Om du tar bort de befintliga inställningarna körs inte funktionsappen. Om du vill uppdatera enskilda programinställningar programmatiskt kan du i stället använda Azure CLI, Azure PowerShell eller Azure Portal för att göra dessa ändringar. Mer information finns i Arbeta med programinställningar.

Distributioner av fack

Med Functions kan du distribuera olika versioner av koden till unika slutpunkter i funktionsappen. Det här alternativet gör det enklare att utveckla, validera och distribuera funktionsuppdateringar utan att påverka funktioner som körs i produktion. Distributionsplatser är en funktion i Azure App Service. Antalet tillgängliga platser beror på din värdplan. Mer information finns i Funktioner för Distributionsfack i Azure Functions.

En fackresurs definieras på samma sätt som en funktionsappresurs (Microsoft.Web/sites), men i stället använder du resursidentifieraren Microsoft.Web/sites/slots . En exempeldistribution (i både Bicep- och ARM-mallar) som skapar både en produktion och en mellanlagringsplats i en Premium-plan finns i Azure Function App with a Deployment Slot (Azure Function App with a Deployment Slot).

Mer information om hur du byter fack med hjälp av mallar finns i Automatisera med Resource Manager-mallar.

Tänk på följande när du arbetar med distributioner av fack:

  • Ange inte uttryckligen WEBSITE_CONTENTSHARE inställningen i distributionsfackdefinitionen. Den här inställningen genereras åt dig när appen skapas i distributionsfacket.

  • När du byter fack anses vissa programinställningar vara "klibbiga", eftersom de stannar kvar i facket och inte med koden som byts ut. Du kan definiera en sådan platsinställning genom att inkludera "slotSetting":true i den specifika programinställningsdefinitionen i mallen. Mer information finns i Hantera inställningar.

Skyddade distributioner

Du kan skapa din funktionsapp i en distribution där en eller flera av resurserna har skyddats genom integrering med virtuella nätverk. Integrering av virtuella nätverk för funktionsappen definieras av en Microsoft.Web/sites/networkConfig resurs. Den här integreringen beror på både den refererade funktionsappen och virtuella nätverksresurser. Din funktionsapp kan också vara beroende av andra privata nätverksresurser, till exempel privata slutpunkter och vägar. Mer information finns i Nätverksalternativ för Azure Functions.

De här projekten innehåller Bicep-baserade exempel på hur du distribuerar dina funktionsappar i ett virtuellt nätverk, inklusive med begränsningar för nätverksåtkomst:

När du skapar en distribution som använder ett skyddat lagringskonto måste du både uttryckligen WEBSITE_CONTENTSHARE ange inställningen och skapa filresursen med namnet i den här inställningen. Se till att du skapar en Microsoft.Storage/storageAccounts/fileServices/shares resurs med värdet WEBSITE_CONTENTSHARE, som du ser i det här exemplet (ARM-mallens|Bicep-fil). Du måste också ange webbplatsegenskapen vnetContentShareEnabled till true.

Kommentar

När de här inställningarna inte ingår i en distribution som använder ett skyddat lagringskonto visas det här felet under distributionsverifieringen: Could not access storage account using provided connection string.

Dessa projekt innehåller både Bicep- och ARM-mallexempel på hur du distribuerar dina funktionsappar i ett virtuellt nätverk, inklusive med begränsningar för nätverksåtkomst:

Begränsat scenario beskrivning
Skapa en funktionsapp med integrering av virtuella nätverk Din funktionsapp skapas i ett virtuellt nätverk med fullständig åtkomst till resurser i nätverket. Inkommande och utgående åtkomst till funktionsappen är inte begränsad. Mer information finns i Integrering av virtuellt nätverk.
Skapa en funktionsapp som har åtkomst till ett skyddat lagringskonto Den skapade funktionsappen använder ett skyddat lagringskonto som Functions kommer åt med hjälp av privata slutpunkter. Mer information finns i Begränsa ett lagringskonto till ett virtuellt nätverk.
Skapa en funktionsapp och ett lagringskonto som båda använder privata slutpunkter Din skapade funktionsapp kan bara nås med hjälp av privata slutpunkter och den använder privata slutpunkter för att komma åt lagringsresurser. Mer information finns i Privata slutpunkter.

Begränsade nätverksinställningar

Du kan också behöva använda de här inställningarna när funktionsappen har nätverksbegränsningar:

Inställning Värde beskrivning
WEBSITE_CONTENTOVERVNET 1 Programinställning som gör att funktionsappen kan skalas när lagringskontot är begränsat till ett virtuellt nätverk. Mer information finns i Begränsa ett lagringskonto till ett virtuellt nätverk.
vnetrouteallenabled 1 Webbplatsinställning som tvingar all trafik från funktionsappen att använda det virtuella nätverket. Mer information finns i Regional integrering av virtuella nätverk. Den här webbplatsinställningen ersätter programinställningen WEBSITE_VNET_ROUTE_ALL.

Överväganden för nätverksbegränsningar

När du begränsar åtkomsten till lagringskontot via de privata slutpunkterna kan du inte komma åt lagringskontot via portalen eller någon enhet utanför det virtuella nätverket. Du kan ge åtkomst till din skyddade IP-adress eller virtuella nätverk i lagringskontot genom att hantera standardregeln för nätverksåtkomst.

Funktionsåtkomstnycklar

Åtkomstnycklar på värdnivå definieras som Azure-resurser. Det innebär att du kan skapa och hantera värdnycklar i ARM-mallar och Bicep-filer. En värdnyckel definieras som en resurs av typen Microsoft.Web/sites/host/functionKeys. I det här exemplet skapas en åtkomstnyckel på värdnivå med namnet my_custom_key när funktionsappen skapas:

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

I det här exemplet är parametern name namnet på den nya funktionsappen. Du måste inkludera en dependsOn inställning för att garantera att nyckeln skapas med den nya funktionsappen. Slutligen properties kan objektet för värdnyckeln även innehålla en value egenskap som kan användas för att ange en specifik nyckel.

När du inte anger value egenskapen genererar Functions automatiskt en ny nyckel åt dig när resursen skapas, vilket rekommenderas. Mer information om åtkomstnycklar, inklusive rekommenderade säkerhetsmetoder för att arbeta med åtkomstnycklar, finns i Arbeta med åtkomstnycklar i Azure Functions.

Skapa mallen

Experter med Bicep- eller ARM-mallar kan koda sina distributioner manuellt med hjälp av en enkel textredigerare. För oss andra finns det flera sätt att göra utvecklingsprocessen enklare:

  • Visual Studio Code: Det finns tillägg som hjälper dig att arbeta med både Bicep-filer och ARM-mallar. Du kan använda de här verktygen för att se till att koden är korrekt och tillhandahålla viss grundläggande validering.

  • Azure Portal: När du skapar din funktionsapp och relaterade resurser i portalen har den sista skärmen Granska + skapa en länk för att ladda ned en mall för automatisering.

    Ladda ned malllänken från processen för att skapa Azure Functions i Azure Portal.

    Den här länken visar arm-mallen som genererats baserat på de alternativ som du valde i portalen. Den här mallen kan verka lite komplex när du skapar en funktionsapp med många nya resurser. Den kan dock ge en bra referens för hur ARM-mallen kan se ut.

Verifiera mallen

När du skapar distributionsmallfilen manuellt är det viktigt att verifiera mallen före distributionen. Alla distributionsmetoder validerar mallsyntaxen och skapar ett validation failed felmeddelande som visas i följande JSON-formaterade exempel:

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

Följande metoder kan användas för att verifiera mallen före distributionen:

Följande Azure-resursgruppsdistribution v2-uppgift med deploymentMode: 'Validation' instruerar Azure Pipelines att verifiera mallen.

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

Du kan också skapa en testresursgrupp för att hitta preflight - och distributionsfel .

Distribuera mallen

Du kan använda något av följande sätt att distribuera Bicep-filen och mallen:

Distribuera till Azure (knapp)

Kommentar

Den här metoden stöder inte distribution av Bicep-filer för närvarande.

Ersätt <url-encoded-path-to-azuredeploy-json> med en URL-kodad version av filens råsökväg azuredeploy.json i GitHub.

Här är ett exempel som använder markdown:

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

Här är ett exempel som använder 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>

Distribuera med hjälp av PowerShell

Följande PowerShell-kommandon skapar en resursgrupp och distribuerar en Bicep-fil eller ARM-mall som skapar en funktionsapp med nödvändiga resurser. Om du vill köra lokalt måste du ha Azure PowerShell installerat. Om du vill logga in på Azure måste du först köra 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

Om du vill testa den här distributionen kan du använda en mall som den här som skapar en funktionsapp i Windows i en förbrukningsplan.

Nästa steg

Läs mer om hur du utvecklar och konfigurerar Azure Functions.