Cet exemple de scénario montre un exemple de charge de travail existante qui a été initialement conçue pour s’exécuter sur Kubernetes peut à la place s’exécuter dans Azure Container Apps. Azure Container Apps est bien adapté aux charges de travail brownfield où les équipes cherchent à simplifier l’infrastructure complexe et l’orchestration des conteneurs. L’exemple de charge de travail exécute une application de micro-services conteneurisée.
L’exemple prend la charge de travail utilisée dans l’architecture de micro-services sur Azure Kubernetes Service et la re-héberge dans Azure Container Apps en tant que plateforme d’application.
Conseil
L’architecture est soutenu par un exemple d’implémentation illustrant certains choix de design décris dans cet article.
Architecture
Téléchargez un fichier Visio de cette architecture.
Dans ce scénario, les images de conteneur proviennent d’Azure Container Registry et sont déployées dans un environnement Container Apps.
Les services qui partagent le même environnement bénéficient des avantages suivants :
- Pénétration interne et détection de service
- Un seul espace de travail Log Analytics pour la journalisation de l’exécution
- Gestion sécurisée des secrets et des certificats
L’application conteneur du service de flux de travail s’exécute en mode révision unique. Une application conteneur en cours d’exécution en mode révision unique aura une seule révision qui est sauvegardée par zéro réplica. Un réplica est composé du conteneur d’application et de tous les conteneurs sidecar requis. Cet exemple n’utilise pas de conteneurs sidecar. Par conséquent, chaque réplica d’application conteneur représente un seul conteneur. Étant donné que cet exemple n’utilise pas la mise à l’échelle, il n’y aura qu’un seul réplica pour chaque application de conteneur.
Le flux de travail utilise une approche hybride pour gérer les secrets. Les identités managées sont utilisées dans les services où cette implémentation ne nécessite aucune modification de code. Les services Drone Scheduler et Delivery utilisent des identités managées attribuées par l’utilisateur pour s’authentifier auprès d’Azure Key Vault pour accéder aux secrets qui y sont stockés. Les services restants stockent des secrets via le service Container Apps au niveau de l’application.
Ce schéma illustre l’architecture d’exécution de la solution.
Téléchargez un fichier Visio de cette architecture.
Dataflow
- Service d’ingestion : reçoit les demandes des clients, les met en mémoire tampon et les envoie via Azure Service Bus au Service de workflow.
- Service de workflow : utilise les messages d’Azure Service Bus et les distribue aux services sous-jacents.
- Le service de package gèrent les packages.
- Service Drone Scheduler : Planifie les drones et surveille les drones en vol.
- Service de livraison : gère les livraisons planifiées ou en transit.
Components
Le service de livraison par drone utilise une série de services Azure associés.
Azure Container Apps
Azure Container Apps est le composant principal.
La plupart des complexités de l’architecture AKS précédente sont remplacées par ces fonctionnalités :
- Détection de service intégrée
- Points de terminaison HTTP et HTTP/2 entièrement managés
- Équilibrage de charge intégré
- Enregistrement et surveillance
- Mise à l’échelle automatique basée sur le trafic HTTP ou les événements KEDA
- Mises à niveau et contrôle de version de l’application
Stockage externe et autres composants
Service Azure Key Vault pour stocker et accéder en toute sécurité aux secrets, tels que les clés d’API, les mots de passe et les certificats.
Azure Container Registry gère les images privées de conteneur. Vous pouvez utiliser d’autres registres de conteneurs, tel Docker Hub.
Azure Cosmos DB stocke les données à l’aide d’Azure Cosmos DB for MongoDB open source. Les microservices étant généralement sans état, ils écrivent leur état dans des magasins de données externes. Azure Cosmos DB est une base de données NoSQL avec des API open source pour MongoDB et Cassandra.
Azure Service Bus offre une messagerie cloud en tant que service fiable et une intégration hybride simple. Service Bus prend en charge des modèles de messagerie asynchrone communs avec les applications de microservices.
Azure Cache pour Redis ajoute une couche de mise en cache à l’architecture d’application pour améliorer la vitesse et les performances des charges de trafic lourdes.
Azure Monitor collecte et stocke les métriques et les journaux depuis l’application. Utilisez ces données pour superviser l’application, définir des alertes et des tableaux de bord et analyser les causes racines des problèmes. Ce scénario utilise un espace de travail Log Analytics pour une surveillance complète de l’infrastructure et de l’application.
Application Insights fournit la supervision et la gestion des performances des applications (APM) extensibles pour les services. Chaque service est instrumenté avec le Kit de développement logiciel (SDK) Application Insights pour surveiller l’application et diriger les données vers Azure Monitor.
Modèles Bicep pour configurer et déployer les applications.
Autres solutions
Un autre scénario de cet exemple est l’application de livraison par drone de Fabrikam à l’aide de Kubernetes, qui est disponible sur GitHub dans le référentiel Azure Kubernetes Service (AKS) Fabrikam Drone Delivery.
Détails du scénario
Votre entreprise peut simplifier le déploiement et la gestion de conteneurs de microservices à l’aide d’Azure Container Apps. Container Apps offre un environnement serverless complètement managé pour la création et le déploiement des applications modernes.
Fabrikam, Inc. (une société fictive) a mise en place une application de livraison par drone, via lequel les utilisateurs peuvent demander un drone pour récupérer des marchandises. Lorsqu’un client planifie un enlèvement de colis, un système principal assigne un drone et donne à l’utilisateur un délai de livraison estimé.
L’application de micro-services a été déployée sur un cluster Azure Kubernetes Service (AKS). Toutefois, l’équipe Fabrikam ne tire pas parti des fonctionnalités AKS avancées ou spécifiques à la plateforme. Ils ont finalement migré l’application vers Azure Container Apps sans trop de surcharge. En transférant cette solution vers Azure Container Apps, Fabrikam a pu :
- Migration de l’application presque telle quelle : des modifications très minime du code ont été requises lors du déplacement de l’application de AKS vers Azure Container Apps.
- 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.
- Exposition de l’application via une entrée gérée : la prise en charge intégrée de l’entrée externe HTTPS pour exposer le service d’ingestion élimine la nécessité de configurer les entrées spécifiques.
- Extraction d’images de conteneur à partir de ACR : Azure Container Apps n’a pas besoin d’image ou de registre de base spécifique.
- Gestion du cycle de vie des applications : la fonctionnalité de révision prend en charge l’exécution de plusieurs révisions de chaque application de conteneur et le fractionnement du trafic entre ces applications pour les tests A/B ou les scénarios de déploiement bleu/vert.
- Utilisation d’une identité managée : l’équipe Fabrikam a pu utiliser une identité managée pour s’authentifier auprès de Azure Key Vault et de Azure Container Registry.
Cas d’usage potentiels
- Déploiement d’une application basée sur des microservices existants dans une offre PaaS (Platform as a service) pour éviter la complexité opérationnelle de la gestion d’un conteneur Orchestrator.
- Optimisation des opérations et de la gestion en migrant les services en conteneur vers une plateforme qui prend en charge la mise à l’échelle native de zéro.
- Exécution d’un processus en arrière-plan de longue durée, tel que le service de workflow en mode de révision unique.
Exemples d’usages courants d’Azure Container Apps :
- Exécution de charges de travail en conteneur sur une plateforme serverless basée sur la consommation.
- Mise à l’échelle automatique des applications en fonction du trafic HTTP/HTTPs et/ou des déclencheurs pilotés par les événements pris en charge par KEDA
- Réduction de la surcharge de maintenance pour les applications en conteneur
- Déploiement de points de terminaison d’API
- Hébergement d’applications de traitement en arrière-plan
- Gestion du traitement piloté par les événements
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Disponibilité
Container Apps vous permet de déployer, de gérer, et de surveiller plus facilement les applications. La disponibilité peut être assurée par ces fonctionnalités clés :
- 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 (non utilisés dans cet exemple de charge de travail).
- Avec les fonctionnalités d’observabilité de bout en bout de Container Apps, vous avez une vue holistique de vos applications en cours d’exécution. Container Apps est intégré à Azure Monitor et Log Analytics, ce qui vous permet de suivre l’exécution de l’application de conteneur et de définir des alertes basées sur des métriques et des événements.
- Quand une application se termine de manière inattendue, le service Container Apps la redémarre automatiquement.
- Vous pouvez activer les règles de mise à l’échelle automatique pour répondre à la demande à mesure que le trafic et les charges de travail augmentent.
- Les performances sont optimisées par les fonctionnalités d’équilibrage de charge dynamique de Container Apps (non utilisées actuellement dans cet exemple de charge de travail).
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
Pour atteindre l’excellence opérationnelle, le service Container Apps offre les fonctionnalités suivantes :
- L’intégration de GitHub Actions pour configurer des déploiements CI/CD automatisés.
- Le mode de révision multiple avec fractionnement du trafic pour tester les modifications apportées à votre code d’application et à vos règles de mise à l’échelle.
- Intégration à Azure Monitor et Log Analytics pour fournir des informations sur votre application en conteneur.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.
Considérations sur les performances dans cette solution :
- La charge de travail est répartie entre plusieurs applications de microservice.
- Les microservices n’ont pas de dépendances les uns envers les autres et ne partagent rien entre eux. Chaque microservice peut donc être mis à l’échelle de manière indépendante.
- La mise à l’échelle automatique peut être activée à mesure que la charge de travail augmente.
- Les requêtes sont équilibrées dynamiquement.
- Les métriques, y compris l’utilisation de l’UC et de la mémoire, les informations de bande passante et l’utilisation du stockage, sont disponibles via Azure Monitor.
- Log Analytics fournit une agrégation de journaux pour collecter des informations dans chaque environnement Container Apps.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
Container Apps va tenter de redémarrer les conteneurs défaillants et extraire le matériel des utilisateurs. Les défaillances temporaires et la haute disponibilité des ressources de calcul de sauvegarde sont gérées par Microsoft.
La surveillance des performances via Log Analytics et Azure Monitor vous permet d’évaluer l’application en charge. Les métriques et les informations de journalisation vous fournissent les données nécessaires pour reconnaître les tendances afin d’éviter les défaillances et d’effectuer une analyse de la cause racine des défaillances lorsqu’elles se produisent.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
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 une application Container Apps, il peut être utilisé par l’application et toutes les règles de mise à l’échelle associées. Si vous exécutez le mode de révision multiple, toutes les révisions partagent les mêmes secrets. Étant donné que les secrets sont considérés comme une modification de niveau application, si vous modifiez la valeur d’un secret, aucune nouvelle révision n’est créée. Toutefois, pour toutes les révisions en cours de chargement pour charger le nouveau secret, vous devez les redémarrer. Dans ce scénario, les valeurs des variables d’environnement et de l’application sont utilisées.
- Variables d’environnement : les valeurs sensibles peuvent être stockées en toute sécurité au niveau de l’application. Lorsque les variables d’environnement sont modifiées, l’application Container Apps génère une nouvelle révision.
Sécurité du réseau
- Entrée : pour limiter l'accès externe, seul le service d'ingestion est configuré pour l'entrée externe. Les services principaux ne sont accessibles que par le réseau virtuel interne dans l'environnement Container Apps. 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 n’offre pas la possibilité 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 de protection DDoS. Toutes les charges de travail web doivent être traitées avec un pare-feu d’applications web.
- Réseau virtuel : lorsque vous créez un environnement, vous pouvez fournir un réseau virtuel personnalisé . sinon, un réseau virtuel est généré et géré automatiquement par Microsoft. 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 forcer le tunneling du trafic vers un pare-feu de sortie. Cet exemple utilise un réseau virtuel généré automatiquement.
Pour plus d’options de topologie de réseau, consultez Architecture réseau dans Azure Container Apps.
Identités de charge de travail
- Container Apps prend en charge les identités managées Microsoft Entra, ce qui permet à votre application de s’authentifier auprès d’autres ressources protégées par Microsoft Entra ID, telles que Azure Key Vault, sans gérer les informations d’identification dans votre application de conteneur. Une application conteneur peut utiliser des identités managées affectées par le système, affectées par l'utilisateur, ou les deux types d’identités managées. Pour les services qui ne prennent pas en charge l’authentification AD, vous devez stocker des secrets dans Azure Key Vault et utiliser une identité managée pour accéder aux secrets.
- Utilisez des identités managées pour l’accès Azure Container Registry. Azure Container Apps prend en charge l’utilisation d’une identité managée différente pour la charge de travail de l’accès au registre de conteneurs, ce qui est recommandé lorsque vous recherchez des contrôles d’accès granulaires sur vos identités managées.
Optimisation des coûts
- La section Cost dans le Microsoft Azure Well-Architected Framework aborde les considérations relatives aux coûts. Utilisez la Calculatrice de prix Azure pour estimer les coûts de votre scénario spécifique.
- Azure Container Apps utilise un modèle de tarification basé sur la consommation.
- Azure Container Apps prend en charge la mise à l’échelle ou le niveau zéro. Quand une application de conteneur est mise à zéro, aucun frais n’est facturé.
- Dans ce scénario, Azure Cosmos DB et Azure Cache pour Redis sont les main les facteurs de coût.
Déployer ce scénario
Suivez les étapes du fichier README.md dans l’exemple de scénario Azure Container Apps pour déployer ce scénario.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Catherine Bundy | Rédacteur technique
Étapes suivantes
- Documentation sur Azure Container Apps
- Azure Kubernetes Service (AKS) Fabrikam Drone delivery GitHub référentiel