Modifier

Partager via

Déployer des microservices avec Azure Container Apps

Azure Container Apps
Azure Cosmos DB
Azure Service Bus

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

Logo Github L’architecture est soutenu par un exemple d’implémentation illustrant certains choix de design décris dans cet article.

Architecture

Diagramme montrant les microservices déployés avec Azure Container Apps.

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 s’exécutant en mode révision unique a une révision unique, soutenue par zéro-plusieurs réplicas. 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. Dans la mesure où cet exemple n’utilise pas la mise à l’échelle, un seul réplica s’exécute pour chaque application 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.

Diagramme montrant l’architecture d’exécution de la solution.

Ce schéma illustre l’architecture d’exécution de la solution.

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

Dataflow

  1. 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.
  2. Service de workflow : utilise les messages d’Azure Service Bus et les distribue aux services sous-jacents.
  3. Le service de package gèrent les packages.
  4. Service Drone Scheduler : Planifie les drones et surveille les drones en vol.
  5. 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.

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

  • 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 alimentés par KEDA (mise à l’échelle automatique basée sur les événements Kubernetes)
  • 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) implémente une application 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 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.
  • Extraire des images conteneur à partir d’ACR (Azure Container Registry) : Azure Container Apps ne nécessite pas d’image de base ou de registre 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é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.
  • 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, de gérer et de surveiller plus facilement les applications. Vous pouvez garantir la disponibilité via les fonctionnalités clés suivantes :

  • 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 fonctionnalités d’équilibrage de charge dynamique de Container Apps optimisent les performances (bien qu’elles ne soient pas utilisées 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. Microsoft gère les défaillances temporaires et garantit la haute disponibilité des ressources de calcul de stockage.

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 en mode multi-révision, 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 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.
  • Variables d’environnement : les valeurs sensibles peuvent être stockées en toute sécurité au niveau de l’application. Lorsque des variables d’environnement sont modifiées, l’application conteneur 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 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 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 en forcez 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 vous permet d’utiliser une identité managée différente pour votre charge de travail que pour l’accès au registre de conteneurs. Cette approche est recommandée pour obtenir un contrôle d’accès granulaire sur vos identités managées.

Optimisation des coûts

  • 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 de la README.md dans l’exemple de référentiel de scénarios Azure Container Apps.

Contributeurs

Microsoft gère cet article. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Étapes suivantes