Hébergement Azure Container Apps de Azure Functions

  • Article

Azure Functions fournit une prise en charge intégrée pour le développement, le déploiement et la gestion d’applications de fonction conteneurisées sur Azure Container Apps. Utilisez Azure Container Apps pour héberger vos conteneurs d’application de fonction lorsque vous devez exécuter vos fonctions pilotées par les événements dans Azure dans le même environnement que d’autres microservices, API, sites web, workflows ou tout programme hébergé par conteneur. L’hébergement Container Apps vous permet d’exécuter vos fonctions dans un environnement Kubernetes avec prise en charge intégrée de la surveillance open source, mTLS, Dapr et KEDA.

Important

La prise en charge des applications de fonction d’hébergement sur Azure Container Apps est actuellement en préversion.

L’intégration à Container Apps vous permet d’utiliser le modèle de programmation de fonctions existant pour écrire du code de fonction dans votre framework ou langage de programmation préféré pris en charge par Azure Functions. Vous obtenez toujours les déclencheurs et les liaisons Functions avec une mise à l’échelle pilotée par les événements. Container Apps utilise la puissance du service Azure Kubernetes (AKS) sous-jacent, tout en éliminant la complexité liée à l'utilisation des API Kubernetes.

Cette intégration signifie également que vous pouvez utiliser les outils clients Functions existants et le portail Azure pour créer des conteneurs, déployer des conteneurs d’application de fonction sur Container Apps et configurer un déploiement continu. Les configurations réseau et d’observabilité sont définies au niveau de l’environnement Container App et s’appliquent à tous les microservices s’exécutant dans un environnement Container Apps, y compris votre application de fonction. Vous bénéficiez également des autres fonctionnalités natives cloud de Container Apps, notamment KEDA, Dapr et Envoy. Vous pouvez toujours utiliser Application Insights pour surveiller les exécutions de vos fonctions.

Profils d’hébergement et de charge de travail

Il existe deux plans d’hébergement principaux pour Container Apps, un Plan consommation serverless et un Plan dédié, qui utilise des profils de charge de travail pour mieux contrôler vos ressources de déploiement. Un profil de charge de travail détermine la quantité de ressources de calcul et de mémoire disponibles pour les applications de conteneur déployées dans un environnement. Ces profils sont configurés pour répondre aux différents besoins de vos applications. Le profil de charge de travail Consommation est le profil par défaut ajouté à chaque type d’environnement de profils de charge de travail. Vous pouvez ajouter des profils de charge de travail dédiés à votre environnement lorsque vous créez un environnement ou après sa création. Pour en savoir plus sur les profils de charge de travail, consultez Profils de charge de travail dans Azure Container Apps.

L’hébergement d’applications de fonction conteneurisées est pris en charge dans toutes les régions qui prennent en charge Container Apps.

Si votre application n’a pas de configuration matérielle spécifique, vous pouvez exécuter votre environnement dans un plan Consommation ou dans un Plan dédié en utilisant la charge de travail Consommation par défaut. Lorsque vous exécutez des fonctions sur Container Apps, vous êtes facturé uniquement pour l’utilisation de Container Apps. Consultez la page sur la tarification d’Azure Container Apps pour en savoir plus.

Azure Functions sur Azure Container Apps prend en charge l’hébergement avec GPU dans le plan dédié avec des profils de charge de travail.

Pour savoir comment créer et déployer un conteneur d’application de fonction dans Container Apps avec le Plan Consommation par défaut, consultez Créer vos premières fonctions conteneurisées sur Azure Container Apps.

Pour savoir comment créer un environnement Container Apps avec des profils de charge de travail et déployer un conteneur d’applications de fonction sur une charge de travail spécifique, consultez Profils de charge de travail Container Apps.

Fonctions dans des conteneurs

Pour utiliser l’hébergement Container Apps, votre code de fonctions doit s’exécuter dans un conteneur Linux que vous créez et gérez. Functions gère un ensemble d’images de base spécifiques à la langue que vous pouvez utiliser pour générer vos applications de fonction conteneurisées.

Lorsque vous créez un projet Functions en utilisant Azure Functions Core Tools et incluez l’option --docker, Core Tools génère le fichier Dockerfile avec l’image de base correcte, que vous pouvez utiliser comme point de départ lors de la création de votre conteneur.

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, puis redéployer la version mise à jour de votre conteneur.

Lorsque vous apportez des modifications au code de vos fonctions, vous devez reconstruire et republier votre image conteneur. Pour plus d’informations, consultez Mettre à jour une image dans le Registre.

Options de déploiement

Azure Functions prend actuellement en charge les méthodes suivantes de déploiement d’une application de fonction conteneurisée sur Azure Container Apps :

Configurer des règles de mise à l’échelle

Azure Functions sur Container Apps est conçu pour configurer les paramètres et les règles de mise à l’échelle en fonction de la cible d’événement. Vous n’avez pas besoin de vous soucier de la configuration des objets mis à l’échelle KEDA. Vous pouvez toujours définir le nombre minimal et maximal de réplica lors de la création ou de la modification de votre application de fonction. La commande Azure CLI suivante définit le nombre minimal et maximal de réplica lors de la création d’une nouvelle application de fonction dans un environnement Container Apps à partir d’un registre Azure Container :

az functionapp create --name <APP_NAME> --resource-group <MY_RESOURCE_GROUP> --max-replicas 15 --min-replicas 1 --storage-account <STORAGE_NAME> --environment MyContainerappEnvironment --image <LOGIN_SERVER>/azurefunctionsimage:v1 --registry-username <USERNAME> --registry-password <SECURE_PASSWORD> --registry-server <LOGIN_SERVER>

La commande suivante définit le même nombre de réplica minimal et maximal sur une application de fonction existante :

az functionapp config container set --name <APP_NAME> --resource-group <MY_RESOURCE_GROUP> --max-replicas 15 --min-replicas 1

Groupes de ressources partagées

Azure Function sur Container Apps exécute vos ressources conteneur fonctionnalisées dans des groupes de ressources spécialement gérés, ce qui permet de protéger la cohérence de vos applications en empêchant la modification ou la suppression non intentionnelles ou non autorisées des ressources dans le groupe géré par des utilisateurs, des groupes ou des principes de service. Ce groupe de ressources managés est créé pour vous la première fois que vous créez des ressources d’application de fonction dans un environnement Container Apps. Les ressources Container Apps requises par votre application de fonction conteneurisée s’exécutent dans ce groupe de ressources managé, et toutes les autres applications de fonction créées dans le même environnement utilisent ce groupe existant. Un groupe de ressources managés est supprimé automatiquement lorsque toutes les ressources de conteneur d’application de fonction sont supprimées de l’environnement. Bien que le groupe de ressources managée soit visible, toutes les tentatives de modification ou de suppression du groupe de ressources managés entraînent une erreur. Pour supprimer un groupe de ressources managé d’un environnement, supprimez toutes les ressources de conteneur d’application de fonction et elle est supprimée pour vous. Si vous rencontrez des problèmes avec ces groupes de ressources managés, contactez le support technique.

Considérations relatives à l’hébergement Container Apps

Gardez à l’esprit les considérations suivantes lors du déploiement de vos conteneurs d’application de fonction dans Container Apps :

  • Bien que tous les déclencheurs puissent être utilisés, seuls les déclencheurs suivants peuvent être mis à l’échelle dynamiquement (à partir de zéro instances) lors de l’exécution sur Container Apps :
    • HTTP
    • Stockage File d’attente Azure
    • Azure Service Bus
    • Hubs d'événements Azure
    • Kafka*
    • Minuteur
      *La valeur de protocole de ssl n’est pas prise en charge lorsqu’elle est hébergée sur Container Apps. Utilisez une autre valeur de protocole.
  • Pour les définitions de stratégie Container Apps intégrées, seules les stratégies au niveau de l’environnement s’appliquent actuellement aux conteneurs Azure Functions.
  • Actuellement, vous ne pouvez pas déplacer un déploiement d’application de fonction hébergée par Container Apps entre des groupes de ressources ou entre des abonnements. Au lieu de cela, vous devrez recréer le déploiement d’application conteneurisée existant dans un nouveau groupe de ressources, dans un nouvel abonnement ou dans une nouvelle région.
  • Lorsque vous utilisez Container Apps, vous n’avez pas d’accès direct aux API Kubernetes de niveau inférieur.
  • L’extension containerapp est en conflit avec l’extension appservice-kube dans Azure CLI. Si vous avez déjà publié des applications sur Azure Arc, exécutez az extension list et vérifiez que appservice-kube n’est pas installée. Si c’est le cas, vous pouvez la supprimer en exécutant az extension remove -n appservice-kube.
  • L’extension Functions Dapr est également en préversion, avec l’aide fournie dans le dépôt.

Étapes suivantes