Quand choisir .NET pour les conteneurs Docker
Conseil
Ce contenu est un extrait du livre électronique « .NET Microservices Architecture for Containerized .NET Applications », disponible sur .NET Docs ou sous forme de PDF téléchargeable gratuitement et pouvant être lu hors ligne.
La modularité et la légèreté de .NET 8 en font l’outil idéal pour des conteneurs. Lorsque vous déployez et démarrez un conteneur, son image est beaucoup plus petite avec .NET 8 qu’avec .NET Framework. En revanche, si vous souhaitez utiliser .NET Framework pour un conteneur, vous devez baser votre image sur l’image Windows Server Core qui est beaucoup plus lourde que les images Windows Nano Server ou Linux utilisées pour .NET 8.
En outre, .NET 8 étant multiplateforme, vous pouvez déployer des applications serveur avec des images conteneur Linux ou Windows. Cependant, si vous utilisez le .NET Framework classique, vous pouvez déployer uniquement des images basées sur Windows Server Core.
Vous trouverez ci-dessous une explication plus détaillée sur les raisons de choisir .NET 8.
Développement et déploiement multiplateformes
De toute évidence, si votre objectif est d’avoir une application (application ou service web) capable de s’exécuter sur plusieurs plateformes prises en charge par Docker (Linux et Windows), .NET 8 est le bon choix, car .NET Framework prend uniquement en charge Windows.
.NET 8 prend également en charge macOS comme plateforme de développement. Cependant, quand vous déployez des conteneurs sur un hôte Docker, celui-ci doit (à ce moment-là) être basé sur Windows ou Linux. Par exemple, dans un environnement de développement, vous pouvez utiliser une machine virtuelle Linux s’exécutant sur un Mac.
Visual Studio propose un environnement de développement intégré (IDE) pour Windows et prend en charge le développement Docker.
Vous pouvez aussi utiliser Visual Studio Code sur macOS, Linux et Windows. Visual Studio Code prend entièrement en charge .NET 8, notamment IntelliSense et le débogage. VS Code étant un éditeur léger, vous pouvez l’utiliser pour développer des applications en conteneur sur la machine en association avec l’interface CLI Docker et l’interface CLI .NET. Vous pouvez également cibler .NET 8 avec la plupart des éditeurs tiers comme Sublime, Emacs, vi, ainsi que le projet open source OmniSharp qui fournit lui aussi une prise en charge d’IntelliSense.
En plus des IDE et des éditeurs, vous pouvez utiliser l’interface CLI .NET pour toutes les plateformes prises en charge.
Utilisation de conteneurs pour les nouveaux projets (« green-field »)
Les conteneurs sont couramment utilisés avec une architecture de microservices, même s’ils peuvent aussi servir à organiser en conteneurs les services ou applications web qui suivent un modèle d’architecture. Vous pouvez utiliser .NET Framework dans des conteneurs Windows, mais par sa modularité et sa légèreté, .NET 8 est parfait pour des conteneurs et des architectures de microservices. Quand vous créez et déployez un conteneur, son image est beaucoup plus petite avec .NET 8 qu’avec .NET Framework.
Créer et déployer des microservices sur des conteneurs
Vous pouvez utiliser le .NET Framework classique pour créer des applications basées sur des microservices (sans conteneurs) en suivant des processus ordinaires. De cette façon, comme .NET Framework est déjà installé et partagé entre les processus, ceux-ci démarrent rapidement du fait de leur légèreté. En revanche, si vous utilisez des conteneurs, l’image pour le .NET Framework classique est aussi basée sur Windows Server Core, ce qui la rend trop lourde pour une approche de microservices dans des conteneurs. Toutefois, les équipes cherchent également des opportunités pour améliorer l’expérience des utilisateurs du .NET Framework. Récemment, la taille des images conteneur Windows Server Core a été réduite de >40 %.
En revanche, .NET 8 est le meilleur choix si vous adoptez un système orienté vers des microservices basé sur des conteneurs, car .NET 8 est léger. De plus, les images de conteneur qui lui sont associées, que ce soit Linux ou Windows Nano Server, sont légères et petites, ce qui permet aux conteneurs de démarrer rapidement.
Un microservice doit être le petit possible de façon à être léger pendant son exécution, à offrir un faible encombrement, à présenter un contexte limité réduit (voir DDD, Conception pilotée par le modèle), à ne pas être une source de problèmes et à démarrer et à s’arrêter rapidement. Pour respecter ces exigences, vous devez utiliser des images conteneur petites et rapides à instancier comme de l’image conteneur .NET 8.
Une architecture de microservices permet aussi de combiner des technologies au-delà des limites d’un service. Cette approche permet une migration progressive vers .NET 8 pour de nouveaux microservices qui fonctionnent conjointement avec d’autres microservices ou des services développés avec Node.js, Python, Java, GoLang ou d’autres technologies.
Déploiement de la haute densité dans des systèmes scalables
Quand votre système basé sur des conteneurs a besoin d’une densité, d’une granularité et de performances optimales, .NET et ASP.NET Core constituent les meilleures options. ASP.NET Core est jusqu’à dix fois plus rapide qu’ASP.NET dans le .NET Framework classique et il devance les autres technologies courantes pour les microservices, telles que les servlets Java, Go et Node.js.
Cette approche est particulièrement intéressante pour les architectures de microservices dans lesquelles plusieurs centaines de microservices (conteneurs) peuvent s’exécuter simultanément. Avec des images ASP.NET Core (basées sur le runtime .NET) sur Linux ou Windows Nano, vous pouvez exécuter votre système avec beaucoup moins de serveurs ou de machines virtuelles, ce qui en fin de compte vous permet de réaliser des économies en infrastructure et hébergement.
