Blog de Hinault Romaric (.NET Core, ASP.NET Core, Azure, DevOps)

Conteneuriser son application .NET : quel système d’exploitation hôte choisir entre Linux, Windows Server Core et Windows Nano Server ?

Docker est venu populariser la notion de conteneur. Les développeurs s’orientent de plus en plus vers la plateforme pour leurs applications. Le gain est indéniable. Une application dans un conteneur est isolée dans une « boite » qui contient toutes les dépendances nécessaires à son exécution. Une application conteneurisée peut donc être portée et exécutée sur un autre environnement sans avoir besoin d’installation d’outils supplémentaires nécessaires à son fonctionnement. Tout est déjà inclus dans le conteneur.

De plus, gérer la scalabilité d’un conteneur est beaucoup plus facile qu’avec une machine virtuelle. Le scalling d’une application sur une VM, demande la création d’une seconde VM avec la configuration de tous les prérequis nécessaires à son fonctionnement. Et ensuite, il faudra gérer le LoadBalancing. Avec un conteneur, il suffit de dupliquer ce dernier. Cela se fait en un clic avec un orchestrateur, qui peut se positionner directement comme interface pour le LoadBalancing.


La livraison des applications conteneurisée est donc plus rapide et l’état d’exécution est identique, qu’on soit en environnement de développement, de test ou de production. La fameuse excuse « pourtant ça fonctionne dans mon environnement » n’a plus de place dans les projets.

À date, les conteneurs Docker s’exécutent uniquement sur Linux et Windows. Les images Docker Windows fonctionnent uniquement sur Windows. Les images Docker Linux s’exécutent uniquement sur un hôte Linux. Docker pour Mac utilise comme hôte Linux. De ce fait, sous OS X, vous pouvez uniquement créer des conteneurs Linux. Docker pour Windows peut utiliser comme hôte Linux et Windows. De ce fait, sous Windows, vous pouvez créer à la fois des containers Linux et Windows.

Pour le développeur qui travaille sous Windows et qui utilise Docker, il devra faire le choix en Linux et Windows pour son conteneur. S’il décide d’utiliser Windows, il devra encore choisir entre Windows Server Core et Windows Nano Server qui sont des implémentations distinctes.


Quel choix adopter en fonction des besoins de son application ? Dans ce billet, je vais donner quelques pistes qui devraient vous aider dans l’adoption de la meilleure option pour votre application .NET conteneurisée.

Docker à la base permettait d’exécuter les applications uniquement dans un hôte Linux. Face à la popularité de la solution, Microsoft a travaillé avec l’éditeur éponyme pour offrir un support de Windows.

Microsoft a d’abord offert dans un premier temps la prise en charge des conteneurs à travers son OS Windows Server Core. Ce dernier avait été lancé avec Windows Server 2008 et permettait d’installer un OS Windows Server léger, avec une interface utilisateur minimale, de meilleures performances, moins de configuration et une surface d’attaque plus petite.

Cependant, de par sa taille, Windows Server Core n’est pas vraiment adapté pour les solutions cloud et les microservices, dont l’OS doit consommer le minimum de ressources (espace disque, mémoire, etc.). C’est pourquoi Microsoft a lancé comme alternative Windows Nano Server avec Windows Server 2016.

Windows Nano Server est un OS serveur dépourvu d’interface utilisateur, qui supporte uniquement les architectures 64 bits. Nano Server est léger (soit environ 1/20^e de la taille de Windows Server Core) et embarque uniquement des composants essentiels pour son fonctionnement. Il est dépourvu par exemple du serveur Web IIS.

Lors de la conteneurisation de votre application .NET le premier choix à faire sera entre des conteneurs Windows ou des conteneurs Linux. Votre choix sera guidé dans un premier temps par la plateforme .NET sur laquelle s’exécute votre application. Si votre application nécessite le Framework .NET, cette dernière pourra fonctionner uniquement sous Windows, donc nécessitera obligatoirement des conteneurs Windows. Si l’application nécessite la disponibilité du serveur IIS, vous n’aurez pas d’autre choix que d’utiliser Windows Server Core. Par contre, pour une application .NET Core, vous avez le choix entre Linux et Windows.

Si vous êtes encore à l’étape du choix entre .NET Core et le Framework .NET, votre orientation dépendra de l’architecture, du type de l’application, des dépendances qui seront utilisées et des fonctionnalités offertes par chaque plateforme.

Mon billet de blog suivant donne de bons indicateurs pour choisir entre .NET Core et le Framework .NET. Le tableau ci-dessous offre un récapitulatif pour vous aider dans votre choix.

En ce qui me concerne, pour une application .NET Core, j’aurais une préférence pour un conteneur Linux. Les conteneurs Linux ont l’avantage de bénéficier d’un important support de la communauté avec des outils d’orchestration diversifiés et assez performants (Swarm, Kubernetes, DC/OS, etc.).

Par ailleurs, si vous souhaitez déployer votre application dans le cloud, de nombreux fournisseurs offrent des CaaS (Containers as a Service) basés sur des orchestrateurs Linux. Un CaaS offre sous forme de service les moteurs, l'orchestration et les ressources de traitement pour la gestion de ses conteneurs dans le cloud.

Si vous utilisez un CaaS par exemple chez Amazon, et que vous n’êtes pas satisfait ou que vous voulez essayer autre chose, vous pouvez aisément migrer vos images Docker vers un CaaS sur Microsoft Azure par exemple ou n’importe quel autre fournisseur de cloud qui offre ce type de service.

En dehors de Microsoft Azure qui offre la prise en charge des conteneurs Windows et l’orchestration avec Azure Service Fabric, je ne sais pas s’il existe à date un autre fournisseur de cloud qui offre une prise en charge des conteneurs Windows. De ce fait, si vous n’êtes pas satisfait du service, vous avez peu d’options pour la migration ailleurs.

Si par contre vous optez pour Windows, utilisez Windows Nano Server au lieu de Windows Server Core. Les applications ASP.NET Core, par exemple, sont self-hosted. Elles n’ont pas besoin du serveur IIS comme prérequis.

Désormais, vous êtes armé pour faire le bon choix et être en mesure de défendre celui-ci devant vos pairs. Si vous avez un point à ajouter ou tout contre-avis, il sera grandement apprécié. Vous pouvez le faire à partir des commentaires.