Containers ou VM ?

Containers ou VM : que choisir ?

Pour simplifier la vision d’un container, on peut dire que cela correspond à un état spécifique du système d’exploitation sous-jacent qui serait sélectionné et exécuté en tant que Version X au sein de sa propre bulle virtuelle. Ainsi, par exemple, vous pouvez exécuter un container basé sur une image X de Windows Server 2016, ajouter une application intégrée dans un autre container, modifier certains paramètres, puis sauvegarder l’ensemble dans une nouvelle Version Y.

Au final, le container n’est pas une VM mais juste un ensemble de paramètres et de pointeurs reposant sur une couche d’abstraction présentant uniquement les fonctionnalités du système d’exploitation sous-jacent dont ont besoin les containers. Bien sûr, cela ne permet pas au container de disposer du même niveau d’isolation ni à la même portabilité qu’une VM, mais il sera très supérieur en termes de montée en charge et d’utilisation des ressources au sein d’une machine hôte donnée.

Container ou VM ? L’objectif des containers Windows

Server n’est pas de proposer une autre alternative de déploiement des anciennes applications. Les applications traditionnelles qui utilisent leur propre machine ou VM, un stockage local persistant, et l’authentification Active Directory, doivent continuer d’utiliser des VM on-premisses ou dans un Cloud public, tels que Microsoft Azure ou Amazon AWS. Utiliser le Référentiel pour créer un container Le processus de création d’un nouveau container permet de bien comprendre comment fonctionnent les containers :

• Le principe est que les images et autres objets présents dans le référentiel ne sont jamais copiés nulle part mais liés vers le dit référentiel.

• La création d’un nouveau container passe par la sélection d’une image source à partir du référentiel. Aujourd’hui, la TP3 de Windows Server 2016 utilise une image de type Windows Server Core laquelle est alors liée au conteneur – sans qu’aucune copie de quoi que ce soit ne soit réalisée. C’est donc sur la base de ces liens que les containers peuvent être déployés si rapidement en quelques secondes.

• Une fois le container X démarré dans sa version 1, la personnalisation peut commencer. A ce stade, tous les changements seront alors conservés de manière persistante comme s’il s’agissait d’une VM.

• Une fois créé et personnalisé, le container peut être démarré et administré en PowerShell via une commande Enter-Possession pour initialiser une session interactive ou aussi directement à l’aide de la commande Invoque-Command qui pourra directement exécuterdes commandes à l’intérieur du container.

• Ensuite, l’administrateur peut décider de stopper un container pour créer une nouvelle image au sein du référentiel. Lors de cette opération de création, les changements sont capturés et stockés en tant que nouvelle image de container et un nouveau lien de type Parent-Enfant est créé.

Intérêts des processus IT basés sur Dev/Ops et relation avec les Containers Dev/Ops est un concept apparu il y a maintenant plus d’une dizaine d’années avec comme objectif ambitieux d’aligner l’ensemble des équipes IT et tout particulièrement, d’une part l’équipe ayant la charge de faire évoluer le système d’information côté Système et Applications (Dev) et d’autre part, celle ayant la charge de son exploitation et maintien en condition opérationnelle (Ops) au quotidien. Au départ, les 2 équipes Dev et Ops sont distinctes mais l’idée sous-jacente de Dev/Ops est de tendre vers une équipe commune capable de prendre en charge l’évolution du système d’information en terme d’applications et de composants systèmes sous-jacents et aussi son exploitation. Ainsi avec Dev/Ops, des personnes ayant des profils différents peuvent travailler ensemble de concert et créer plus de valeur pour l’entreprise

La figure ci-dessus illustre le concept avec des applications déployées via des containers :

• Au commencement, les développeurs créent et testent leurs applications dans des containers via leurs outils de développement habituels. Le cycle de vie du logiciel ou du composant applicatif est pris en charge via la mise à jour et le déploiement des containers existants. Les containers applicatifs sont placés par les développeurs dans le magasin central regroupant tous les containers.

• L’équipe Ops prend en charge l’automation du déploiement ainsi que la surveillance des applications déployées à partir du magasin central.

• Enfin, les spécialistes des opérations – Ops, collaborent avec les développeurs – Dev, afin de fournir des indicateurs d’utilisation, des statistiques de performances et aussi des projections de charges pour envisager les évolutions à court et moyen termes. Docker : Beaucoup d’avantages aujourd’hui mais encore plus dans le futur… Les avantages apportés par les containers sont nombreux car :

• Qui dit Containers, dit Agilité : Grace à l’utilisation des liens, la création et la mise en production d’un nouveau container est très rapide – de l’ordre de la seconde.

• Les équipes de développement peuvent fournir un package qui s’exécutera à l’identique quelle que soit la plateforme Docker – mais en respectant le système d’exploitation sous-jacent, c’est-à-dire de Windows vers Windows et de Linux vers Linux.

• Les images mises à disposition par les développeurs au sein du référentiel sont disponibles pour le service IT en charge du déploiement et de la mise en production.

• L’espace de stockage est minimisé : Il n’est plus nécessaire de disposer d’un système d’exploitation complet et de beaucoup de mémoire RAM, comme cela est le cas habituellement s’agissant d’une VM. Le container contient uniquement les différences.

• Les déploiements peuvent être illimités : L’image d’un container déployée mille fois vous permet de disposer de mille containers identiques.

• En cas de problème lié à une version d’un container donné, il suffit d’effectuer un retour en arrière en instanciant un nouveau container dans sa version correcte N-x. Docker : Quelques inconvénients mais il nous reste les VM !

Du côté des inconvénients, il y en a tout de même quelques-uns :

• Les containers ont été initialement créés pour les environnements Cloud massifs tels que ceux d’Amazon ou de Microsoft. Ils sont fortement orientés applications et Microsoft ne prévoit pas de supporter le rôle AD, DNS ou encore moins Exchange au sein d’un container.

• Si l’application doit stocker des données, il est recommandé de stocker ces données en dehors du container dans le cas de la perte d’un container.

• Les containers ne supportent pas de mécanisme de HA. Une machine hôte en VM peut fonctionner au sein d’un cluster Hyper-V mais il n’est pas possible de mettre en cluster un container.

• Les containers ne supportant pas l’adhésion à un domaine Active Directory, il sera donc nécessaire de rechercher une alternative d’authentification. Voilà, ce tour d’horizon dédié aux containers Docker est terminé mais c’est là que l’aventure commence. Alors, pour tester les containers Windows Server, téléchargez la TP3 de Windows Server 2016 ou essayez directement la technologie en vous connectant gratuitement sur Microsoft Azure.

Pour plus d’informations sur les containers de Windows Server 2016, connectez-vous sur le site Microsoft Open Technologies https://msopentech.com ou sur GitHub à l’adresse https://github.com/Microsoft/Virtualization-Documentation.