« Docker est un jeune homme à la tête bien faite », Jean-Philippe Gouigoux (Directeur Technique)

Jean-Philippe Gouigoux, auteur de l’ouvrage « Docker : Prise en main et mise en pratique sur une architecture micro-services », publié aux Editions ENI revient  sur les fondements de Docker et comment cette coqueluche des conteneurs Linux se positionne sur le marché.

Niveau de maturité, sécurité, relations à la virtualisation, cas d’usages type et place dans les architectures en micro-services, ce spécialiste passe en revue les points essentiels de Docker.

LeMagIT : Quel est aujourd’hui le niveau de maturité de Docker ?

Jean-Philippe Gouigoux : Docker pourrait être comparé à ce qu’on appelle aujourd’hui un « adulescent ». Adulte par son âge (version 1.10), il reste encore adolescent dans certains de ses comportements. Par exemple, bien qu’il ait obtenu son appartement séparé (grâce à libcontainer) et son indépendance financière (un premier job de rêve en Californie), il reste dépendant de ses parents (la technologie LXC) et de sa communauté.

Docker n’est pas non plus un adolescent attardé, comme la génération récente est souvent caricaturée. Il a certes de grands idéaux (dogme du processus unique par conteneur), mais cherche réellement à concilier ses aspirations techniques (améliorer le logiciel et le diffuser) avec une approche communautaire (open source). Parfois accusé d’usurpation, il a au contraire su faire preuve d’une grande maturité en se juchant sur les épaules de géants comme LXC. C’est d’ailleurs certainement la clé de son succès : ayant dépassé l’adolescence, il sait se départir de son instinct de rejet de ce qui vient de la génération précédente et l’utiliser à son profit lorsqu’il y trouve un intérêt objectif. Et n’étant pas tout-à-fait adulte, il a encore toute sa fraîcheur et sa créativité.

Conscient de ses manques, et à la fois très proche de ses amis, il a sélectionné les meilleurs d’entre eux (Fig, Tutum, Unikernel récemment) et les invite dans sa grande maison communautaire. Toute cette réunion fait beaucoup de bruit, bien sûr : il faut bien que jeunesse se passe. Les voisins, tendance grande bourgeoisie installée (IBM, Microsoft) s’inquiètent légitimement, mais là encore, Docker est plus adulte qu’on ne le croit. Au lieu d’envoyer balader les empêcheurs de faire la fête, Docker les invite à passer prendre le café, leur montre sa stéréo… En connaisseurs, les riches voisins s’intéressent et, grand seigneur, Docker leur propose de leur donner les plans, de façon qu’ils puissent la reconstruire chez eux (l’Open Container Initiative standardise les formats et runtime de conteneurs). Microsoft se voit déjà lancer de grandes fêtes avec une stéréo de qualité, dont l’utilisation est connue de tous, mais diffusant bien sûr sa propre musique (Microsoft est plutôt fan de classique). Evidemment, ce ne sera pas la petite fête de quartier du voisin Docker, mais la grande garden party (conteneurs dans Windows Server en 2016) utilisera bien l’électronique de ce dernier (son API).

Au final, Docker est parfaitement représentatif de sa génération. Il n’est pas adulte au sens où les anciens l’entendent, certes, mais c’est un jeune homme à la tête bien faite, qui sait ce qu’il veut et qui ira certainement loin. Créatif, doté d’une mission qui le guide, il sait travailler en groupe pour arriver à ses fins. Les énormes pas qu’il a franchis sur l’année 2015 montrent clairement qu’il est sur le bon chemin de la maturité.

LeMagIT : La sécurité est souvent présentée comme le maillon faible de Docker. Est-ce une réalité et pourquoi ?

Jean-Philippe Gouigoux : Nous pourrions filer la métaphore précédente, en expliquant que l’adulescent Docker est un pragmatique. Le quotient intellectuel n’ayant jamais permis d’attirer les regards en soirée, Docker sait qu’il vaut mieux être excellent danseur et bien habillé. Le logiciel a donc habilement emprunté à ses amis un peu moins ambitieux (Linux) leurs techniques de danse (namespaces) et leur chemise classe (cgroups). La capacité de Docker à mettre en pleine lumière ces atouts a fait le reste, et l’adulescent s’est rapidement retrouvé le roi de la fête.

Au bout de quelques soirées (1.6, environ), il devenait de plus en plus visible que le Travolta en herbe marchait sur les pieds de ses partenaires. L’adulescent, peut-être ébloui par les spots, menait la danse comme un dictateur (accès privilégié au système, processus lancés dans les conteneurs avec ces mêmes droits élevés), clamait bien haut les secrets que ses partenaires lui chuchotaient à l’oreille (pas de SSL par défaut, pas de vérification des empreintes des images téléchargées) voire même abandonnait certaines conquêtes imprudentes après les avoir engrossées (volumes orphelins).

Heureusement, comme expliqué plus haut, Docker est un jeune homme à la tête bien faite, et son attachement à sa tribu est réel : il a très vite écouté ces doléances de la communauté, a fait amende honorable et – bien plus important – s’est attaqué au fond du problème. Aujourd’hui (depuis la 1.9), après un sérieux travail sur lui-même (réécriture de la gestion du réseau), Docker propose gentiment de limiter sa danse (en termes de CPU ou de RAM) et refuse même d’écouter les secrets de ses partenaires (SSL obligatoire pour les échanges vers les démons, validation du hash des images). Ce faisant, il a réalisé un grand pas vers le stade adulte.

LeMagIT : Quels cas d’usage conseilleriez-vous pour des conteneurs Docker ?

Jean-Philippe Gouigoux : Si Docker s’était limité à être simplement un danseur élégant, il n’aurait certainement pas eu autant d’invitations à des soirées partout dans le monde. La raison de son succès est qu’il fournit la soirée tout-en-un, en installant son propre Sound System (le Docker Hub) qui contient tous les tops musicaux du moment (les images officielles des logiciels le plus courants). Pas de mise en place compliquée : la fête démarre sur un sol carrelé (un OS Linux) – ou bientôt du parquet (un OS Windows) – et avec une simple prise de courant (une connexion internet). Le premier cas d’usage de Docker est donc le test extrêmement rapide d’une nouvelle technologie : nul besoin de passer par une installation complexe ni de risquer de dégrader son système, une simple commande « docker run » et le processus est lancé en parfaite isolation du reste du système. Une commande « docker rm » et il revient exactement à son état précédent : plus une seule trace de la grande fête dans la maison…

Mais il serait réducteur d’assigner Docker à ce simple rôle d’animateur de soirée, car sa force  - et le second cas d’usage – est de pouvoir mettre en mouvement tout un quartier (plusieurs machines), voire une ville (des machines sur plusieurs sites), en synchronisant les soirées dans toutes les maisons. Certaines joueront les mêmes morceaux (la même image logicielle dupliquée dans plusieurs conteneurs pour tenir la charge), d’autres quartiers se spécialiseront en fonction du type de musique (référentiels de données d’un côté, services de calcul de l’autre, interface web sur un troisième ensemble). Au final, Docker sera l’invité majeur (le démon) de chacune des soirées (les machines), et saura mettre en œuvre les playlists (Docker Compose permet de définir des ensembles cohérents d’images et leurs relations). Il saura s’appuyer sur des amis orchestrateurs (Deis, Marathon, Kubernetes) qui veillent à ce que la répartition et le nombre de soirées (nombre de machines et lancement de services sous forme de conteneurs) satisfassent au mieux les variations de goût et de nombre de danseurs dans la ville (le Système d’Information). Enfin, Docker propose de construire des pistes de danse en urgence si besoin (Docker Machine, qui provisionne des serveurs avec le démon Docker dessus).

En conclusion, Docker est l’ami idéal si vous souhaitez organiser une soirée (une application) : il s’occupe de tout, sélectionne la musique, la met à disposition dans toutes les pièces, poursuit la playlist que vous avez définie, nettoie tout de fond en comble à la fin, et sait se faire petit dans un coin pour laisser la piste de danse la plus libre possible pour vos invités (les processus logiciels). Bref, il est si efficace que même pour une soirée tout seul (une application autonome), on tend à lui confier l’organisation et, finalement, il n’y a que peu de cas d’usage où l’on préfère se passer d’une telle assistance.

LeMagIT : Et pour être complet,  quid des autres technologies de conteneurs Linux ?

Jean-Philippe Gouigoux : Devant le succès de Docker, quelques autres jeunes personnes donnent de la voix pour exister sur le dancefloor, comme LXD de Canonical ou Rocket de CoreOS. La difficulté pour eux est multiple : non seulement Docker remplit à merveille son rôle et est donc très apprécié par ses utilisateurs mais il a en plus le bon goût, malgré sa position dominante, d’être ouvert aux demandes d’améliorations, comme nous l’avons vu plus haut.

De fait, la plupart des danseuses ayant dansé une première fois avec Docker ne demandent qu’à recommencer, voire tombent carrément amoureuses. Elles n’ont alors plus d’yeux que pour lui et les quelques adolescents au fond de la salle qui ont capté un peu d’attention en claquant la porte lors de leur entrée sont très vite rendus à leur solitude. Certains préparent certainement un coup d’éclat, et auront peut-être un jour leur part de lumière. Mais pour l’instant, Docker est au centre de la piste, les spots sont pointés sur lui, il danse déjà très bien et s’améliore à vue d’œil. Bref, les adolescents du fond ont du pain sur la planche pour rattraper le presque adulte qui plait tant aux demoiselles, qu’elles soient administratrices réseau ou système, développeuses, testeuses ou exploitantes d’un cloud.

LeMagIT : L’approche apportée par les conteneurs va-t-il rendre désuète la traditionnelle virtualisation ?

Jean-Philippe Gouigoux : Les grandes salles de concert (la virtualisation) ne voient pas d’un très bon œil la progression fulgurante de Docker dans sa façon de mettre en œuvre des soirées musicales privées. Pour elles, la musique se fait nécessairement en grand (la virtualisation a tendance à utiliser de grosses machines onéreuses) et il ne faut pas regarder à la dépense (la duplication des OS virtuels fait perdre énormément de ressources). Leurs utilisateurs leur ont bien reproché parfois que l’orchestre prenne autant de place, mais vue la taille de la salle, les reproches sont restés relatifs.

Les régisseurs, par contre, sont furieux : les grandes salles nécessitent beaucoup plus de budget d’entretien que prévu et l’investissement dérape parfois avec l’achat de nouveaux équipements devenus réglementaires (vMotion, etc.) alors qu’ils n’étaient pas prévus au budget.

A l’inverse, Docker reste admiratif devant la qualité d’insonorisation des grandes salles de concerts. Il faut dire que la technologie (l’hyperviseur) a été rôdée depuis plusieurs dizaines d’années maintenant. L’adulescent n’a pas encore réussi à garantir le même niveau d’étanchéité entre les différents conteneurs. De même, la gestion des flux d’énergie dans les grandes salles est très sophistiquée (Software Defined Networks, par exemple), alors que Docker a récemment été obligé de recabler ses Sound System (la gestion réseau), qui ne donnaient pas satisfaction.

L’un dans l’autre, les grandes salles ne sont pas encore menacées par le DJ-at-home que représente Docker : les utilisateurs qui achètent une chaîne hifi vont tout de même au concert, et les deux approches sont finalement complémentaires pour les vrais amateurs de musique (un bon administrateur utilisera ainsi les deux technologies). Les mélomanes organisent d’ailleurs des petits concerts dans différentes pièces d’une grande salle de spectacle, pour avoir les bénéfices conjoints des deux approches (Docker sur des machines virtualisées est une bonne pratique).

Mais Docker apprend vite, et s’il peut un jour proposer une isolation sonore aussi bonne qu’une salle de concert (étanchéité des conteneurs) et un rendement électrique (gestion du réseau) à la hauteur, il n’est pas impossible que les mélomanes ne trouvent finalement plus d’intérêt aux grandes salles de concerts. La virtualisation va devoir proposer d’autres atouts.

LeMagIT : Les conteneurs, et donc Docker, poussent à reconsidérer les architectures d’applications en s’appuyant sur la notion de micro-services. Pouvez-vous nous décrire comment se composent aujourd’hui ces nouvelles applications ? Et qu’impose cette forme d’architecture ?

Jean-Philippe Gouigoux : Abandonnons là la métaphore usée jusqu’à la corde, et intéressons-nous à l’origine de l’attrait de Docker. Comme souvent lorsque l’adoption d’une technologie est rapide et continue, l’étude du contexte montre une concordance forte entre la montée d’un besoin et l’apparition d’une solution. Dans le cas de Docker, l’alignement des astres est triple.

La virtualisation par conteneurs existe depuis longtemps, que ce soit avec les solutions Zones dans Solaris, Jails dans FreeBSD ou OpenVZ. La découpe des solutions logicielles en modules autonomes est également un vieux rêve de développeur, matérialisé successivement par les routines, les librairies, les composants puis les services, avec à chaque fois toutes les limites associées à ces approches purement techniques. Du point de vue de la méthodologie, les mouvements agiles ont montré les limites des approches en cascade où les développeurs fournissent un produit aux testeurs qui le fournissent aux administrateurs systèmes, chacun se souciant uniquement de son rôle propre.

Nous assistons aujourd’hui à une véritable cristallisation de ces trois approches dans un seul mouvement :

1)  Une autonomie réelle des services logiciels a été rendue possible par la compréhension que le problème n’était pas technique mais sémantique. La mise en place de contrats d’interfaces et le respect de normes rendent enfin possible le vieux Graal du remplacement d’un module informatique par un autre. L’urbanisation des Systèmes d’Information a conduit à des résultats phénoménaux dans les domaines de l’assurance, du transport et plus récemment de la téléphonie.

2) Les méthodologies de type DevOps se rencontrent de plus en plus, et les différents rôles dans la chaîne logicielle sont appelés à travailler de manière plus collaborative, en utilisant en particulier des outils communs. L’impact sur le time-to-market a été largement démontré dans de nombreux projets, et la méthode est en phase de diffusion large.

3) Docker s’inscrit à un titre éminent dans l’approche DevOps, car il permet de garantir que l’environnement vu par les testeurs, les développeurs et les administrateurs est le même, de par l’isolation des conteneurs au regard des machines sous-jacentes. La phrase « pourtant ça fonctionne sur mon environnement de développement » pourrait bien disparaître du registre millénaire des analystes-programmeurs.

Ces trois mouvements sont tellement étroitement corrélés qu’il est difficile de se prononcer sur une quelconque chaîne de causalité. Docker a-t-il donné corps au mouvement DevOps en fournissant l’outil nécessaire à la réalisation efficace de cette méthode ? Les architectures de services seraient-elles revenues sur le devant de la scène sans l’effet Docker ? Ou au contraire, Docker s’est-il construit pour répondre à ce besoin conjugué de modularité et d’efficacité collaborative ? Chacun aura son point de vue sur la question, mais la réponse importe finalement peu au regard du résultat, à savoir un changement de paradigme fort dans l’industrie logicielle. Comme le Lean dans l’industrie est né de pratiques différentes mais finalement complémentaires (Kaizen pour l’amélioration continue, Gemba pour la solution des problèmes, Kanban pour la visualisation), le phénomène auquel nous assistons se manifeste dans l’urbanisation des SI, la gestion des conteneurs et le DevOps, mais procède d’un mouvement plus global.

Pour revenir aux fondements de ce mouvement, la découpe d’un système en modules avec des responsabilités séparées est intellectuellement reconnue comme clairement bénéfique : le postulat de départ – «  découper pour mieux régner » – était  bon. Simplement, pendant longtemps, cette séparation des responsabilités se traduisait par une séparation nette des rôles des personnes, mais pas franchement dans les logiciels (souvent monolithiques, et donc mélangeant de nombreuses responsabilités). Nous savons désormais que c’est l’approche inverse qui produit de meilleurs résultats, à savoir une séparation stricte du point de vue technique (étanchéité des services, par exemple par des conteneurs, contrats normatifs régissant les API) et au contraire relâchée du point de vue organisationnelle (mélange des rôles développeur et opérationnel).

L’approche de découpage étant validée, reste l’épineuse question de la granularité. Il y a peu de temps encore, le mètre étalon était l’architecture dite « microservices » telle que la pratiquent Netflix ou Google, avec une granularité de services de l’ordre de la centaine de lignes de code. Cette découpe très fine se justifie par le très haut niveau de mise à l’échelle auquel opèrent ces majors de l’internet. A l’échelle de 100 000 serveurs, ne pas pouvoir faire rentrer un grain de fonctionnalité dans les 4% de ressources restant disponibles correspond à un coût important.

Aujourd’hui que les autres opérateurs se sont appropriés ces architectures, la granularité évolue dans les deux sens. Les opérateurs de masse ont tout intérêt à raffiner encore plus la taille des services, et si l’idée est poussée à l’extrême, un service peut être ramené à une seule fonction. C’est l’approche des architectures dites lambda, dont Amazon est un des promoteurs, et qui consiste à créer un conteneur léger pour exécuter une fonction, stocker son résultat puis immédiatement détruire le conteneur. Difficile de faire plus extrême, aucun état ne persistant plus dans cette architecture.

A l’inverse, quelques rares éditeurs de logiciels se sont rendu compte que la découpe en microservices avait un coût important, et qu’une découpe à plus gros grain, dans des systèmes informatiques de taille raisonnable, fournissait déjà une très grande partie des bénéfices attendus. En particulier, si ces grains d’API s’alignent sur des normes ou des standards reconnus dans leur domaine de compétence, la découpe permet non seulement d’envisager une interopérabilité technique, mais également sémantique, synonyme d’important apport de valeur. La granularité idéale varie donc d’un domaine informatique à l’autre.

Pour revenir aux conteneurs, de la même manière qu’ils permettent d’isoler des processus, ils permettent également de fournir une couche d’indirection en regard du choix de la granularité décrit ci-dessus. Et la séparation optimale entre la granularité des machines et la granularité des services composant les applications (ou plutôt le SI, car la notion d’application, dans des SI orientés services, a de moins en moins d’importance) est le mode dit « Container as a Service », ou CaaS, dans lequel un opérateur fournit un ensemble de ressources de taille élastique exposé sous la forme d’un démon Docker unique. Ce fournisseur n’a alors pas à s’occuper de la répartition des services et, en miroir, l’exploitant des conteneurs n’a aucune connaissance du nombre et des caractéristiques des machines sous-jacentes au cloud de conteneurs. C’est cette séparation idéale des responsabilités qui est le point fort de Docker, et qui permet de lui prédire un avenir brillant.

 Jean-Philippe Gouigoux est Microsoft Valuable Professional (MVP) Connected System Developer. Spécialisé en sécurité logicielle et en méthodes d’intégration agile, il travaille en tant que directeur technique chez l’éditeur breton MGDIS qui développe des solutions IT pour les collectivités. Il est un expert.NET reconnu (certifié MCTS SQL Server et MCPD Enterprise Architect).