L’essentiel sur Docker et les conteneurs Windows

Le support de Docker est une des principales nouveautés de Windows Server 2016, et maintenant qu’il est possible de conteneuriser nos bonnes vieilles applications ASP.net ainsi que toutes les nouvelles sous .net Core, je vous propose un petit tour de toutes les notions essentielles pour comprendre Docker et les conteneurs Windows.

windows-10-docker

Afin de ne pas se laisser distancer par Linux sur le marché des serveurs, Microsoft a conclu un partenariat avec Docker, leader de la conteneurisation sous Linux, afin d’implémenter la même possibilité sous Windows. 2 ans de développement en commun plus tard, nous pouvons enfin profiter de ceci afin d’héberger nos applications On-Premise, en IaaS, ou via services cloud d’hébergement de conteneurs.

Les conteneurs

image

On compare souvent les conteneurs à de la virtualisation d’OS. Ainsi au lieu de virtualiser tout le matériel d’une machine (CPU, RAM, Disques, carte réseau, etc.),  un conteneur permet de faire fonctionner une application au sein d’un environnement isolé où la couche hardware utilisée correspond à celle de la machine hôte du conteneur, mais également où le kernel de la machine hôte est partagé par tous les conteneurs en cours d’exécution.

L’idée est de proposer un environnement d’exécution isolé sans payer le coût lié à l’hébergement d’une VM, et ainsi  de parvenir à héberger un nombre beaucoup plus important d’applicatifs isolés au sein d’une machine hôte.

Les containers permettent également d’avoir une grande souplesse au sujet du type de déploiement que pouvez effectué. Déployer votre application sur un serveur physique, dans une VM, ou encore sur le Cloud se fait de manière extrêmement simple puisqu’il vous suffit de déployer votre conteneur où vous le souhaitez pour avoir une application fonctionnelle, sans réinstallation logicielle, ni paramétrage.

Différents niveaux d’isolations sont proposés sous Windows Server 2016.

Les conteneurs Windows

Avec ce niveau d’isolation, chaque conteneur partage le kernel de la machine hôte. Ainsi, il est uniquement possible de faire fonctionner des conteneurs Windows au sein d’un serveur fonctionnant lui-même sous Windows, et ayant la même version de kernel.

Les conteneurs Hyper-V

Un niveau d’isolation supplémentaire est possible grâce aux conteneurs Hyper-V. Les conteneurs Hyper-V nécessitent un hyperviseur Hyper-V, Une petite VM est automatiquement créé et démarrée lorsque vous souhaitez démarrer votre conteneur.

Le kernel n’est donc plus partagée entre conteneurs, mais reste propre à chaque conteneur.

Autre avantage, vous pouvez faire fonctionner un conteneur Linux sous Windows grâce à ce niveau d’isolation.

Les images Docker

image

Les conteneurs sont basés sur des images qui contiennent :

  • Une image de l’OS souhaité. Même si le conteneur partage le même kernel que la machine hôte, on s’assure ainsi d’utiliser une image “propre” indépendante de la machine hôte, et non polluée par les différents drivers et logiciel du constructeur de votre serveur
  • Le ou les frameworks applicatifs souhaités
  • Et bien évidemment votre application !

Les images sont construites grâce à un fichier Dockerfile qui permet de définir l’image de base utilisée, et qui permet d’exécuter différentes commandes pour installer votre application et ses dépendances, et effectuer différents paramétrages.

Les couches

Cela signifie-t-il qu’en plus de mon application web (par exemple packagée via un package webdeploy) je dois en plus uploader et télécharger toute une image de Windows ?

Au lieu d’avoir une application de 50Mo, je me donc retrouve avec une image de plusieurs Go ?

Oui, et non (et même surtout non). Il est certes nécessaire de packager l’application au sein d’une image Docker qui contient l’image de l’OS et qui pèse donc au total assez lourd, mais il n’est pas pourtant nécessaire de télécharger l’intégralité de tout cela pour déployer une application.

Les images Docker reposent en effet sur un principe de couches, chaque instruction d’un fichier dockerfile créé en effet une couche au dessus des modifications déjà effectuées.

docker-layers

Lorsque l’on souhaite récupérer une image, Docker va donc récupérer celle-ci, couche par couche en commençant par l’image de base de l’OS. Et bien évidemment si la ou les couches sous-jacentes à la dernière couche de votre image sont déjà disponibles sur votre ordinateur, Docker ne les récupèrera pas de nouveau.

Ainsi si vous avez différentes images basées sur l’image microsoft/windowservercore, vous n’aurez pas à récupérer les 4Go de celle-ci à chaque fois, vous récupèrerez uniquement les couches qui ne sont pas encore disponible sur la machine hôte.

Les images de base

D’un point de vue OS, Microsoft propose deux images de base de Windows Server, une pour Windows Server Core qui pèse 4 Go en compressé, et une autre pour la nouvelle version “ultra-light” de Windows nommée Windows Nano Server. Celle-ci pèse 300Mo compressée.

Windows Nano Server correspond à un important travail de refactoring de Windows et de suppression de différents services considérés comme étant inutiles pour ce type de serveur.

Vous pouvez apprécier avec le schéma ci-dessous le résultat de cet effort de réduction :

image

25 fois plus petit qu’un Windows Server classique,  et avec une image Docker 10 fois plus petite que Windows Server Core, Windows Nano Server est l’édition indispensable pour bénéficier d’une empreinte la plus petite possible.

Ces deux images sont disponibles comme beaucoup d’autres images sur le hub de docker. Docker Hub est une bibliothèque d’images Docker, les plus grandes sociétés et éditeurs mettent à disposition leurs images Docker directement sur ce service qui permet d’héberger des images publiques mais également privées.

Il est important de noter que des images de base contenant uniquement des OS sont disponibles mais également des images contenant des frameworks applicatifs déjà installés. Il n’est donc pas nécessaire de se baser sur une image “nue”, le plus simple est de partir sur l’image correspondant le plus à votre besoin.

Le choix entre Windows Server Core et Windows Nano Server va essentiellement se faire en fonction de l’applicatif que vous souhaitez conteneuriser. Les deux éditions sont effet loin d’être iso-fonctionnelles et vous devrez faire votre choix en fonction des dépendances de votre application.

Ainsi si vous souhaitez déployer une application ASP.net WebForms ou MVC et donc basée sur le framework .net classique, vous devrez impérativement utiliser Windows Server Core car le framework .net n’est pas supporté sur Nano Server.

A contrario, si vous déployez une application ASP.net Core, Windows Nano Server, plus léger sera probablement votre choix de prédilection.

D’un point de vue Licensing

D’un point de vue Licensing tout est décrit dans le tableau ci-dessous :

image

Comme vous pouvez le voir, il est important de noter la limitation à deux conteneurs Hyper-V en édition standard alors que les conteneurs Windows sont eux, illimités.

Du côté du cloud

Côté cloud, que cela soit sur Microsoft Azure ou sur le cloud d’Amazon, il est pour le moment nécessaire de passer par des offres IaaS et donc d’avoir un host sous forme de VM pour héberger des conteneurs Windows. Les deux fournisseurs fournissent le même type d’image Windows Server 2016 with Containers qui proposent une instance de Windows Server 2016 avec les fonctionnalités de conteneurisation déjà installées et fonctionnelles.

Les services d’hébergement de conteneurs ne peuvent héberger que des conteneurs Linux chez ces deux fournisseurs de cloud.

Une preview privée est en cours sur le service Azure Container Service, et Amazon à annoncé le support des conteneurs Windows d’ici la fin de l’année 2016.

Il va donc falloir patienter un petit peu pour profiter d’un service dédié probablement moins coûteux qu’un service d’IaaS.

 

Rendez-vous pour un prochain post sur Docker afin d’aborder le déploiement d’applications d’ASP.net par la pratique !

2 réflexions au sujet de « L’essentiel sur Docker et les conteneurs Windows »

  1. Ping : L’essentiel de Docker : Débuter par la pratique - Blog de Patrice Lamarche

  2. Ping : Blog de Patrice Lamarche -

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *