Conteneurisation des applications monolithiques

Conseil / Astuce

Ce contenu est un extrait du livre électronique 'Architecture des microservices .NET pour les applications .NET conteneurisées', disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement, lisible hors ligne.

Télécharger le PDF

Vous pouvez créer une application web ou un service web déployé de manière monolithique et le déployer en tant que conteneur. L’application elle-même peut ne pas être monolithique en interne, mais structurée en tant que plusieurs bibliothèques, composants ou même couches (couche application, couche domaine, couche d’accès aux données, etc.). Toutefois, en externe, il s’agit d’un seul conteneur , d’un seul processus, d’une application web unique ou d’un seul service.

Pour gérer ce modèle, vous déployez un conteneur unique pour représenter l’application. Pour augmenter la capacité, vous effectuez un scale-out, c’est-à-dire ajouter plus de copies avec un équilibreur de charge en avant. La simplicité provient de la gestion d’un déploiement unique dans un seul conteneur ou machine virtuelle.

Figure 4-1. Exemple d’architecture d’une application monolithique conteneurisée

Vous pouvez inclure plusieurs composants, bibliothèques ou couches internes dans chaque conteneur, comme illustré dans la figure 4-1. Une application conteneurisée monolithique a la plupart de ses fonctionnalités au sein d’un seul conteneur, avec des couches internes ou des bibliothèques, et effectue un scale-out en clonant le conteneur sur plusieurs serveurs/machines virtuelles. Toutefois, ce modèle monolithique peut entrer en conflit avec le principe du conteneur « un conteneur fait une chose et le fait dans un processus », mais peut être ok pour certains cas.

L’inconvénient de cette approche devient évident si l’application augmente, ce qui exige qu’elle soit mise à l’échelle. Si l’ensemble de l’application peut être mis à l’échelle, ce n’est pas vraiment un problème. Toutefois, dans la plupart des cas, quelques parties de l’application sont les points d’étranglement qui nécessitent une mise à l’échelle, tandis que d’autres composants sont utilisés moins.

Par exemple, dans une application de commerce électronique classique, vous devez probablement mettre à l’échelle le sous-système d’informations sur le produit, car beaucoup plus de clients parcourent les produits que de les acheter. Plus de clients utilisent leur panier que le pipeline de paiement. Moins de clients ajoutent des commentaires ou affichent leur historique d’achat. Et vous n’avez peut-être qu’une poignée d’employés qui doivent gérer le contenu et les campagnes marketing. Si vous mettez à l’échelle la conception monolithique, tout le code de ces différentes tâches est déployé plusieurs fois et mis à l’échelle au même niveau.

Il existe plusieurs façons de mettre à l’échelle une duplication horizontale d’application, de fractionner différentes zones de l’application et de partitionner des concepts métier ou des données similaires. Toutefois, en plus du problème de mise à l’échelle de tous les composants, les modifications apportées à un composant unique nécessitent une retestation complète de l’ensemble de l’application et un redéploiement complet de toutes les instances.

Toutefois, l’approche monolithique est courante, car le développement de l’application est initialement plus facile que pour les approches de microservices. Ainsi, de nombreuses organisations se développent à l’aide de cette approche architecturale. Même si certaines organisations ont eu suffisamment de résultats, d’autres atteignent des limites. De nombreuses organisations ont conçu leurs applications à l’aide de ce modèle, car les outils et l’infrastructure ont rendu trop difficile la création d’architectures orientées services (SOA) il y a des années, et ils n’ont pas vu le besoin jusqu’à ce que l’application se développe.

Du point de vue de l’infrastructure, chaque serveur peut exécuter de nombreuses applications au sein du même hôte et avoir un ratio acceptable d’efficacité dans l’utilisation des ressources, comme illustré dans la figure 4-2.

Figure 4-2. Approche monolithique : héberger plusieurs applications, chaque application s’exécutant en tant que conteneur

Les applications monolithiques dans Microsoft Azure peuvent être déployées à l’aide de machines virtuelles dédiées pour chaque instance. En outre, à l’aide de jeux d'échelle pour machines virtuelles Azure, vous pouvez facilement redimensionner les machines virtuelles. Azure App Service peut également exécuter des applications monolithiques et mettre facilement à l’échelle des instances sans avoir à gérer les machines virtuelles. Depuis 2016, Azure App Services peut également exécuter des instances uniques de conteneurs Docker, ce qui simplifie le déploiement.

En tant qu’environnement d'assurance qualité ou environnement de production limité, vous pouvez déployer plusieurs machines virtuelles hôtes Docker et les équilibrer à l’aide de l’équilibreur Azure, comme illustré dans la Figure 4-3. Cela vous permet de gérer la mise à l’échelle avec une approche grossière, car toute l’application se trouve dans un seul conteneur.

Figure 4-3. Exemple de la mise à l'échelle d'une application conteneur unique sur plusieurs hôtes

Le déploiement sur les différents hôtes peut être géré avec des techniques de déploiement traditionnelles. Les hôtes Docker peuvent être gérés avec des commandes comme docker run ou docker-compose effectuées manuellement, ou par le biais d’automatisations telles que des pipelines de livraison continue (CD).

Déploiement d’une application monolithique en tant que conteneur

Il existe des avantages à utiliser des conteneurs pour gérer les déploiements d’applications monolithiques. La mise à l’échelle des instances de conteneur est beaucoup plus rapide et plus facile que le déploiement de machines virtuelles supplémentaires. Même si vous utilisez des ensembles de machines virtuelles, les machines virtuelles mettent du temps à démarrer. Lorsqu’elle est déployée en tant qu’instances d’application traditionnelles au lieu de conteneurs, la configuration de l’application est gérée dans le cadre de la machine virtuelle, ce qui n’est pas idéal.

Le déploiement des mises à jour en tant qu’images Docker est beaucoup plus rapide et efficace sur le réseau. Les images Docker démarrent généralement en secondes, ce qui accélère le déploiement. La destruction d’une instance d’image Docker est aussi simple que l’émission d’une docker stop commande et se termine généralement en moins d’une seconde.

Étant donné que les conteneurs sont immuables par conception, vous n’avez jamais besoin de vous soucier des machines virtuelles endommagées. En revanche, les scripts de mise à jour d’une machine virtuelle peuvent oublier de tenir compte d’une configuration ou d’un fichier spécifique laissé sur le disque.

Bien que les applications monolithiques puissent tirer parti de Docker, nous touchons uniquement aux avantages. Les avantages supplémentaires de la gestion des conteneurs proviennent du déploiement avec des orchestrateurs de conteneurs, qui gèrent les différentes instances et le cycle de vie de chaque instance de conteneur. Diviser l’application monolithique en sous-systèmes qui peuvent être mis à l’échelle, développés et déployés individuellement est votre point d’entrée dans le domaine des microservices.

Publication d’une application basée sur un conteneur unique dans Azure App Service

Que vous souhaitiez obtenir la validation d’un conteneur déployé sur Azure ou lorsqu’une application est simplement une application à conteneur unique, Azure App Service offre un excellent moyen de fournir des services à conteneur unique évolutifs. L’utilisation d’Azure App Service est simple. Il fournit une excellente intégration à Git pour faciliter la prise de votre code, la générer dans Visual Studio et la déployer directement sur Azure.

Figure 4-4. Publication d’une application à conteneur unique dans Azure App Service à partir de Visual Studio 2022

Sans Docker, si vous avez besoin d’autres fonctionnalités, infrastructures ou dépendances qui ne sont pas prises en charge dans Azure App Service, vous devez attendre que l’équipe Azure ait mis à jour ces dépendances dans App Service. Vous deviez également basculer vers d’autres services comme Azure Cloud Services ou machines virtuelles, où vous aviez davantage de contrôle et que vous pouviez installer un composant ou une infrastructure requis pour votre application.

La prise en charge des conteneurs dans Visual Studio 2017 et versions ultérieures vous donne la possibilité d’inclure ce que vous souhaitez dans votre environnement d’application, comme illustré dans la figure 4-4. Étant donné que vous l’exécutez dans un conteneur, si vous ajoutez une dépendance à votre application, vous pouvez inclure la dépendance dans votre fichier Dockerfile ou votre image Docker.

Comme indiqué dans la figure 4-4, le flux de publication envoie une image via un registre de conteneurs. Il peut s’agir d’Azure Container Registry (registre proche de vos déploiements dans Azure et sécurisés par les groupes et comptes Azure Active Directory), ou tout autre registre Docker, tel que Docker Hub ou un registre local.

PrécédentSuivant