Docker, tour d'horizon rapide

Une précédente série d'articles a introduit la virtualisation, ses usages, et son rôle dans le développement de l'offre Cloud, en particulier IAAS et PAAS.

Vous êtes maintenant armés pour aborder le nouveau sujet qui fait le buzz depuis 2 ans et qui ne cesse de monter : Docker !

Si la virtualisation, les termes IAAS PAAS SAAS, la gestion de configuration, sont des termes abstraits, je vous recommande de commencer par lire ces articles précédents qui introduisent toutes ces notions :

La Haute Disponibilité en bref
Virtualisation, principes et usages
Formes et intérêts du Cloud computing

Déjà une précision : Docker est une technologie de conteneurisation, et au delà de Docker nous allons nous intéresser à cette notion de container. Docker est le produit phare dans ce domaine mais il n'est pas le seul et l'offre est probablement amenée à se diversifier fortement. 

On peut aborder Docker et la notion de container sous différents angles. Un angle très technique consisterait à expliquer comment ça fonctionne, ce qui nous amènerait inévitablement à devoir aborder des notions systèmes avancées, avec un pré-requis important sur le fonctionnement interne d'un système d'exploitation Linux. Nous n'allons pas prendre ce chemin, j'aborderais quelques points mais tant mes compétences en la matière que le vocation de ce blog me font privilégier une approche plus axée sur les usages.

L'idée de base du container

Comme le nom l'indique, un container est une espèce de boite logique, virtuelle, dans laquelle on enferme certains éléments pour les isoler du reste du monde.

Pensez à une boite fermée dans laquelle vous stockez des aliments dans votre cuisine. Remplacez la boite physique par une boite virtuelle, les aliments par des fichiers stockant des données binaires représentant des programmes et des données, et la cuisine par un serveur et vous devez comprendre à peu près l'idée. 

On parle bien sur de serveur physique ici, un ordinateur sur lequel on fait tourner un système d'exploitation, Linux dans le cas de Docker.

Vous pouvez donc avoir plusieurs containers sur votre serveur, de la même façon que vous pouvez avoir plusieurs boites dans votre cuisine. L'avantage est que les aliments d'une boite n'iront pas, par exemple, imprégner de leur odeur les éléments d'une autre boite. Et dans le serveur l'objectif est le même, les données et programmes d'un container n'iront pas interagir avec ceux d'un autre container.

L'intérêt est que comme vos boites se partagent la cuisine, ses étagères et son frigo, les containers se partagent un certain nombre de ressources à commencer par le système d'exploitation. Imaginez un peu si deviez avoir un placard ou un frigo distincts pour chaque aliment, ça vous coûterait cher et ça vous prendrait plein de place. Mais grâce aux boites hermétiques, vous pouvez tout ranger côte à côte.

J'arrête là les métaphores culinaires, je pense que l'idée de base est posée.

En terme informatique, on obtient la possibilité pour un serveur physique de fournir davantage de services grâce à la mutualisation de ses ressources entre divers containers fournissant chacun un service. Sans cette technologie, si on a 10 containers et donc 10 services, il nous faudrait 10 serveurs avec chacun un système d'exploitation supportant un service. Ou encore, un serveur physique avec un hyperviseur et 10 machines virtuelles chacune hébergeant un système d'exploitation supportant un service.

Et bien sur comme vous l'aurez deviné, 10 serveurs et 10 licences d'OS ou encore 1 gros serveur de VM, 1 licence pour un hyperviseur, et 10 licences d'OS ça coûte plus cher que la solution où on a un seul serveur, qui a bien moins besoin de puissance que le serveur de VM, avec 1 seul OS et 10 containers.

Pourquoi le serveur qui héberge 10 containers a il moins besoin de puissance qu'un serveur qui héberge 10 VM ?

Point besoin d'être un grand crack en informatique pour comprendre. L'hyperviseur consomme des ressources, et 10 VM ça veut dire 10 OS qui chacun consomment des ressources (et en outre elles émulent le matériel ce qui a aussi un coût), alors que dans le cas du container on n'a ni hyperviseur, ni émulation, et un seul OS qui tourne (qui embarque un démon Docker, c'est à dire un service en tâche de fond qui tourne en permanence).

Alors bien sur, toutes choses étant égales par ailleurs, cet avantage se paye ailleurs par des inconvénients, mais nous y viendrons plus loin.

J'en termine sur cette introduction sur la notion de container pour parler des usages qui sont faits de cette technologie :

• exploiter des plateformes multi-utilisateur : un seul système d'exploitation qui est partagé par un grand nombre d'utilisateurs (bien sur connectés à distance, avec par exemple le bureau à distance Windows, ou avec une solution de DAAS comme le propose Citrix par exemple). On a un container par utilisateur qui isole ses données et programmes de ceux des autres utilisateurs simultanés.

• exploiter de nombreux programmes sur un seul ordinateur de façon à limiter les coûts matériel

C'est ce second usage qui va nous intéresser, et en particulier sa mise en perspective avec les solutions de virtualisation qui permettent également de répondre à ce même besoin.

Container vs Machine virtuelle

La technique de conteneurisation a certaines similitudes avec la virtualisation au niveau des usages ; elle permet d'atteindre de façon différente, avec des avantages et des inconvénients, certains des avantages clés procurés par la virtualisation.

Du fait des ces similitudes, on qualifie souvent Docker, la solution phare, de solution de virtualisation légère pour l'opposer aux hyperviseurs qualifiés de virtualisation lourde. C'est à mon sens un abus de langage, Docker n'étant pas une solution de virtualisation. Simplement, il entre en concurrence avec la virtualisation sur certains cas d'usages.

L'isolation des environnements est un point important. Il ne serait pas acceptable de faire tourner de multiples services sur une même machine physique si ils pouvaient se perturber mutuellement. Cette isolation est assurée par l'hyperviseur dans le cas de la virtualisation et par le logiciel de conteneurisation, disons Docker, dans le cas des containers. Et ici la virtualisation gagne la manche sans aucune discussion possible, l'isolation est bien plus sure et le risque d'avoir un service qui fait dysfonctionner les autres bien moins grand.

La consolidation de multiples serveurs sur un seul serveur physique. C'est l'avantage économique majeur qui a permis à la virtualisation de s'installer depuis 10 ans comme une technologie incontournable. Ici le match est plus serré et dépend fortement des besoins à satisfaire. Comme nous l'avons déjà vu, la conteneurisation est plus optimale en terme de ressources requises et permet donc de consolider davantage de serveurs et donc de réaliser des économies plus importantes. Mais il y a une contrainte forte ; alors qu'avec un hyperviseur vous pouvez faire tourner à peu près n'importe quel système d'exploitation courant, tous les containers se partagent le même OS et donc doivent impérativement tourner sous le même OS, Linux en l’occurrence pour Docker.

Automatisation

La conteneurisation n'est en rien une idée nouvelle et diverses technologies, essentiellement propriétaires, existent depuis bien longtemps, notamment au niveau des systèmes Unix.

En fait, on peut même faire le rapprochement avec un style d'architecture logicielle qu'on appelle le multi-tenant (multi-tenancy) et qui vise à permettre la mutualisation d'un élément utilisé pour rendre un même service dans différents contextes d'utilisation. Simplement ici, l'élément factorisé au lieu d'être un logiciel serveur quelconque ou une application métier commercialisée en PAAS (contexte le plus fréquent de mise en oeuvre du principe) est l'OS lui même.

Linux a des capacités en la matière depuis longtemps, inspirées des Unix propriétaires, mais elles ont été étendues de façon astucieuse par les auteurs de Docker. En particulier, ils ont ajouté la capacité de gérer des modèles de container qu'on peut stocker, référencer, mettre à disposition ... et les outils permettant de les déployer avec une grande facilité et une très grande vitesse. Et ainsi procuré à l'outil un avantage important par rapport aux solutions de virtualisation.

Ainsi, en couplant un repository (un endroit où on stocke des définitions de container) avec un outil simple d'utilisation disponible sur un système Linux équipé du logiciel Docker, on obtient la possibilité d'automatiser le déploiement des environnements avec une grande facilité (chaque environnement étant un container).

De la même façon qu'un développement logiciel bien organisé s'appuie sur un repository de composants (librairies de code, frameworks) et des outils de build automatisant leur téléchargement et leur déploiement (ici le déploiement c'est l'intégration du composant dans le produit final issu du build), on a des repository Docker et les outils Docker associés. Pour faire le parallèle avec le monde du développement Web Java, Docker fournit à la fois le repository Maven et l'outil Maven avec le plugin qui va bien (ou encore un équivalent npm ou bower côté développement front). 

On utilise parfois le terme terme Infrastructure As A Code pour désigner cette capacité. Cette capacité est très importante en ingénierie logicielle car elle améliore la gestion de configuration en permettant de gérer les versions de l'environnement d'exécution d'un programme (la définition d'un container, ce qui est quelque chose de léger) avec ou en parallèle du code du programme proprement dît. Toujours pour faire un parallèle avec le développement Java/Web c'est l'équivalent du stockage du pom.xml Maven avec le code source (pour ceux à qui ça parle).

Un des articles sur la virtualisation cité en préambule détaille l'intérêt de la capacité à reproduire de façon automatisée un environnement et cite un certain nombre d'outils existants et utilisés conjointement avec les solutions de virtualisation (Vagrant and co). Docker apporte les mêmes capacités mais de façon plus simple et mieux intégrée. Et surtout... déployer et démarrer un container Docker est une affaire de secondes, là où la même opération pour une machine virtuelle est infiniment plus lourde.

DevOps

La démarche DevOps est à la croisée de nombreuses tendances (en matière d'organisation des DSI, d'architecture logicielle, d'outils, de démarche agile ...) et on ne saurait la résumer en quelques mots tant elle impacte de nombreux aspects du métier. 

Un de ses aspects clés est de casser la barrière existant entre les équipes de développement d'une part (Devs), et les équipes d'exploitation d'autre part (Ops). Les premières travaillent à fabriquer les logiciels utilisés dans l'entreprise, les secondes à les mettre à disposition des utilisateurs et à s'assurer qu'elles fonctionnent correctement et avec des coûts de fonctionnement maîtrisés. 

Je détaillerais ceci dans un article futur sur le sujet mais pour le moment ce qui nous intéresse est de savoir que ces équipes travaillent chacune sur des environnements différents qui sont, dans une DSI correctement organisée selon les cadres méthodologiques de référence, totalement étanches. Or, il est essentiel que ces environnements soient identiques afin d'éviter des différences de comportement des logiciels entre par exemple le serveur de test utilisé par les développeurs pour le test et la mise au point des programmes, et le serveur de qualification utilisée par la maîtrise d'ouvrage pour qualifier le bon fonctionnement, ou encore le serveur de production utilisé par les vrais utilisateurs.

Et ici Docker apporte une vraie plus value en permettant le partage des environnements (de la définition des containers stockée dans un repository commun par exemple) entre les deux équipes. C'est une autre des raisons de son succès.

Docker peut donc être cité comme un des outils favorisant l'adoption d'une démarche DevOps dans une DSI.

Cloud

Les capacités natives d'automatisation du déploiement des environnements, la forte capacité de consolidation de nombreux environnement sur un serveur physique, et le fort intérêt de la profession envers Docker ont amené tous les grands acteurs du Cloud à mettre en place des offres basées sur Docker, en particulier pour les offres de PAAS.

Et les choses choses vont au delà. Pour offrir de la haute disponibilité, il s'avère nécessaire de gérer des clusters de containers, c'est à dire des ensembles de containers coordonnés sur des machines physiques différentes. Ceci est indispensable pour le support de la tolérance de panne par exemple, mais également utile pour permettre l'ajustement dynamique des capacités de traitements aux besoins ce qui est une caractéristique essentielle du Cloud.

La gestion de repository de container est également un autre aspect, tant pour permettre aux organisation de gérer leurs containers, que fournir des containers "clés en mains" (ce qu'on appelle des appliances) pour répondre aux besoins courants.

Signe de l'intérêt pour Docker et de son adoption, divers outils sont apparus :

• Google a mis à disposition Kubernetes qui a reçu un accueil très favorable
• Docker fournit Swarm
• La fondation Apache (acteur incontournable de l'open source) a étendu son offre Mesos pour prendre en compte Docker

Le temps et la place me manquent pour entrer plus dans le détail de ces sujets passionnants. Si vous devez retenir une chose, c'est que ces outils permettent à Docker de passer à une dimension supérieure et le signe indubitable du grand intérêt de la profession pour cette solution. Pour le reste, Google is your friend ;-)

Adoption de la technologie

Il semble indéniable que la technologie Docker est plus qu'un effet de mode. Elle est soutenue par tous les acteurs majeurs de l'industrie qui investissent.

Quelques éléments à l'appui de cette affirmation.

Un consortium a été créé ce qui est un signe favorable car la mise en place d'une gouvernance autour du sujet est essentielle pour éviter l'apparition de multiples chapelles et d'incompatibilité qui peuvent conduire une belle idée à l'échec.

Microsoft met les bouchées doubles pour le support de Docker, dans son offre Cloud Azure bien sur, mais également dans son offre de systèmes d'exploitation ce qui est déjà plus surprenant. Il y a également des rumeurs de rachat de la société Docker par Microsoft.

Le support de Google s'exprime de diverses façons, nous avons déjà cité Kubernetes, IBM en fait la pierre angulaire de son offre BlueMix, nous avons déjà parlé du support de Microsoft, nous pourrions continuer longtemps ainsi.

La fin de la virtualisation ?

Je tue d'entrée le suspense.

L'intérêt grandissant pour Docker ne va pas mettre un terme à la prééminence actuelle des solutions de virtualisation, et pour de nombreuses raisons.

Détaillons.


Déjà, les entreprises ont lourdement investi sur la virtualisation ; il a fallut recruter, former, monter en compétences... Tout ceci prend du temps et coûte cher et ces investissements ne vont pas être jeté aux orties tout de suite. L'accélération du rythme des innovations technologiques et des ruptures majeures est en décalage avec les capacités des organisations à les intégrer (et la question se pose de leur intérêt d'un point de vue purement économique).

Docker est encore trop jeune, insuffisamment éprouvé, et présente des défauts. Les choses progressent vite, il y a des exemples de sites importants en production mais on n'en est pas encore au stade de l'adoption générale. Même si on a largement dépassé le stade du buzz, il ne faut pas confondre vitesse et précipitation.

La société Docker, qui a développé le produit éponyme, doit faire face à l'émergence de nouveaux acteurs sur ce marché, facilitée par le modèle open source des produits, ce qui peut créer de l'incertitude (mais aussi stimuler l'innovation). Je pense en premier lieu à CoreOS (la société). 

La virtualisation et Docker ont des cas d'usages distincts. Du fait de leurs avantages et inconvénients respectifs, ces technologies sont adaptées à des besoins différents. Docker est par exemple adapté en cas de très nombreuses instances d'un même service unique, tandis que la virtualisation est indispensable pour supporter une multitude d'OS hétérogènes, et recommandée dans le cas où un noeud (une VM ou un container) doit exécuter plusieurs services (encore qu'à titre personnel je sois moins affirmatif sur ce point). 

La combinaison des deux technologies est possible et présente des intérêts certains. On a aujourd'hui trois possibilités :

• un serveur physiques avec un hyperviseur et des VM (virtualisation classique)

• un serveur physique avec Linux et Docker (ou un concurrent équivalent), approche qualifiée de "bare-metal"

• et une architecture mixte : un serveur physique avec un hyperviseur hébergeant des VM Linux/Docker.

Chaque architecture a ses avantages et inconvénients mais on peut simplement noter que l'architecture mixte présente ses intérêts propres et permet de s'appuyer sur l'existant tout en bénéficiant des dernières innovations.

VMWare, le plus gros acteur de la virtualisation, a senti le vent et promeut l'architecture mixte, notamment au travers du projet Photon. Il a tout simplement fait une version de Linux/Docker optimisée pour fonctionner avec son hyperviseur ESX. A noter, d'autres acteurs développent (ou participent dans le cadre d'un projet open source) sur des noyaux Linux spécialisés pour une large utilisation de Docker comme par exemple CoreOS (sur lequel s'appuie Kubernetes de Google).

Conclusion

J'espère que cet article vous permettra d'avoir les idées claires sur ce qu'est Docker et pourquoi tous les geeks ont le zizi tout dur dès qu'on aborde le sujet ;-)

Ce qui me semble le plus important à comprendre est d'une part l'écosystème autour de la solution de conteneurisation proprement dite (dépôts de containers, format standard de container  non lié à un éditeur, outils de gestion de clusters évolués Kubernetes and Co), et le fait que la technologie ne remplacera pas la virtualisation mais sera une possibilité supplémentaire et éventuellement complémentaire. Du pain sur la planche pour les architectes système, et des décisions compliquées pour les directeurs informatique en vue ...

Pour un développeur, au sens large, c'est la vision "infrastructure as a code" et l'appui de la démarche DevOps qui me semble la plus importante.