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) |
Viktigt!
Flex Consumption-planen är för närvarande i förhandsversion.
Tänk på följande när du använder den här artikeln:
Det finns inget kanoniskt sätt att strukturera en ARM-mall.
En Bicep-distribution kan modulariseras till flera Bicep-filer.
Den här artikeln förutsätter att du har en grundläggande förståelse för att skapa Bicep-filer eller redigera Azure Resource Manager-mallar.
- Exempel visas som enskilda avsnitt för specifika resurser. En bred uppsättning kompletta Bicep-fil- och ARM-mallexempel finns i dessa exempel på funktionsappdistribution.
- 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.
- Den här artikeln förutsätter att du redan har skapat en App Service-aktiverad anpassad plats i ett Azure Arc-aktiverat Kubernetes-kluster. Du behöver både det anpassade plats-ID:t och Kubernetes-miljö-ID:t för att skapa en funktionsapp som finns på en anpassad Azure Arc-plats.
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
, EP2
eller 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:
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:
I Flex Consumption-planen distribueras projektkoden från ett zip-komprimerat paket som publicerats till en Blob Storage-container. Mer information finns i Distribution 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.
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.
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 siteConfig
av . 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:
- Förbrukningsplaner i Linux stöder
WEBSITE_RUN_FROM_PACKAGE = 1
inte . Du måste i stället ange URI:n för distributionspaketet direkt i inställningenWEBSITE_RUN_FROM_PACKAGE
. Mer information finns i WEBSITE_RUN_FROM_PACKAGE. En exempelmall finns i Funktionsapp som finns i Linux i en förbrukningsplan.
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 uppdateraWEBSITE_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:
- Ange platsinställningen
linuxFxVersion
med identifieraren för containeravbildningen. - Ange nödvändiga
DOCKER_REGISTRY_SERVER_*
inställningar när du hämtar containern från ett privat register. - Ange
WEBSITES_ENABLE_APP_SERVICE_STORAGE
programinställningen tillfalse
.
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ärdetfunctionapp,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 enMicrosoft.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:
- Inställningar för anslutningssträngar:
- Hanterade identitetsbaserade instä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ådehttp
gruppen och en enda funktion med namnethelloworld
, som är av en icke-grupperad utlösartyp:
- 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 referensenWEBSITE_CONTENTSHARE
.
- För containerdistributioner anger du
WEBSITES_ENABLE_APP_SERVICE_STORAGE
även tillfalse
, eftersom appinnehållet tillhandahålls i själva containern.
Du bör alltid definiera dina programinställningar som en
siteConfig/appSettings
samling av resursenMicrosoft.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:
- Högskalad HTTP-utlöst funktion ansluter till en händelsehubb som skyddas av ett virtuellt nätverk: En HTTP-utlöst funktion (.NET-isolerat arbetsläge) accepterar anrop från valfri källa och skickar sedan brödtexten för dessa HTTP-anrop till en säker händelsehubb som körs i ett virtuellt nätverk med hjälp av integrering av virtuellt nätverk.
- Funktionen utlöses av en Service Bus-kö som skyddas i ett virtuellt nätverk: En Python-funktion utlöses av en Service Bus-kö som skyddas i ett virtuellt nätverk. Kön nås i det virtuella nätverket med hjälp av en privat slutpunkt. En virtuell dator i det virtuella nätverket används för att skicka meddelanden.
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.
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. Kör Connect-AzAccount
för att logga in.
# 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.