Partager via

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 complètement managé, basé sur Kubernetes, avec une prise en charge intégrée de la supervision open-source, de mTLS, de Dapr et de Kubernetes Event-driven Autoscaling (KEDA).

Vous pouvez écrire votre code de fonction dans n’importe quelle pile de langage prise en charge par Functions. Vous pouvez utiliser les mêmes déclencheurs et les même liaisons Functions avec une mise à l’échelle pilotée par les événements. Vous pouvez également 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.

L’intégration Container Apps signifie également que les configurations réseau et d’observabilité, définies au niveau de l’environnement Container App, s’appliquent à votre application de fonction comme à tous les microservices s’exécutant dans un environnement Container Apps. 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 vos exécutions de fonctions et votre application de fonction peut accéder aux mêmes ressources de mise en réseau virtuelle fournies par l’environnement.

Pour obtenir une vue d’ensemble des options d’hébergement de conteneurs pour Azure Functions, veuillez consulter la rubrique Prise en charge des conteneurs Linux dans Azure Functions.

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 Dedicated 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 doit s’exécuter sur une application de fonction 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 de code en utilisant Azure Functions Core Tools et incluez --dockerl’option, 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 :

Intégration du réseau virtuel

Lorsque vous hébergez vos applications de fonction dans un environnement Container Apps, vos fonctions peuvent tirer profit des réseaux virtuels accessibles en interne et en externe. Si vous souhaitez en savoir plus sur les réseaux d’environnement, veuillez consulter la rubrique Réseau dans l’environnement 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 Functions sur Container Apps exécute vos ressources d’application de fonction conteneurisées dans des groupes de ressources spécialement managés. Ces groupes de ressources managés aident à protéger la cohérence de vos applications en empêchant une modification ou une suppression involontaire ou non autorisée de ressources dans le groupe managé, même par les principaux de service.

Un groupe de ressources managé 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é. Toutes les autres applications de fonction que vous créez 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 dans un environnement Container Apps :
    • HTTP
    • Stockage File d’attente Azure
    • Azure Service Bus
    • Hubs d'événements Azure
    • Kafka
    • Minuteur
  • Les limitations suivantes s’appliquent aux déclencheurs Kafka :
    • 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 qu’un déclencheur Kafka soit mis à l’échelle dynamiquement lorsqu’il est connecté à Event Hubs, la propriété username doit être résolue en paramètre d’application qui contient la valeur réelle du nom d’utilisateur. Lorsque la valeur de $ConnectionString par défaut est utilisée, le déclencheur Kafka ne peut pas entraîner la mise à l’échelle dynamique de l’application.
  • 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.
  • Vous pouvez utiliser des identités managées à la fois pour les connexions de déclencheur et de liaison et pour les déploiements depuis un registre Azure Container Registry.
  • Lorsque votre application de fonction et votre déploiement basé sur Azure Container Registry utilisent des connexions basées sur des identités managées, vous ne pouvez pas modifier les paramètres d’allocation du processeur et de la mémoire dans le portail. À la place, vous devez utiliser Azure CLI.
  • 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.

Étapes suivantes