Azure Container Apps

Les applications conteneurisées Azure (ACA) constituent un service entièrement managé d’hébergement de conteneurs sans serveur, basé sur Kubernetes et sur KEDA (mise à l’échelle automatique pilotée par les événements Kubernetes). Contrairement à AKS, vous ne gérez pas directement le plan de contrôle, les pools de nœuds ou les manifestes Kubernetes. Vous déployez plutôt les conteneurs à l’aide d’une CLI simple ou d’une définition YAML, et Azure prend en charge toute l’orchestration. ACA convient parfaitement aux microservices, aux backends d’API, aux travailleurs pilotés par les événements et aux tâches de traitement en arrière-plan qui doivent s’adapter dynamiquement, notamment avec une mise à l’échelle jusqu’à zéro.

Un environnement d’applications conteneurisées est la limite isolée dans laquelle s’exécutent une ou plusieurs applications conteneurisées. Toutes les applications d’un environnement partagent le même réseau virtuel et le même espace de travail Log Analytics. Les environnements sont associés à une région et à un groupe de ressources. Vous pouvez déployer plusieurs environnements afin d’isoler les équipes ou les étapes (production et préproduction). Un environnement peut éventuellement être injecté dans un réseau virtuel qui vous appartient afin d’autoriser les communications privées entre les applications conteneurisées et les autres services Azure sans passer par Internet public.

Pour déployer une application conteneurisée, vous spécifiez l’image du conteneur (provenant d’Azure Container Registry ou de tout registre public), le nombre de réplicas et les variables d’environnement. L’application est accessible publiquement via une URL HTTPS générée automatiquement si vous activez l’entrée externe. La configuration de l’entrée comprend le port cible, la répartition du trafic pour les déploiements bleu-vert et l’autorisation du protocole HTTP ou HTTPS uniquement. ACA récupère l’image au moment du déploiement ; l’environnement doit disposer des autorisations de récupération sur le registre.

Les applications conteneurisées utilisent des agents de mise à l’échelle KEDA qui se déclenchent en fonction de métriques externes. Les agents KEDA intégrés comprennent : le trafic HTTP (requêtes simultanées par réplica), la profondeur de la file d’attente Azure Service Bus (messages en attente), la file d’attente Azure Storage, Cron (selon l’heure) et le processeur ou la mémoire. Lorsque la métrique de l’agent tombe à zéro et que minReplicas est défini sur 0, les applications conteneurisées passent à zéro : aucun coût de calcul n’est engendré jusqu’à l’arrivée de nouvelles requêtes. La mise à l’échelle jusqu’à zéro est idéale pour les travailleurs pilotés par les événements dont la charge de travail est intermittente.

Dapr (environnement d’exécution d’applications distribuées) est un environnement d’exécution portable et piloté par les événements qui simplifie la création de microservices. Les applications conteneurisées offrent une intégration native de Dapr : vous l’activez pour chaque application à l’aide d’un seul indicateur. Dapr fournit des blocs fonctionnels pour : l’invocation de services (avec nouvelle tentative et mTLS), la messagerie publication-abonnement (en faisant abstraction de Service Bus et d’Event Hubs), la gestion de l’état (en faisant abstraction de Redis et de Cosmos DB) et les liaisons de sortie. Avec Dapr, les microservices communiquent via le side-car Dapr sans connaître les détails de l’infrastructure sous-jacente.

Chaque déploiement d’une application conteneurisée crée une nouvelle révision. En mode de révisions multiples, vous pouvez répartir le trafic entre les révisions pour des déploiements bleu-vert ou canari. Par exemple, envoyez 10 % du trafic vers une nouvelle révision et 90 % vers la révision stable actuelle. Surveillez les taux d’erreur et la latence de la nouvelle révision avant d’augmenter son poids de trafic jusqu’à 100 %. Les anciennes révisions peuvent être désactivées, mais elles sont conservées dans l’historique, ce qui permet un retour en arrière instantané en réattribuant le poids du trafic.

Les applications conteneurisées prennent en charge deux façons d’injecter la configuration : les variables d’environnement (pour les configurations non sensibles, comme les indicateurs de fonctionnalité ou les URL d’API) et les secrets (pour les valeurs sensibles, comme les chaînes de connexion). Les secrets sont stockés au niveau de l’application conteneurisée et référencés par des variables d’environnement ou des composants Dapr. Pour la configuration la plus sécurisée, référencez les secrets depuis Azure Key Vault à l’aide d’une identité managée, afin que la valeur du secret soit récupérée au moment de l’exécution et ne soit jamais stockée dans le plan de configuration de l’application conteneurisée.

Container Apps Jobs étend la plateforme pour prendre en charge les charges de travail exécutées jusqu'à leur terminaison : des conteneurs qui démarrent, effectuent un travail, puis s'arrêtent. Les tâches prennent en charge trois types de déclencheurs : Manuel (déclenché via une API ou la CLI), Planifié (expression cron) et piloté par les événements (le dispositif de mise à l'échelle KEDA déclenche chaque exécution). Les tâches sont facturées uniquement pour leur durée réelle d'exécution et sont idéales pour le traitement par lots, la génération de rapports, les migrations de bases de données et les chaînes d'inférence ML exécutées périodiquement ou en réponse à des événements.

Container Apps envoie les journaux système (événements de la plateforme, comme la création d'une révision et la mise à l'échelle) ainsi que les journaux de console (la sortie standard et la sortie d'erreur de votre application) vers l'espace de travail Log Analytics associé à l'environnement. Interrogez les journaux avec KQL : ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Les métriques Azure Monitor intégrées comprennent le nombre de réplicas, le nombre de requêtes, la latence des requêtes et l'utilisation du processeur et de la mémoire par réplica, le tout étant disponible dans le portail Azure sans configuration supplémentaire.

Pour choisir la plateforme de conteneurs Azure adaptée : Container Apps convient particulièrement aux microservices, aux travailleurs pilotés par les événements et aux API lorsque vous souhaitez bénéficier des avantages de Kubernetes sans gérer le cluster, notamment lorsque la mise à l'échelle jusqu'à zéro est utile. AKS convient lorsque vous avez besoin d'un contrôle total sur Kubernetes, d'opérateurs personnalisés ou de configurations de nœuds spécifiques (GPU, mémoire élevée). App Service convient aux applications web et aux API traditionnelles lorsque l'équipe de développement préfère un modèle PaaS simple, sans la surcharge liée à la gestion des conteneurs. Les trois services prennent en charge les conteneurs ; la différence réside dans le compromis entre la complexité de la gestion et le niveau de contrôle.

Container Apps prend en charge deux modes d'entrée : Externe (accessible publiquement via un point de terminaison HTTPS équilibré en charge, avec TLS automatique) et Interne (accessible uniquement depuis le même environnement Container Apps ou depuis des ressources appairées au réseau virtuel). L'entrée interne est utilisée pour les services principaux qui ne doivent jamais être exposés à Internet. Les applications peuvent s'appeler entre elles à l'aide du nom DNS interne généré automatiquement http://myapi dans le même environnement, ce qui permet une communication simple de service à service sans déployer de passerelle API.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que Azure Container Apps fournit un hébergement de conteneurs sans serveur reposant sur Kubernetes et KEDA, sans gestion de cluster, que les dispositifs de mise à l'échelle KEDA permettent une mise à l'échelle jusqu'à zéro en fonction de la profondeur d'une file d'attente, du trafic HTTP ou de planifications cron, et que l'intégration de Dapr simplifie la communication de microservice à microservice ainsi que la gestion de l'état. Nous allons maintenant relier tous ces éléments dans un flux de travail de développement complet de bout en bout.