Partager via

Automatiser le déploiement de ressources pour votre application de fonction dans Azure Functions

  • Article

Vous pouvez utiliser un fichier Bicep ou un modèle ARM (Azure Resource Manager) pour automatiser le processus de déploiement de votre application de fonction. Durant le déploiement, vous pouvez utiliser des ressources Azure existantes, ou en créer d’autres. L’automatisation vous aide dans ces scénarios :

  • Intégration de vos déploiements de ressources à votre code source dans les déploiements basés sur Azure Pipelines et GitHub Actions.
  • Restauration d’une application de fonction et des ressources associées à partir d’une sauvegarde.
  • Déploiement d’une topologie d’application à plusieurs reprises.

Cet article explique comment automatiser la création de ressources et le déploiement pour Azure Functions. En fonction des déclencheurs et des liaisons utilisés par vos fonctions, vous devrez peut-être déployer d'autres ressources, ce qui n'entre pas dans le cadre de cet article.

Le code de modèle nécessaire dépend des options d’hébergement souhaitées pour votre application de fonction. Cet article s’adresse aux options d’hébergement suivantes :

Option d’hébergement Type de déploiement Pour en savoir plus, consultez...
Plan Consommation Azure Functions Code uniquement Plan Consommation
Plan Consommation flexible Azure Functions Code uniquement Plan Consommation flexible
Plan Élastique Premium Azure Functions Code | Conteneur Plan Premium
Plan dédié pour Azure Functions (App Service) Code | Conteneur Plan dédié
Azure Container Apps Conteneur uniquement Hébergement Container Apps de Azure Functions
Azure Arc Code | Conteneur App Service, Functions et Logic Apps sur Azure Arc (préversion)

Quand vous utilisez cet article, gardez à l’esprit les considérations suivantes :

  • Les exemples sont présentés dans des sections individuelles pour des ressources spécifiques.

Ressources nécessaires

Vous devez créer ou configurer ces ressources pour un déploiement hébergé par Azure Functions :

Ressource Condition requise Référence sur la syntaxe et les propriétés
Un compte de stockage Obligatoire Microsoft.Storage/storageAccounts
Un composant Application Insights Recommandé Microsoft.Insights/components*
Un plan d’hébergement Requis Microsoft.Web/serverfarms
Une application de fonction Obligatoire Microsoft.Web/sites

Vous devez créer ou configurer ces ressources pour un déploiement hébergé par Azure Functions :

Ressource Condition requise Référence sur la syntaxe et les propriétés
Un compte de stockage Obligatoire Microsoft.Storage/storageAccounts
Un composant Application Insights Recommandé Microsoft.Insights/components*
Une application de fonction Obligatoire Microsoft.Web/sites

Un déploiement hébergé Azure Container Apps comprend généralement les ressources suivantes :

Ressource Condition requise Référence sur la syntaxe et les propriétés
Un compte de stockage Obligatoire Microsoft.Storage/storageAccounts
Un composant Application Insights Recommandé Microsoft.Insights/components*
Un environnement managé Requis Microsoft.App/managedEnvironments
Une application de fonction Obligatoire Microsoft.Web/sites

Un déploiement hébergé Azure Arc comprend généralement les ressources suivantes :

Ressource Condition requise Référence sur la syntaxe et les propriétés
Un compte de stockage Obligatoire Microsoft.Storage/storageAccounts
Un composant Application Insights Recommandé Microsoft.Insights/components1
Un environnement Kubernetes App Service Requis Microsoft.ExtendedLocation/customLocations
Une application de fonction Obligatoire Microsoft.Web/sites

*Si vous n’avez pas encore d’espace de travail Log Analytics utilisable par votre instance d’Application Insights, vous devez également créer cette ressource.

Lorsque vous déployez plusieurs ressources dans un seul fichier Bicep ou modèle ARM, l'ordre dans lequel les ressources sont créées est important. Cette exigence résulte des dépendances entre les ressources. Pour ces dépendances, veillez à utiliser l’élément dependsOn pour définir la dépendance dans la ressource dépendante. Pour plus d'informations, voir Définir l'ordre de déploiement des ressources dans les modèles ARM ou Dépendances des ressources dans Bicep.

Prérequis

  • Les exemples sont conçus pour s’exécuter dans le contexte d’un groupe de ressources existant.
  • Application Insights et les journaux de stockage nécessitent un espace de travail Azure Log Analytics existant. Les espaces de travail peuvent être partagés entre les services. En règle générale, vous devez créer un espace de travail dans chaque région géographique pour améliorer les performances. Pour obtenir un exemple montrant comment créer un espace de travail Log Analytics, consultez Créer un espace de travail Log Analytics. Vous trouverez l’ID de ressource d’espace de travail complet dans une page d’espace de travail du portail Azure sous Paramètres>Propriétés>ID de ressource.
  • Cet article suppose que vous avez déjà créé un environnement managé dans Azure Container Apps. Vous avez besoin du nom et de l’ID de l’environnement managé pour créer une application de fonction hébergée sur Container Apps.

Créer un compte de stockage

Toutes les applications de fonction nécessitent un compte de stockage Azure. Vous avez besoin d’un compte à usage général qui prend en charge les objets blob, les tables, les files d’attente et les fichiers. Pour plus d’informations, consultez Configuration requise du compte de stockage Azure Functions.

Important

Le compte de stockage permet de stocker les données importantes de l’application, dont parfois le code proprement dit de l’application. Vous devez limiter l’accès des autres applications et utilisateurs au compte de stockage.

Cet exemple de section crée un compte de stockage v2 universel 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
  }
}

Pour plus de contexte, consultez le fichier complet main.bicep dans le référentiel de modèles.

Pour plus de contexte, consultez le fichier storage-account.bicep complet dans l’exemple de référentiel.

Vous devez définir la chaîne de connexion de ce compte de stockage comme paramètre d’application AzureWebJobsStorage, ce dont Functions a besoin. Les modèles présentés dans cet article construisent la valeur de la chaîne de connexion en fonction du compte de stockage créé, ce qui est une meilleure pratique. Pour plus d’informations, consultez Configuration d’application.

Conteneur de déploiement

Les déploiements sur une application s’exécutant dans le plan Consommation flexible nécessitent un conteneur au sein du service Stockage Blob Azure en tant que source de déploiement. Vous pouvez utiliser le compte de stockage par défaut, ou spécifier un compte de stockage distinct. Pour plus d’informations, consultez Configurer les paramètres de déploiement.

Ce compte de déploiement doit déjà être configuré quand vous créez votre application, notamment le conteneur spécifique utilisé pour les déploiements. Pour en savoir plus sur la configuration des déploiements, consultez Sources de déploiement.

Cet exemple montre comment créer un conteneur dans le compte de stockage :

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

Pour obtenir l’extrait de code en contexte, consultez cet exemple de déploiement.

Les autres paramètres de déploiement sont configurés avec l’application elle-même.

Activer les journaux de stockage

Étant donné que le compte de stockage est utilisé pour les données d’application de fonction importantes, vous devez surveiller le compte pour la modification de ce contenu. Pour surveiller votre compte de stockage, vous devez configurer les journaux de ressources Azure Monitor pour Stockage Azure. Dans la section de cet exemple, un espace de travail Log Analytics nommé myLogAnalytics est utilisé comme destination de ces journaux.

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

Ce même espace de travail peut être utilisé pour la ressource Application Insights définie ultérieurement. Pour plus d’informations, notamment sur l’utilisation de ces journaux d’activité, consultez Surveillance du stockage Azure.

Créer Application Insights

Vous devez utiliser Application Insights pour effectuer le monitoring des exécutions de vos applications de fonction. Application Insights nécessite désormais un espace de travail Azure Log Analytics, qui peut être partagé. Ces exemples partent du principe que vous utilisez un espace de travail existant, et que vous disposez de l’ID de ressource complet de l’espace de travail. Pour plus d’informations, consultez Espace de travail Azure Log Analytics.

Dans cette section d'exemple, la ressource Application Insights est définie avec le type Microsoft.Insights/components et le genreweb :

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

Pour plus de contexte, consultez le fichier complet main.bicep dans le référentiel de modèles.

La connexion doit être fournie à l’application de fonction à l’aide du paramètre d’application APPLICATIONINSIGHTS_CONNECTION_STRING. Pour plus d’informations, consultez Configuration d’application.

Les exemples de cet article obtiennent la valeur de chaîne de connexion de l’instance créée. Les versions antérieures peuvent plutôt utiliser APPINSIGHTS_INSTRUMENTATIONKEY pour définir la clé d’instrumentation, ce qui n’est plus recommandé.

Créer le plan d’hébergement

Les applications hébergées dans un plan Consommation flexible, Premium ou Dedicated (App Service) Azure Functions doivent avoir un plan d’hébergement défini de manière explicite.

Consommation flexible est un plan d’hébergement basé sur Linux, qui s’appuie sur le modèle de facturation serverless de la consommation. Il s’agit du paiement à l’utilisation. Le plan prend en charge la mise en réseau privée, la sélection de la taille de la mémoire d’instance ainsi que l’amélioration de la gestion des identités managées.

Le plan Consommation flexible est un type spécial de ressource serverfarm. Vous pouvez le spécifier en utilisant FC1 pour la valeur de propriété Name dans la propriété sku avec une valeur tier de FlexConsumption.

Cet exemple de section crée un plan Consommation flexible :

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

Pour plus de contexte, consultez le fichier function.bicep complet dans l’exemple de référentiel du plan Consommation flexible.

Dans la mesure où le plan Consommation flexible prend uniquement en charge Linux, vous devez également affecter la valeur true à la propriété reserved.

Le plan Premium offre la même mise à l’échelle que le plan Consommation, mais il inclut des ressources dédiées et des fonctionnalités en plus. Pour plus d’informations, consultez Plan Premium Azure Functions.

Un plan Premium est un type spécial de ressource serverfarm. Vous pouvez le spécifier en utilisant EP1, EP2 ou EP3 pour la valeur de propriété Name dans la propriété sku. La façon dont vous définissez le plan d’hébergement Functions dépend de l’exécution de votre application de fonction sur Windows ou sur Linux. Cet exemple de section crée un plan 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
  }
}

Pour plus de contexte, consultez le fichier complet main.bicep dans le référentiel de modèles.

Pour plus d’informations sur l’objet sku, consultez SkuDefinition ou évaluez les exemples de modèles.

Dans le plan dédié (App Service), vos applications de fonction sont exécutées sur des machines virtuelles dédiées sur des références de base, Standard et Premium dans les plan App Service, à l’instar des applications web. Pour plus d’informations, consultez Plan dédié.

Pour obtenir un exemple de fichier Bicep/modèle Azure Resource Manager, consultez Application de fonction dans le plan Azure App Service.

Dans Functions, le plan dédié n’est qu’un plan App Service standard, qui est défini par une ressource serverfarm. Vous devez fournir au moins la valeur name. Pour obtenir la liste des noms de plans pris en charge, consultez le --sku paramètre dans az appservice plan create pour obtenir la liste actuelle des valeurs prises en charge pour un plan dédié.

La façon dont vous définissez le plan d’hébergement dépend de l’exécution de votre application de fonction sur Windows ou sur Linux :

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

Pour plus de contexte, consultez le fichier complet main.bicep dans le référentiel de modèles.

Créer le plan d’hébergement

Vous n’avez pas besoin de définir explicitement une ressource de plan d’hébergement Consommation. Lorsque vous ignorez la définition de cette ressource, un plan est automatiquement créé ou sélectionné sur une base régionale lorsque vous créez la ressource d’application de fonction.

Vous pouvez définir explicitement un plan Consommation en tant que type spécial de ressource serverfarm, que vous spécifiez à l’aide de la valeur Dynamic pour les propriétés computeMode et sku. Cet exemple de section vous montre comment définir explicitement un plan Consommation. La façon dont vous définissez un plan d’hébergement dépend de l’exécution de votre application de fonction sur Windows ou sur 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'
  }
}

Pour plus de contexte, consultez le fichier complet main.bicep dans le référentiel de modèles.

Environnement Kubernetes

Azure Functions peut être déployé sur Kubernetes compatible avec Azure Arc en tant que projet de code ou application de fonction conteneurisée.

Pour créer les ressources d’application et de plan, vous devez avoir déjà créé un environnement App Service Kubernetes pour un cluster Kubernetes avec Azure Arc. Les exemples de cet article supposent que vous disposez de l'identifiant de ressource de l'emplacement personnalisé (customLocationId) et de l'environnement App Service Kubernetes (kubeEnvironmentId) vers lequel vous effectuez le déploiement, qui sont définis dans cet exemple :

param kubeEnvironmentId string
param customLocationId string

Les sites et les plans doivent référencer l’emplacement personnalisé par le biais d’un champ extendedLocation. Comme illustré dans cet exemple tronqué, extendedLocation se trouve en dehors de properties, en tant qu’homologue pour kind et location :

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

La ressource de plan doit utiliser la valeur Kubernetes (K1) pour SKU, le champ kind doit être linux,kuberneteset la propriété reserved doit être true, car il s’agit d’un déploiement Linux. Vous devez également définir les extendedLocation et les kubeEnvironmentProfile.id sur l’ID d’emplacement personnalisé et l’ID d’environnement Kubernetes, respectivement, qui peuvent ressembler à cet exemple de section :

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

Créer l’application de fonction

La ressource d’application de fonction est définie par une ressource de type Microsoft.Web/sites et kind qui inclut functionapp, au minimum.

La façon dont vous définissez une ressource d'application de fonction varie selon que vous hébergez sous Linux ou sous Windows :

Pour obtenir la liste des paramètres d’application requis lors de l’exécution sur Windows, consultez Configuration de l’application. Pour un exemple de modèle de fichier Bicep/Azure Resource Manager, voir l'application de fonction hébergée sur Windows dans un modèle de plan Consommation.

Pour obtenir la liste des paramètres d’application requis lors de l’exécution sur Windows, consultez Configuration de l’application.

Le plan Consommation flexible remplace la plupart des paramètres d’application et des propriétés de configuration de site standard utilisés dans les déploiements de modèles Bicep et ARM. Pour plus d’informations, consultez Configuration d’application.

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

Pour plus de contexte, consultez le fichier function.bicep complet dans l’exemple de référentiel du plan Consommation flexible.

Remarque

Si vous choisissez de définir facultativement votre plan Consommation, vous devez définir la propriété serverFarmId sur l’application afin qu’elle pointe vers l’ID de ressource du plan. Assurez-vous que l’application de fonction a un paramètre dependsOn qui référence également le plan. Si vous n’avez pas défini explicitement de plan, un plan est créé pour vous.

Définissez la propriété serverFarmId sur l’application afin qu’elle pointe sur l’ID de ressource du plan. Assurez-vous que l’application de fonction a un paramètre dependsOn qui référence également le plan.

resource functionAppName_resource 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTSHARE'
          value: toLower(functionAppName)
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~14'
        }
      ]
    }
  }
}

Pour obtenir un exemple complet de bout en bout, consultez ce fichier 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'
        }
      ]
    }
  }
}

Pour obtenir un exemple complet de bout en bout, consultez ce fichier main.bicep.

Sources de déploiement

Vous pouvez utiliser le paramètre de site linuxFxVersion pour demander qu’un conteneur Linux spécifique soit déployé sur votre application lors de sa création. D’autres paramètres sont nécessaires pour accéder aux images dans un référentiel privé. Pour plus d’informations, consultez Configuration d’application.

Important

Quand vous créez vos propres conteneurs, vous devez conserver l’image de base de votre conteneur mise à jour vers la dernière image de base prise en charge. Les images de base prises en charge pour Azure Functions sont spécifiques au langage et se trouvent dans le référentiel d’images de base Azure Functions.

L’équipe Functions s’engage à publier des mises à jour mensuelles pour ces images de base. Les mises à jour régulières incluent les dernières mises à jour de version mineure et les correctifs de sécurité pour le runtime et les langages Functions. Vous devez régulièrement mettre à jour votre conteneur à partir de la dernière image de base et redéployer la version mise à jour de votre conteneur.

Votre fichier Bicep ou votre modèle ARM peut également définir un déploiement pour votre code de fonction, qui peut inclure ces méthodes :

Le plan Flex Consumption conserve le code de votre projet dans un fichier compressé au format zip dans un conteneur de stockage appelé conteneur de déploiement. Vous pouvez configurer le compte de stockage et le conteneur utilisés pour le déploiement. Pour en savoir plus, consultez Déploiement.

Vous devez utiliser un déploiement pour publier votre package de code dans le conteneur de déploiement. Pendant un déploiement ARM ou Bicep, vous pouvez le faire en définissant une source de package qui utilise l’extension /onedeploy. Si vous choisissez de charger directement votre package sur le conteneur, le package n’est pas déployé automatiquement.

Conteneur de déploiement

Le compte de stockage et le conteneur spécifiques utilisés pour les déploiements, la méthode d’authentification ainsi que les informations d’identification sont définis dans l’élément functionAppConfig.deployment.storage de properties du site. Le conteneur et les paramètres d’application doivent exister au moment de la création de l’application. Pour obtenir un exemple de création du conteneur de stockage, consultez Conteneur de déploiement.

Cet exemple utilise une identité managée affectée par le système pour accéder au conteneur de stockage d’objets blob spécifié, qui est créé ailleurs dans le déploiement :

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

Quand vous utilisez des identités managées, vous devez également activer l’application de fonction pour accéder au compte de stockage à l’aide de l’identité, comme le montre cet exemple :

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

Pour obtenir un exemple de référence complet, consultez ce fichier Bicep.

Cet exemple nécessite que vous connaissiez la valeur GUID du rôle affecté. Vous pouvez obtenir cette valeur d’ID pour n’importe quel nom de rôle convivial à l’aide de la commande az role definition list, comme dans cet exemple :

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

Quand vous utilisez une chaîne de connexion à la place d’identités managées, vous devez en fait affecter StorageAccountConnectionString à authentication.type, et affecter à authentication.storageAccountConnectionStringName le nom du paramètre d’application qui contient la chaîne de connexion du compte de stockage de déploiement.

Package de déploiement

Le plan Flex Consumption utilise un déploiement pour déployer votre projet de code. Le package de code lui-même est identique à celui que vous utiliseriez pour le déploiement zip dans d’autres plans d’hébergement Functions. Toutefois, le nom du fichier de package lui-même doit être released-package.zip.

Pour inclure un package de déploiement dans votre modèle, utilisez la définition de ressource /onedeploy pour l’URL distante qui contient le package de déploiement. L’hôte Functions doit pouvoir accéder à la fois à cette source de package distante et au conteneur de déploiement.

Cet exemple ajoute une source de déploiement à une application existante :

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

Votre fichier Bicep ou votre modèle ARM peut également définir un déploiement pour votre code de fonction, en utilisant un déploiement de fichier zip.

Il est important de comprendre comment les ressources sont déployées dans Azure pour déployer correctement votre application en utilisant Azure Resource Manager. Dans la plupart des exemples, les configurations de niveau supérieur sont appliquées à l’aide de siteConfig. Il est important de définir ces configurations à un niveau supérieur, car elles fournissent des informations au moteur de déploiement et au runtime Functions. Des informations de niveau supérieur sont requises avant que la ressource enfant sourcecontrols/web soit appliquée. Bien qu’il soit possible de configurer ces paramètres dans la ressource config/appSettings au niveau enfant, dans certains cas, votre application de fonction doit être déployée avant que config/appSettings ne soit appliqué.

Package du déploiement de fichier zip

Le déploiement zip est un moyen recommandé de déployer le code de votre application de fonction. Par défaut, les fonctions qui utilisent le déploiement zip s’exécutent dans le package de déploiement lui-même. Pour plus d’informations, notamment la configuration requise pour un package de déploiement, consultez déploiement zip pour Azure Functions. Lorsque vous utilisez l’automatisation du déploiement de ressources, vous pouvez référencer le package de déploiement .zip dans votre modèle Bicep ou ARM.

Pour utiliser le déploiement zip dans votre modèle, définissez le paramètre WEBSITE_RUN_FROM_PACKAGE dans l’application sur 1 et incluez la définition de ressource /zipDeploy.

Pour un plan Consommation sur Linux, définissez plutôt l’URI du package de déploiement directement dans le paramètre WEBSITE_RUN_FROM_PACKAGE , comme indiqué dans cet exemple de modèle.

Cet exemple ajoute une source de déploiement zip à une application existante :

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

Gardez à l’esprit les éléments suivants lors de l’inclusion des ressources de déploiement zip dans votre modèle :

  • Le packageUri doit être un emplacement accessible par Functions. Envisagez d'utiliser le stockage Azure blob avec une signature d'accès partagé (SAS). Une fois la SAS expirée, Functions ne peut plus accéder au partage pour les déploiements. Lorsque vous régénérez votre SAP, n’oubliez pas de mettre à jour le paramètre WEBSITE_RUN_FROM_PACKAGE avec la nouvelle valeur d’URI.

  • Lors de la définition WEBSITE_RUN_FROM_PACKAGE vers un URI, vous devez synchroniser manuellement les déclencheurs.

  • Veillez à toujours définir tous les paramètres d’application requis dans la collection appSettings lors de l’ajout ou de la mise à jour des paramètres. Les paramètres existants non définis explicitement sont supprimés par la mise à jour. Pour plus d’informations, consultez Configuration d’application.

  • Functions ne prend pas en charge Web Deploy (msdeploy) pour les déploiements de packages. Vous devez utiliser plutôt le déploiement zip dans vos pipelines de déploiement et automatisation. Pour plus d’informations, consultez Déploiement zip pour Azure Functions.

Builds distantes

Le processus de déploiement suppose que le fichier .zip que vous utilisez ou un déploiement zip contienne une application prête à l’exécution. Cela signifie que, par défaut, aucune personnalisation n’est exécutée.

Dans certains scénarios, vous êtes obligé de regénérer votre application à distance. C’est le cas, par exemple, quand vous devez inclure des packages spécifiques à Linux dans des applications Python ou Node.js que vous avez développées sur un ordinateur Windows. Dans ce cas, vous pouvez configurer Functions pour effectuer une build distante sur votre code après le déploiement zip.

La façon dont vous demandez une build distante dépend du système d’exploitation sur lequel vous effectuez le déploiement :

Lorsqu'une application est déployée sur Windows, des commandes spécifiques au langage (comme dotnet restore pour les applications C# ou npm install pour les applications Node.js) sont exécutées.

Pour activer les mêmes processus de construction que vous obtenez avec l'intégration continue, ajoutez SCM_DO_BUILD_DURING_DEPLOYMENT=true à vos paramètres d'application dans votre code de déploiement et supprimez WEBSITE_RUN_FROM_PACKAGE entièrement.

Conteneurs Linux

Si vous déployez une application de fonction conteneurisée dans un plan Azure Functions Premium ou dédié, vous devez :

Si certains paramètres sont manquants, l’approvisionnement de l’application peut échouer avec cette erreur HTTP/500 :

Function app provisioning failed.

Pour plus d’informations, consultez Configuration d’application.

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

Lorsque vous déployez fonctions conteneurisées sur Azure Container Apps, votre modèle doit :

  • Définissez le champ kind sur une valeur de functionapp,linux,container,azurecontainerapps.
  • Définissez la propriété de site managedEnvironmentId sur l’URI complet de l’environnement Container Apps.
  • Ajoutez un lien de ressource dans la collection dependsOn du site lors de la création d’une ressource Microsoft.App/managedEnvironments en même temps que le site.

La définition d'une application fonctionnelle conteneurisée déployée à partir d'un registre de conteneurs privé dans un environnement Container Apps existant peut ressembler à cet exemple :

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

Lors du déploiement de fonctions sur Azure Arc, la valeur que vous définissez pour le champ kind de la ressource d’application de fonction dépend du type de déploiement :

Type de déploiement Valeur de champ kind
Déploiement de code uniquement functionapp,linux,kubernetes
Déploiement de conteneur functionapp,linux,kubernetes,container

Vous devez également définir customLocationId comme vous l’avez fait pour la ressource de plan d’hébergement.

La définition d'une application de fonction conteneurisée, à l'aide d'une image de démarrage rapide .NET 6, peut ressembler à cet exemple :

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

Configuration de l’application

Dans un plan Consommation flexible, vous configurez votre application de fonction au sein d’Azure avec deux types de propriétés :

Configuration PropriétéMicrosoft.Web/sites
Configuration de l’application functionAppConfig
Paramètres de l’application siteConfig.appSettingscollection

Ces configurations d’application sont gérées dans functionAppConfig :

Comportement Paramètre dans functionAppConfig
Instances toujours prêtes scaleAndConcurrency.alwaysReady
Source de déploiement deployment
Taille de la mémoire de l’instance scaleAndConcurrency.instanceMemoryMB
Concurrence du déclencheur HTTP scaleAndConcurrency.triggers.http.perInstanceConcurrency
Runtime de langage runtime.name
Version du langage runtime.version
Nombre maximal d’instances scaleAndConcurrency.maximumInstanceCount

Le plan Consommation flexible prend également en charge les paramètres d’application suivants :

Functions fournit les options suivantes pour configurer votre application de fonction dans Azure :

Configuration PropriétéMicrosoft.Web/sites
Paramètres de site siteConfig
Paramètres de l’application siteConfig.appSettingscollection

Les paramètres de site suivants sont obligatoires dans la propriété siteConfig :

Ces paramètres de site sont requis uniquement lors de l’utilisation d’identités managées pour obtenir l’image à partir d’une instance Azure Container Registry :

Ces paramètres d'application sont requis (ou recommandés) pour un système d'exploitation et une option d'hébergement spécifiques :

Ces paramètres d’application sont requis pour les déploiements de conteneurs :

Ces paramètres sont uniquement requis lors du déploiement à partir d’un registre de conteneurs privé :

Gardez ces considérations à l’esprit lors de l’utilisation des paramètres de site et d’application à l’aide de fichiers Bicep ou de modèles ARM :

  • Le paramètre alwaysReady facultatif contient un tableau d’un ou plusieurs objets {name,instanceCount} , avec un objet pour chaque groupe de mise à l’échelle par fonction. Il s’agit des groupes de mise à l’échelle utilisés pour prendre des décisions de mise à l’échelle pour les instances toujours prêtes. Cet exemple définit les nombres d’instances toujours prêtes pour le groupe http et une fonction unique nommée helloworld, qui est d’un type de déclencheur non groupé :
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • Il existe des considérations importantes concernant la nécessité de définir WEBSITE_CONTENTSHARE dans un déploiement automatisé. Pour obtenir des instructions détaillées, consultez la référence WEBSITE_CONTENTSHARE.

  • Vous devez toujours définir vos paramètres d’application en tant que siteConfig/appSettings collection de la ressource Microsoft.Web/sites en cours de création, comme dans les exemples de cet article. Cette définition garantit que les paramètres dont votre application de fonction a besoin pour s’exécuter sont disponibles au démarrage initial.

  • Lorsque vous ajoutez ou mettez à jour des paramètres d'application à l'aide de modèles, veillez à inclure tous les paramètres existants dans la mise à jour. Pour ce faire, les appels d’API REST de mise à jour sous-jacents remplacent l’intégralité de la ressource /config/appsettings. Si vous supprimez les paramètres existants, votre application de fonction ne s’exécute pas. Pour mettre à jour par programme les paramètres d'une application individuelle, vous pouvez utiliser l’Interface de ligne de commande Azure (Azure CLI), Azure PowerShell ou le Portail Microsoft Azure pour effectuer ces modifications. Pour plus d’informations, consultez Utiliser des paramètres d’application.

Déploiements d’emplacements

Functions vous permet de déployer différentes versions de votre code sur des points de terminaison uniques dans votre application de fonction. Cette option facilite le développement, la validation et le déploiement des mises à jour de fonctions sans impacter les fonctions s’exécutant en production. Les emplacements de déploiement sont une fonctionnalité de Azure App Service. Le nombre d'emplacements disponibles dépend de votre plan d'hébergement. Pour plus d’informations, consultez les fonctions Emplacements de déploiement Azure Functions.

Une ressource d’emplacement est définie de la même façon qu’une ressource d’application de fonction (Microsoft.Web/sites), mais vous utilisez plutôt l’identificateur de ressource Microsoft.Web/sites/slots. Pour obtenir un exemple de déploiement (dans les modèles Bicep et ARM) qui crée à la fois une production et un emplacement intermédiaire dans un plan Premium, consultez Application de fonction Azure avec un emplacement de déploiement.

Pour en savoir plus sur l’échange d’emplacements à l’aide de modèles, consultez Automatiser avec des modèles Resource Manager.

Gardez les considérations suivantes à l'esprit lorsque vous travaillez avec des emplacements de déploiement :

  • Ne définissez pas explicitement le paramètre WEBSITE_CONTENTSHARE dans la définition de l’emplacement de déploiement. Ce paramètre est généré automatiquement lors de la création de l’application dans l’emplacement de déploiement.

  • Lorsque vous échangez des emplacements, certains paramètres d’application sont considérés comme « collants », car ils restent avec l’emplacement et non avec le code en cours d’échange. Vous pouvez définir un tel paramètre d’emplacement en incluant "slotSetting":true dans la définition du paramètre d’application spécifique dans votre modèle. Pour plus d’informations, consultez Gérer les paramètres.

Déploiements sécurisés

Vous pouvez créer votre application de fonction dans un déploiement où une ou plusieurs des ressources ont été sécurisées en intégrant des réseaux virtuels. L'intégration d'un réseau virtuel pour votre application fonctionnelle est définie par une ressource Microsoft.Web/sites/networkConfig. Cette intégration dépend à la fois de l’application de fonction référencée et des ressources de réseau virtuel. Votre application de fonction peut également dépendre d’autres ressources réseau privées, telles que des points de terminaison privés et des itinéraires. Pour plus d’informations, consultez la section Options de mise en réseau Azure Functions.

Ces projets fournissent des exemples basés sur Bicep, qui illustrent la façon de déployer vos applications de fonction dans un réseau virtuel, notamment avec des restrictions d’accès au réseau :

Lors de la création d’un déploiement qui utilise un compte de stockage sécurisé, vous devez à la fois définir explicitement le paramètre WEBSITE_CONTENTSHARE et créer la ressource de partage de fichiers nommée dans ce paramètre. Veillez à créer une ressource Microsoft.Storage/storageAccounts/fileServices/shares à l’aide de la valeur de WEBSITE_CONTENTSHARE, comme illustré dans cet exemple (Modèle ARM|Fichier Bicep). Vous devez également définir la propriété de site vnetContentShareEnabled sur true.

Remarque

Lorsque ces paramètres ne font pas partie d’un déploiement qui utilise un compte de stockage sécurisé, cette erreur s’affiche lors de la validation du déploiement : Could not access storage account using provided connection string.

Ces projets fournissent des exemples de modèles Bicep et ARM sur la manière de déployer vos applications fonctionnelles dans un réseau virtuel, y compris avec des restrictions d'accès au réseau :

Scénario restreint Description
Créez une application de fonction avec intégration du réseau virtuel Votre application de fonction est créée dans un réseau virtuel avec un accès total aux ressources de ce réseau. L’accès entrant et sortant à votre application de fonction n’est pas restreint. Pour plus d’informations, consultez Intégration de réseau virtuel.
Créez une application de fonction qui accède à un compte de stockage sécurisé Votre application de fonction créée utilise un compte de stockage sécurisé, auquel Functions accède à l’aide de points de terminaison privés. Pour plus d’informations, consultez Restreindre votre compte de stockage à un réseau virtuel.
Créez une application de fonction et un compte de stockage qui utilisent tous deux des points de terminaison privés L'application de fonction que vous avez créée n'est accessible qu'à l'aide de points de terminaison privés, et elle utilise des points de terminaison privés pour accéder aux ressources de stockage. Pour plus d’informations, consultez Points de terminaison privés.

Paramètres de réseau restreint

Vous devrez peut-être également utiliser ces paramètres lorsque votre application de fonction a des restrictions réseau :

Paramètre valeur Description
WEBSITE_CONTENTOVERVNET 1 Paramètre d'application qui permet à votre application fonctionnelle d'évoluer lorsque le compte de stockage est limité à un réseau virtuel. Pour plus d’informations, consultez Restreindre votre compte de stockage à un réseau virtuel.
vnetrouteallenabled 1 Paramètre de site qui force tout le trafic de l’application de fonction à utiliser le réseau virtuel. Pour plus d’informations, consultez Intégration régionale de réseau virtuel. Ce paramètre de site remplace le paramètre d’application WEBSITE_VNET_ROUTE_ALL.

Considérations relatives aux restrictions réseau

Lorsque vous limitez l'accès au compte de stockage par le biais des points de terminaison privés, vous ne pouvez pas accéder au compte de stockage via le portail ou tout autre appareil situé en dehors du réseau virtuel. Vous pouvez accorder l’accès à votre adresse IP sécurisée ou à votre réseau virtuel dans le compte de stockage en Gérant de la règle d’accès réseau par défaut.

Clé d’accès aux fonctions

Les clés d’accès aux fonctions au niveau de l’hôte sont définies en tant que ressources Azure. Cela signifie que vous pouvez créer et gérer des clés d’hôte dans vos modèles ARM et vos fichiers Bicep. Une clé d’hôte est définie en tant que ressource de type Microsoft.Web/sites/host/functionKeys. Cet exemple crée une clé d’accès au niveau de l’hôte nommée my_custom_key au moment de la création de l’application de fonction :

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

Dans cet exemple, le paramètre name correspond au nom de la nouvelle application de fonction. Vous devez inclure un paramètre dependsOn pour garantir la création de la clé avec la nouvelle application de fonction. Enfin, l’objet properties de la clé d’hôte peut également inclure une propriété value, qui peut être utilisée pour définir une clé spécifique.

Quand vous ne définissez pas la propriété value, Functions génère automatiquement une clé pour vous au moment de la création de la ressource, ce qui est recommandé. Pour en savoir plus sur les clés d’accès, notamment sur les meilleures pratiques de sécurité relatives à l’utilisation des clés d’accès, consultez Utiliser des clés d’accès dans Azure Functions.

Créer votre modèle

Les experts avec des modèles Bicep ou ARM peuvent coder manuellement leurs déploiements à l’aide d’un éditeur de texte simple. Pour le reste de nous, il existe plusieurs façons de faciliter le processus de développement :

  • Visual Studio Code : il existe des extensions disponibles pour vous aider à utiliser les fichiers Bicep et les modèles ARM. Vous pouvez utiliser ces outils pour vous assurer que votre code est correct et qu’il fournit des validation de base.

  • Portail Azure : lorsque vous créer votre application de fonction et les ressources associées dans le portail, l’écran final Vérifier + créer écran comporte un lien Télécharger un modèle pour l’automatisation.

    Téléchargez le lien du modèle à partir du processus de création d’Azure Functions dans le Portail Azure.

    Ce lien vous montre le modèle ARM généré en fonction des options que vous avez choisies dans le portail. Ce modèle peut sembler un peu complexe quand vous créez une application de fonction avec de nombreuses nouvelles ressources. Toutefois, il peut représenter une bonne référence pour savoir à quoi peut ressembler votre modèle ARM.

Valider votre modèle

Lorsque vous créez manuellement votre fichier de modèle de déploiement, il est important de le valider avant le déploiement. Toutes les méthodes de déploiement valident la syntaxe de votre modèle et déclenchent un message d’erreur validation failed, comme indiqué dans l’exemple au format JSON suivant :

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

Les méthodes suivantes peuvent être utilisées pour valider votre modèle avant le déploiement :

La tâche de déploiement de groupe de ressources Azure v2 suivante avec deploymentMode: 'Validation' demande à Azure Pipelines de valider le modèle.

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

Vous pouvez également créer un groupe de ressources de test pour détecter les erreurs de contrôle en amont et de déploiement.

Déployer votre modèle

Vous pouvez utiliser une des méthodes suivantes pour déployer votre fichier Bicep et votre modèle :

Bouton Déployer dans Azure

Notes

Cette méthode ne prend actuellement pas en charge le déploiement de fichiers Bicep.

Remplacez <url-encoded-path-to-azuredeploy-json> par une version d’URL encodée du chemin brut de votre fichier azuredeploy.json dans GitHub.

Voici un exemple qui utilise Markdown :

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

Voici un exemple qui utilise 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>

Déployer à l’aide de PowerShell

Les commandes PowerShell suivantes créent un groupe de ressources, et déploient un fichier Bicep ou un modèle ARM, qui crée une application de fonction avec les ressources nécessaires. Pour une exécution locale, Azure PowerShell doit être installé. Pour vous connecter à Azure, vous devez d’abord exécuter 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

Pour tester ce déploiement, vous pouvez utiliser un modèle comme celui-ci, qui crée une application de fonction sur Windows dans un plan Consommation.

Étapes suivantes

En savoir plus sur le développement et la configuration d’Azure Functions.