Déployer sur Azure Functions avec Azure Developer CLI

Azure Developer CLI (azd) prend en charge les déploiements de code et de conteneur pour Azure Functions. Utilisez l’hôte dédié function dans azure.yaml pour les deux modes :

  • Le déploiement de code empaquette votre code de fonction généré en tant qu’archive zip et le charge dans la Function App.
  • Le déploiement de conteneur génère ou résout une image conteneur, la publie sur Azure Container Registry (ACR) si nécessaire et met à jour la Function App pour exécuter l’image.

Azure Functions et Azure App Service utilisent le Microsoft.Web/sites fournisseur de ressources et leurs flux de déploiement de conteneurs partagent certaines mécaniques internes. Toutefois, ce n’est pas le même hôte azd. Functions utilisent host: function, ont un empaquetage spécifique à Functions et un comportement de génération à distance, et n’utilisent pas le flux de travail d’emplacement de déploiement App Service.

Choisir un mode de déploiement

azd sélectionne le mode de déploiement dans la configuration du service :

Configuration Mode de déploiement
Une source project avec un language non-Docker pris en charge et sans docker.path Déploiement de code
language: docker Déploiement de conteneurs
Une valeur docker.path ayant une langue source Déploiement de conteneurs
Un image préconstruit Déploiement de conteneurs

L’application de fonction provisionnée doit utiliser le même mode que la configuration du service. Si l’application de fonction est configurée pour les conteneurs, mais azure.yaml sélectionne le déploiement de code, ou l’inverse, azd deploy s’arrête avant le chargement et signale l’incompatibilité.

Déployer le code de la fonction

Configurez un service de fonction basé sur du code avec un projet source, un langage pris en charge et host: function:

services:
  api:
    project: ./src/api
    language: ts
    host: function

Pendant azd deploy, azd compile le projet, applique des exclusions .funcignore, crée une archive zip et charge le package via l’API de déploiement Azure Functions.

Votre Bicep ou Terraform doit provisionner une application de fonction basée sur le code et l’étiqueter avec azd-service-name défini sur le nom du service, sauf si vous identifiez la ressource en utilisant azure.yaml dans resourceName. Configurez le plan d’hébergement, le runtime, le stockage, les identités, la mise en réseau et les paramètres d’application via l’infrastructure en tant que code.

Configurer des builds distants pour les déploiements de code

La propriété de service remoteBuild de niveau supérieur s’applique uniquement aux Function Apps basées sur du code sur le plan Flex Consumption. Elle contrôle si Azure Functions utilise Oryx pour générer le package chargé :

services:
  api:
    project: ./src/api
    language: python
    host: function
    remoteBuild: true

Lorsque vous omettez remoteBuild dans Flex Consumption, azd sélectionne une valeur par défaut en fonction de la langue et du contenu du package :

Language Comportement par défaut
JavaScript ou TypeScript Utilise la build distante lorsque .funcignore exclut node_modules, ou lorsqu’aucun fichier .funcignore n’existe. Sinon, utilise le package compilé localement.
Python Utilise la compilation à distance.
Go Génère localement. Go Function Apps ne prend pas en charge la génération à distance.
Autres langues prises en charge Utilise le package compilé localement.

Pour JavaScript et TypeScript, une valeur remoteBuild explicitement configurée doit correspondre à .funcignore lorsque ce fichier existe. Définir remoteBuild: true lorsque .funcignore exclut node_modules. Définissez remoteBuild: false lorsque .funcignore inclut node_modules dans le package.

Ne définissez pas la propriété remoteBuild de niveau supérieur pour les plans non Flex. Pour activer une build Oryx sur un autre plan pris en charge, configurez ENABLE_ORYX_BUILD=true et SCM_DO_BUILD_DURING_DEPLOYMENT=true en tant que paramètres de Function App dans votre infrastructure.

Déployer une fonction conteneurisée

Pour un projet source avec un fichier Dockerfile, définissez language: docker ou conservez la langue source et spécifiez docker.path.

L’exemple suivant utilise un projet TypeScript avec un fichier Dockerfile :

services:
  api:
    project: ./src/api
    language: ts
    host: function
    docker:
      path: ./Dockerfile

Vous pouvez également déployer une image prédéfinie sans projet local :

services:
  api:
    host: function
    image: myregistry.azurecr.io/functions/api:1.0

Pour une image prédéfinie, omettez language ou définissez-la sur docker. Ne pas combiner image avec project.

Pendant un déploiement de conteneur, azd:

  1. Génère l’image localement ou à distance, ou utilise l’image précompilée configurée.
  2. Publie l’image sur l’instance ACR configurée pour le projet lors de la publication.
  3. Met à jour le linuxFxVersion de l’application de fonction vers DOCKER|<image>.
  4. Déploie sur le site principal de Function App.

La propriété de service remoteBuild de niveau supérieur ne s’applique pas aux conteneurs. Pour générer une image conteneur avec ACR Tasks, utilisez docker.remoteBuild:

services:
  api:
    project: ./src/api
    language: docker
    host: function
    docker:
      path: ./Dockerfile
      remoteBuild: true

Créer une Function App prête pour le conteneur

azd deploy met à jour la référence d’image, mais ne convertit pas une application de fonction Azure basée sur du code en application de fonction Azure basée sur un conteneur. Votre infrastructure doit provisionner un site compatible avant le déploiement.

Requirement Details
Application Function App Linux Provisionner une application de fonction Linux sur un plan Azure Functions Premium ou Dédié (App Service). Flex Consumption ne prend pas en charge les conteneurs personnalisés. Ce host: function flux de travail cible Microsoft.Web/sites, et non Azure Functions hébergé sur Azure Container Apps.
Configuration du site de conteneurs Définissez le type de site pour inclure functionapp, linux et container. Initialiser linuxFxVersion avec une DOCKER\|<image> valeur. Une image de remplacement est suffisante, car azd deploy la remplace.
Registre de conteneurs Pour les builds sources, provisionnez une instance ACR et exposez son serveur de connexion via la sortie de l’infrastructure AZURE_CONTAINER_REGISTRY_ENDPOINT, ou configurez docker.registry pour le service. Un image précompilé entièrement qualifié peut être utilisé directement sans registre de publication distinct.
Accès au registre Accordez à l’identité qui publie l’image l’autorisation d’envoi (push) vers le registre de destination lorsqu’une publication est requise. Configurez séparément la Function App pour extraire l’image déployée. Pour les images ACR privées, accordez des droits d’extraction (pull) à l’identité managée de l’application de fonction et configurez le site pour utiliser les informations d’identification de l’identité managée. Pour un autre registre privé, configurez les identifiants d’extraction appropriés dans votre infrastructure.
Paramètres de la fonction Configurez les paramètres requis tels que FUNCTIONS_EXTENSION_VERSION, FUNCTIONS_WORKER_RUNTIMEet AzureWebJobsStorage via Bicep ou Terraform.
Découverte de ressources Appliquez une azd-service-name balise dont la valeur correspond au nom du service dans azure.yaml, ou définissez resourceName explicitement.

Les paramètres au niveau env du service ne sont pas pris en charge pour l’hôte function . Définissez plutôt les paramètres de Function App dans votre infrastructure.

Comprendre les emplacements de déploiement

azd déploie toujours un function service sur le site principal de la Function App. Elle ne détecte pas, n’invite pas à sélectionner ou ne déploie pas vers les emplacements de Function App. Les paramètres de slot App Service, tels que AZD_DEPLOY_{SERVICE}_SLOT_NAME, ne concernent pas un déploiement d’application de fonction.

Si vous avez besoin d’un processus de publication Functions basé sur un emplacement, gérez l’emplacement et le déploiement en dehors du flux de travail intégré host: function .

Comparer Functions et les hôtes App Service

Les fonctions et App Service partagent le Microsoft.Web/sites type de ressource, mais sélectionnez l’hôte qui correspond à la charge de travail :

Comportement function hôte appservice hôte
Charge de travail Azure Functions pilotées par les événements applications web et API
Déploiement de code Utilise le flux de déploiement zip Azure Functions Utilise le flux de déploiement App Service
Déploiement de conteneurs Met à jour l’image de la Function App après avoir validé que le site est basé sur un conteneur Met à jour l’image de Web App après avoir validé que le site est prêt pour les conteneurs
Compilation de code à distance Prend en charge l’option de niveau remoteBuild de service pour les Function Apps Flex Consumption N’utilise pas l’option Functions remoteBuild
Emplacements de déploiement Se déploie toujours sur le site principal Prend en charge le workflow d’emplacement App Service azd
Niveau de service env Non pris en charge ; utiliser les paramètres de Function App dans l’infrastructure Configurer les paramètres d’application dans l’infrastructure

Contenu connexe

  • Dernière mise à jour :