Le 6 Octobre prochain, ops et développeurs vous donnent rendez-vous au TIAD Camp Docker, pour échanger et partager autour du déploiement de Docker en production. Parmi les speakers qui seront présents, Quentin Adam, CEO de Clever Cloud lancera le coup d’envoi de la journée avec un talk destiné à démêler le vrai du faux sur la virtualisation et la conteneurisation.

Quentin Adam

TIAD Camp s’inscrit dans la même philosophie que le TIAD, celle de donner à la communauté de l’automatisation un espace de partage, de rencontre et d’expérimentation. TIAD Camp vous propose des deep dive techniques plus réguliers, tout au long de l’année, sur les sujets techniques qui font l’actualité. En préparation du TIAD Camp Docker, nous avons rencontré Quentin Adam pour un échange particulièrement instructif sur Docker et les conteneurs.

Pouvez-vous présenter CleverCloud ?

CleverCloud fournit un outil d’IT automation, sur notre Cloud ou celui de nos clients. Cet outil permet l’automatisation et l’industrialisation de l’ensemble d’une infrastructure, depuis le push du développeur : déploiement, monitoring, backups, mises à jour de sécurité, gestion des logs… le tout packagé dans un outil. Nous travaillons sur du bare metal, avec quelques milliers de serveurs, et sur ceux de nos clients.

Quel est votre usage de Docker ?

Nous étions le premier Cloud compatible Docker au monde. J’ai certes un regard très critique sur Docker, mais c’est en toute connaissance de cause. Nous packageons Docker sur Exherbo notre propre distribution, nous suivons le projet et nous en sommes acteurs. Donc, je ne suis pas anti-Docker comme certains peuvent me le dire, mais le sujet de la sécurité est délicat, cela demande de comprendre des notions de protocole, de corruption, et de pouvoir imaginer comment on sera attaqués.

Pourquoi avez-vous été taxé d’anti-Docker ?

Quand les containers sont apparus, il y a eu un effet de mode et beaucoup de gens y ont vu la solution à tous leurs problèmes. Nous étions plus réservés sur la réelle utilité des containers, une solution que nous connaissions déjà bien. On a commencé à présenter les containers comme des mini VMs, alors que ce ne sont pas des VMs. Certains développeurs, excellents développeurs par ailleurs, se sont alors revendiqués experts Docker, sans jamais avoir lu la moindre release du Kernel… forcément, ça m’a fait réagir. De fait, je suis un peu connu pour avoir fait quelques conférences pour rappeler ce que sont vraiment les containers et expliquer comment et pourquoi la technologie a été construite. En cela, nous ne sommes pas vraiment aidés par le discours officiel qui entretient un flou artistique sur l’utilisation réelle de cette technologie.

Quel sujet de votre talk ? Mythes et réalités de Docker ?

Comme l’objectif de la journée est de parler des containers, le sujet du talk est d’expliquer ce qu’est un container, ce qu’est une VM, et de détailler les concepts d’orchestrateur. Aujourd’hui parler de Docker sans parler de Kubernetes et de l’ensemble des systèmes d’orchestration qui sont autour est un non-sens. Les orchestrateurs font partie des briques essentielles de l’évolution de la technologie des containers.

J’aborderai peut-être également la question des protocoles de congruence. Avoir un “point de vérité” sur le fonctionnement de l’infrastructure est essentiel quand on utilise des orchestrateurs, et cela suppose un protocole de congruence… L’objectif de ce talk est vraiment de reprendre les bases pour que chacun puisse commencer la journée en sachant ce qui est vrai, ce qui ne l’est pas, et comprendre ce qu’on peut faire de l’outil, plutôt que de croire en une baguette magique technologique qui n’existe pas. Pour bien tirer parti de la journée, commençons par éliminer ce qui relève de la croyance et non de la technologie.

C’est vraiment un kickstarter autour de Docker et des orchestrateurs : nous allons réellement expliquer ce que c’est, comment fonctionne Docker de façon concrète. C’est une vraie démo qui se déroule entièrement sur mon terminal, je n’ai pas de slide. Dans le marché très concurrentiel de l’IT où chacun essaie de vendre son produit, ce n’est pas simple pour le décideur et le client final de comprendre de quoi il s’agit. D’autant que Docker est un sujet très bas niveau. Jusque-là, le client final était toujours maintenu au niveau des couches les plus hautes, et là il faut lutter avec des options de compilation du Kernel. Moi, j’aime ça, mais ce n’est peut-être pas le cas de tout le monde !

Pourquoi un tel effet de mode autour des containers ?

C’est un écosystème qui fonctionne beaucoup à la hype et au marketing et aux annonces du type “on va faire tourner Kubernetes au-dessus de DC/OS”, ce qui n’a pas de sens étant donné que les deux sont concurrents. Il y a tellement d’annonces dépourvues de sens qu’il faut naviguer au travers du marketing pour décoder. Les containers sont une technologie qui vient du Kernel, qui sont utilisées dans le Kernel depuis des années, nous l’utilisons tous sans le savoir. “Container” est un terme très bien choisi d’un point de vue marketing, beaucoup moins d’un point de vue technique. Un container, c’est un processus qui tourne à côté d’un autre. Ce n’est pas de l’isolation, c’est de la réservation plus ou moins forte de ressources par les processus. Ces processus, nous les utilisons depuis des années, et les multiples tentatives du Kernel pour verrouiller les processus existent depuis des années. C’est aussi ce qui explique qu’au départ Google ait été si virulent envers Docker, parce qu’il y avait beaucoup de marketing autour d’un travail fourni depuis des années par Google, celui de la sécurisation du Kernel.

Qu’est-ce qui explique que Docker ait décollé et que RKT reste confidentiel ?

Beaucoup de marketing et de communication, un discours qui entretient le flou, plus de 300 meetups en 90 jours dans la Silicon Valley… et puis à partir du moment où les conteneurs ont été présentés comme des VM légères, cela a fait le succès de Docker. On a alors entendu tout et son contraire, comme le fait de pouvoir régler le problème des multi-devices sur Android en dockerisant les applications Android. Ou de prendre les binaires de dev pour les amener sur la production, ce qui est un non-sens. Beaucoup d’effets d’annonce donc. Par ailleurs, quand Docker s’est lancé (à la base, c’était un script Python), ils ont raflé la mise du “premier soft connu en Go”: l’écosystème Go cherchait une reconnaissance, un projet emblématique, qui devienne un point de référence et légitime Go, et Docker est arrivé à point nommé pour remplir ce rôle. C’était un mouvement très malin.

Quel est l’intérêt de Docker du point de vue du DevOps ?

Il est vrai qu’avec Docker on peut construire des outils DevOps, mais pour moi, ce n’est pas un outil DevOps en tant que tel. Docker n’amène pas toute une chaîne de déploiement continu, mais Docker est un outil qui permet de construire le DevOps, et qui a été conçu dans la philosophie des infrastructures immutables, qui est une des racines du DevOps. C’est donc un outil du DevOps, mais ce n’est pas le seul, il y en a de nombreux autres. Docker a contribué au décollage du DevOps, mais rappelons que le DevOps est plus une méthodologie que des outils.

Comment situez-vous Docker dans l’éco-système du Cloud ?

C’est paradoxal, Docker est à la fois un enfant du Cloud et un anti-Cloud. Pour les extrémistes de Docker, on va arrêter la virtualisation et aller sur du bare metal pour obtenir le maximum de performance du CPU. Aujourd’hui la communication de Docker va dans ce sens, en insistant sur le gain de performances par rapport à du VMware. Pourtant, parmi les premières utilisations de Docker, on peut citer dot Cloud(Ex-Docker), qui a commencé à rentabiliser son investissement sur de larges instances Amazon réservées à l’année en divisant ces instances par lots avec des conteneurs. De fait, j’irai jusqu’à dire que Docker est un enfant de la politique tarifaire des fournisseurs de Cloud public, plus qu’une réponse à une vraie problématique technologique.

Est-ce qu’il y a des cas d’usage type de Docker ?

L’intégration continue (CI) est un très bon cas d’usage de Docker. Dans certains cas isolés, il est possible de faire du run. Sur des très larges infrastructures, il est possible de gagner en performance et construire du pur Docker peut avoir du sens. A contrario, nous avons essayé de concentrer de la BDD avec du Docker, mais nous avons arrêté suite à de gros problèmes de stabilité.

Est-ce qu’il est risqué de passer en production avec Docker ?

Ce n’est que mon avis et tous ne le partageront pas, mais je considère que dans une infrastructure normale, certaines applications sont en danger, d’autres ne le sont pas. Établir un modèle de menace demande de décider comment réagir à chaque type de risque. Or, faire du Docker en production, c’est s’exposer à ouvrir dans son modèle de menaces l’idée que chaque application puisse parler à une autre. Faire de la production d’une seule entreprise sur une même machine ne me choque pas, par contre utiliser des applications tiers sur des machines en containers Docker expose à un vrai risque de sécurité. Ma politique est de considérer toute application comme potentiellement corrompue, et donc il n’est pas acceptable qu’une application puisse remonter dans une autre. Pour autant, il existe de nombreux cas d’usages, comme la CI, qui est est probablement le meilleur cas d’usage de Docker qui soit.

Quentin animera le talk « Virtualization  and containerization, how do those technologies work and relate to each other? » lors du TIAD Camp Docker le 6 Octobre prochain :