Condividi tramite

Automatizzare la distribuzione di risorse per l'app per le funzioni in Funzioni di Azure

  • Articolo

È possibile usare un file Bicep o un modello di Azure Resource Manager (ARM) per automatizzare il processo di distribuzione dell'app per le funzioni. Durante la distribuzione, è possibile usare le risorse di Azure esistenti o crearne di nuove. L'assistenza per l'automazione si presenta con questi scenari:

  • Integrazione delle distribuzioni di risorse con il codice sorgente nelle distribuzioni basate su Azure Pipelines e GitHub Actions.
  • Ripristino di un'app per le funzioni e delle risorse correlate da un backup.
  • Distribuzione di una topologia di app più volte.

Questo articolo illustra come automatizzare la creazione di risorse e distribuzione per Funzioni di Azure. A seconda dei trigger e delle associazioni usate dalle funzioni, potrebbe essere necessario distribuire altre risorse, cosa che non rientra nell'ambito di questo articolo.

Il codice del modello necessario dipende dalle opzioni di hosting desiderate per l'app per le funzioni. Questo articolo supporta le opzioni di hosting seguenti:

Opzione Hosting Tipo di distribuzione Per altre informazioni, vedere...
Piano di consumo di Funzioni di Azure Solo codice Piano a consumo
Piano a consumo di Funzioni di Azure Flex Solo codice Piano A consumo Flex
Piano Elastico di Funzioni di Azure Premium Codice | Contenitore Piano Premium
Piano dedicato di Funzioni di Azure (servizio app) Codice | Contenitore Piano dedicato
App contenitore di Azure Solo contenitore Hosting di app contenitore di Funzioni di Azure
Azure Arc Codice | Contenitore Servizio app, Funzioni e App per la logica in Azure Arc (anteprima)

Importante

Il piano A consumo Flex è attualmente in anteprima.

Quando si usa questo articolo, tenere presenti queste considerazioni:

  • Gli esempi vengono visualizzati come singole sezioni per risorse specifiche.

Risorse necessarie

È necessario creare o configurare queste risorse per una distribuzione ospitata in Funzioni di Azure:

Conto risorse Requisito Informazioni di riferimento su sintassi e proprietà
Un account di archiviazione Richiesto Microsoft.Storage/storageAccounts
Un componente di Application Insights Consigliato Microsoft.Insights/components*
Un piano di hosting Richiesto Microsoft.Web/serverfarms
Un'app per le funzioni Richiesto Microsoft.Web/sites

È necessario creare o configurare queste risorse per una distribuzione ospitata in Funzioni di Azure:

Conto risorse Requisito Informazioni di riferimento su sintassi e proprietà
Un account di archiviazione Richiesto Microsoft.Storage/storageAccounts
Un componente di Application Insights Consigliato Microsoft.Insights/components*
Un'app per le funzioni Richiesto Microsoft.Web/sites

Una distribuzione ospitata in App Contenitore di Azure è in genere costituita da queste risorse:

Conto risorse Requisito Informazioni di riferimento su sintassi e proprietà
Un account di archiviazione Richiesto Microsoft.Storage/storageAccounts
Un componente di Application Insights Consigliato Microsoft.Insights/components*
Un ambiente gestito Richiesto Microsoft.App/managedEnvironments
Un'app per le funzioni Richiesto Microsoft.Web/sites

Una distribuzione ospitata in Azure Arc è in genere costituita da queste risorse:

Conto risorse Requisito Informazioni di riferimento su sintassi e proprietà
Un account di archiviazione Richiesto Microsoft.Storage/storageAccounts
Un componente di Application Insights Consigliato Microsoft.Insights/components1
Un ambiente Kubernetes del servizio app Richiesto Microsoft.ExtendedLocation/customLocations
Un'app per le funzioni Richiesto Microsoft.Web/sites

*Se non si ha già un'area di lavoro Log Analytics che può essere usata dall'istanza di Application Insights, è anche necessario creare questa risorsa.

Quando si distribuiscono più risorse in un singolo file Bicep o modello di Resource Manager, l'ordine in cui vengono create le risorse è importante. Questo requisito è il risultato delle dipendenze tra le risorse. Per tali dipendenze, assicurarsi di usare l'elemento dependsOn per definire la dipendenza nella risorsa dipendente. Per altre informazioni, vedere Definire l'ordine di distribuzione delle risorse nei modelli ARM o Dipendenze delle risorse in Bicep.

Prerequisiti

  • Gli esempi sono progettati per l'esecuzione nel contesto di un gruppo di risorse esistente.
  • Sia Application Insights che i log di archiviazione richiedono che sia disponibile un'area di lavoro Azure Log Analytics. Le aree di lavoro possono essere condivise tra i servizi e, di norma, è consigliabile creare un'area di lavoro in ogni area geografica per migliorare le prestazioni. Per un esempio di come creare un'area di lavoro Log Analytics, vedere Creare un'area di lavoro Log Analytics. È possibile trovare l'ID risorsa dell'area di lavoro completo in una pagina dell'area di lavoro nel portale di Azure in Impostazioni>Proprietà>ID risorsa.
  • Questo articolo presuppone che sia già stato creato un ambiente gestito in App Azure Container. È necessario sia il nome che l'ID dell'ambiente gestito per creare un'app per le funzioni ospitata in App contenitore.

Creare un account di archiviazione

Tutte le app per le funzioni richiedono un account di archiviazione di Azure. È necessario un account per utilizzo generico che supporti BLOB, tabelle, code e i file. Per altre informazioni, vedere i requisiti dell'account di archiviazione per Funzioni di Azure.

Importante

L'account di archiviazione viene usato per archiviare dati importanti dell'app, a volte incluso il codice dell'applicazione stesso. È consigliabile limitare l'accesso da altre app e utenti all'account di archiviazione.

In questa sezione di esempio viene creato un account di archiviazione per utilizzo generico v2 Standard:

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

Per altre informazioni di contesto, vedere il file main.bicep completo nel repository dei modelli.

Per altre informazioni di contesto, vedere il file storage-account.bicep completo nel repository di esempio.

È necessario impostare la stringa di connessione di questo account di archiviazione come impostazione dell'app AzureWebJobsStorage, che funzioni richiede. I modelli in questo articolo creano questo valore della stringa di connessione in base all'account di archiviazione creato, una procedura consigliata. Per altre informazioni, vedere Configurazione dell'applicazione.

Contenitore di distribuzione

Le distribuzioni in un'app in esecuzione nel piano a consumo Flex richiedono un contenitore in Archiviazione BLOB di Azure come origine di distribuzione. È possibile usare l'account di archiviazione predefinito oppure specificare un account di archiviazione separato. Per altre informazioni, vedere Configurare le impostazioni di distribuzione.

Questo account di distribuzione deve essere già configurato quando si crea l'app, incluso il contenitore specifico usato per le distribuzioni. Per altre informazioni sulla configurazione delle distribuzioni, vedere Origini di distribuzione.

Questo esempio illustra come creare un contenitore nell'account di archiviazione:

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

Per il frammento di codice nel contesto, vedere questo esempio di distribuzione.

Altre impostazioni di distribuzione vengono configurate con l'app stessa.

Abilitare i log di archiviazione

Poiché l'account di archiviazione viene usato per i dati importanti dell'app per le funzioni, è necessario monitorare l'account per la modifica del contenuto. Per monitorare l'account di archiviazione, è necessario configurare i log delle risorse di Monitoraggio di Azure per Archiviazione di Azure. In questa sezione di esempio viene usata un'area di lavoro Log Analytics denominata myLogAnalytics come destinazione per questi log.

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

Questa stessa area di lavoro può essere usata per la risorsa di Application Insights definita in un secondo momento. Per altre informazioni, tra cui come usare questi log, vedere Monitoraggio di Archiviazione di Azure.

Creare Application Insights

È consigliabile usare Application Insights per monitorare le esecuzioni delle app per le funzioni. Application Insights richiede ora un'area di lavoro Log Analytics di Azure, che può essere condivisa. Questi esempi presuppongono che si usi un'area di lavoro esistente e che sia disponibile l'ID risorsa completo per l'area di lavoro. Per altre informazioni, vedere Area di lavoro Log Analytics di Azure.

In questa sezione di esempio la risorsa di Application Insights viene definita con il tipo Microsoft.Insights/components e la tipologia 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>'
  }
}

Per altre informazioni di contesto, vedere il file main.bicep completo nel repository dei modelli.

La connessione deve essere fornita all'app per le funzioni usando l'impostazione dell'applicazione APPLICATIONINSIGHTS_CONNECTION_STRING. Per altre informazioni, vedere Configurazione dell'applicazione.

Gli esempi in questo articolo ottengono il valore della stringa di connessione per l'istanza creata. Le versioni precedenti potrebbero invece usare APPINSIGHTS_INSTRUMENTATIONKEY per impostare la chiave di strumentazione, che non è più consigliata.

Creare il piano di hosting

Le app ospitate in un piano a consumo Flex, piano Premiumo piano dedicato (servizio app) devono avere il piano di hosting definito in modo esplicito.

Consumo Flex è un piano di hosting basato su Linux che si basa sul modello di fatturazione serverless di pagamento a consumo per ciò che si usa. Il piano supporta la rete privata, la selezione delle dimensioni della memoria dell'istanza e il supporto migliorato per le identità gestite.

Un piano Flex Consumption è un tipo speciale di risorsa serverfarm. È possibile specificarlo usando FC1 per il valore della proprietà Name nella proprietà sku con un valore tier di FlexConsumption.

Questa sezione di esempio crea il piano Flex Consumption:

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

Per altre informazioni di contesto, vedere il file function.bicep completo nel repository di esempio del piano a consumo Flex.

Poiché il piano Flex Consumption supporta attualmente solo Linux, è necessario impostare anche la proprietà reserved su true.

Il piano Premium offre la stessa scalabilità del piano a consumo, ma include risorse dedicate e funzionalità aggiuntive. Per altre informazioni, vedere Piano Premium di Funzioni di Azure.

Un piano Premium è un tipo speciale di risorsa serverfarm. È possibile specificarlo usando EP1, EP2o EP3 per il valore della proprietà Name nella proprietà sku. Il modo in cui si definisce il piano di hosting di Funzioni dipende dal fatto che l'app per le funzioni venga eseguita in Windows o in Linux. In questa sezione di esempio viene creato un piano EP1:

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

Per altre informazioni di contesto, vedere il file main.bicep completo nel repository dei modelli.

Per altre informazioni sull'oggetto sku, vedere SkuDefinition o esaminare i modelli di esempio.

Nel piano dedicato (servizio app) l'app per le funzioni viene eseguita in macchine virtuali dedicate in SKU Basic, Standard e Premium nei piani di servizio app, in modo analogo alle app Web. Per altre informazioni, vedere piano dedicato.

Per un esempio di file Bicep/modello di Azure Resource Manager, vedere 'app per le funzioni nel piano di servizio app di Azure

In Funzioni il piano dedicato è solo un piano di servizio app normale, definito da una risorsa serverfarm. È necessario specificare almeno il valore name. Per un elenco dei nomi dei piani supportati, vedere l'impostazione --sku in az appservice plan create per l'elenco corrente dei valori supportati per un piano dedicato.

Il modo in cui si definisce il piano di hosting dipende dal fatto che l'app per le funzioni venga eseguita in Windows o in Linux:

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

Per altre informazioni di contesto, vedere il file main.bicep completo nel repository dei modelli.

Creare il piano di hosting

Non è necessario definire in modo esplicito una risorsa del piano di hosting a consumo. Quando si ignora questa definizione di risorsa, un piano viene creato o selezionato automaticamente per ogni area quando si crea la risorsa dell'app per le funzioni stessa.

È possibile definire in modo esplicito un piano a consumo come tipo speciale di risorsa serverfarm, che si specifica usando il valore Dynamic per le proprietà computeMode e sku. Questa sezione di esempio illustra come definire in modo esplicito un piano a consumo. Il modo in cui si definisce un piano di hosting dipende dal fatto che l'app per le funzioni venga eseguita in Windows o in 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'
  }
}

Per altre informazioni di contesto, vedere il file main.bicep completo nel repository dei modelli.

Ambiente Kubernetes

Funzioni di Azure può essere distribuito in Kubernetes abilitato per Azure Arc come progetto di codice o come app per le funzioni in contenitori.

Per creare l'app e pianificare le risorse, è necessario avere già creato un ambiente Kubernetes del servizio app per un cluster Kubernetes abilitato per Azure Arc. Gli esempi in questo articolo presuppongono di avere l'ID risorsa della posizione personalizzata (customLocationId) e dell'ambiente Kubernetes del servizio app (kubeEnvironmentId) in cui si esegue la distribuzione, che vengono impostati in questo esempio:

param kubeEnvironmentId string
param customLocationId string

Sia i siti che i piani devono fare riferimento alla posizione personalizzata tramite un campo extendedLocation. Come illustrato in questo esempio troncato, extendedLocation si trova all'esterno di properties, come peer a kind e location:

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

La risorsa di piano deve usare il valore kubernetes (K1) per SKU, il campo kind deve essere linux,kubernetes e la proprietà reserved deve essere true, poiché si tratta di una distribuzione Linux. È anche necessario impostare extendedLocation e kubeEnvironmentProfile.id rispettivamente sull'ID percorso personalizzato e sull'ID ambiente Kubernetes, che potrebbe essere simile alla sezione di esempio seguente:

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

Creare l'app per le funzioni

La risorsa dell'app per le funzioni è definita da una risorsa di tipo Microsoft.Web/sites e kind che include, almeno, functionapp.

Il modo in cui si definisce una risorsa dell'app per le funzioni dipende dal fatto che si stia ospitando in Linux o in Windows:

Per un elenco delle impostazioni dell'applicazione necessarie durante l'esecuzione in Windows, vedere Configurazione dell'applicazione. Per un esempio di file Bicep/modello di Azure Resource Manager, vedere il modello app per le funzioni ospitata in Windows in un piano a consumo.

Per un elenco delle impostazioni dell'applicazione necessarie durante l'esecuzione in Windows, vedere Configurazione dell'applicazione.

Flex Consumption sostituisce molte delle impostazioni dell'applicazione standard e le proprietà di configurazione del sito usate nelle distribuzioni di modelli Bicep e ARM. Per altre informazioni, vedere Configurazione dell'applicazione.

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

Per altre informazioni di contesto, vedere il file function.bicep completo nel repository di esempio del piano a consumo Flex.

Nota

Se si sceglie di definire facoltativamente il piano a consumo, è necessario impostare la proprietà serverFarmId nell'app in modo che punti all'ID risorsa del piano. Assicurarsi che l'app per le funzioni abbia un'impostazione dependsOn che faccia riferimento anche al piano. Se non è stato definito in modo esplicito un piano, ne viene creato uno.

Impostare la proprietà serverFarmId nell'app in modo che punti all'ID risorsa del piano. Assicurarsi che l'app per le funzioni abbia un'impostazione dependsOn che faccia riferimento anche al piano.

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

Per un esempio completo end-to-end, vedere questo file main.bicep.

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

Per un esempio completo end-to-end, vedere questo file main.bicep.

Origini di distribuzione

Il file Bicep o il modello di Resource Manager può anche definire una distribuzione per il codice della funzione, che può includere questi metodi:

Origini di distribuzione

Nel piano Flex Consumption il codice del progetto viene distribuito da un pacchetto compresso zip pubblicato in un contenitore di archiviazione BLOB. Per ulteriori informazioni, vedi Distribuzione. L'account di archiviazione e il contenitore specifici usati per le distribuzioni, il metodo di autenticazione e le credenziali vengono impostati nell'elemento functionAppConfig.deployment.storage di properties per il sito. Il contenitore e tutte le impostazioni dell'applicazione devono esistere al momento della creazione dell'app. Per un esempio di come creare il contenitore di archiviazione, vedere Contenitore di distribuzione.

Questo esempio usa un'identità gestita assegnata dal sistema per accedere al contenitore di archiviazione BLOB specificato, creato altrove nella distribuzione:

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

Quando si usano le identità gestite, è anche necessario abilitare l'app per le funzioni per accedere all'account di archiviazione usando l'identità, come illustrato in questo esempio:

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

Per un esempio di riferimento completo, vedere questo file Bicep.

Quando si usa una stringa di connessione anziché le identità gestite, è necessario impostare il authentication.type su StorageAccountConnectionString e impostare authentication.storageAccountConnectionStringName sul nome dell'impostazione dell'applicazione che contiene la stringa di connessione dell'account di archiviazione di distribuzione.

Origini di distribuzione

Il file Bicep o il modello di Resource Manager può anche definire una distribuzione per il codice della funzione usando un pacchetto di distribuzione ZIP.

Per poter distribuire l'applicazione usando Azure Resource Manager, è importante comprendere come vengono distribuite le risorse in Azure. Nella maggior parte degli esempi, le configurazioni di primo livello vengono applicate tramite siteConfig. È importante impostare le configurazioni a un livello superiore perché forniscono informazioni al motore di runtime e di distribuzione di Funzioni di Azure. Le informazioni di primo livello sono necessarie prima dell'applicazione della risorsa figlio sourcecontrols/web. Sebbene sia possibile configurare queste impostazioni nella risorsa config/appSettings a livello figlio, in alcuni casi l'app per le funzioni deve essere distribuita prima di applicare config/appSettings.

Pacchetto di distribuzione ZIP

La distribuzione zip è un modo consigliato per distribuire il codice dell'app per le funzioni. Per impostazione predefinita, le funzioni che usano la distribuzione ZIP vengono eseguite nel pacchetto di distribuzione stesso. Per altre informazioni, inclusi i requisiti per un pacchetto di distribuzione, vedere Distribuzione ZIP per Funzioni di Azure. Quando si usa l'automazione della distribuzione delle risorse, è possibile fare riferimento al pacchetto di distribuzione .zip nel modello Bicep o ARM.

Per usare la distribuzione ZIP nel modello, impostare l'impostazione WEBSITE_RUN_FROM_PACKAGE nell'app su 1 e includere la definizione di risorsa /zipDeploy.

Per un piano a consumo in Linux, impostare invece l'URI del pacchetto di distribuzione direttamente nell'impostazione WEBSITE_RUN_FROM_PACKAGE, come illustrato in questo modello di esempio.

Questo esempio aggiunge un'origine di distribuzione ZIP a un'app esistente:

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

Tenere presente quanto segue quando si includono le risorse di distribuzione ZIP nel modello:

  • packageUri deve essere una posizione accessibile da Funzioni. Prendere in considerazione l'uso dell'archiviazione BLOB di Azure con una firma di accesso condiviso. Dopo la scadenza della firma di accesso condiviso, Funzioni non può più accedere alla condivisione per le distribuzioni. Quando si rigenera la firma di accesso condiviso, ricordarsi di aggiornare l'impostazione WEBSITE_RUN_FROM_PACKAGE con il nuovo valore URI.

  • Quando si imposta WEBSITE_RUN_FROM_PACKAGE su un URI, è necessario sincronizzare manualmente i trigger.

  • Assicurarsi di impostare sempre tutte le impostazioni dell'applicazione necessarie nella raccolta appSettings durante l'aggiunta o l'aggiornamento delle impostazioni. Le impostazioni esistenti non impostate in modo esplicito vengono rimosse dall'aggiornamento. Per altre informazioni, vedere Configurazione dell'applicazione.

  • Funzioni non supporta Distribuzione Web (msdeploy) per le distribuzioni di pacchetti. È invece necessario usare la distribuzione ZIP nelle pipeline di distribuzione e nell'automazione. Per altre informazioni, vedere distribuzione zip per Funzioni di Azure.

Compilazioni remote

Il processo di distribuzione presuppone che il file .zip usato o una distribuzione ZIP contenga un'app pronta per l'esecuzione. Ciò significa che per impostazione predefinita non vengono eseguite personalizzazioni.

Esistono scenari che richiedono di ricompilare l'app in modalità remota. Un esempio è quando è necessario includere pacchetti specifici di Linux in Python o Node.js app sviluppate in un computer Windows. In questo caso, è possibile configurare Funzioni per eseguire una compilazione remota sul codice dopo la distribuzione zip.

Il modo in cui si richiede una compilazione remota dipende dal sistema operativo in cui si sta distribuendo:

Quando un'app viene distribuita in Windows, vengono eseguiti comandi specifici del linguaggio (ad esempio dotnet restore per le app C# o npm install per le app Node.js).

Per abilitare gli stessi processi di compilazione che si ottengono con l'integrazione continua, aggiungere SCM_DO_BUILD_DURING_DEPLOYMENT=true alle impostazioni dell'applicazione nel codice di distribuzione e rimuovere WEBSITE_RUN_FROM_PACKAGE completamente.

Contenitori Linux

Se si distribuisce un'app per le funzioni in contenitori in un piano Premium o Dedicato di Funzioni di Azure, è necessario:

Se alcune impostazioni risultano mancanti, il provisioning dell'applicazione potrebbe fallire con questo errore HTTP/500:

Function app provisioning failed.

Per altre informazioni, vedere Configurazione dell'applicazione.

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

Quando si distribuiscono funzioni in contenitori in App Azure Container, il modello deve:

  • Impostare il campo kind su un valore di functionapp,linux,container,azurecontainerapps.
  • Impostare la proprietà del sito managedEnvironmentId sull'URI completo dell'ambiente App contenitore.
  • Aggiungere un collegamento alla risorsa nella raccolta di dependsOn del sito durante la creazione di una risorsa Microsoft.App/managedEnvironments contemporaneamente al sito.

La definizione di un'app per le funzioni in contenitori distribuita da un registro contenitori privato in un ambiente app contenitore esistente potrebbe essere simile all'esempio seguente:

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

Quando si distribuiscono funzioni in Azure Arc, il valore impostato per il campo kind della risorsa dell'app per le funzioni dipende dal tipo di distribuzione:

Tipo di distribuzione kind valore del campo
Distribuzione solo codice functionapp,linux,kubernetes
Distribuzione di contenitori functionapp,linux,kubernetes,container

È anche necessario impostare il customLocationId come è stato fatto per la risorsa del piano di hosting.

La definizione di un'app per le funzioni in contenitori, usando un'immagine di avvio rapido di .NET 6, potrebbe essere simile all'esempio seguente:

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

Configurazione dell'applicazione

In un piano a consumo Flex si configura l'app per le funzioni in Azure con due tipi di proprietà:

Impostazione Proprietà Microsoft.Web/sites
Configurazione dell'applicazione functionAppConfig
Impostazioni delle applicazioni siteConfig.appSettings raccolta

Queste configurazioni dell'applicazione sono mantenute in functionAppConfig:

Comportamento Impostazione in functionAppConfig
Istanze sempre pronte scaleAndConcurrency.alwaysReady
Origine distribuzione deployment
Dimensioni della memoria dell'istanza scaleAndConcurrency.instanceMemoryMB
Concorrenza di trigger HTTP scaleAndConcurrency.triggers.http.perInstanceConcurrency
Runtime del linguaggio runtime.name
Versione del linguaggio runtime.version
Numero massimo di istanze scaleAndConcurrency.maximumInstanceCount

Il piano Flex Consumption supporta anche queste impostazioni dell'applicazione:

Funzioni offre le opzioni seguenti per la configurazione dell'app per le funzioni in Azure:

Impostazione Proprietà Microsoft.Web/sites
Impostazioni sito siteConfig
Impostazioni delle applicazioni siteConfig.appSettings raccolta

Queste impostazioni del sito sono necessarie nella proprietà siteConfig:

Queste impostazioni dell'applicazione sono obbligatorie (o consigliate) per un sistema operativo specifico e un'opzione di hosting:

Queste impostazioni dell'applicazione sono necessarie per le distribuzioni di contenitori:

Queste impostazioni sono necessarie solo quando si esegue la distribuzione da un registro contenitori privato:

Tenere presenti queste considerazioni quando si usano le impostazioni del sito e dell'applicazione usando i file Bicep o i modelli di Resource Manager:

  • L'impostazione facoltativa alwaysReady contiene una matrice di uno o più oggetti {name,instanceCount}, con uno per ogni gruppo di scalabilità per funzione. Si tratta dei gruppi di scalabilità usati per prendere decisioni di scalabilità tempestive. Questo esempio imposta i conteggi sempre pronti sia per il gruppo http che per una singola funzione denominata helloworld, la quale è di un tipo di trigger non raggruppato:
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • Quando è necessario impostare WEBSITE_CONTENTSHARE in una distribuzione automatizzata, è necessario tenere presenti considerazioni importanti. Per indicazioni dettagliate, vedere le informazioni di riferimento su WEBSITE_CONTENTSHARE.

  • È consigliabile definire sempre le impostazioni dell'applicazione come raccolta siteConfig/appSettings della risorsa Microsoft.Web/sites creata, come illustrato negli esempi di questo articolo. Questa definizione garantisce che le impostazioni necessarie per l'esecuzione dell'app per le funzioni siano disponibili all'avvio iniziale.

  • Quando si aggiungono o aggiornano le impostazioni dell'applicazione usando i modelli, assicurarsi di includere tutte le impostazioni esistenti con l'aggiornamento. Questa operazione deve essere eseguita perché le chiamate dell'API REST di aggiornamento sottostante sostituiscono l'intera risorsa /config/appsettings. Se si rimuovono le impostazioni esistenti, l'app per le funzioni non verrà eseguita. Per aggiornare a livello di codice singole impostazioni dell'applicazione, è invece possibile usare l'interfaccia della riga di comando di Azure, Azure PowerShell o il portale di Azure per apportare queste modifiche. Per altre informazioni, vedere Usare le impostazioni dell'applicazione.

Distribuzioni di slot

Funzioni consente di distribuire versioni diverse del codice in endpoint univoci nell'app per le funzioni. Questa opzione semplifica lo sviluppo, la convalida e la distribuzione degli aggiornamenti delle funzioni senza influire sulle funzioni in esecuzione nell'ambiente di produzione. Gli slot di distribuzione sono una funzionalità del servizio app di Azure. Il numero di slot disponibili dipende dal piano di hosting. Per altre informazioni, vedere funzioni di distribuzione di Funzioni di Azure.

Una risorsa slot viene definita nello stesso modo di una risorsa dell'app per le funzioni (Microsoft.Web/sites), ma si usa l'identificatore di risorsa Microsoft.Web/sites/slots. Per una distribuzione di esempio (sia nei modelli Bicep che ARM) che crea sia una produzione che uno slot di staging in un piano Premium, vedere app per le funzioni di Azure con uno slot di distribuzione.

Per informazioni su come scambiare gli slot usando i modelli, vedere Automatizzare con i modelli di Resource Manager.

Quando si lavora con le distribuzioni di slot, tenere presenti le considerazioni seguenti:

  • Non impostare in modo esplicito l'impostazione WEBSITE_CONTENTSHARE nella definizione dello slot di distribuzione. Questa impostazione viene generata automaticamente quando l'app viene creata nello slot di distribuzione.

  • Quando si scambiano gli slot, alcune impostazioni dell'applicazione vengono considerate "permanenti", in quanto rimangono nello slot e non con il codice da scambiare. È possibile definire tale impostazione dello slot includendo "slotSetting":true nella definizione specifica dell'impostazione dell'applicazione nel modello. Per altre informazioni, vedere Gestire le impostazioni.

Distribuzioni protette

È possibile creare l'app per le funzioni in una distribuzione in cui una o più risorse sono state protette tramite l'integrazione con le reti virtuali. L'integrazione della rete virtuale per l'app per le funzioni è definita da una risorsa Microsoft.Web/sites/networkConfig. Questa integrazione dipende sia dall'app per le funzioni a cui si fa riferimento che dalle risorse di rete virtuale. L'app per le funzioni può anche dipendere da altre risorse di rete privata, ad esempio endpoint privati e route. Per altre informazioni, vedere Opzioni di rete di Funzioni di Azure.

Questi progetti forniscono esempi basati su Bicep di come distribuire le app per le funzioni in una rete virtuale, incluse le restrizioni di accesso alla rete:

Quando si crea una distribuzione che usa un account di archiviazione protetto, è necessario impostare in modo esplicito l'impostazione WEBSITE_CONTENTSHARE e creare la risorsa di condivisione file denominata in questa impostazione. Assicurarsi di creare una risorsa Microsoft.Storage/storageAccounts/fileServices/shares usando il valore di WEBSITE_CONTENTSHARE, come illustrato in questo esempio (modello ARM|file Bicep). È anche necessario impostare la proprietà vnetContentShareEnabled del sito su true.

Nota

Quando queste impostazioni non fanno parte di una distribuzione che usa un account di archiviazione protetto, viene visualizzato questo errore durante la convalida della distribuzione: Could not access storage account using provided connection string.

Questi progetti forniscono esempi di modelli Bicep e ARM di come distribuire le app per le funzioni in una rete virtuale, incluse le restrizioni di accesso alla rete:

Scenario con restrizioni Descrizione
Creare un'app per le funzioni con integrazione di rete virtuale L'app per le funzioni viene creata in una rete virtuale con accesso completo alle risorse in tale rete. L'accesso in ingresso e in uscita all'app per le funzioni non è limitato. Per altre informazioni, vedere Integrazione della rete virtuale.
Creare un'app per le funzioni che accede a un account di archiviazione protetto L'app per le funzioni creata usa un account di archiviazione protetto a cui funzioni accede tramite endpoint privati. Per altre informazioni, vedere Limitare l'account di archiviazione a una rete virtuale.
Creare un'app per le funzioni e un account di archiviazione che usano entrambi gli endpoint privati L'app per le funzioni creata può essere accessibile solo usando endpoint privati e usa endpoint privati per accedere alle risorse di archiviazione. Per altre informazioni, vedere endpoint privati.

Impostazioni di rete con restrizioni

Potrebbe anche essere necessario usare queste impostazioni quando l'app per le funzioni presenta restrizioni di rete:

Impostazione valore Descrizione
WEBSITE_CONTENTOVERVNET 1 Impostazione dell'applicazione che consente all'app per le funzioni di ridimensionarsi quando l'account di archiviazione è limitato a una rete virtuale. Per altre informazioni, vedere Limitare l'account di archiviazione a una rete virtuale.
vnetrouteallenabled 1 Impostazione del sito che forza tutto il traffico dall'app per le funzioni a usare la rete virtuale. Per altre informazioni, vedere Integrazione della rete virtuale a livello di area. Questa impostazione del sito sostituisce l'impostazione dell'applicazione WEBSITE_VNET_ROUTE_ALL.

Considerazioni sulle restrizioni di rete

Quando si limita l'accesso all'account di archiviazione tramite gli endpoint privati, non è possibile accedere all'account di archiviazione tramite il portale o qualsiasi dispositivo all'esterno della rete virtuale. È possibile concedere l'accesso all'indirizzo IP protetto o alla rete virtuale nell'account di archiviazione tramite Gestione della regola di accesso di rete predefinita.

Chiavi di accesso alle funzioni

Le chiavi di accesso alle funzioni a livello di host sono definite come risorse di Azure. Ciò significa che è possibile creare e gestire chiavi host nei modelli di Resource Manager e nei file Bicep. Una chiave host è definita come risorsa di tipo Microsoft.Web/sites/host/functionKeys. Questo esempio crea una chiave di accesso a livello di host denominata my_custom_key quando viene creata l'app per le funzioni:

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 questo esempio il parametro name è il nome della nuova app per le funzioni. È necessario includere un'impostazione dependsOn per garantire che la chiave venga creata con la nuova app per le funzioni. Infine, l'oggetto properties della chiave host può includere anche una proprietà value che può essere usata per impostare una chiave specifica.

Quando non si imposta la proprietà value, Funzioni genera automaticamente una nuova chiave quando viene creata la risorsa, consigliata. Per altre informazioni sulle chiavi di accesso, incluse le procedure consigliate per la sicurezza per l'uso delle chiavi di accesso, vedere Usare le chiavi di accesso in Funzioni di Azure.

Creare il modello

Gli esperti con modelli Bicep o ARM possono codificare manualmente le distribuzioni usando un semplice editor di testo. Per il resto di noi, esistono diversi modi per semplificare il processo di sviluppo:

  • Visual Studio Code: sono disponibili estensioni che consentono di usare sia i file Bicep che i modelli ARM. È possibile usare questi strumenti per assicurarsi che il codice sia corretto e forniscano una convalida di base.

  • Portale di Azure: quando si crea l'app per le funzioni e le risorse correlate nel portale, la schermata finale Rivedi e crea include un collegamento Scarica un modello per l'automazione.

    Scaricare il collegamento al modello dal processo di creazione di Funzioni di Azure nel portale di Azure.

    Questo collegamento mostra il modello di Resource Manager generato in base alle opzioni scelte nel portale. Questo modello può sembrare un po' complesso quando si crea un'app per le funzioni con molte nuove risorse. Tuttavia, può fornire un buon riferimento per l'aspetto del modello di Resource Manager.

Convalidare il modello

Quando si crea manualmente il file del modello di distribuzione, è importante convalidare il modello prima della distribuzione. Tutti i metodi di distribuzione convalidano la sintassi del modello e generano un messaggio di errore validation failed come illustrato nell'esempio JSON seguente:

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

È possibile usare i metodi seguenti per convalidare il modello prima della distribuzione:

L'attività di distribuzione v2 del gruppo di risorse di Azure seguente con deploymentMode: 'Validation' indica ad Azure Pipelines di convalidare il modello.

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

È anche possibile creare un gruppo di risorse di test per trovare gli errori preliminari e di distribuzione.

Distribuire il modello

È possibile usare uno dei modi seguenti per distribuire il file e il modello Bicep:

Pulsante Distribuisci in Azure

Nota

Questo metodo non supporta attualmente la distribuzione di file Bicep.

Sostituire <url-encoded-path-to-azuredeploy-json> con una versione con codifica URL del percorso non elaborato del file azuredeploy.json in GitHub.

Di seguito è riportato un esempio che usa la sintassi markdown:

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

Di seguito è riportato un esempio che usa 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>

Distribuire tramite PowerShell

I comandi di PowerShell seguenti creano un gruppo di risorse e distribuiscono un file Bicep o un modello di Resource Manager che crea un'app per le funzioni con le risorse necessarie. Per l'esecuzione in locale, è necessario che sia installato Azure PowerShell. Eseguire Connect-AzAccount per accedere.

# 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

Per testare questa distribuzione, è possibile usare un modello come questo che crea un'app per le funzioni in Windows in un piano a consumo.

Passaggi successivi

Altre informazioni su come sviluppare e configurare le Funzioni di Azure.