Condividi tramite

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

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

È possibile ottenere questi vantaggi nelle app di produzione usando l'automazione della distribuzione, sia l'infrastruttura come codice (IaC) che l'integrazione e la distribuzione continue (CI/CD):

  • Coerenza: definire l'infrastruttura nel codice per garantire distribuzioni coerenti tra ambienti.
  • Controllo della versione: tenere traccia delle modifiche apportate alle configurazioni dell'infrastruttura e dell'applicazione nel controllo del codice sorgente, insieme al codice del progetto.
  • Automazione: automatizzare la distribuzione, che riduce gli errori manuali e riduce il processo di rilascio.
  • Scalabilità: replica facilmente l'infrastruttura per più ambienti, ad esempio sviluppo, test e produzione.
  • Ripristino di emergenza: ricreare rapidamente l'infrastruttura dopo gli errori o durante le migrazioni.

Questo articolo illustra come automatizzare la creazione di risorse di Azure e configurazioni di distribuzione per Funzioni di Azure. Per altre informazioni sulla distribuzione continua del codice del progetto, vedere Distribuzione continua per Funzioni di Azure.

Il codice del modello per creare le risorse di Azure necessarie 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 Modelli di esempio
Piano A consumo Flex Code-only Bicep
Modello ARM
Terraform
Piano Premium Codice | Contenitore Bicep
Modello ARM
Piano dedicato Codice | Contenitore Bicep
Modello ARM
App contenitore di Azure Container-only Bicep
Piano A consumo Code-only Bicep
Modello ARM

Assicurarsi di selezionare il piano di hosting nella parte superiore dell'articolo.

Important

Dopo il 30 settembre 2028, l'opzione di ospitare l'app per le funzioni su Linux in un piano a consumo sarà ritirata. Per evitare interruzioni, eseguire la migrazione delle app del piano a consumo esistenti eseguite in Linux al piano a consumo Flex prima di tale data. Le app in esecuzione in Windows in un piano a consumo non sono interessate da questa modifica. Per ulteriori informazioni, vedere l'avviso di eliminazione del piano di consumo di Linux.

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:

Resource Requirement Informazioni di riferimento su sintassi e proprietà
Un account di archiviazione Required Microsoft.Storage/storageAccounts
Un componente di Application Insights Recommended Microsoft.Insights/components*
Un piano di hosting Required Microsoft.Web/serverfarms
Un'app per le funzioni Required Microsoft.Web/sites

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

Resource Requirement Informazioni di riferimento su sintassi e proprietà
Un account di archiviazione Required Microsoft.Storage/storageAccounts
Un componente di Application Insights Recommended Microsoft.Insights/components*
Un'app per le funzioni Required Microsoft.Web/sites

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

Resource Requirement Informazioni di riferimento su sintassi e proprietà
Un account di archiviazione Required Microsoft.Storage/storageAccounts
Un componente di Application Insights Recommended Microsoft.Insights/components*
Un ambiente gestito Required Microsoft.App/managedEnvironments
Un'app per le funzioni Required Microsoft.Web/sites

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

Resource Requirement Informazioni di riferimento su sintassi e proprietà
Un account di archiviazione Required Microsoft.Storage/storageAccounts
Un componente di Application Insights Recommended Microsoft.Insights/components1
Un ambiente Kubernetes del servizio app Required Microsoft.ExtendedLocation/customLocations
Un'app per le funzioni Required 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.

Prerequisites

  • 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 completo dell'area di lavoro in una pagina dell'area di lavoro nel portale di Azure sotto Impostazioni>Proprietà> ID risorsa.
  • Questo articolo presuppone che abbiate già creato un ambiente gestito in Azure Container Apps. È necessario sia il nome che l'ID dell'ambiente gestito per creare un'app per le funzioni ospitata in App contenitore.

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

Important

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

Per altre informazioni di contesto, vedere il file storage-PrivateEndpoint.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:

module storage 'br/public:avm/res/storage/storage-account:0.25.0' = {
  name: 'storage'
  scope: rg
  params: {
    name: !empty(storageAccountName) ? storageAccountName : '${abbrs.storageStorageAccounts}${resourceToken}'
    allowBlobPublicAccess: false
    allowSharedKeyAccess: false // Disable local authentication methods as per policy
    dnsEndpointType: 'Standard'
    publicNetworkAccess: 'Enabled'
    networkAcls: {
      defaultAction: 'Allow'
      bypass: 'AzureServices'
    }
    blobServices: {
      containers: [{name: deploymentStorageContainerName}]
    }
    tableServices:{}
    queueServices: {}
    minimumTlsVersion: 'TLS1_2'  // Enforcing TLS 1.2 for better security
    ___location: ___location
    tags: tags
  }
}

Questo esempio mostra come usare il modulo AVM per gli account di archiviazione per creare il contenitore BLOB di archiviazione insieme all'account di archiviazione. 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 templates.

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 un piano Flex Consumption:

module appServicePlan 'br/public:avm/res/web/serverfarm:0.1.1' = {
  name: 'appserviceplan'
  scope: rg
  params: {
    name: !empty(functionPlanName) ? functionPlanName : '${abbrs.webServerFarms}${resourceToken}'
    sku: {
      name: 'FC1'
      tier: 'FlexConsumption'
    }
    reserved: true
    ___location: ___location
    tags: tags
    zoneRedundant: zoneRedundant
  }
}

In questo esempio viene usata la macchina virtuale di Azure per i piani di servizio app. Per il frammento di codice nel contesto, vedere questo esempio di distribuzione.

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

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

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

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.

module functionApp 'br/public:avm/res/web/site:0.16.0' = {
  name: 'functionapp'
  scope: rg
  params: {
    kind: 'functionapp,linux'
    name: functionAppName_resolved
    ___location: ___location
    tags: union(tags, { 'azd-service-name': 'api' })
    serverFarmResourceId: appServicePlan.outputs.resourceId
    managedIdentities: {
      systemAssigned: true
    }
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.outputs.primaryBlobEndpoint}${deploymentStorageContainerName}'
          authentication: {
            type: 'SystemAssignedIdentity'
          }
        }
      }
      scaleAndConcurrency: {
        maximumInstanceCount: maximumInstanceCount
        instanceMemoryMB: instanceMemoryMB
      }
      runtime: { 
        name: functionAppRuntime
        version: functionAppRuntimeVersion
      }
    }
    siteConfig: {
      alwaysOn: false
    }
    configs: [{
      name: 'appsettings'
      properties:{
        // Only include required credential settings unconditionally
        AzureWebJobsStorage__credential: 'managedidentity'
        AzureWebJobsStorage__blobServiceUri: 'https://${storage.outputs.name}.blob.${environment().suffixes.storage}'
        AzureWebJobsStorage__queueServiceUri: 'https://${storage.outputs.name}.queue.${environment().suffixes.storage}'
        AzureWebJobsStorage__tableServiceUri: 'https://${storage.outputs.name}.table.${environment().suffixes.storage}'

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

In questo esempio viene usata la VM di Azure per le funzioni app. Per il frammento di codice nel contesto, vedere questo esempio di distribuzione.

Note

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

È possibile usare l'impostazione del sito linuxFxVersion per richiedere la distribuzione di un contenitore Linux specifico all'app al momento della creazione. Sono necessarie altre impostazioni per accedere alle immagini in un repository privato. Per altre informazioni, vedere Configurazione dell'applicazione.

Important

Quando si creano contenitori personalizzati, è necessario mantenere aggiornata l'immagine di base del contenitore all'immagine di base supportata più recente. Le immagini di base supportate per Funzioni di Azure sono specifiche del linguaggio. Consulta i repository delle immagini di base delle Funzioni di Azure.

Il team di Funzioni si impegna a pubblicare aggiornamenti mensili per queste immagini di base. Gli aggiornamenti regolari includono gli aggiornamenti della versione secondaria più recenti e le correzioni di sicurezza sia per il runtime di Funzioni che per i linguaggi. È consigliabile aggiornare regolarmente il contenitore dall'immagine di base più recente e ridistribuire la versione aggiornata del contenitore. Per altre informazioni, vedere Gestione di contenitori personalizzati.

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

Il piano Flex Consumption gestisce il codice del progetto nel file di pacchetto compresso zip in un contenitore di archiviazione BLOB noto come contenitore di distribuzione. È possibile configurare sia l'account di archiviazione che il contenitore usati per la distribuzione. Per altre informazioni, vedere Distribuzione.

È necessario usare una distribuzione per pubblicare il pacchetto di codice nel contenitore di distribuzione. Durante una distribuzione di Arm o Bicep, è possibile eseguire questa operazione definendo un'origine del pacchetto che usa l'estensione /onedeploy. Se si sceglie di caricare direttamente il pacchetto nel contenitore, il pacchetto non viene distribuito automaticamente.

Contenitore di 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:

functionAppConfig: {
  deployment: {
    storage: {
      type: 'blobContainer'
      value: '${storage.outputs.primaryBlobEndpoint}${deploymentStorageContainerName}'
      authentication: {
        type: 'SystemAssignedIdentity'
      }
    }
  }
  scaleAndConcurrency: {
    maximumInstanceCount: maximumInstanceCount
    instanceMemoryMB: instanceMemoryMB
  }
  runtime: { 
    name: functionAppRuntime
    version: functionAppRuntimeVersion
  }
}

In questo esempio viene usata la VM di Azure per le funzioni app. Per il frammento di codice nel contesto, vedere questo esempio di distribuzione.

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:

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

In questo esempio viene utilizzato il Manager delle Risorse di Azure per l'assegnazione di ruoli con ambito specifico delle risorse. Per il frammento di codice nel contesto, vedere questo esempio di distribuzione.

In questo esempio è necessario conoscere il valore GUID per il ruolo assegnato. È possibile ottenere questo valore ID per qualsiasi nome descrittivo del ruolo usando il comando az role definition list, come in questo esempio:

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

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.

Pacchetto di distribuzione

Il piano Flex Consumption usa un'implementazione per implementare il progetto di codice. Il pacchetto di codice stesso è identico a quello usato per la distribuzione zip in altri piani di hosting di Funzioni. Tuttavia, il nome del file del pacchetto stesso deve essere released-package.zip.

Per includere un pacchetto di distribuzione nel modello, usare la definizione della risorsa /onedeploy per l'URL remoto che contiene il pacchetto di distribuzione. L'host funzioni deve essere in grado di accedere sia all'origine del pacchetto remoto che al contenitore di distribuzione.

Questo esempio aggiunge un'origine di distribuzione 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 for released-package.zip.')
param packageUri string

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

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 di 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à:

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

Queste configurazioni dell'applicazione sono mantenute in functionAppConfig:

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

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:

Configuration Proprietà Microsoft.Web/sites
Impostazioni sito siteConfig
Impostazioni dell'applicazione siteConfig.appSettings raccolta

Queste impostazioni del sito sono necessarie nella proprietà siteConfig:

Queste impostazioni del sito sono necessarie solo quando si usano identità gestite per ottenere l'immagine da un'istanza di Registro Azure Container:

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 http gruppo che per una singola funzione denominata helloworld, che è 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.

  • Quando possibile, è consigliabile usare connessioni gestite basate su identità ad altri servizi di Azure, inclusa la connessione AzureWebJobsStorage. Per altre informazioni, vedere Configurare una connessione basata su identità.

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.

Note

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

Setting Value Description
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 Deploy to Azure per la distribuzione in Azure

Note

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 Azure PowerShell sia installato. Per accedere ad Azure, è prima necessario eseguire Connect-AzAccount.

# Register Resource Providers if they're not already registered
Register-AzResourceProvider -ProviderNamespace "microsoft.web"
Register-AzResourceProvider -ProviderNamespace "microsoft.storage"

# Create a resource group for the function app
New-AzResourceGroup -Name "MyResourceGroup" -Location 'West Europe'

# Deploy the template
New-AzResourceGroupDeployment -ResourceGroupName "MyResourceGroup" -TemplateFile main.bicep  -Verbose

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.

  • Last updated on