Déployer des microservices sur Azure Container Apps

Azure Container Apps

Azure Cosmos DB

Azure Service Bus

Ce scénario montre une charge de travail existante conçue à l’origine pour Kubernetes, qui est réplateformée pour s’exécuter dans Azure Container Apps. Container Apps prend en charge les charges de travail brownfield où les équipes souhaitent simplifier l’infrastructure et l’orchestration de conteneurs.

L’exemple de charge de travail est une application de microservices en conteneur. Elle réutilise la même charge de travail définie dans l’architecture des microservices sur Azure Kubernetes Service (AKS). Cette architecture réhéberge la charge de travail dans Container Apps en tant que plateforme d’applications.

Important

Cette architecture se concentre sur la réduction des modifications de code d’application et l’approche de la transition d’AKS vers Container Apps en tant que migration de plateforme. L’objectif est de répliquer l’implémentation existante et de différer le code ou les optimisations d’infrastructure qui peuvent compromettre la migration.

Pour obtenir une charge de travail greenfield, consultez Déployer des microservices à l’aide de Container Apps et dapr.

Conseil

Un exemple d’implémentation prend en charge cette architecture et illustre certains des choix de conception décrits dans cet article.

Architecture

Le diagramme montre un environnement Container Apps sous la forme d’un grand rectangle qui contient cinq applications conteneur. Une flèche source du trafic HTTP pointe vers le service d’ingestion. Une flèche ascendante partant de l'Ingestion va vers Azure Service Bus. Une flèche pointant vers le bas part de Service Bus et retourne au service Workflow. À partir du flux de travail, trois connecteurs noirs descendent et se plient vers chaque service inférieur : le package, le planificateur de drone et les services de livraison. Chaque service inférieur a une flèche verticale vers son propre magasin d’état externe : le service de package accède à Azure DocumentDB. Le service Drone Scheduler est dirigé vers Azure Cosmos DB pour NoSQL. Le service de livraison est dirigé vers Azure Managed Redis. Deux flèches quittent le milieu de l’environnement : la flèche supérieure accède à Azure Application Insights. La flèche inférieure accède à l’espace de travail Azure Log Analytics. En dessous de l'espace de travail se trouvent Azure Key Vault puis Azure Container Registry, illustrés sans flèches de connexion.

Téléchargez un fichier Visio de cette architecture.

Les services qui partagent le même environnement bénéficient de la façon suivante :

• Pénétration interne et détection de service
• Un seul espace de travail Log Analytics pour la journalisation de l’exécution
• Méthode de gestion sécurisée pour les secrets et les certificats

Flux de données

1. Service d’ingestion : Reçoit les demandes du client, les met en mémoire tampon, puis les publie dans Azure Service Bus. Il s’agit du seul point d’entrée dans la charge de travail.

2. Service de flux de travail : Consomme des messages de Service Bus et les répartit vers des microservices sous-jacents.

3. Le service de package gèrent les packages. Le service conserve son propre état dans Azure Cosmos DB.

4. Service Drone Scheduler : Planifie les drones et surveille les drones en vol. Le service conserve son propre état dans Azure Cosmos DB.

5. Service de livraison : Gère les livraisons planifiées ou en transit. Le service conserve son propre état dans Azure Managed Redis.

6. Récupération des secrets : Étant donné qu’il s’agit d’une charge de travail existante, seuls certains composants accèdent à Azure Key Vault pour obtenir des secrets d’exécution. Les autres services reçoivent ces secrets de l’environnement Container Apps.

7. Journaux et métriques : L’environnement et toutes les applications conteneur émettent des journaux et des métriques qu’Azure Monitor propose, puis collectent et visualisent.

8. Images conteneur : Les images conteneur sont extraites d’Azure Container Registry existant qui a été précédemment utilisé pour AKS et déployé dans l’environnement Container Apps.

Composants

La charge de travail utilise les services Azure suivants en coordination entre eux :

• Container Apps est une plateforme de conteneur serverless qui simplifie l’orchestration et la gestion des conteneurs. Dans cette architecture, Container Apps sert de plateforme d’hébergement principale pour tous les microservices.

  Les fonctionnalités suivantes remplacent la plupart des fonctionnalités de l’architecture AKS précédente :

  • Détection de service intégrée
  • Points de terminaison HTTP et HTTP/2 managés
  • Équilibrage de charge intégré
  • Enregistrement et surveillance
  • Mise à l’échelle automatique basée sur le trafic HTTP ou les événements alimentés par la mise à l’échelle automatique basée sur les événements Kubernetes (KEDA)
  • Mises à niveau et contrôle de version de l’application

• Container Registry est un service de registre managé permettant de stocker et de gérer des images conteneur privées. Dans cette architecture, il s’agit de la source de toutes les images conteneur déployées dans l’environnement Container Apps. Le Registre est le même que celui utilisé dans l’implémentation AKS.

• Azure Cosmos DB est un service de base de données multimodèle distribué à l’échelle mondiale. Dans cette architecture, le service drone scheduler utilise Azure Cosmos DB comme magasin de données.

• Azure DocumentDB est un service de base de données entièrement managé compatible MongoDB pour la création d’applications modernes. Dans cette architecture, le service de package utilise Azure DocumentDB comme magasin de données.

• Service Bus est un service de messagerie cloud qui fournit des fonctionnalités de communication asynchrones et une intégration hybride. Dans cette architecture, elle gère la messagerie asynchrone entre le service d’ingestion et le microservice de workflow basé sur les tâches. Les autres services de l’application existante sont conçus pour que d’autres services puissent les appeler avec des requêtes HTTP.

• Azure Managed Redis est un service de mise en cache en mémoire. Dans cette architecture, elle réduit la latence et améliore le débit pour les données de livraison de drone fréquemment sollicitées.

• Key Vault est un service cloud permettant de stocker et d’accéder en toute sécurité aux secrets tels que les clés API, les mots de passe et les certificats. Dans cette architecture, le planificateur de drone et les services de livraison utilisent des identités managées affectées par l’utilisateur pour s’authentifier auprès de Key Vault et récupérer les secrets nécessaires à leurs exigences d’exécution.

• Azure Monitor est une solution de supervision complète qui collecte et analyse les données de télémétrie. Dans cette architecture, elle collecte et stocke les métriques et les journaux à partir de tous les composants d’application via un espace de travail Log Analytics. Vous utilisez ces données pour surveiller l’application, configurer des alertes et des tableaux de bord, et effectuer une analyse de la cause racine des défaillances.

  • Application Insights est un service de gestion des performances des applications qui fournit des fonctionnalités de surveillance extensibles. Dans cette architecture, chaque service est instrumenté avec le Kit de développement logiciel (SDK) Application Insights pour surveiller les performances des applications.

Autres solutions

L’architecture avancée des microservices AKS décrit un autre scénario de cet exemple qui utilise Kubernetes.

Détails du scénario

Vous pouvez simplifier le déploiement et la gestion des conteneurs de microservice à l’aide de Container Apps, un environnement serverless pour l’hébergement d’applications conteneurisées.

Fabrikam, Inc., une société fictive, implémente une charge de travail de livraison de drone où les utilisateurs demandent à un drone de récupérer des marchandises pour la livraison. Lorsqu’un client planifie un enlèvement, un système back-end affecte un drone et avertit l’utilisateur avec une durée estimée d’enlèvement.

L’application de microservices a été déployée sur un cluster AKS. Mais l’équipe Fabrikam ne tire pas parti des fonctionnalités AKS avancées ou propres à la plateforme. Ils ont migré l’application vers Container Apps, ce qui leur a permis d’effectuer les actions suivantes :

• Utilisez des modifications de code minimales lors du déplacement de l’application d’AKS vers Container Apps. Les changements de code étaient liés aux bibliothèques d'observabilité qui ont enrichi les logs et les métriques avec des informations sur les nœuds Kubernetes, qui ne sont plus pertinentes dans le nouvel environnement.

• Déployer l’infrastructure et la charge de travail avec des modèles Bicep : aucun manifeste YAML Kubernetes n’était nécessaire pour déployer les conteneurs d’application.

• Exposez l’application grâce à l’ingress managé. La prise en charge intégrée de l’entrée basée sur HTTPS externe pour exposer le service d’ingestion a supprimé la nécessité de configurer ses propres entrées.

• Récupérez des images conteneur depuis Container Registry. Container Apps est compatible avec n’importe quelle image de base Linux stockée dans n’importe quel référentiel disponible.

• Utilisez la fonctionnalité de révision pour prendre en charge les besoins du cycle de vie de l’application. Ils peuvent exécuter plusieurs révisions d’une application conteneur particulière et fractionner le trafic entre eux pour les scénarios de déploiement A/B ou bleu/vert.

• Utilisez une identité managée pour vous authentifier auprès de Key Vault et de Container Registry.

Cas d’usage potentiels

Déployez une application basée sur des microservices brownfield dans une plateforme en tant que service (PaaS) pour simplifier la gestion et éviter la complexité de l’exécution d’un orchestrateur de conteneurs. La charge de travail d'infrastructure existante a permis de réaliser des économies en utilisant cette architecture plutôt que son déploiement Kubernetes pour les raisons suivantes :

• Choix des profils de charge de travail
• Moins de temps consacré aux tâches opérationnelles de jour 2 pour l’équipe des opérations
• Possibilité d’éviter le sur-provisionnement

Note

Toutes les charges de travail ne produisent pas de telles économies.

Envisagez d’autres utilisations courantes de Container Apps :

• Exécutez des charges de travail conteneurisées sur une plateforme sans serveur reposant sur la consommation.
• Mise à l’échelle automatique des applications basées sur le trafic HTTP ou HTTPS et les déclencheurs pilotés par les événements pris en charge par KEDA.
• Réduisez la surcharge de maintenance pour les applications conteneurisées.
• Déployez des points de terminaison d’API.
• Héberger des applications de traitement en arrière-plan.
• Gérer le traitement piloté par les événements.

Optimizations

L’objectif de l’équipe de charge de travail est de migrer la charge de travail existante vers Container Apps avec des modifications de code minimales. Toutefois, vous devez effectuer plusieurs optimisations pour améliorer l’implémentation de l’architecture et de la charge de travail après la migration.

Améliorer la gestion des secrets

La charge de travail utilise une approche hybride pour gérer les secrets. Les identités managées s’appliquent uniquement aux services où le passage aux identités managées ne nécessite pas de modifications de code. Le planificateur de drone et les services de livraison utilisent des identités managées affectées par l’utilisateur avec Key Vault pour accéder aux secrets stockés. Les autres services nécessitent des modifications de code pour adopter des identités managées. Ces services utilisent donc des secrets fournis par l’environnement Container Apps.

Une meilleure approche consiste à mettre à jour tout le code pour prendre en charge les identités managées à l’aide de l’application ou de l’identité de travail au lieu des secrets fournis par l’environnement. Pour plus d’informations sur les identités de charge de travail, consultez Identités managées dans Container Apps.

Éviter les conceptions qui nécessitent un mode de révision unique

L’application conteneur du service de flux de travail s’exécute en mode révision unique. En mode révision unique, l’application a une révision soutenue par zéro ou plusieurs répliques. Un réplica est composé du conteneur d’application et des sidecars requis. Cet exemple n’utilise pas de sidecars. Chaque réplica est donc un conteneur unique. Le service de flux de travail n’est pas conçu pour assurer la compatibilité avec les schémas de message. Deux versions différentes du service ne doivent jamais s’exécuter simultanément.

Si le schéma de message Service Bus doit changer, vous devez vider le bus avant de déployer la nouvelle version du service de flux de travail. Une meilleure approche consiste à mettre à jour le code de service pour assurer la compatibilité vers l’avant et à utiliser le mode multi-révision pour réduire les temps d’arrêt associés aux files d’attente de drainage.

Envisager un travail basé sur un emploi

Le service de flux de travail est implémenté en tant qu’application conteneur de longue durée. Mais il peut également s’exécuter en tant que job dans Container Apps. Un travail est une application conteneurisée qui démarre à la demande, s’exécute jusqu’à la fin en fonction du travail disponible, puis arrête et libère des ressources. Les tâches peuvent être plus économiques que l’exécution continue de répliques. Migrer le service pour qu'il s'exécute en tant que tâche Container Apps en fonction des tâches disponibles dans la file d'attente pourrait être une option pratique. Cela dépend du volume de file d’attente classique et de la façon dont le service de workflow est écrit, parallélisable et optimisé pour les ressources. Expérimentez et vérifiez pour déterminer la meilleure approche.

Implémenter le contrôle d’entrée

La charge de travail utilise la fonctionnalité d’entrée externe intégrée de Container Apps pour exposer le service d’ingestion. L’approche de contrôle d’entrée ne permet pas de positionner complètement votre point d’entrée derrière un pare-feu d’applications web (WAF) ou de l’inclure dans les plans Azure DDoS Protection. Vous devez fronter toutes les charges de travail web avec un WAF. Pour obtenir cette configuration dans l’environnement Container Apps, vous devez désactiver l’entrée publique intégrée et ajouter Application Gateway ou Azure Front Door.

Note

Les passerelles nécessitent des sondes de santé significatives, qui maintiennent le service d'entrée actif et empêchent son échelle de revenir à zéro.

Moderniser avec Dapr

Vous pouvez moderniser davantage la charge de travail en intégrant Distributed Application Runtime (Dapr). Il ajoute de l’abstraction entre le code de la charge de travail, les magasins d'états, les systèmes de messagerie, et les mécanismes de découverte de services. Pour plus d’informations, consultez Déployer des microservices avec Container Apps et Dapr. Si votre charge de travail dans Kubernetes utilise déjà Dapr ou des scalers KEDA courants, la migration vers Container Apps est souvent directe et peut conserver cette fonctionnalité.

Migrer vers l’authentification et l’autorisation des utilisateurs

La charge de travail ne délègue pas l’autorisation à une passerelle. Le service d’ingestion supervise l’authentification de ses clients. Une meilleure approche consiste à décharger cette responsabilité à la fonctionnalité d’authentification et d’autorisation intégrée, souvent appelée authentification simple. Cette modification tire parti des fonctionnalités de plateforme et réduit le code personnalisé dans le microservice d’ingestion.

Considérations

Les considérations suivantes implémentent les piliers de Microsoft Azure Well-Architected Framework, qui est un ensemble de lignes directrices que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Container Apps vous aide à déployer, gérer, maintenir et surveiller les applications au sein de la charge de travail. Vous pouvez améliorer la fiabilité en suivant les recommandations principales. Certaines recommandations sont implémentées lors de la migration à partir de Kubernetes.

• Les révisions vous aident à déployer des mises à jour d’application sans temps d’arrêt. Vous pouvez utiliser des révisions pour gérer le déploiement des mises à jour d’application et fractionner le trafic entre les révisions pour prendre en charge les déploiements bleu/vert et les tests A/B.

• Avec les fonctionnalités d’observabilité container Apps, vous avez des informations sur les composants qui s’exécutent dans l’environnement. Container Apps s’intègre à Application Insights et Log Analytics. Vous utilisez ces données pour suivre les opérations et définir des alertes en fonction des métriques et des événements dans le cadre de votre système d’observabilité.

  La surveillance des performances vous permet d’évaluer l’application en cours de chargement. Les métriques et les journaux fournissent des données pour reconnaître les tendances, examiner les défaillances et effectuer une analyse de la cause racine.

• Utilisez des sondes d’intégrité et de préparation pour gérer les conteneurs à démarrage lent et éviter d’envoyer du trafic avant qu’ils ne soient prêts. L’implémentation de Kubernetes inclut ces points de terminaison. Continuez à les utiliser s’ils fournissent des signaux efficaces.

• Lorsqu’un service se termine de façon inattendue, Container Apps le redémarre automatiquement. La découverte de service est activée afin que le service de flux de travail puisse découvrir ses microservices en aval. Utilisez des stratégies de résilience pour gérer les délais d’attente et introduire une logique disjoncteur sans avoir à ajuster davantage le code.

• Activez les règles de mise à l’échelle automatique pour répondre à la demande à mesure que le trafic et les charges de travail augmentent.

• Utilisez les fonctionnalités d’équilibrage de charge dynamique et de mise à l’échelle de Container Apps pour améliorer la disponibilité. Surprovisionnez le sous-réseau de votre environnement afin qu’il dispose toujours de suffisamment d’adresses IP disponibles pour les réplicas ou travaux futurs.

• Évitez de stocker l’état directement dans l’environnement Container Apps, car tout état est perdu lorsque le réplica s’arrête. Externalisez le stockage vers un stockage dédié pour chaque microservice. Cette architecture distribue l’état dans trois magasins distincts : Azure Managed Redis, Azure Cosmos DB pour NoSQL et Azure DocumentDB.

• Déployez toutes les ressources, y compris Container Apps, à l’aide d’une topologie multizone. Pour plus d’informations, consultez la prise en charge des zones de disponibilité dans Container Apps.

  Définissez le nombre minimal de répliques pour les applications persistantes à au moins une réplique par zone de disponibilité. Pendant les conditions d’exploitation classiques, les réplicas sont distribués de manière fiable et équilibrée entre les zones de disponibilité de la région.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

Secrets

• Votre version de Container Apps peut stocker et récupérer des valeurs sensibles en tant que secrets. Après avoir défini un secret pour l’application conteneur, il est disponible pour être utilisé par l’application et toutes les règles d’échelle associées. Si vous exécutez en mode multi-révision, toutes les révisions partagent les mêmes secrets. Étant donné que les secrets sont considérés comme des modifications d’étendue d’application, si vous modifiez la valeur d’un secret, une nouvelle révision n’est pas créée. Toutefois, pour toutes les révisions en cours d’exécution pour charger la nouvelle valeur secrète, vous devez les redémarrer. Dans ce scénario, les valeurs des variables d’environnement et de l’application sont utilisées.

• Réécrire le code de service pour utiliser la propre identité managée de l’application pour s’authentifier auprès des dépendances au lieu de partager des secrets prépartagés. Toutes les dépendances ont des sdk qui prennent en charge l’authentification d’identité managée.

• Vous pouvez stocker en toute sécurité des valeurs sensibles dans les variables d’environnement au niveau de l’application. Lorsque les variables d’environnement changent, l’application conteneur crée une nouvelle révision.

Sécurité du réseau

• Pour limiter l’accès externe, seul le service d’ingestion est configuré pour l’entrée externe. Les services principaux sont accessibles uniquement via le réseau virtuel interne dans l’environnement Container Apps et sont configurés en mode interne. Exposez uniquement les services à Internet si nécessaire.

  Étant donné que cette architecture utilise la fonctionnalité d’entrée externe intégrée, cette solution ne fournit pas la possibilité de positionner complètement votre point d’entrée derrière un WAF ou de l’inclure dans les plans de protection DDoS. Frontez toutes les charges de travail web avec un pare-feu d’applications web. Pour plus d’informations sur les améliorations apportées à l’entrée, consultez Implémenter le contrôle d’entrée.

• Lorsque vous créez un environnement, vous pouvez fournir un réseau virtuel personnalisé. Sinon, Microsoft génère et gère automatiquement un réseau virtuel. Vous ne pouvez pas manipuler ce réseau virtuel géré par Microsoft, par exemple en ajoutant des groupes de sécurité réseau (NSG) ou en forcez le tunneling du trafic vers un pare-feu de sortie. L’exemple utilise un réseau virtuel généré automatiquement, mais un réseau virtuel personnalisé améliore le contrôle de sécurité. Un réseau personnalisé vous permet d’appliquer des NSGs et un routage basé sur un itinéraire défini par l'utilisateur (UDR) via le Pare-feu Azure.

Pour plus d’informations sur les options de topologie de réseau, notamment la prise en charge des points de terminaison privés pour l’entrée, consultez Architecture de mise en réseau dans Container Apps.

Identités de charge de travail

• Container Apps prend en charge les identités managées Microsoft Entra qui permettent à votre application de s’authentifier auprès d’autres ressources protégées par l’ID Microsoft Entra, comme Key Vault, sans gérer les informations d’identification dans votre application conteneur. Une application conteneur peut utiliser des identités affectées par le système, des identités affectées par l’utilisateur ou les deux. Pour les services qui ne prennent pas en charge l’authentification d’ID Microsoft Entra, stockez les secrets dans Key Vault et utilisez une identité managée pour accéder aux secrets.

• Utilisez une identité managée dédiée affectée par l’utilisateur pour l’accès à Container Registry. Container Apps prend en charge l’utilisation d’une identité managée différente pour l’opération de charge de travail que pour l’accès au registre de conteneurs. Cette approche fournit un contrôle d’accès granulaire. Si votre charge de travail a plusieurs environnements Container Apps, ne partagez pas l’identité entre les instances.

• Utilisez des identités managées affectées par le système pour les identités de charge de travail afin de lier le cycle de vie des identités au cycle de vie des composants de charge de travail.

Autres recommandations en matière de sécurité

• L’implémentation kubernetes de cette charge de travail fournit une protection à l’aide des fonctionnalités de Microsoft Defender pour conteneurs. Dans cette architecture, Defender pour conteneurs évalue uniquement la vulnérabilité des conteneurs dans votre registre de conteneurs. Defender pour conteneurs ne fournit pas de protection d’exécution pour Container Apps. Évaluez les compléments avec les solutions de sécurité non-Microsoft si la protection du runtime est requise.

• N’exécutez pas la charge de travail dans un environnement Container Apps partagé. Segmentez-le à partir d’autres charges de travail ou composants qui n’ont pas besoin d’accéder à ces microservices. Créez des environnements Container Apps distincts. Les applications et les travaux qui s’exécutent dans un environnement Container Apps peuvent découvrir et atteindre n’importe quel service qui s’exécute dans l’environnement avec l’entrée interne activée.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

• Passez en revue un exemple d’estimation de prix pour la charge de travail. Utilisez la calculatrice de prix Azure. Les configurations varient, donc ajustez-la pour qu’elle corresponde à votre scénario.

• Dans ce scénario, Azure Cosmos DB, Azure Managed Redis et Service Bus Premium sont les principaux pilotes de coût.

• Pour les conteneurs qui consomment généralement une faible quantité d'UC et de mémoire, commencez par évaluer le profil de consommation de la charge de travail. Estimez le coût du profil de consommation en fonction de votre utilisation pour vous aider à collecter les données de coût de référence et à évaluer d’autres profils. Par exemple, vous pouvez utiliser un profil de charge de travail dédié pour les composants qui ont une utilisation hautement prévisible et stable et peuvent partager des nœuds dédiés. Pour optimiser les coûts, conservez un multiple de trois nœuds pour chaque profil dédié afin de garantir un nombre suffisant d’hôtes de calcul et de distribution de réplicas dans les zones de disponibilité.

• Éliminez les coûts de calcul pendant les périodes d'inactivité en veillant à ce que les composants puissent être réduits à zéro afin de ne payer que si nécessaire. Cette approche réduit les dépenses des applications qui ont une utilisation variable ou peu fréquente. Les contrôles d’intégrité empêchent généralement une mise à l’échelle complète à zéro. Dans l’architecture, vous pouvez réimplémenter le service de flux de travail en tant que tâche pour tirer parti de l'extensibilité à zéro pendant les périodes d’inactivité. Cette approche s'intègre bien avec les charges de travail pouvant utiliser un plan de consommation.

• Pour éviter les frais réseau interrégions, déployez tous les composants, tels que les magasins d’état et le registre de conteneurs, dans la même région.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

• Utilisez GitHub Actions ou l’intégration d’Azure Pipelines pour configurer des pipelines d’intégration continue et de déploiement continu automatisés (CI/CD).

• Utilisez le mode de révision multiple avec le fractionnement du trafic pour tester les modifications de votre code de charge de travail et appliquer des règles de mise à l’échelle.

• Intégrez Application Insights et Log Analytics pour fournir des informations sur votre charge de travail. Utilisez le même espace de travail Log Analytics que le reste des composants de votre charge de travail pour conserver tous les insights de charge de travail ensemble.

• Utilisez l’infrastructure en tant que code (IaC), comme Bicep ou Terraform, pour gérer tous les déploiements d’infrastructure. Les déploiements incluent l’environnement "Container Apps", le registre de conteneurs et les stockages d’état des microservices. Séparez les pipelines de déploiement de microservice des pipelines d’infrastructure, car ils ne partagent souvent pas de cycle de vie similaire. Votre pipeline déclaratif pour l’infrastructure Azure doit déployer toutes les ressources à l’exception des ressources de l’application conteneur.

• Utilisez une approche impérative pour créer, mettre à jour et supprimer des applications conteneur de l’environnement. Il est particulièrement important si vous ajustez dynamiquement la logique de déplacement du trafic entre les révisions. Utilisez une action GitHub ou une tâche Azure Pipelines dans vos flux de travail de déploiement. Cette approche impérative peut être basée sur les définitions d’application YAML . Pour réduire les échecs de vérification d'intégrité, assurez-vous toujours que votre pipeline remplit votre registre de conteneurs avec la nouvelle image de conteneur avant de déployer l'application de conteneur.

  Une modification importante de l’implémentation Kubernetes est le passage de la gestion des fichiers manifeste Kubernetes, tels que la définition Deployment d’objets Kubernetes. Kubernetes fournit une approche atomique réussissent ensemble ou échouent ensemble pour le déploiement de microservices, via cet objet manifeste. Dans Container Apps, chaque microservice est déployé indépendamment. Vos pipelines de déploiement deviennent responsables de l’orchestration de toute stratégie de séquencement et de retour en arrière nécessaire pour avoir un déploiement sécurisé.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

• La charge de travail est répartie entre plusieurs applications de microservice.

• Chaque microservice est indépendant et ne partage aucun état avec d’autres microservices, ce qui permet une mise à l’échelle indépendante.

• Utilisez des tâches Container Apps pour des exécutions de processus limitées afin d'implémenter des runtimes transitoires et réduire la consommation de ressources pour les services inactifs. Évaluez les implications en matière de performances du démarrage et arrêt des tâches par rapport au maintien des composants en état de préparation.

• La mise à l’échelle automatique est activée. Préférez la mise à l’échelle basée sur les événements par rapport à la mise à l’échelle basée sur les métriques si possible. Par exemple, le service de flux de travail, s’il est conçu pour le prendre en charge, peut être mis à l’échelle en fonction de la profondeur de la file d’attente Service Bus. La mise à l’échelle automatique par défaut est basée sur les requêtes HTTP. Lors d’une nouvelle mise en forme, il est important de commencer par la même approche de mise à l’échelle, puis d’évaluer les optimisations de mise à l’échelle ultérieurement.

• Les requêtes sont réparties dynamiquement entre les réplicas disponibles d’une révision.

• Les métriques, notamment l’utilisation du processeur, de la mémoire, des informations de bande passante et du stockage, sont disponibles via Azure Monitor.

Déployer ce scénario

Suivez les étapes dans le fichier README.md dans le dépôt d'exemple de scénario Container Apps.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Contributeurs:

• Julien Strebler | Architecture de solution cloud
• Steve Caravajal | Architecture de solution cloud
• Simon Kurtz | Architecture de solution cloud

Étapes suivantes

• Documentation des Container Apps

Ressources associées

• Style d’architecture de microservices
• Concevoir une architecture de microservices
• Créer un pipeline CI/CD pour les applications AKS à l’aide d’Azure Pipelines
• Architecture de microservices avancée sur AKS

Ce scénario montre une charge de travail existante conçue à l’origine pour Kubernetes, qui est réplateformée pour s’exécuter dans Azure Container Apps. Container Apps prend en charge les charges de travail brownfield où les équipes souhaitent simplifier l’infrastructure et l’orchestration de conteneurs.

L’exemple de charge de travail est une application de microservices en conteneur. Elle réutilise la même charge de travail définie dans l’architecture des microservices sur Azure Kubernetes Service (AKS). Cette architecture réhéberge la charge de travail dans Container Apps en tant que plateforme d’applications.

Important

Cette architecture se concentre sur la réduction des modifications de code d’application et l’approche de la transition d’AKS vers Container Apps en tant que migration de plateforme. L’objectif est de répliquer l’implémentation existante et de différer le code ou les optimisations d’infrastructure qui peuvent compromettre la migration.

Pour obtenir une charge de travail greenfield, consultez Déployer des microservices à l’aide de Container Apps et dapr.

Conseil

Un exemple d’implémentation prend en charge cette architecture et illustre certains des choix de conception décrits dans cet article.

Architecture

Le diagramme montre un environnement Container Apps sous la forme d’un grand rectangle qui contient cinq applications conteneur. Une flèche source du trafic HTTP pointe vers le service d’ingestion. Une flèche ascendante partant de l'Ingestion va vers Azure Service Bus. Une flèche pointant vers le bas part de Service Bus et retourne au service Workflow. À partir du flux de travail, trois connecteurs noirs descendent et se plient vers chaque service inférieur : le package, le planificateur de drone et les services de livraison. Chaque service inférieur a une flèche verticale vers son propre magasin d’état externe : le service de package accède à Azure DocumentDB. Le service Drone Scheduler est dirigé vers Azure Cosmos DB pour NoSQL. Le service de livraison est dirigé vers Azure Managed Redis. Deux flèches quittent le milieu de l’environnement : la flèche supérieure accède à Azure Application Insights. La flèche inférieure accède à l’espace de travail Azure Log Analytics. En dessous de l'espace de travail se trouvent Azure Key Vault puis Azure Container Registry, illustrés sans flèches de connexion.

Téléchargez un fichier Visio de cette architecture.

Les services qui partagent le même environnement bénéficient de la façon suivante :

• Pénétration interne et détection de service
• Un seul espace de travail Log Analytics pour la journalisation de l’exécution
• Méthode de gestion sécurisée pour les secrets et les certificats

Flux de données

1. Service d’ingestion : Reçoit les demandes du client, les met en mémoire tampon, puis les publie dans Azure Service Bus. Il s’agit du seul point d’entrée dans la charge de travail.

2. Service de flux de travail : Consomme des messages de Service Bus et les répartit vers des microservices sous-jacents.

3. Le service de package gèrent les packages. Le service conserve son propre état dans Azure Cosmos DB.

4. Service Drone Scheduler : Planifie les drones et surveille les drones en vol. Le service conserve son propre état dans Azure Cosmos DB.

5. Service de livraison : Gère les livraisons planifiées ou en transit. Le service conserve son propre état dans Azure Managed Redis.

6. Récupération des secrets : Étant donné qu’il s’agit d’une charge de travail existante, seuls certains composants accèdent à Azure Key Vault pour obtenir des secrets d’exécution. Les autres services reçoivent ces secrets de l’environnement Container Apps.

7. Journaux et métriques : L’environnement et toutes les applications conteneur émettent des journaux et des métriques qu’Azure Monitor propose, puis collectent et visualisent.

8. Images conteneur : Les images conteneur sont extraites d’Azure Container Registry existant qui a été précédemment utilisé pour AKS et déployé dans l’environnement Container Apps.

Composants

La charge de travail utilise les services Azure suivants en coordination entre eux :

• Container Apps est une plateforme de conteneur serverless qui simplifie l’orchestration et la gestion des conteneurs. Dans cette architecture, Container Apps sert de plateforme d’hébergement principale pour tous les microservices.

  Les fonctionnalités suivantes remplacent la plupart des fonctionnalités de l’architecture AKS précédente :

  • Détection de service intégrée
  • Points de terminaison HTTP et HTTP/2 managés
  • Équilibrage de charge intégré
  • Enregistrement et surveillance
  • Mise à l’échelle automatique basée sur le trafic HTTP ou les événements alimentés par la mise à l’échelle automatique basée sur les événements Kubernetes (KEDA)
  • Mises à niveau et contrôle de version de l’application

• Container Registry est un service de registre managé permettant de stocker et de gérer des images conteneur privées. Dans cette architecture, il s’agit de la source de toutes les images conteneur déployées dans l’environnement Container Apps. Le Registre est le même que celui utilisé dans l’implémentation AKS.

• Azure Cosmos DB est un service de base de données multimodèle distribué à l’échelle mondiale. Dans cette architecture, le service drone scheduler utilise Azure Cosmos DB comme magasin de données.

• Azure DocumentDB est un service de base de données entièrement managé compatible MongoDB pour la création d’applications modernes. Dans cette architecture, le service de package utilise Azure DocumentDB comme magasin de données.

• Service Bus est un service de messagerie cloud qui fournit des fonctionnalités de communication asynchrones et une intégration hybride. Dans cette architecture, elle gère la messagerie asynchrone entre le service d’ingestion et le microservice de workflow basé sur les tâches. Les autres services de l’application existante sont conçus pour que d’autres services puissent les appeler avec des requêtes HTTP.

• Azure Managed Redis est un service de mise en cache en mémoire. Dans cette architecture, elle réduit la latence et améliore le débit pour les données de livraison de drone fréquemment sollicitées.

• Key Vault est un service cloud permettant de stocker et d’accéder en toute sécurité aux secrets tels que les clés API, les mots de passe et les certificats. Dans cette architecture, le planificateur de drone et les services de livraison utilisent des identités managées affectées par l’utilisateur pour s’authentifier auprès de Key Vault et récupérer les secrets nécessaires à leurs exigences d’exécution.

• Azure Monitor est une solution de supervision complète qui collecte et analyse les données de télémétrie. Dans cette architecture, elle collecte et stocke les métriques et les journaux à partir de tous les composants d’application via un espace de travail Log Analytics. Vous utilisez ces données pour surveiller l’application, configurer des alertes et des tableaux de bord, et effectuer une analyse de la cause racine des défaillances.

  • Application Insights est un service de gestion des performances des applications qui fournit des fonctionnalités de surveillance extensibles. Dans cette architecture, chaque service est instrumenté avec le Kit de développement logiciel (SDK) Application Insights pour surveiller les performances des applications.

Autres solutions

L’architecture avancée des microservices AKS décrit un autre scénario de cet exemple qui utilise Kubernetes.

Détails du scénario

Vous pouvez simplifier le déploiement et la gestion des conteneurs de microservice à l’aide de Container Apps, un environnement serverless pour l’hébergement d’applications conteneurisées.

Fabrikam, Inc., une société fictive, implémente une charge de travail de livraison de drone où les utilisateurs demandent à un drone de récupérer des marchandises pour la livraison. Lorsqu’un client planifie un enlèvement, un système back-end affecte un drone et avertit l’utilisateur avec une durée estimée d’enlèvement.

L’application de microservices a été déployée sur un cluster AKS. Mais l’équipe Fabrikam ne tire pas parti des fonctionnalités AKS avancées ou propres à la plateforme. Ils ont migré l’application vers Container Apps, ce qui leur a permis d’effectuer les actions suivantes :

• Utilisez des modifications de code minimales lors du déplacement de l’application d’AKS vers Container Apps. Les changements de code étaient liés aux bibliothèques d'observabilité qui ont enrichi les logs et les métriques avec des informations sur les nœuds Kubernetes, qui ne sont plus pertinentes dans le nouvel environnement.

• Déployer l’infrastructure et la charge de travail avec des modèles Bicep : aucun manifeste YAML Kubernetes n’était nécessaire pour déployer les conteneurs d’application.

• Exposez l’application grâce à l’ingress managé. La prise en charge intégrée de l’entrée basée sur HTTPS externe pour exposer le service d’ingestion a supprimé la nécessité de configurer ses propres entrées.

• Récupérez des images conteneur depuis Container Registry. Container Apps est compatible avec n’importe quelle image de base Linux stockée dans n’importe quel référentiel disponible.

• Utilisez la fonctionnalité de révision pour prendre en charge les besoins du cycle de vie de l’application. Ils peuvent exécuter plusieurs révisions d’une application conteneur particulière et fractionner le trafic entre eux pour les scénarios de déploiement A/B ou bleu/vert.

• Utilisez une identité managée pour vous authentifier auprès de Key Vault et de Container Registry.

Cas d’usage potentiels

Déployez une application basée sur des microservices brownfield dans une plateforme en tant que service (PaaS) pour simplifier la gestion et éviter la complexité de l’exécution d’un orchestrateur de conteneurs. La charge de travail d'infrastructure existante a permis de réaliser des économies en utilisant cette architecture plutôt que son déploiement Kubernetes pour les raisons suivantes :

• Choix des profils de charge de travail
• Moins de temps consacré aux tâches opérationnelles de jour 2 pour l’équipe des opérations
• Possibilité d’éviter le sur-provisionnement

Note

Toutes les charges de travail ne produisent pas de telles économies.

Envisagez d’autres utilisations courantes de Container Apps :

• Exécutez des charges de travail conteneurisées sur une plateforme sans serveur reposant sur la consommation.
• Mise à l’échelle automatique des applications basées sur le trafic HTTP ou HTTPS et les déclencheurs pilotés par les événements pris en charge par KEDA.
• Réduisez la surcharge de maintenance pour les applications conteneurisées.
• Déployez des points de terminaison d’API.
• Héberger des applications de traitement en arrière-plan.
• Gérer le traitement piloté par les événements.

Optimizations

L’objectif de l’équipe de charge de travail est de migrer la charge de travail existante vers Container Apps avec des modifications de code minimales. Toutefois, vous devez effectuer plusieurs optimisations pour améliorer l’implémentation de l’architecture et de la charge de travail après la migration.

Améliorer la gestion des secrets

La charge de travail utilise une approche hybride pour gérer les secrets. Les identités managées s’appliquent uniquement aux services où le passage aux identités managées ne nécessite pas de modifications de code. Le planificateur de drone et les services de livraison utilisent des identités managées affectées par l’utilisateur avec Key Vault pour accéder aux secrets stockés. Les autres services nécessitent des modifications de code pour adopter des identités managées. Ces services utilisent donc des secrets fournis par l’environnement Container Apps.

Une meilleure approche consiste à mettre à jour tout le code pour prendre en charge les identités managées à l’aide de l’application ou de l’identité de travail au lieu des secrets fournis par l’environnement. Pour plus d’informations sur les identités de charge de travail, consultez Identités managées dans Container Apps.

Éviter les conceptions qui nécessitent un mode de révision unique

L’application conteneur du service de flux de travail s’exécute en mode révision unique. En mode révision unique, l’application a une révision soutenue par zéro ou plusieurs répliques. Un réplica est composé du conteneur d’application et des sidecars requis. Cet exemple n’utilise pas de sidecars. Chaque réplica est donc un conteneur unique. Le service de flux de travail n’est pas conçu pour assurer la compatibilité avec les schémas de message. Deux versions différentes du service ne doivent jamais s’exécuter simultanément.

Si le schéma de message Service Bus doit changer, vous devez vider le bus avant de déployer la nouvelle version du service de flux de travail. Une meilleure approche consiste à mettre à jour le code de service pour assurer la compatibilité vers l’avant et à utiliser le mode multi-révision pour réduire les temps d’arrêt associés aux files d’attente de drainage.

Envisager un travail basé sur un emploi

Le service de flux de travail est implémenté en tant qu’application conteneur de longue durée. Mais il peut également s’exécuter en tant que job dans Container Apps. Un travail est une application conteneurisée qui démarre à la demande, s’exécute jusqu’à la fin en fonction du travail disponible, puis arrête et libère des ressources. Les tâches peuvent être plus économiques que l’exécution continue de répliques. Migrer le service pour qu'il s'exécute en tant que tâche Container Apps en fonction des tâches disponibles dans la file d'attente pourrait être une option pratique. Cela dépend du volume de file d’attente classique et de la façon dont le service de workflow est écrit, parallélisable et optimisé pour les ressources. Expérimentez et vérifiez pour déterminer la meilleure approche.

Implémenter le contrôle d’entrée

La charge de travail utilise la fonctionnalité d’entrée externe intégrée de Container Apps pour exposer le service d’ingestion. L’approche de contrôle d’entrée ne permet pas de positionner complètement votre point d’entrée derrière un pare-feu d’applications web (WAF) ou de l’inclure dans les plans Azure DDoS Protection. Vous devez fronter toutes les charges de travail web avec un WAF. Pour obtenir cette configuration dans l’environnement Container Apps, vous devez désactiver l’entrée publique intégrée et ajouter Application Gateway ou Azure Front Door.

Note

Les passerelles nécessitent des sondes de santé significatives, qui maintiennent le service d'entrée actif et empêchent son échelle de revenir à zéro.

Moderniser avec Dapr

Vous pouvez moderniser davantage la charge de travail en intégrant Distributed Application Runtime (Dapr). Il ajoute de l’abstraction entre le code de la charge de travail, les magasins d'états, les systèmes de messagerie, et les mécanismes de découverte de services. Pour plus d’informations, consultez Déployer des microservices avec Container Apps et Dapr. Si votre charge de travail dans Kubernetes utilise déjà Dapr ou des scalers KEDA courants, la migration vers Container Apps est souvent directe et peut conserver cette fonctionnalité.

Migrer vers l’authentification et l’autorisation des utilisateurs

La charge de travail ne délègue pas l’autorisation à une passerelle. Le service d’ingestion supervise l’authentification de ses clients. Une meilleure approche consiste à décharger cette responsabilité à la fonctionnalité d’authentification et d’autorisation intégrée, souvent appelée authentification simple. Cette modification tire parti des fonctionnalités de plateforme et réduit le code personnalisé dans le microservice d’ingestion.

Considérations

Les considérations suivantes implémentent les piliers de Microsoft Azure Well-Architected Framework, qui est un ensemble de lignes directrices que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Container Apps vous aide à déployer, gérer, maintenir et surveiller les applications au sein de la charge de travail. Vous pouvez améliorer la fiabilité en suivant les recommandations principales. Certaines recommandations sont implémentées lors de la migration à partir de Kubernetes.

• Les révisions vous aident à déployer des mises à jour d’application sans temps d’arrêt. Vous pouvez utiliser des révisions pour gérer le déploiement des mises à jour d’application et fractionner le trafic entre les révisions pour prendre en charge les déploiements bleu/vert et les tests A/B.

• Avec les fonctionnalités d’observabilité container Apps, vous avez des informations sur les composants qui s’exécutent dans l’environnement. Container Apps s’intègre à Application Insights et Log Analytics. Vous utilisez ces données pour suivre les opérations et définir des alertes en fonction des métriques et des événements dans le cadre de votre système d’observabilité.

  La surveillance des performances vous permet d’évaluer l’application en cours de chargement. Les métriques et les journaux fournissent des données pour reconnaître les tendances, examiner les défaillances et effectuer une analyse de la cause racine.

• Utilisez des sondes d’intégrité et de préparation pour gérer les conteneurs à démarrage lent et éviter d’envoyer du trafic avant qu’ils ne soient prêts. L’implémentation de Kubernetes inclut ces points de terminaison. Continuez à les utiliser s’ils fournissent des signaux efficaces.

• Lorsqu’un service se termine de façon inattendue, Container Apps le redémarre automatiquement. La découverte de service est activée afin que le service de flux de travail puisse découvrir ses microservices en aval. Utilisez des stratégies de résilience pour gérer les délais d’attente et introduire une logique disjoncteur sans avoir à ajuster davantage le code.

• Activez les règles de mise à l’échelle automatique pour répondre à la demande à mesure que le trafic et les charges de travail augmentent.

• Utilisez les fonctionnalités d’équilibrage de charge dynamique et de mise à l’échelle de Container Apps pour améliorer la disponibilité. Surprovisionnez le sous-réseau de votre environnement afin qu’il dispose toujours de suffisamment d’adresses IP disponibles pour les réplicas ou travaux futurs.

• Évitez de stocker l’état directement dans l’environnement Container Apps, car tout état est perdu lorsque le réplica s’arrête. Externalisez le stockage vers un stockage dédié pour chaque microservice. Cette architecture distribue l’état dans trois magasins distincts : Azure Managed Redis, Azure Cosmos DB pour NoSQL et Azure DocumentDB.

• Déployez toutes les ressources, y compris Container Apps, à l’aide d’une topologie multizone. Pour plus d’informations, consultez la prise en charge des zones de disponibilité dans Container Apps.

  Définissez le nombre minimal de répliques pour les applications persistantes à au moins une réplique par zone de disponibilité. Pendant les conditions d’exploitation classiques, les réplicas sont distribués de manière fiable et équilibrée entre les zones de disponibilité de la région.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

Secrets

• Votre version de Container Apps peut stocker et récupérer des valeurs sensibles en tant que secrets. Après avoir défini un secret pour l’application conteneur, il est disponible pour être utilisé par l’application et toutes les règles d’échelle associées. Si vous exécutez en mode multi-révision, toutes les révisions partagent les mêmes secrets. Étant donné que les secrets sont considérés comme des modifications d’étendue d’application, si vous modifiez la valeur d’un secret, une nouvelle révision n’est pas créée. Toutefois, pour toutes les révisions en cours d’exécution pour charger la nouvelle valeur secrète, vous devez les redémarrer. Dans ce scénario, les valeurs des variables d’environnement et de l’application sont utilisées.

• Réécrire le code de service pour utiliser la propre identité managée de l’application pour s’authentifier auprès des dépendances au lieu de partager des secrets prépartagés. Toutes les dépendances ont des sdk qui prennent en charge l’authentification d’identité managée.

• Vous pouvez stocker en toute sécurité des valeurs sensibles dans les variables d’environnement au niveau de l’application. Lorsque les variables d’environnement changent, l’application conteneur crée une nouvelle révision.

Sécurité du réseau

• Pour limiter l’accès externe, seul le service d’ingestion est configuré pour l’entrée externe. Les services principaux sont accessibles uniquement via le réseau virtuel interne dans l’environnement Container Apps et sont configurés en mode interne. Exposez uniquement les services à Internet si nécessaire.

  Étant donné que cette architecture utilise la fonctionnalité d’entrée externe intégrée, cette solution ne fournit pas la possibilité de positionner complètement votre point d’entrée derrière un WAF ou de l’inclure dans les plans de protection DDoS. Frontez toutes les charges de travail web avec un pare-feu d’applications web. Pour plus d’informations sur les améliorations apportées à l’entrée, consultez Implémenter le contrôle d’entrée.

• Lorsque vous créez un environnement, vous pouvez fournir un réseau virtuel personnalisé. Sinon, Microsoft génère et gère automatiquement un réseau virtuel. Vous ne pouvez pas manipuler ce réseau virtuel géré par Microsoft, par exemple en ajoutant des groupes de sécurité réseau (NSG) ou en forcez le tunneling du trafic vers un pare-feu de sortie. L’exemple utilise un réseau virtuel généré automatiquement, mais un réseau virtuel personnalisé améliore le contrôle de sécurité. Un réseau personnalisé vous permet d’appliquer des NSGs et un routage basé sur un itinéraire défini par l'utilisateur (UDR) via le Pare-feu Azure.

Pour plus d’informations sur les options de topologie de réseau, notamment la prise en charge des points de terminaison privés pour l’entrée, consultez Architecture de mise en réseau dans Container Apps.

Identités de charge de travail

• Container Apps prend en charge les identités managées Microsoft Entra qui permettent à votre application de s’authentifier auprès d’autres ressources protégées par l’ID Microsoft Entra, comme Key Vault, sans gérer les informations d’identification dans votre application conteneur. Une application conteneur peut utiliser des identités affectées par le système, des identités affectées par l’utilisateur ou les deux. Pour les services qui ne prennent pas en charge l’authentification d’ID Microsoft Entra, stockez les secrets dans Key Vault et utilisez une identité managée pour accéder aux secrets.

• Utilisez une identité managée dédiée affectée par l’utilisateur pour l’accès à Container Registry. Container Apps prend en charge l’utilisation d’une identité managée différente pour l’opération de charge de travail que pour l’accès au registre de conteneurs. Cette approche fournit un contrôle d’accès granulaire. Si votre charge de travail a plusieurs environnements Container Apps, ne partagez pas l’identité entre les instances.

• Utilisez des identités managées affectées par le système pour les identités de charge de travail afin de lier le cycle de vie des identités au cycle de vie des composants de charge de travail.

Autres recommandations en matière de sécurité

• L’implémentation kubernetes de cette charge de travail fournit une protection à l’aide des fonctionnalités de Microsoft Defender pour conteneurs. Dans cette architecture, Defender pour conteneurs évalue uniquement la vulnérabilité des conteneurs dans votre registre de conteneurs. Defender pour conteneurs ne fournit pas de protection d’exécution pour Container Apps. Évaluez les compléments avec les solutions de sécurité non-Microsoft si la protection du runtime est requise.

• N’exécutez pas la charge de travail dans un environnement Container Apps partagé. Segmentez-le à partir d’autres charges de travail ou composants qui n’ont pas besoin d’accéder à ces microservices. Créez des environnements Container Apps distincts. Les applications et les travaux qui s’exécutent dans un environnement Container Apps peuvent découvrir et atteindre n’importe quel service qui s’exécute dans l’environnement avec l’entrée interne activée.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

• Passez en revue un exemple d’estimation de prix pour la charge de travail. Utilisez la calculatrice de prix Azure. Les configurations varient, donc ajustez-la pour qu’elle corresponde à votre scénario.

• Dans ce scénario, Azure Cosmos DB, Azure Managed Redis et Service Bus Premium sont les principaux pilotes de coût.

• Pour les conteneurs qui consomment généralement une faible quantité d'UC et de mémoire, commencez par évaluer le profil de consommation de la charge de travail. Estimez le coût du profil de consommation en fonction de votre utilisation pour vous aider à collecter les données de coût de référence et à évaluer d’autres profils. Par exemple, vous pouvez utiliser un profil de charge de travail dédié pour les composants qui ont une utilisation hautement prévisible et stable et peuvent partager des nœuds dédiés. Pour optimiser les coûts, conservez un multiple de trois nœuds pour chaque profil dédié afin de garantir un nombre suffisant d’hôtes de calcul et de distribution de réplicas dans les zones de disponibilité.

• Éliminez les coûts de calcul pendant les périodes d'inactivité en veillant à ce que les composants puissent être réduits à zéro afin de ne payer que si nécessaire. Cette approche réduit les dépenses des applications qui ont une utilisation variable ou peu fréquente. Les contrôles d’intégrité empêchent généralement une mise à l’échelle complète à zéro. Dans l’architecture, vous pouvez réimplémenter le service de flux de travail en tant que tâche pour tirer parti de l'extensibilité à zéro pendant les périodes d’inactivité. Cette approche s'intègre bien avec les charges de travail pouvant utiliser un plan de consommation.

• Pour éviter les frais réseau interrégions, déployez tous les composants, tels que les magasins d’état et le registre de conteneurs, dans la même région.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

• Utilisez GitHub Actions ou l’intégration d’Azure Pipelines pour configurer des pipelines d’intégration continue et de déploiement continu automatisés (CI/CD).

• Utilisez le mode de révision multiple avec le fractionnement du trafic pour tester les modifications de votre code de charge de travail et appliquer des règles de mise à l’échelle.

• Intégrez Application Insights et Log Analytics pour fournir des informations sur votre charge de travail. Utilisez le même espace de travail Log Analytics que le reste des composants de votre charge de travail pour conserver tous les insights de charge de travail ensemble.

• Utilisez l’infrastructure en tant que code (IaC), comme Bicep ou Terraform, pour gérer tous les déploiements d’infrastructure. Les déploiements incluent l’environnement "Container Apps", le registre de conteneurs et les stockages d’état des microservices. Séparez les pipelines de déploiement de microservice des pipelines d’infrastructure, car ils ne partagent souvent pas de cycle de vie similaire. Votre pipeline déclaratif pour l’infrastructure Azure doit déployer toutes les ressources à l’exception des ressources de l’application conteneur.

• Utilisez une approche impérative pour créer, mettre à jour et supprimer des applications conteneur de l’environnement. Il est particulièrement important si vous ajustez dynamiquement la logique de déplacement du trafic entre les révisions. Utilisez une action GitHub ou une tâche Azure Pipelines dans vos flux de travail de déploiement. Cette approche impérative peut être basée sur les définitions d’application YAML . Pour réduire les échecs de vérification d'intégrité, assurez-vous toujours que votre pipeline remplit votre registre de conteneurs avec la nouvelle image de conteneur avant de déployer l'application de conteneur.

  Une modification importante de l’implémentation Kubernetes est le passage de la gestion des fichiers manifeste Kubernetes, tels que la définition Deployment d’objets Kubernetes. Kubernetes fournit une approche atomique réussissent ensemble ou échouent ensemble pour le déploiement de microservices, via cet objet manifeste. Dans Container Apps, chaque microservice est déployé indépendamment. Vos pipelines de déploiement deviennent responsables de l’orchestration de toute stratégie de séquencement et de retour en arrière nécessaire pour avoir un déploiement sécurisé.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

• La charge de travail est répartie entre plusieurs applications de microservice.

• Chaque microservice est indépendant et ne partage aucun état avec d’autres microservices, ce qui permet une mise à l’échelle indépendante.

• Utilisez des tâches Container Apps pour des exécutions de processus limitées afin d'implémenter des runtimes transitoires et réduire la consommation de ressources pour les services inactifs. Évaluez les implications en matière de performances du démarrage et arrêt des tâches par rapport au maintien des composants en état de préparation.

• La mise à l’échelle automatique est activée. Préférez la mise à l’échelle basée sur les événements par rapport à la mise à l’échelle basée sur les métriques si possible. Par exemple, le service de flux de travail, s’il est conçu pour le prendre en charge, peut être mis à l’échelle en fonction de la profondeur de la file d’attente Service Bus. La mise à l’échelle automatique par défaut est basée sur les requêtes HTTP. Lors d’une nouvelle mise en forme, il est important de commencer par la même approche de mise à l’échelle, puis d’évaluer les optimisations de mise à l’échelle ultérieurement.

• Les requêtes sont réparties dynamiquement entre les réplicas disponibles d’une révision.

• Les métriques, notamment l’utilisation du processeur, de la mémoire, des informations de bande passante et du stockage, sont disponibles via Azure Monitor.

Déployer ce scénario

Suivez les étapes dans le fichier README.md dans le dépôt d'exemple de scénario Container Apps.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Contributeurs:

• Julien Strebler | Architecture de solution cloud
• Steve Caravajal | Architecture de solution cloud
• Simon Kurtz | Architecture de solution cloud

Étapes suivantes

• Documentation des Container Apps

Ressources associées

• Style d’architecture de microservices
• Concevoir une architecture de microservices
• Créer un pipeline CI/CD pour les applications AKS à l’aide d’Azure Pipelines
• Architecture de microservices avancée sur AKS