.NET Core vs .NET Framework pour les conteneurs Docker

Pourquoi Docker et qu’est-ce que c’est ?

Docker devient le standard de facto dans l’industrie des conteneurs et sa popularité ne cesse de croître de jour en jour. Selon Docker, plus de 3,5 millions d’applications ont été placées dans des conteneurs grâce à la technologie Docker et plus de 37 milliards d’applications conteneurisées ont été téléchargées. Vous serez surpris de voir combien de technologies populaires fonctionnent sous Docker : NGINX, Redis, Postgres, Elasticsearch, MongoDB, MySQL, RabbitMQ – et ce n’est même pas une liste exhaustive !

Il est évident que vous pouvez travailler sans Docker. De nombreuses applications fonctionnent sans lui et tout semble bien se passer. Habituellement, en coulisses, la situation est tout autre. Si vous êtes développeur ou DevOps, vous comprenez bien que ce n’est pas aussi facile et agréable qu’il y paraît à première vue. Combien de fois avez-vous travaillé sur certaines fonctionnalités et tout s’est bien passé sur votre machine locale, pour réaliser, juste après le déploiement en staging ou en production, que quelque chose n’allait pas. Avec Docker, vous n’entendrez plus jamais parler de tels problèmes, car l’application Docker packagée peut être exécutée sur n’importe quel environnement Docker pris en charge, et elle fonctionnera comme prévu sur toutes les cibles de déploiement. Vous pouvez la développer et la déboguer sur votre machine, puis la déployer sur une autre machine avec le même environnement, garanti.

Chez Redwerk, nous utilisons Docker assez souvent ces derniers temps, tant pour nos projets internes que pour ceux de nos clients. Cela dit, nous avons appris par notre propre expérience que l’utilisation de Docker peut vous faciliter la vie.

Avec l’aide de Docker, nous avons réussi à réduire le temps d’arrêt de nos sites de test lors des déploiements grâce à la capacité de Docker à utiliser le conteneur actuel pendant qu’une nouvelle construction est en cours de création. Cela est certainement utile dans divers cas : votre équipe QA n’aura pas à attendre le déploiement des nouveaux changements ; vos clients ne se rendront même pas compte que quelque chose était en cours de déploiement pendant qu’ils utilisaient votre site web. Dans le monde moderne, c’est une question assez importante.

Docker permet de regrouper une application ou un service, ses dépendances et sa configuration, sous forme d’une image de conteneur portable et autonome qui peut s’exécuter dans le cloud ou sur site. En bref, les conteneurs offrent les avantages d’isolation, de portabilité, d’agilité, d’évolutivité et de contrôle tout au long du cycle de vie de l’application. Il nous permet de regrouper nos applications avec toutes leurs dépendances dans un conteneur Docker et de les déployer facilement sur des environnements de test ou de production. Il simplifie notre processus de développement, facilite la transition du travail sur un projet vers une autre machine et permet de réduire le temps d’intégration de nouveaux développeurs dans un projet.

Docker ressemble parfois à une machine virtuelle, et il existe de nombreuses similitudes entre les deux. En particulier, ils permettent tous deux de créer une image et de la faire évoluer vers quelques instances, qui fonctionnent en toute sécurité en isolation les unes des autres. Cependant, les conteneurs présentent plus d’avantages, ce qui les rend plus appropriés pour la création et le déploiement d’applications.

Contrairement aux machines virtuelles, les conteneurs partagent le noyau du système d’exploitation et toutes les bibliothèques entre eux, ils ne nécessitent pas de système d’exploitation invité complet et s’exécutent comme des processus isolés (une exception concerne les conteneurs Hyper-V). De ce fait, ils sont faciles à déployer et démarrent très rapidement, ce qui est finalement important pour la production. De plus, les conteneurs sont plus légers que les images de machines virtuelles. Les applications conteneurisées sont faciles à faire évoluer car les conteneurs peuvent être ajoutés ou retirés rapidement d’un environnement. C’est comme instancier un processus tel qu’une application web ou un service. Les développeurs peuvent utiliser différents environnements de développement : sur Mac, Linux, vous pouvez utiliser des images Linux, sur Windows – soit Linux, soit Windows. Cela n’affecte pas la cohérence des conteneurs, ils sont donc plus portables.

Les machines virtuelles ont toujours un rôle important, car elles sont très souvent utilisées pour exécuter des conteneurs parmi des machines virtuelles – y compris lors de l’utilisation de l’infrastructure cloud de fournisseurs tels qu’Amazon, Google et Microsoft.

Terminologie Docker

Voici une courte liste de termes Docker, nécessaires pour comprendre certains détails et approfondir Docker.

Image de conteneur : les images Docker sont la base des conteneurs. Une image est une collection ordonnée de modifications du système de fichiers racine et des paramètres d’exécution correspondants à utiliser dans un environnement d’exécution de conteneur (en d’autres termes, toutes les dépendances plus la configuration de déploiement et d’exécution). Une image contient généralement une union de systèmes de fichiers en couches empilées les unes sur les autres. Une image est immuable et n’a pas d’état.

Conteneur : est une instance d’exécution d’une image Docker. Il se compose d’une image, d’un environnement d’exécution et d’un ensemble standard d’instructions. Selon Docker, le concept est emprunté aux conteneurs maritimes, qui définissent une norme pour l’expédition de marchandises à l’échelle mondiale. Docker définit une norme pour l’expédition de logiciels.

Tag : une étiquette que vous pouvez appliquer aux images afin de distinguer différentes images ou versions dans un dépôt.

Dockerfile : un document texte contenant toutes les commandes que vous exécuteriez normalement manuellement pour construire une image Docker. Les images peuvent être construites automatiquement par Docker, en utilisant ces instructions.

Dépôt : est un ensemble d’images Docker. Un dépôt peut être partagé en le poussant vers un serveur de registre. Il peut contenir plusieurs variantes d’une image spécifique (variantes de plateforme, variantes plus lourdes ou plus légères d’une image).

Docker Hub : est une ressource centralisée pour travailler avec Docker et ses composants. Il fournit l’hébergement d’images, l’authentification utilisateur, les constructions d’images automatisées et des outils de flux de travail (comme les déclencheurs de build et les webhooks), l’intégration avec GitHub et Bitbucket.

Kitematic : une interface graphique héritée, fournie avec Docker Toolbox, pour gérer les conteneurs Docker.

Cluster : une collection d’hôtes Docker exposés comme un seul. Peut être créé avec Docker Swarm, Mesosphere DC/OS, Kubernetes et Azure Service Fabric.

Orchestrateur : un outil qui simplifie la gestion des clusters et des hôtes Docker. Les orchestrateurs incluent un certain nombre de fonctionnalités qui permettent de gérer les images, les conteneurs et les hôtes, la mise en réseau des conteneurs, les configurations, l’équilibrage de charge, la découverte de services, la haute disponibilité, et plus encore. Typiquement, les produits d’orchestration sont les mêmes produits qui fournissent l’infrastructure de cluster.

.NET Core vs .NET Framework pour les conteneurs Docker

Il existe deux frameworks pris en charge pour la création d’applications Docker côté serveur conteneurisées avec .NET : .NET Framework et .NET Core. Il existe des différences fondamentales entre les deux, et la réponse à la question “Quel framework doit être utilisé ?” dépendra de ce que vous voulez accomplir. Alors, parlons de ce qu’il faut choisir – .NET Core ou .NET Framework pour les conteneurs Docker.

Quand .NET Core doit être utilisé pour les conteneurs Docker

La réponse la plus rapide sera basée sur les avantages énumérés ci-dessus : vous devriez évidemment choisir .NET Core si vous avez besoin d’une plateforme multiplateforme, rapide et légère, et si votre architecture d’application est basée sur des microservices. Mais approfondissons les détails.

Ainsi, le premier point est que vous devriez utiliser .NET Core si votre objectif est d’avoir une application qui peut s’exécuter sur plusieurs plateformes. Pas besoin d’explications : si vous avez besoin de déployer des applications serveur avec des images de conteneurs Linux ou Windows, votre choix est évident.

Deuxièmement, lorsque votre objectif est de créer et de déployer des microservices sur des conteneurs, votre choix privilégié est .NET Core. Et encore une fois, cela peut s’expliquer par la légèreté de la plateforme. Un microservice est destiné à être aussi petit que possible : léger au démarrage, avec une petite empreinte, un petit Contexte Délimité, représentant une petite zone de préoccupations, et capable de démarrer et de s’arrêter rapidement. Pour ces exigences, vous voudrez utiliser des images de conteneurs petites et rapides à instancier, comme l’image de conteneur .NET Core. En revanche, pour utiliser .NET Framework pour un conteneur, vous devez baser votre image uniquement sur l’image Windows Server Core, qui est beaucoup plus lourde que les images Windows Nano Server ou Linux que vous utilisez pour .NET Core.

Troisièmement, s’il est important pour vous d’avoir des mises à jour régulières des packages. Étant donné que votre projet a des mises à jour régulières, économisant ainsi de l’argent et réduisant les risques, ce point revêt une importance capitale. .NET Core offre la possibilité d’installer différentes versions du runtime sur la même machine. Cet avantage est plus important pour les serveurs ou les VM qui n’utilisent pas de conteneurs, car les conteneurs isolent les versions de .NET dont l’application a besoin. Bien sûr, s’ils sont compatibles avec le système d’exploitation sous-jacent.

Enfin, et ce n’est pas le moins important, si vous avez un site web basé sur des conteneurs, votre meilleur choix sera .NET Core et ASP.NET Core pour la pile technologique afin d’obtenir la meilleure densité, granularité et performance possibles pour votre système. ASP.NET Core est jusqu’à dix fois plus rapide qu’ASP.NET dans le .NET Framework traditionnel. Et, de plus, pour les architectures de microservices, c’est particulièrement pertinent. Lorsque vous avez des centaines de microservices (conteneurs) en cours d’exécution, ou que vous prévoyez d’augmenter leur nombre à l’avenir, avec des images ASP.NET Core (basées sur le runtime .NET Core) sur Linux ou Windows Nano, vous pouvez exécuter votre système avec un nombre beaucoup plus faible de serveurs ou de VM, ce qui permet d’économiser des coûts d’infrastructure et d’hébergement.

Quand .NET Framework doit être utilisé pour les conteneurs Docker

.NET Core présente de nombreux avantages, mais malgré cela, .NET Framework reste un bon choix pour de nombreux scénarios existants.

Certains packages NuGet nécessitent Windows pour s’exécuter et pourraient ne pas prendre en charge .NET Core. Et bien que les bibliothèques tierces adoptent rapidement .NET Standard, qui permet le partage de code entre toutes les saveurs de .NET, y compris .NET Core, ce problème existe toujours. Si ces packages sont critiques pour votre application et fortement requis, vous devrez alors utiliser .NET Framework sur des conteneurs Windows. Pour certains packages, le problème est déjà résolu, car le Windows Compatibility Pack a été récemment publié pour étendre la surface d’API disponible pour .NET Standard 2.0 sous Windows. Ce pack permet de recompiler la plupart du code existant en .NET Standard 2.x avec peu ou pas de modifications, pour s’exécuter sous Windows. Mais il existe toujours une chance que votre package spécifique ne soit pas compatible, et dans cette situation, votre choix est définitivement .NET Framework.

Certaines technologies .NET Framework ne sont pas disponibles dans la version actuelle de .NET Core (version 2.1 au moment de la rédaction). Certaines seront disponibles dans des versions ultérieures, mais d’autres pourraient ne jamais l’être. Voici la liste officielle des technologies les plus courantes qui ne se trouvent pas dans .NET Core de Microsoft :

• Applications ASP.NET Web Forms : ASP.NET Web Forms est uniquement disponible dans .NET Framework et ASP.NET Core ne peut pas être utilisé pour elles. Il n’est pas prévu d’intégrer ASP.NET Web Forms à .NET Core.
• Applications ASP.NET Web Pages : elles ne sont pas incluses dans ASP.NET Core. Les pages Razor ASP.NET Core ont de nombreuses similitudes avec Web Pages.
• Implémentation des services WCF. Même s’il existe une bibliothèque WCF-Client pour consommer des services WCF à partir de .NET Core, l’implémentation serveur WCF n’est actuellement disponible que dans .NET Framework. Ce scénario ne fait pas partie du plan actuel pour .NET Core, mais il est envisagé pour l’avenir.
• Services liés au workflow : Windows Workflow Foundation, Workflow Services (WCF + WF dans un seul service) et WCF Data Services ne sont disponibles que dans .NET Framework. Il n’est pas prévu de les intégrer à .NET Core.
• Support linguistique : Visual Basic et F# sont actuellement pris en charge dans .NET Core, mais pas pour tous les types de projets. Ils sont tous deux pris en charge (au moment de la rédaction) pour l’application Console, la bibliothèque de classes classlib, le projet de test unitaire mstest, le projet de test xUnit. Et F# est également pris en charge pour ASP.NET Core vide, ASP.NET Core Web App (Model-View-Controller) et ASP.NET Core Web API. Tous les autres ne sont pas pris en charge.

Et évidemment, si vous avez un projet stable, sans besoin d’extension et qui ne pose aucun problème pour l’instant, vous n’avez vraiment pas besoin de migrer votre projet vers .NET Core. Une approche recommandée est d’utiliser .NET Core lors de l’extension d’une application existante, comme l’écriture d’un nouveau service en ASP.NET Core. Vous pourriez utiliser des conteneurs Docker uniquement pour simplifier le déploiement. Par exemple, les conteneurs offrent de meilleurs environnements de test isolés et peuvent également éliminer les problèmes de déploiement causés par des dépendances manquantes lors du passage à un environnement de production. Dans de tels cas, il est logique d’utiliser Docker et des conteneurs Windows pour vos applications .NET Framework actuelles.

Alors, pourquoi .NET Core est-il si génial ?

Maintenant que nous avons discuté des principaux avantages et inconvénients des deux frameworks, nous souhaitons partager quelques détails supplémentaires sur les raisons pour lesquelles .NET Core est si performant et ce que vous devez savoir pour travailler avec.

La plateforme .NET a été introduite en 2002 et a subi d’énormes transformations depuis lors. Pendant longtemps, .NET était un environnement multiplateforme, mais pas cross-platform et principalement axé sur Windows.

.NET Core a été un nouveau souffle pour la plateforme .NET. Il a été entièrement réécrit à partir de zéro pour être un framework open source, modulaire, léger et cross-platform pour la création d’applications et de services web qui s’exécutent sur Windows, Linux et Mac. Voici les faits clés que vous devez connaître sur .NET Core de Microsoft.

.NET Core est cross-platform. Si vous avez l’habitude de penser que la plateforme .NET est conçue uniquement pour Windows, alors maintenant, avec .NET Core, la réalité change. Ce framework s’exécute déjà sous Windows, Mac OS X et Linux. Dans notre entreprise, nous avons un projet ASP.NET Core réussi, au sein duquel notre équipe utilise différentes plateformes OS : l’équipe frontend utilise le système d’exploitation Linux pour le développement, l’un de nos développeurs backend utilise MacOS, et deux autres développeurs travaillent sur des machines Windows. Et tout fonctionne comme un mécanisme d’horlogerie, sans accroc, comme si tout le monde avait le même système d’exploitation. Si cela aurait semblé incroyable il y a quelques années, c’est aujourd’hui une réalité. Bien sûr, certains composants individuels, par exemple, des éléments spécifiques à l’OS comme le système de fichiers, nécessitent une implémentation distincte. Le modèle de livraison via NuGet permet d’effacer ces différences. Pour les développeurs, il s’agit d’une API unique qui s’exécute sur différentes plateformes, ils n’ont pas à s’en soucier, car le package contient déjà différentes implémentations pour chacun des environnements.

Dans notre entreprise, nous avons quelques projets ASP.NET Core réussis, au sein desquels notre équipe utilise différentes plateformes OS : l’équipe frontend utilise le système d’exploitation Linux pour le développement, l’un de nos développeurs backend utilise MacOS, et deux autres développeurs travaillent sur des machines Windows. Et tout fonctionne comme un mécanisme d’horlogerie, sans accroc, comme si tout le monde avait le même système d’exploitation. Si cela aurait semblé incroyable il y a quelques années, c’est aujourd’hui une réalité.

Support des conteneurs. La modularité et la légèreté de .NET Core le rendent parfait pour les conteneurs. Il est optimisé pour les charges de travail spécifiques au cloud, et Microsoft Azure prend même en charge le déploiement de votre application dans des conteneurs et Kubernetes. Lorsque vous créez et déployez un conteneur, son image est beaucoup plus petite avec .NET Core qu’avec .NET Framework. Et en plus, il correspond mieux à la philosophie et au style de travail des conteneurs.

.NET Core est open-source. L’utilisation d’une plateforme open source présente de nombreux avantages : elle est plus transparente, vous avez plus de contrôle dans son utilisation et sa modification, et elle offre évidemment un écosystème plus solide.

Haute performance. .NET Core est aussi le .NET le plus rapide jamais conçu. Et le meilleur dans tout ça, c’est que vous n’avez pas besoin de modifier votre code. Le compilateur optimisera naturellement votre code avec les nouvelles améliorations du langage. Le nouveau serveur web Kestrel a été repensé à partir de zéro pour tirer parti des modèles de programmation asynchrones, être plus léger et rapide. La combinaison de Kestrel et d’ASP.NET Core s’est avérée être plusieurs fois plus rapide.

Ceci n’est qu’un aperçu très rapide de toutes les excellentes fonctionnalités de .NET Core.

Dans cet article, nous avons essayé d’expliquer certains détails de Docker et de la plateforme .NET Core, de montrer les avantages de l’utilisation de Docker avec .NET Core et d’aider les développeurs à choisir la bonne plateforme pour développer. Pour résumer, le tableau de décision suivant, fourni par Microsoft, résume s’il faut utiliser .NET Framework ou .NET Core. N’oubliez pas que pour les conteneurs Linux, vous avez besoin d’hôtes Docker basés sur Linux (VM ou serveurs) et que pour les conteneurs Windows, vous avez besoin d’hôtes Docker basés sur Windows Server (VM ou serveurs).

À propos de Redwerk

Notre équipe comprend des programmeurs ASP.NET qui possèdent une solide expérience dans la création d’applications sur des plateformes Microsoft. En tant qu’agence de sous-traitance en développement logiciel, nous fournissons des services complets de développement concernant le E-commerce, l’automatisation des entreprises, la e-santé, les médias et divertissement, le e-gouvernement, le développement de jeux, les startups et l’innovation. Plus d’une décennie d’expérience avec des centaines de projets réussis – c’est l’entreprise de développement logiciel Microsoft Redwerk.

Découvrez comment nous avons développé une solution de logistique fitness claire en utilisant le framework .NET

Veuillez saisir votre adresse courriel professionnelle n'est pas un courriel professionnel

Obtenir l'étude de cas