Partagez l'article

Connexion






Mot de passe oublié ?
Identifiant oublié ?
Pas encore inscrit ? Créer un compte

Up-coming events

There are no up-coming events

Nouveautés Windows 2016 - Hyper-V Container PDF Imprimer Envoyer
Note des utilisateurs: / 25
MauvaisTrès bien 
Écrit par Cédric Bravo   

Nouveautés Windows Server 2016 Hyper-V

Windows container et Hyper-V container

docker logo

Toujours plus haut, toujours plus loin, Windows Server 2016 apporte de très nombreuses nouveautés en ce qui concerne la virtualisation et l'intégration Cloud.
Cette série d'article propose de mettre le focus sur différentes nouveautés (et elles sont très nombreuses). Aujourd'hui Hyper-V Container.

Il n'est pas possible de parler de Hyper-V container sans parler de Docker.


Rappel :
En octobre 2014, Microsoft Corp et Docker annonçaient la mise en œuvre d'un partenariat stratégique visant à intégrer la technologie Docker directement dans Windows Server Vnext.

 

La "containarisation", c'est quoi ?

La containarisation est un concept issu des technologies de virtualisation applicative développée sous Linux depuis de nombreuses années et popularisé par Docker.

Comme nous le notions déjà dans notre article parut dans le hors série ITPro.fr des techdays 2015, une même application peut avoir à s’exécuter dans des environnements très différents, ce qui représente un casse tête pour les développeurs. Ceux ci doivent réfléchir à la manière de délivrer leurs applications sur des machines qui n’auront pas forcément les mêmes caractéristiques ou les mêmes prérequis.

Le « packaging », c’est-à-dire la manière dont l’application va être distribuée et installée représente dès lors un coût non négligeable (et très franchement, c'est une activité que les développeurs détestent).

La containerisation pourquoi ? (DevOps, vous avez dit DevOps ?)

Le principal interêt des container, c'est l'agilité. Créer un container et le mettre en production, c'est très, très rapide!

Les développeurs peuvent désormais fournir un unique "package" qui s'exécutrea exactement de la même manière quelle que soit la plateforme, Linux, Azure ou AWS... (Enfin en théorie... Cf. Les limites.)

Une fois les images publiées dans le repository, les IT n'ont plus qu'a automatiser la mise en production.
Un problème avec la nouvelle version ? Un bug dans l'application ? Il suffit d'effectuer un rollback en instanciant un container de la version N-1.

Bien sur, ce mode de fonctionnement nécessite de revoir en profondeur les notions d'architecture que nous appliquons aujourd'hui pour prendre en compte la persistence des données (containers Stateless et Statefull).

Container DevOps

 

Il est impossible de parler des containers sous Windows, sans faire un petit passage par la case Docker.
Le projet Docker s'adresse en premier lieu aux développeurs et se présentant comme un framework d'outils pour packager, distribuer et exécuter les applications quel que soit l'environnement.

 

Docker, comment ça marche ?

La virtualisation utilisée par Docker est différente de ce que nous connaissons avec Microsoft App-V ou Vmware ThinApp. Comme avec App-V ou ThinApp, une application "Dockerisée" dispose de sa propre registry, librairie, file system etc... mais détail important, elle dispose de sa propre identité réseau (Sa propre IP, ses propres tables de routages etc..) !
En ce sens, un "container" est d'un point de vue conceptuel assez semblable à une machine virtuelle, et il est bien probable que l'on finisse par se poser la question suivante... "Je fais une VM ou un Container ?"

 

Inside Docker.

Le framework Docker est composée des éléments suivants :

  • Un client qui permet de piloter le service Docker (Docker Daemon). Le client peut être local ou non. C'est le client qui permet de créer, lancer, stopper, publier etc.. vos container.
  • Un "Docker host", qui est l'environnement d'exécution du Service Docker (c'est à dire un système d'exploitation).
  • Une registry, à ne surtout pas confondre avec la registry de Windows ! La registry est en réalité une librairie d'images, un repository central utilisé par le Docker Daemon. Il existe une registry publique (le Docker Hub) avec des milliers d'images déjà disponibles.
  • Des images, qui sont des templates en lecture seule. Vous pouvez par exemple disposer d'une image contentant un OS Ubuntu avec apache et vos applications déjà installées. Ce sont les images qui sont utilisées pour "instancier" les containers.
  • Les containers sont des instances en lecture écriture des images. Les containers contiennent tout ce qu'il faut à une application pour tourner.

docker Architecture


Nous avons donc un template en lecture seule (l'image) et un container en lecture écriture. Ceci peut fortement nous faire penser aux disques différentiel n'est ce pas ? Et bien c'est le même principe, le système de fichier permet de générer une relation "parent / enfants" de la même manière. En outre, il est possible de créer de nouvelles images à partir d'image existantes. L'image résultante ne contiendra que les différences.

Les limites.

Comme nous l'avons vu précedment, les containers sont d'un point de vue conceptuel assez similaire à des machines virtuelle.

  • Ils disposent de leur propre identité réseau (Il est conseillé de disposer d'un serveur DHCP, car chaque démarrage d'un container nécessite sa propre IP).
  • Ils permettent d'isoler l'exécution des applications les unes par rapport aux autres.

Cependant, certaines limitations importantes sont à noter.

  • Les containers doivent utiliser le même kernel que le Host.
    Il existe de nombreuses dépendances entre le moteur Docker et le Kernel du Docker Host, il n'est pas possible de faire tourner des containers issus d'images avec un noyau différent.

    • Ex : Il n'est pas possible de faire tourner un Container Linux sur un Docker Host Windows et vice et versa. Pour résoudre ce problème, il faut utiliser des machines virtuelles...

  • Les containers ne sont pas fait pour du multi-tenant.
    La surface de contact entre les containers et le kernel du host est importante. Ceci rend plus vulnérable les containers à une attaque autorisant l'accès à l'Hote. Pour résoudre ce problème, il suffit de faire tourner sont Docker Host dans une VM. Les machines virtuelles offrent un exélent niveau d'isolation.

  • L'overhead.
    Si il est possible de réduire une machine exécutant un serveur mail, relay SMTP, Antivirus, Antispam, Authentification etc... à une suite de "micro services" en container, les interactions entres les containers vont introduire de la complexité et un certain overhead. La manière de concevoir les applications et les infrastructures dont prendre en compte ces nouvelles architectures orientées "micro services".

 

Windows et Hyper-V Container

Nous y voila ! Vous l'aurez compris, Windows Server 2016 va intégrer nativement le framework Docker. Il sera donc possible d'y faire tourner des containers Windows, à partir notamment d'une image Nano Server !

Comme nous l'avons vu, les limitations actuelles de la technologie nécessitent que le "Docker Host" utilise la même version de Kernel que le container. On fera donc tourner les container "Windows Server" sur un host "Windows Server". 

De plus, nous avons vu aussi que les containers ne sont pas une bonne solution dans un contexte d'isolation multi-tenant... C'est là que les Hyper-V container rentrent en lisse.

 

Hyper-Vcontainer

 

Comme leur nom le laisse présager, les Hyper-V container nécessitent le rôle Hyper-V, et pour cause, les hyper-V container vont utiliser la technologie Hyper-V pour assurer l'isolation vis à vis du host. Cette isolation ouvre la voie à des scénarios de co-location multi tenant.

Les Hyper-V container seront instanciés et gérés de la même manière qu'un container classique via le service VMMS (Virtual Machine Management Service). De fait, l'expérience utilisateur sera la même, selon que l'on manipule un container classique ou un Hyper-V container.

 

Alors comment fonctionnent les Hyper-V container ?

Microsoft n'a pas révélé le mode de foncitonnement des Hyper-V container, cependant, on peut emmettre quelques hypothèses.

  • Le principe d'isolation des hyperviseurs est basés sur des partitions (Enfants / Parents).
  • Le service Docker (Docker Daemon) a besoin d'un environnement d'exécution pour tourner.
  • Les containers s'exécutent en mode utilisateur.

A partir ce là, on peut tout à fait imaginer un bootstrap dont le rôle est d'instancier un moteur docker. Ce bootstrap serait en réalité une machine virtuelle réduite à sa plus simple expression, uniquement chargée en mémoire, bootant sur une image Iso et ne consomant que quelques dizaine de Mo de mémoire... 

De là à penser que Nano Server ferait un bon Bootstrap, l'avenir nous le dira :)

Dans un premier temps, on ne sait pas si les Hyper-V Container prendront en charge les container Linux, Microsoft confesse mettre le focus sur Windows pour le moment, mais cet article sur Boot2Docker pourrait vous mettre la puce à l'oreille ;)

Boot2Docker est une machine virtuelle spécifiquement conçue pour faire tourner le Docker Engine. Elle est chargée uniquement en mémoire (27mo) et boot en 5s... ça donne des idées.

D'un point de vue technique, ça devrait donner un peu près cela.

Note de l'auteur : Le schéma suivant illustre une probable architecture des Hyper-V Container (Totalement non officielle et totalement supposée)

Probable architecture 
Not Official & Totaly Suposed Architecture

 

Note : Autre indice, la fonctionalités Powershell Direct qui permet d'exécuter des commandes directement dans la machine virtuelle a été développée pour les besoins des Hyper-V Container :)

 

Et le cloud dans tout ça ?

Si vous avez suivit l'actualité, vous n'aurez pas manqué qu'il est désormais possible d'installer Hyper-V dans Hyper-V. Les IT sont désormais ravis, nous allons enfin pouvoir enrichir nos labs ! Mais saviez vous que cette fonctionalités a aussi été apportée pour permettre le déploiement des Hyper-V container dans Azure ?

Attention, le syndrome Inception nous guette ;)

 

Pour aller plus loin, nous vous conseillons la consultation des documents suivants :

Mise à jour le Mardi, 20 Septembre 2016 10:32
 
Bannière

Joomla! is Free Software released under the GNU/GPL License.