Le projet Docker fête ses 10 ans ! Retour sur une décennie de conteneurs

Le 15 mars 2023 marquait le 10e anniversaire du célèbre lightning talk de Solomon Hyke à PyCon, où il a fait découvrir Docker au monde entier.

Revenons sur tout ce qui a changé et découvrons les témoignages de personnes qui ont ouvert la voie vers le monde conteneurisé dans lequel nous vivons aujourd’hui. J’ai ouvert mon petit carnet d’adresses de contacts spécialisés dans les conteneurs et le cloud natif, et je leur ai demandé de raconter leurs débuts avec Docker et de partager quelques anecdotes du terrain, depuis notre première rencontre avec Moby et Molly, il y a dix ans.

Bonjour wowrld !

Solomon Hykes s’exprimant à PyCon 2013

En 2013, le monde découvrait Docker. Pour beaucoup de développeurs, c’était notre premier contact avec les concepts de cgroups, d’espaces de noms et d’autres technologies Linux utilisées pour « isoler » les processus. Comme les équipes de Docker aiment le dire, elles ont « démocratisé » la technologie des conteneurs, en la rendant facile à utiliser sans diplôme en administration de systèmes Linux.

Époustouflant et magique

Certains adjectifs revenaient souvent lorsque je demandais aux gens de me parler de leur première expérience avec Docker : magique, époustouflant, ou encore « révélation ».

Nirmal Mehta prenant la parole à DockerCon 2015

Imaginez la scène ! Portland, dans l’Oregon, en 2013, à la conférence OpenSource d’O’Reilly. Quelques mois après la naissance du projet open source Docker, celui-ci gagnait déjà en popularité au sein de différentes communautés informatiques : open source, cloud, DevOps, etc. C’était le dernier jour de la conférence et j’assistais à une session matinale, un vendredi, consacrée à cette nouveauté appelée Docker ! Solomon Hykes était l’intervenant. Il est entré directement dans le vif du sujet en expliquant les concepts de couches de conteneurs, leurs capacités et les technologies sous-jacentes. Il a conclu sa présentation par une démo où, si ma mémoire est bonne, il a lancé 5, 10, 15, 20 conteneurs apache/httpd en quelques secondes ! Même devant le petit public encore ensommeillé de ce matin-là — et moi tout particulièrement — c’était époustouflant… J’ai tout de suite eu le sentiment d’assister au début d’un changement de paradigme, et je voulais tout savoir !

Je sais que Docker n’était pas le premier à assembler ces technologies sous-jacentes pour créer des processus ou des conteneurs isolés, mais l’expérience utilisateur présentée ce jour-là — et qui perdure encore aujourd’hui — était magique.

- Nirmal Mehta, Principal Specialist SA chez AWS

Brandon Mitchell bien emmitouflé dans des vêtements aux couleurs de Docker

Je me souviens de ma première utilisation de Docker, après avoir suivi toutes les étapes nécessaires pour configurer une VM afin d’exécuter nginx avec des outils comme Ansible et Chef. Je passais une heure à créer un playbook, à le configurer pour la VM qui venait d’être lancée, puis j’attendais que l’installation s’exécute. Ensuite, j’ai lancé la commande Docker pour démarrer nginx et, moins de 30 secondes plus tard, le processus était lancé dans cet environnement isolé magique. C’est ce qui m’a donné envie de découvrir ce qui venait de se passer et comment Docker fonctionnait.

- Brandon Mitchell, Solutions Architect chez BoxBoat, une entreprise IBM

Découvrir Docker, c’était comme découvrir des pouvoirs magiques. J’avais déjà vécu cela lorsque la virtualisation avait remplacé les serveurs : je pouvais regrouper des VM sur une infrastructure physique et en tirer le meilleur parti. Docker, c’était comme descendre d’un niveau dans un autre rêve : je pouvais désormais regrouper des applications dans des VM et exploiter encore mieux le matériel.

- Adrian Goins, ancien Developer Advocate chez Rancher/SUSE

Andy Clemenko, pionnier de Docker et ingénieur de terrain

Début 2015, mon employeur m’a demandé de devenir un expert « Docker ». Je connaissais très peu de choses sur le sujet, à part quelques articles du site Orange, alors j’ai commencé à expérimenter. Comme tout le monde, j’ai commencé par le classique exemple « hello world » de Docker avec Nginx. Pour moi, la révélation a été immédiate. En tant qu’administrateur système de longue date, j’ai vu dans l’isolation des processus une avancée majeure. À partir de ce jour, j’ai réorienté toute ma carrière vers les conteneurs. J’ai eu la chance d’aider le gouvernement américain à adopter les conteneurs dans plusieurs agences. Un an et demi plus tard, j’ai eu la chance de poursuivre l’aventure Docker en rejoignant l’entreprise.

- Andy Clemenko, Field Engineer chez  Rancher Government Solutions

Scénario catastrophe

David Flanagan, qui a adopté Docker dès sa première année, a rapidement compris comment cette technologie pouvait révolutionner les déploiements dans son entreprise.

David Flanagan, fondateur de Rawkode Academy et papa sympa

J’ai découvert Docker grâce à la démo de Solomon à PyCon en 2013. À l’époque, je travaillais comme directeur du développement pour une entreprise britannique de radio et de magazines, et j’essayais de l’aider à faire entrer son activité dans le XXIe siècle… la transformation numérique, quoi ! Son principal problème était la montée en charge. Nous avions même un scénario « catastrophe » : « Que faire si Lemmy de Motörhead meurt ? » Notre charge était extrêmement prévisible… jusqu’à ce qu’elle ne le soit plus. Impossible de prévoir l’actualité : il faut pouvoir monter en charge en temps réel, aussi vite que possible.

Nous utilisions Vagrant et des VM depuis quelque temps, mais les mettre rapidement à l’échelle était pénible. Il fallait surdimensionner l’infrastructure au départ, puis la réduire rapidement après l’« événement » afin de diminuer les coûts. Alors, quand nous avons découvert Docker, ça a été une révélation. Sauf que… à l’époque, Docker n’avait pas encore de commande « docker build »… Elle est toutefois arrivée peu après, avec le slogan toujours utilisé aujourd’hui : « Build. Ship. Run ». Docker n’a pas seulement résolu le problème de l’exécution : la création d’images de conteneurs est devenue incroyablement simple, et leur distribution aussi. Kubernetes et le cloud natif doivent énormément à l’équipe dotCloud des débuts, quel que soit le moteur d’exécution de conteneurs que nous utilisons aujourd’hui.

- David Flanagan, fondateur de Rawkode Academy

Stabiliser la grille

J’utilise moi aussi Docker depuis ses tout débuts et, si vous me permettez de le dire, voici comment cela s’est passé pour moi.

Capture d’écran du tweet de James Spurin : James Spurin, Eric Smalling, Bret Fisher, Chad Crowell, Kunal Kushwaha et Ramesh Kumar à KubeCon 2022

J’ai commencé à expérimenter Docker fin 2013, en l’intégrant à nos pipelines CI pour exécuter des centaines de tests fonctionnels de bout en bout à chaque commit d’une importante application web de commerce en ligne. Aux heures de pointe, nous lancions souvent plus de 2 000 instances de navigateur via des grilles Selenium2 basées sur des VM. Les résultats de tests instables, dus aux problèmes de stabilité de la grille, étaient notre pire cauchemar. Nous lancions et arrêtions constamment des instances dans le cloud et avons essayé différentes stratégies au fil des ans pour accélérer les démarrages, assurer la stabilité et réduire les coûts. Nous avons même testé les instances spot et nous sommes livrés à des guerres d’enchères dans plusieurs régions ! 

Nous avions déjà commencé à utiliser Docker pour exécuter l’application web et les contrôleurs de la suite de tests, mais j’ai eu une révélation en comprenant que je pouvais créer une image contenant le navigateur et xvfb, puis la démarrer instantanément. Nous avons ainsi pu faire fonctionner des grilles Selenium stables avec autant de navigateurs qu’un seul nœud pouvait en accueillir ! (Nos problèmes de stabilité venaient généralement de l’incapacité des nœuds à faire tourner de nombreux navigateurs, ce qui nous obligeait à utiliser beaucoup de petits nœuds avec peu de navigateurs sur chacun.) La réussite a été telle que nous avons pu abandonner en grande partie les instances cloud et utiliser seulement quelques VM locales pour ces grilles, économisant ainsi des milliers de dollars par semaine.

- Eric Smalling, Sr. Developer Advocate chez Snyk

Convaincre le plus grand nombre

Pour les personnes qui découvrent le développement logiciel en entreprise, les avantages des conteneurs et de l’écosystème qui s’est développé autour d’eux peuvent sembler aller de soi. Pourtant, pendant les cinq ou six premières années, l’avenir de Docker était loin d’être assuré.

Les résultats parlent d’eux-mêmes

Le changement est souvent difficile à accepter, mais les avantages concrets de Docker ont vite convaincu :

J’avais l’habitude d’introduire de nouvelles technologies à la mode. Alors, j’entendais souvent des soupirs exaspérés : « Dave a encore trouvé un nouveau jouet ». La plupart de mon équipe utilisait un Mac, alors vous imaginez : ils ne m’appréciaient pas vraiment !

Mais chez nous, Docker était principalement utilisé côté serveur. boot2docker n’existait pas encore, alors l’équipe a continué à utiliser Vagrant pour le développement. Nous avons fini par intégrer Docker à cet environnement, lorsque l’intérêt de la chose est devenu évident. L’équipe a constaté à quel point cela simplifiait notre pipeline de déploiement, et s’est laissée convaincre.

Difficile de contester quand nos déploiements sont passés de 40 minutes à environ 3 !

- David Flanagan

Sevi Karakula fait bouger les choses !

Lorsque j’ai découvert Docker, j’étais développeur logiciel depuis assez longtemps pour savoir à quel point il peut être difficile d’intégrer un nouveau membre à l’équipe et de lui fournir tous les outils nécessaires. De même, chaque fois que nous essayions d’introduire de nouveaux frameworks et langages dans l’environnement de développement — pour alléger un peu les choses —, cela tournait souvent au casse-tête, car la plupart des développeurs réagissaient en levant les yeux au ciel.

Docker nous a grandement simplifié la vie : il suffisait de présenter cet outil magique à l’équipe pour qu’elle en voie immédiatement les avantages, sans avoir à gérer toute la complexité de l’installation et de la configuration. Ce fut un grand moment d’émancipation pour les développeurs : plus besoin d’installer chaque outil sur une machine étroitement surveillée, de relancer des demandes d’autorisation ou de se soucier des licences. Dès lors qu’une image existait, tout était possible.

- Sevi Karakulak, Engineering Lead chez Container Solutions

Pas « prêt pour l’entreprise »

L’expression « prêt pour l’entreprise » est subjective et peut avoir un sens différent pour chaque entreprise avec laquelle vous travaillez. Matt Bentley raconte comment, à ses débuts comme Solutions Engineer chez Docker, il a dû répondre à la question de savoir si Docker était « attrayant » — ou, en l’occurrence, ne l’était pas.

Matt Bentley à DockerCon 2019

… le client adorait Docker en tant que technologie, [et] il appréciait le produit Docker Trusted Registry. Mais tant que nous n’aurions pas proposé autre chose qu’une interface reposant uniquement sur une API et la ligne de commande, sa direction ne considérerait jamais le produit comme prêt pour l’entreprise.

Le client devait présenter les produits en interne. Si je lui montrais ce que j’avais fait avec un pipeline CI/CD construit dans Jenkins — récupérer le code, le compiler et le tester dans un conteneur, le déployer, puis promouvoir l’image —, les équipes ne comprendraient pas. Pour elles, une solution prête pour l’entreprise devait offrir de belles interfaces utilisateur.

- Matt Bentley, Manager, Solutions Engineering chez VMware

Une hésitation plus fréquente concernait l’immaturité relative du projet. Même si les technologies sous-jacentes existaient depuis de nombreuses années, beaucoup hésitaient à miser sur un projet open source issu d’une start-up, avec ses mascottes de dessin animé et sa tortue de compagnie qui effectuait des déploiements.

Rachel Leeken et Eric Smalling à KubeCon EU 2022

J’ai commencé à découvrir Docker en 2015 et, au vu de son potentiel, j’ai proposé de l’étudier pour moderniser notre environnement plutôt que d’utiliser la solution ancienne et coûteuse d’un fournisseur. Le client n’a pas voulu l’adopter : il nous a dit qu’il n’était pas sûr de la technologie des conteneurs ni de sa pérennité pendant les cinq années du contrat.

- Rachel LeeKin, Containers Specialist SA chez AWS

Se tirer une balle dans le pied

Parfois, le plus difficile n’était pas de convaincre une équipe d’adopter les conteneurs, mais de lui apprendre à bien les utiliser.

Adrian Goins et l’Iron Condor, son quad paramoteur

Au début, il était difficile de convaincre mes clients de s’y mettre… Ceux qui comprenaient l’idée ne voyaient pas toujours les avantages ni comment tirer parti d’un conteneur. Je me souviens d’un client qui se connectait à ses conteneurs pour y recompiler son application ou ses dépendances, puis validait le conteneur comme s’il s’agissait d’un dépôt de code. Leurs conteneurs de production étaient énormes et probablement plus fragiles que leur infrastructure d’origine, sans conteneurs.

- Adrian Goins

L’intérêt grandit

Au fil des années, de plus en plus de personnes ont commencé à voir le potentiel des conteneurs, notamment à mesure que les orchestrateurs ont mûri — même s’ils ont apporté leurs propres défis. Adrian Mouat (@adrianmouat | @adrianmouat@hachyderm.io), auteur et autre Docker Captain de la première heure, se souvient des premières conférences DockerCon et de l’effervescence qui régnait alors que de plus en plus de personnes commençaient à s’intéresser au sujet et que des entreprises proposaient des solutions pour répondre à leurs besoins.

Adrian Mouat avec Betty Junod, Eric Smalling et Matt Jarvis à KubeCon NA 2022

Je me souviens surtout qu’en 2014, les intervenants — moi compris — demandaient : « Qui utilise Docker ? » Une forêt de mains se levait. « Qui utilise Docker en production ? » Presque toutes les mains retombaient.

Cela dit, le nombre de personnes qui utilisaient Docker en production avant même sa version 1.0 (octobre 2014) et sa déclaration d’aptitude à la production était stupéfiant.

Nous utilisions des métaphores maritimes et parlions de la façon dont cela réglait le problème du « ça marche sur ma machine » — malheureusement, k8s est arrivé et a recréé le même problème.

Quand je travaillais chez Container Solutions, nous avons contribué à organiser le premier Docker Con EU au NEMO Science Center. L’enthousiasme était incroyable ; tout le monde savait assister aux débuts de quelque chose d’important. CoreOS était présent (avec le lancement de Rocket !), Alexis Richardson faisait la promotion du réseau Weave, Luke Marsden dirigeait ClusterHQ et le gestionnaire de données Flocker, et Timo Derstappen faisait des choses remarquables avec Giant Swarm. Les entreprises étaient partout, essayant simplement de comprendre ce qui se passait.

- Adrian Mouat, Product Manager chez Chainguard

Bret Fisher remporte le prix « Tip of the Captains Hat » à DockerCon 18 Europe

J’ai assisté à la conférence de Solomon à PyCon 2013 et j’ai essayé Docker en 2014 pour améliorer nos tests Node.js, mais je n’ai tout simplement pas compris. Je n’arrêtais pas d’essayer de faire tenir un serveur entier dans une image de conteneur (sans succès), et le réseau relevait pour moi de la sorcellerie. C’était un tel amas de nouvelles notions et d’automatisations magiques que j’ai abandonné, puis je suis revenu six mois plus tard. Cette fois, j’ai compris — et ça m’a frappé de plein fouet. Le trio 1-2-3 : créer des images, les stocker dans des registres et lancer des conteneurs à partir de celles-ci, m’a époustouflé. Je ne suis jamais revenu en arrière.

- Bret Fisher, expert DevOps et créateur de Docker Mastery

Les orchestrateurs

Si l’annonce de Docker à PyCon 2013 a été l’étincelle qui a allumé le feu, l’arrivée des plateformes d’orchestration de conteneurs a été le vent qui a embrasé la forêt. Mesosphere, Rancher, Swarm, Nomad et Kubernetes ont été les « applications phares » qui ont véritablement fait décoller les conteneurs. On a beaucoup écrit sur les avantages et les inconvénients de chaque plateforme, mais on ne saurait trop insister sur leur rôle dans la généralisation des conteneurs.

Kubernetes est aujourd’hui la plateforme dominante, mais Swarm compte toujours une communauté très fidèle, et Nomad conserve lui aussi quelques poches de popularité. Mesos est antérieur à Docker, et je suis sûr qu’il a encore un nombre considérable d’utilisateurs. Pour certains, Kubernetes semblait trop complexe, mais, comme le montre sa part de marché, la plupart ont fini par l’adopter.

À l’arrivée de Kubernetes, je l’ai détesté. C’était une couche d’abstraction supplémentaire qui n’apportait pas grand-chose… jusqu’au jour où ce fut le cas. Alors, je l’ai adoré : je pouvais prendre ces serveurs, avec leurs VM et leurs conteneurs, et en faire un petit centre de données. Le fait qu’un processus veille sur tout ça 24 heures sur 24, 7 jours sur 7, me permettait de faire autre chose.

- Adrian Goins

Même si Kubernetes est désormais la norme de fait pour déployer des conteneurs, il est intéressant de voir l’évolution de ce domaine et le nombre d’abstractions qui se créent autour.

Quand il est devenu évident que les orchestrateurs seraient essentiels à l’adoption des conteneurs à grande échelle, je pensais qu’il y aurait de la place pour plusieurs orchestrateurs majeurs. Chacun avait ses points forts et ses cas d’usage idéaux. Ce que j’aimais avec Swarm, c’est que je pouvais prendre une personne qui maîtrisait les simples commandes docker run ou savait créer un fichier Docker Compose facile à comprendre, et déployer un service Swarm en quelques minutes. La simplicité de la CLI docker et d’outils comme Docker Compose était remarquable : si quelqu’un savait lancer des conteneurs sur un hôte avec l’un ou l’autre, il lui était facile de passer à l’orchestration. Aujourd’hui, le secteur s’efforce de masquer Kubernetes aux développeurs, car il détournait trop leur attention du développement pour la reporter sur l’orchestration. Le temps que les développeurs consacrent à l’orchestration est autant de temps en moins pour apporter de la valeur métier avec les applications qu’ils développent.

- Matt Bentley

Des carrières et des vies transformées

Moby, la baleine, dans les anciens bureaux de Docker à SFO

Le point commun entre toutes les personnes que j’ai contactées pour cet article, c’est la façon dont le projet Docker et la communauté qui s’est développée autour ont changé la carrière et, en fait, les moyens de subsistance de tant de personnes.

Je savais que c’était la prochaine évolution de l’infrastructure. J’en étais obsédé et j’ai réorienté toute ma carrière vers les conteneurs.

- Bret Fisher

À partir de ce jour, j’ai entièrement réorienté ma carrière vers les conteneurs… Aujourd’hui encore, je m’emploie à informer et à guider le gouvernement américain dans son parcours vers les conteneurs. C’est incroyable de voir une technologie aussi transformatrice durer depuis 10 ans.

- Andy Clemenko

Plus j’en apprenais, plus les possibilités offertes par la conteneurisation me passionnaient. J’ai fini par enseigner Docker, puis j’ai décidé de réorienter ma carrière vers les conteneurs, puis Kubernetes. Avec le recul, je peux affirmer sans hésiter que Docker a changé ma vie.

- Sevi Karakulak

Snyk aime l’open source

Nous saluons les dix années de travail transformateur du projet Docker, comme en témoignent les témoignages éloquents cités ici, ainsi que les millions de développeurs qui créent, livrent et exécutent chaque jour des applications dans des conteneurs partout dans le monde.

Snyk a été fondée en 2015 avec pour objectif de permettre aux développeurs d’écrire du code et d’utiliser des logiciels open source en toute sécurité — y compris dans les conteneurs où ils les exécutent. Convaincus du pouvoir et de l’importance du modèle de développement open source, nous proposons gratuitement nos outils d’analyse aux développeurs individuels depuis le premier jour.

Contributeurs

Merci à toutes les personnes qui ont contribué à cet article !