Nous recevions récemment dans nos locaux parisiens, Jérôme Petazzoni de passage à Paris pour un set de formations Kubernetes accompagné de Sébastien (Enix.io). C'est donc autour d'une bière que nous avons pu échanger autour de Docker, des pratiques DevOp et bien sûr, du logiciel libre et de quelques trolls difficilement évitables.
Olivier Laurelli : Bonjour, pourrais tu te présenter Jérôme ?
Jérôme Petazzoni : Jérôme, j'ai passé 30 ans en France à être la caricature du barbu open source, je suis passé par plein de petites boîtes où je restais un ou deux ans, j'ai fait entre autres de la VOIP, du streaming, j'ai même fait du Plone...". Et puis ensuite on m'a proposé de rejoindre une startup californienne qui a fini par devenir Docker Inc, donc je suis resté 7 ans là bas, j'ai porté pas mal de casquettes, j'ai commencé par de l'admin, j'ai par exemple monté la plateforme sur EC2.
Olivier Laurelli : Tu viens de l'adminsys à la base ?
Jérôme Petazzoni : un petit peu les deux, j'ai toujours eu la double casquette développeur / sysadmin j'ai toujours aimé faire le métier de sysadmin en automatisant grâce à mes compétences de développeur et inversement faire le développeur qui arrive à être un peu à l'aise sur une plateforme parce que je l'ai déployé, que je sais comment ça marche, j'ai toujours eu les deux passions, pas de préférence ni de religion d'un côté ou de l'autre, c'est ça qui intéressait les fondateurs de Dotcloud à l'époque. Donc après quelques années en mode startup à 6 dans un garage à faire un peu de tout, l’entreprise a grandi, je suis devenu manager d'une petite équipe, puis quand on a fait le pivot vers Docker, il m'a fallu un petit moment pour vraiment me mettre sur Docker même, parce que j'étais celui qui continuait à faire tourner notre plateforme Dotcloud, jusqu'au dernier moment, c'est moi qui ai éteint la lumière avant de partir comme on dit. Et puis par accident, en 2013, j'ai commencé à donner des talks sur notre truc qui allait devenir Docker. C'est comme ça que je suis devenu Evangelist ou Advocate on peut dire ça... et avant que je puisse m'en rendre compte, je vivais avec une valise dans les aéroports. De 2013 à 2016 j'ai passé 50% du temps sur la route dans des confs, ça a été une chance extraordinaire parce qu'il y avait des conférences que je voyais de loin en me disant peut être qu'un jour j'irai assister à cette conf, et là je me suis mis à donner des talks à ces conférences. Docker ça m'a ouvert une porte parce que tout le monde voulait en entendre parler, savoir ce que c'était, et je me retrouvais à être un peu à l'intersection entre les gens qui savaient ce que c'était et qui voulaient bien en parler, ou inversement les gens qui en parlaient mais qui en plus avait un peu le background niveau containeurs, Linux, kernel etc...
Olivier Laurelli : Tu as senti des réticences au début ?
Jérôme Petazzoni : bien sur il y a eu beaucoup de réticences et j'ai essayé de faire des parallèles avec les réticences qu'on a eu autour de la virtualisation 10 ans avant, quand les gens disaient "il y a des trucs qu'on pourra jamais mettre dans des VM c'est pas possible". J'ai un souvenir comme ça quand je bossais dans la VOIP, j’entendais "Asterisk c'est pas possible tu te rends compte il y a du temps réel, on pourra jamais mettre ça dans des VM" et puis une semaine après, j’avais cassé les deux serveurs de préproduction, j'ai mis des Xen dessus, j’ai remis la préproduction dans les Xen. Maintenant on de la capacité en plus pour une seconde plateforme de qualification, et ça fonctionne. Pour les containers, j'ai fais pareil, j'ai essayé de jouer avec les gens qui avaient des réticences, c'était souvent des gens, je n’ai pas envie de dire de la vielle garde mais des gens qui avaient plutôt de l'expérience, de la bouteille, du vécu, donc je ne voulais pas arriver en leur disant « tais toi tu n'y connais rien », ce que je voulais, c'était faire un peu appel à cette expérience que j'ai vécu et qu'eux aussi ont surement vécu. Ce sont des gens qui savent faire du cloud de la virtualisation. Je leur disais « tu sais il y a 10 ans tu n’étais pas content parce que tu voulais mettre des VM pour consolider, pour automatiser, et les gens autour de toi trainaient des pieds, et bien avec les containers c'est pareil ». J'essayais de faire un parallèle un peu comme ça à leur expliquer que "non je ne veux pas tout mettre dans des containers, on va commencer par les trucs qui font gagner du temps, etc »... Donc voilà ça a été un peu ma mission jusque vers 2015/2016 et puis ensuite j'ai du ralentir un peu le rythme parce que ça ne suivait pas au niveau santé. Je me suis recentré un peu : au lieu de faire des talks, je me suis mis a faire des workshops. L'avantage du workshop, c'est qu'au lieu de faire sans arrêt un nouveau talk je peux faire évoluer un workshop dans le temps. Pour l'anecdote là on fait cette semaine des formations Kubernetes, on a une application de démo, le code de cette application de démo est un truc qui a été écrit il y a plus de 3 ans, en avril ou mai 2015 pour mon premier worshop d'orchestration sur Docker qui se tenait en juin 2015. Le code de l'application n'a pas changé d'une seule ligne depuis, puisque justement la mission c'est de dire : « bonjour on est développeur, on met du code dans des containers, maintenant il faut déployer les containers sur un cluster scalé, mettre du load balancing etc », donc je réponds au défi en prenant mes Docker build de 2015, je les fais tourner sur Kubernetes et ça marche. Donc le fait de faire des workshops ça permet d'itérer au lieu de faire un talk spécifique genre « sécurité et containers en multi-tenant sur du multi-cloud » et à chaque fois tu repars à reconstruire un truc from scratch. C'est sympa, c'est gratifiant, mais niveau charge de travail c'est pas pareil. J'ai, petit à petit, voulu faire des workshops sur Docker, sur Swarm puis sur Kubernetes... et depuis mon départ de Docker au début de l'année, on fait plutôt de la formation payante. Ça me permet de me donner un petit peu le temps de voir venir et de réfléchir à ce que je veux faire l'année prochaine et aussi de me re-permettre de bosser avec des potes que j'avais laissé à Paris il y a bientôt 10 ans et qui ont eux continué à faire tourner la boutique.
Olivier Laurelli : Oui tiens vous êtes combien maintenant chez Enix ?
Sébastien : il me semble que là on est 8, il y a un 9e qui arrive en décembre et si on résume ce qu’il s'est passé, c'est qu'on a réussi à faire venir plus de potes pour venir travailler avec nous, ce qui fait qu'on a atteint une masse critique maintenant qui nous permet de nous structurer vraiment comme une société qui est prête à proposer des services et qui n'est plus une société de prestation de personnes. Jusqu'alors chez Enix il y avait des gens compétents mais les clients venaient voir Enix parce qu'ils voulaient les gens compétents dedans. Alors que maintenant on devrait réussir à sortir des choses et les gens viendront parce qu'Enix a une image de marque. Enix c'est des gens qui ont tous un point commun : faire du bon travail, et pour le client ce qui va rester c'est "Enix fait du bon travail".
Olivier Laurelli : Qui sont les plus gros contributeurs de Docker aujourd'hui ?
Jérôme Petazzoni : Whaou, je ne l'attendais pas du tout cette question ... honnêtement je n'en sais rien, mais si on voulait répondre, je pense qu'on pourrait aller prendre juste les repositories Docker et faire un coup de git dm ou je sais pas quoi pour analyser un peu. Je me rappelle l'avoir fait il y a quelques années et on voit qu'il y a beaucoup de Docker Inc, sans mystère... et puis il y a des bouts où de mon point de vue, enfin ce que je vais dire date d'il y a au moins deux ans, je savais identifier des gens précis dans certaines grosses boîtes comme RedHat qui avait contribué sur des choses précises. Chez RedHat par exemple il y a Alex Larson et Vincent Batz qui ont fait un boulot énorme. Alex Larson je crois qu'il est aussi très connu côté Gnome. Vincent Batz je sais pas trop sur quelle autre chose mais il y a des gens comme ça qui ont fait des contributions précises sur certains points... c'est une bonne question, joker !
Olivier Laurelli : Parlons de l'apport de Microsoft en terme de code
Jérôme Petazzoni : Alors il y a eu un apport, ce que je peux dire c'est que sur la partie Windows par exemple ils ont été très clean, la manière dont ils ont contribué le support Windows dans Docker, ça a vraiment été dans les règles de l'art en faisant de la pull request qui a été review comme il faut, il y avait une volonté des deux côtés de dire « on va sortir Docker sur Windows, au niveau business, ça va être énorme », mais il n'y a pas eu de coup de pied de biche d'un côté ou de l'autre pour faire entrer ça dans la codebase, tous les gens de chez Docker qui étaient dans la core team avec qui j'ai parlé de ça m'ont dit qu'ils étaient contents de la collaboration avec Microsoft. Ce qui m'avait vraiment ouvert les yeux (NDLR : sur les efforts de Microsoft vers le libre), c'était en septembre 2014, quand j'étais en mode VRP, j'étais allé parler à un meetup Docker à New York, c'était chez Microsoft, et comme Microsoft commençait à fait des trucs avec Docker sur Azure ... Puis quand j'ai commencé à regarder la doc d'Azure, je me suis rendu compte que le source était sur Github dans un dépôt public en Markdown et là j'ai fait "Waw !". Alors oui il y a beaucoup d’entreprises qui ont leur documentation en Markdown dans un dépôt public sur Github mais venant de chez Microsoft, je me suis dit qu'il s'était passé quelque chose pendant qu'on regardait ailleurs. Il y a eu une grosse transformation et quand je parle avec des potes qui sont là bas, ils me disent qu'une bonne partie de leur travail c'est de changer cette image pour montrer que Microsoft a changé.
Olivier Laurelli : Ça fait quand même des années que Microsoft est le plus gros contributeur du logiciel libre, ce n'est pas tout nouveau (du moins financièrement). Sinon qui sont les plus gros utilisateurs de docker ?
Jérôme Petazzoni : Heu là c'est comme si tu me demandais qui sont les plus gros utilisateurs de Linux... je ne veux pas dire que c'est les mêmes mais je pense qu'on est passé très discrètement, à pas de velours, du mode où il fallait chercher les utilisateurs de Dockers désespérément « vous êtes où les gars ? », personne levait la main, et d'un coup s'est retrouvé, je vais pas dire quasiment tout le monde, mais tu vas prendre des développeurs comme ça en random et y'en a peut-être la moitié qui vont dire « ouais j'ai Docker sur mon desktop, peut- être que je m'en sers pas tous les jours mais de temps en temps je vais lancer un docker run d'une image »... donc il y a un peu de tout, bien entendu ça va plutôt être les entreprises qui vont être un peu plus à la pointe, mais on trouve aussi de la bonne grosse IT de banques ou d’assurances qui s'y sont mises assez vite.
Mathieu Lecarme : Il y a eu une grosse phase de conquête de Docker, ça avançait au fur et à mesure jusqu'au moment ou on a eu Kubernetes, Containerd etc.... alors maintenant que Google a mis ses gros pieds dans le plat avec Kubernetes en disant que c'est eux qui avaient la main sur les spécifications et tout, il reste quoi comme place pour Docker par rapport à ça ?
Jérôme Petazzoni : ce que je vais dire là, ça date déjà un peu parce que c'est au moment où je suis parti de chez Docker. Il y a eu un virage, on passe un peu d'une boite open source à fond les ballons à une boite ou la réalité du terrain nous rattrape. Le but c'est quand même de faire gagner de l’argent, donc il faut avoir de vraies offres commerciales, de vrais produits... Heureusement ça faisait un bon moment que c’était entamé, c’est Roger Gan qui est SVPCM qui est arrivé en 2014 / 2015 et qui a commencé tout ce truc en amont : tu sais les cycles de vente super longs ou tu vas vendre des contrats de maintenance sur 250 noeuds à des structures comme Visa, Paypal etc, tout ça c'est des trucs initiés il y a déjà plusieurs années. Justement parce que c'est des cycles longs, il va falloir deux ans avant de signer le contrat. Ça commençait à porter ses fruits quand je suis parti, avec des entreprises dont je ne connaissais pas toujours le nom parce que c'était de grosses boites US, puis quand tu regardes tu fais « ah ouais quand même... ». Donc ce virage il n’a pas été anodin parce qu'on est passés d'un mode où par exemple mon rôle c'était de m'assurer que les gens puissent utiliser Docker, et souvent c'était juste expliquer « tiens tu peux faire ça, changer deux lignes dans ton Docker build etc ... » mon rôle est alors passé après à « maintenant on veut que les ops, les gens qui font de la production, se sentent en confiance » et ne se disent pas « tiens, ça tient avec des élastiques, qu'est-ce qu’il se passe ?». Et ça se reflète aussi côté business, parce qu'au lieu d'avoir juste un barbu comme moi qui fait la tournée des conférences, on s'est retrouvés à avoir une armée d'avant-vente, après-vente, support, pour accompagner les clients pour de vrai, en mode tickets.
Olivier Laurelli : C'était combien de personnes Docker Inc au moment où tu es parti ?
Jérôme Petazzoni : Alors quand je suis parti c'était entre 400 et 500, oui ça a vraiment explosé, quand je suis arrivé on était 6, la boite s'est transformée plusieurs fois et ce virage, je pense que forcément, il y a plein de gens qui ont du mal le vivre, parce que l'être humain en général déteste le changement, et quand tu passes de la start up à...
Olivier Laurelli : Oui déjà tu changes 4 fois de locaux par an...
Jérôme Petazzoni : Oui quasiment tous les ans en fait, moi j'ai vu 4 bureaux différents. On en a eu un où tu avais plus de plantes que d'humains. On pouvait se cacher dans les feuilles et tu avais des batailles de Nerf qui partaient comme ça... là on était encore en mode startup à la cool, et puis après, un moment donné tu évolues, et là tu as des gens qui vont se plaindre de plus pouvoir jouer au babyfoot. Un moment donné il faut aussi se rendre compte qu'on est là pour bosser, pour produire, pour livrer des trucs. Une chose intéressante, on faisait régulièrement des sondages internes pour prendre la température de la boite et tu avais une question qui revenait tout le temps, et qui était « est-ce que vous pensez que Docker Inc fait trop d'open source, pas assez d'open source ou juste assez ?», et tu avais toujours une courbe de Gauss avec des gens qui pensaient qu'on en faisait pas assez, d'autres qui pensaient qu'on en faisait trop. Et ça n'a pas tant évolué que ça au fil du temps. Je pense qu'on s'est mis à faire plus de business et peut-être un peu moins d'open source en proportion mais que je pense qu'au fur et à mesure, les gens à qui ça plaisait pas de changer un peu d'horizon le vivaient mal. Moi ça m'a beaucoup fait murir sur les modèles de l'open source, je partais de « on va faire du libre c'est magique », et puis j'ai vu l'envers du décor et je n’ai plus du tout les mêmes réactions... tu vois par exemple je serais curieux de savoir comment j'aurais réagit il y a 10 ans à l'annonce de Redis faite il a peu quand ils ont décidé de passer certains modules de Redis en Common Close, j'ai vu des réactions hyper violentes en me disant « les gars ... déjà sur les réactions violentes que je vois je suis sur qu'il y en a 90% qui n'ont jamais contribué une ligne à Redis » et ensuite ça concerne quelques modules spécifiques, pas le core. Donc oui je pense que ça m'a fait murir parce que ça m'a mis dans la situation du mainteneur en face qui s'en prend plein la tête tout le temps, et du coup ça ma permis de développer une certaine empathie par rapport à ça et j'espère être devenu un bien meilleur "citoyen". J'ai conscience grâce à Docker de m'être construit une espèce de plateforme et j'essaie d'en profiter pour faire passer ce que j'espère être de bons messages, en espérant ne pas me planter. J'adore la comparaison free beer ou free speech mais tu vois il y a un 3e côté, le « free puppy ». Quand on te file un chat ou un chien, il faut que tu t'en occupes derrière, c'est gratuit mais si tu ne t'occupes pas de ton chien ou de ton chat, il va crever et tu seras un salaud. Donc ce côté là, l'open source où il faut maintenir un peu les choses, il faut aussi comprendre que ça ne s'alimente pas d'amour et d'eau fraiche.
Olivier Laurelli : Tu passes combien de temps à répondre aux questions de la communauté ?
Jérôme Petazzoni : Il y a eu une période où je le faisais énormément, alors la technique que j'avais c'est à l'époque ou on avait les mailing list Docker user et Docker devel, sur Docker user c'était de faire le rattrappeur de balles, il y avait beaucoup de questions où des utilisateurs et contributeurs répondaient directement. Je prenais les anciens messages de plus de 2/3 semaines pour y répondre. Je pense que ça a aidé, impossible de vraiment quantifier, puis au bout d'un moment, la masse de gens qui va répondre via différents canaux fait le travail. Aujourd'hui, répondre à la communauté je ne le fais presque plus dans le sens ou je ne suis plus sollicité. Avant ça arrivait beaucoup, en interne ou en meetup, en plus des gens qui te shootent un mail ou te ping sur Twitter. Il y en a beaucoup moins aujourd'hui, ça ne représente pas grand chose. Aujourd'hui il y a Stackoverflow, il y a un Discourse etc. qui sont assez actifs.
Olivier Laurelli : Docker, Inc se sent-il concerné par les releases packagées et maintenues dans les branches stables des distributions (principalement : Debian, RHEL) ? Ou alors en dehors du repo APT de Docker point de salut ?
Jérôme Petazzoni : Très bonne question, alors c'est une question qui m'embête dans le sens où il n’y a jamais LA bonne réponse facile, dès que tu as un soft qui bouge vite ce n'est pas simple.
Olivier Laurelli : Ça couplé à l'inertie de certaines distributions ... "quoi il n'y a pas Docker dans OpenBSD ?"
Jérôme Petazzoni : Oh je crois qu'il y a des tentatives dans FreeBSD. Enfin tu es toujours un peu entre le marteau et l'enclume. J'aime bien parce que j'ai une vue un peu des deux côtés... Je n’ai jamais été mainteneur Debian pour de vrai mais c'est une communauté que j'aime énormément et à laquelle je m'identifie beaucoup. Donc voir d'un côté les développeurs qui te disent « on va faire les packages nous mêmes parce que les mainteneurs de distro n’y connaissent rien » puis de l'autre côté tu as des gens, packager c'est un peu leur métier depuis une décennie et qui voient sortir ces packages avec des outils douteux et dans de sombres dépôts... Il y a un savoir faire énorme des deux côtés mais il y a des moment où les incentives sont pas alignés, c'est à dire que ce n’est pas toujours les mêmes buts visés, mais faut arriver à trouver un terrain d'entente. Il n’a pas toujours été trouvé et je le déplore parce que par exemple tu vas avoir sur RedHat ou Debian un package qui va être super vieux, et ça donne des mainteneurs qui ne sont pas contents, avec une campagne de dénigrement en face... et tu vas avoir des trucs parfois mérités, parfois non. Par exemple quand tu as une distribution qui te sort un package et qui a introduit un patch qui ajoute une faille de sécurité, c'est tendre le bâton pour se faire battre. Après je ne sais pas s'il y a une bonne solution ou si, peut-être d'avoir en interne des mainteneurs. On en était vraiment pas loin, on a collaboré avec des boites qui ont des mainteneurs Debian en interne, ça permet d'avoir une communication directe et non filtrée où les gens vont pouvoir te dire « écoutes, là tu fais de la merde » au lieu de « Peut-être devrais-tu envisager... ». In fine il n'y a pas de bonne solution car quand la distro te dit « on ne fait que des point releases ou des bug fix » mais que tu as un truc comme Docker qui itère très vite, surtout en début de vie, et que les gens veulent quand même foncer, je ne sais pas quelle est la bonne solution ... Est-ce qu'on fait un dowloader à la flash qui t'installe le truc ?... Il n’y a pas de bonne solution, je déplore la situation, je ne donne raison à personne c'est bien que les deux existent, ensuite la difficulté est d'être capable de dire que dans la CentOS 6 les limites du package Docker ça va être ça, ça et ça. La bonne nouvelle c'est que j'ai remarqué que depuis le début de l’année, le train de releases s'est bien calmé, c'est une bonne nouvelle
Olivier Laurelli : Ça va peut être motiver des packagers oui
Jérôme Petazzoni : Je pense que dans peu de temps, on va arriver au stade où dans une Debian ou une Ubuntu LTS tu auras un Docker 18.06 et l'année prochaine ce sera toujours un Docker 18.06 et ce ne sera pas grave. Par contre c'est vrai qu'avant tu avais beaucoup de nouvelles focntionnalités d’une version à l’autre, ça fusait et quand tu n'étais pas à la toute dernière version, tu ratais des petits morceaux et c'était dommage.
Olivier Laurelli : Le développement de Docker est devenu assez mature, il pourrait être packagé aujourd'hui ?
Jérôme Petazzoni : Tout à fait oui.
Mathieu Lecarme : Le fait de faire des specs avant ça aide à stabiliser aussi...
Jérôme Petazzoni : Oui après les spécifications ont beaucoup évolué.
Mathieu Lecarme : Je regrette pas du tout les versions qui avançaient avec de vraies features, je suis fan de faire des updates pour voir qu'il se passe quelque chose. Là il se passe plus rien donc je suis frustré, après derrière la tactique c'est d'abord que vous écriviez des spécifications, ensuite vous implémentez : les gens discutent au niveau des specs et ça avance tranquillement. Il y a une stabilité et quelque chose de beaucoup plus prévisible qu'avant, mais ça c'est quand on a atteint une vitesse de croisière pour pouvoir se permettre de le faire. Et puis un truc bizarre le fait de passer de AUFS à Overlay 2... quand c'est en production et qu'il faut changer le package qui change 4 fois au niveau des Debian ... il y avait des surprises comme ça. Après il n'y a pas de paquet qui va dépendre du paquet Docker donc ça simplifie les choses. Puis il reste le troll sur GoLang, comment on package GoLang pour pouvoir compiler Docker, les librairies qui vont avec et compagnie, mais ça ce n’est pas un problème Docker c'est un problème GoLang.
Jérôme Petazzoni : Oui absolument et rien que le mécanisme de build ça fait une des parties du conflit entre les gens qui développent Docker et les gens qui packagent, la méthode de build officielle c'est dans un container parce que comme ça tu as la bonne version de Go des dépendances etc... et bien sûr tu peux builder Docker en dehors d'un container mais tu vas avoir un binaire légèrement différent. En fait j'ai trouvé un peu le même raisonnement que ce qu'il y avait pour Firefox, c'est assez intéressant et je pense que Mozilla aurait du communiquer un peu plus la dessus. Tu sais c'était tout le débat Firefox contre Iceweazel dans Debian... ce que j'avais compris à l'époque c'était que Mozilla voulait absolument que ce soit le même binaire parce que sinon ça va se comporter différemment, il y avait un petit peu ça. Mais j'ai appris par la suite qu'il y avait un traitement en bulk des crash, des reports... et c'est vrai que de ce point de vue, tu préfères avoir 500 millions d'utilisateurs avec le même binaire plutôt que 50 millions qui ont un binaire compilé par Debian, 50 millions un binaire compilé par machin... quand tu veux faire du gros traitement bourrin sur tes crash et sur ta performance, le fait d'avoir 15 binaires dans la nature multiplié par le nombre de versions... quand j'ai lu cet argument là, j'ai trouvé que c'était vraiment un bon argument. Sans faire d'élitisme les gens qui utilisent Debian ont un certain background technique et une culture technique assez importante, et je pense que ce genre d'argument aurait pu les convaincre d'avantage. Se dire « effectivement on aime bien construire nos binaires mais on aime bien que les développeurs puissent avoir un retour qualité » ça a du sens, ce n’est pas une décision complètement arbitraire. Nous avons aussi eu ces débats en nous disant que ce serait bien qu'on ai le même binaire Docker Engine partout pour pourvoir traiter les incidents et qu'on puisse comparer avec tous les autres déploiements qui ont les mêmes versions, au lieu de se demander si ça ne vient pas d'une régression dans une dépendance.
Olivier Laurelli : Il y avait un vieux troll aussi qui trainait sur Docker Swarm vs Kubernetes, tu en penses quoi ?
Jérôme Petazzoni : je pense que Swarm a fait quelques petites erreurs stratégiques mais pas forcément celles qu'on va imaginer, alors il y avait le côté que c'était « trop peu trop tard », mais il y a eu aussi le truc qu'on a appelé Swarm Classic qui était le premier jet, c'était une espèce de Sy Project en mode hack de Victor Vieux et Andrea Luzzardi qui sont des gens de la core team qui se sont dit « tiens avec l'API Docker on peut très facilement mettre un coup de baguette magique pour que quand tu lances un docker run ça lance un container en local, ça fait une décision de scheduling ça met ton container quelques part et toi en utilisateur c'est comme si tu avais une grosse machine Docker ». C'était super en terme de prise en main, sauf qu'il y avait des choses qui manquaient côté API. Au bout d'un moment le message a finit par passer donc du coup on part sur ce qui a été appelé Swarm Mode, et le fait que ça s'appelle toujours Swarm, ça a créé une confusion, parce qu'il y a des gens qui se sont dit « moi Swarm j'ai déjà testé, ça ne me plait pas ». Alors que Swarm Mode c'était vraiment pas mal, je me rappelle des premiers retours, juin 2016, à DockerCon, j'avais formé une cinquantaine de personnes en leur faisant des démo... Ils avaient des étoiles dans les yeux parce que pour certains, ils avaient passé des semaines à essayer de monter un truc avec Kubernetes, et là on leur montrait un truc super simple qui marchait. Je pense qu'il y a toujours une place pour Swarm parce que ça s'installe hyper facilement... Il y a eu un gros message marketing de Docker "Swarm secure by default" : ce sont de petits détails, mais ce n’est pas que du marketing. Par exemple dans Kubernetes tu as un grand réseau à plat, tout le monde parle à tout le monde et quand tu veux filtrer, il faut mettre des network policies pour mettre des barrières entre tes déploiements, alors que Swarm, l'idée c'est que tu vas créer les réseaux un peu comme des VM, chaque application est sur son réseau et par défaut ça ne communique pas. Donc c'est vrai que pour quelqu'un qui arrive sans connaitre l'intégralité de la stack, tu as plus de chances de faire des bêtises avec Kubernetes qu'avec un Swarm. N'empêche qu'après, une fois que tu sais ce que tu fais, Kubernetes c'est une boite à outils magique avec des tournevis et des marteaux de toutes les tailles… c'est chouette, mais il y a beaucoup de gens pour lesquels Swarm c'est cool parce que tu as beaucoup moins de choses à connaître pour être opérationnel. J'arrive à montrer en une heure et demie comment setup un Swarm et déployer dessus une application micro service, et puis la scaler et faire des petites manipulations, comme monter en version un composant etc... Kubernetes je n’en suis pas là, il me faut au moins le double de temps, une demie journée, et encore à ce prix là on part avec des clusters pré-installés tout prêts. Après bien sûr l'accessibilité et le nombre de choses que tu peux faire avec Kubernetes ça plait bien plus, mais je pense qu'il y a des gens pour qui Swarm est une bonne alternative.
Mathieu Lecarme : L'arrivée de Swarm ça a massacré des fonctions Docker Compose, ça a cassé des trucs, ça c'était un peu frustrant. Je pense que la différence c'est que souvent le Kubernetes il est infogéré par quelqu'un d'autre alors que son Swarm on l'installe : au niveau des responsabilités on n’est pas du tout à la même échelle. Exemple : Kubernetes "moi je m'en fiche je pousse mes machins dans Kubernetes et après ce n'est plus mon problème". Ce joker des responsabilités intéresse plein de gens, même s'ils ne te disent pas explicitement.
Jérôme Petazzoni : Absolument, et oui disons qu'il y a quelques offres Docker un peu hostées, mais pas du même niveau que Kubernetes.
Athoune: Le fait d'hoster et infogérer un Kubernetes, c'est quelque chose qui est énorme. Effectivement, c'est Open source et disponible mais est-ce que je vais pouvoir le debugger au milieu de la nuit si il y a un souci, est-ce que je peux avoir confiance et l'assumer. Et d'un autre côté si je donne mes sous à Google Cloud, ou à Amazon, ce n’est plus mon problème. J'aurais une garantie de tranquillité... Ça se résume à « est-ce que je vais prendre le risque de me faire taper sur les doigts ou est-ce que je vais dépenser des sous qui ne sont pas à moi ». Et quand tu commences à comparer des trucs comme ça, c'est plié d'avance.
Olivier Laurelli : Justement chez Enix, vous avez dans les bacs une offre de hosting Kubernetes ?
Sébastien : Tout à fait, alors ce n'est pas moi qui m'occupe de cette partie là, je suis généralement très mauvais pour tout ce qui est marketing, commercial etc, mais oui, on va avoir une offre de cluster Kubernetes. Soit hébergée chez nous, soit infogérée chez le client avec exactement la conclusion qui est que : les problèmes qu'on rencontre sont souvent ultra complexes et la première fois qu'on croise le problème on ne peut pas être bon pour le résoudre... et c'est généralement important; Du coup ça veut dire qu'il y a un métier autour des gens qui savent résoudre ces problèmes. Il y a un empilement de couches technologiques qui est assez flippant, par exemple quand on se met à faire tourner du Kubernetes dans de l'Open Stack et qu'on se rend compte qu'il y a toute une partie d'Open Stack qui peut être réutilisée par Kubernetes... et là c'est génial parce que on ne voit pas l'empreinte carbone de chaque couche mais bon…
Jérôme Petazzoni : Justement ça a été un peu l'exercice auquel on s'est livré : faire tourner les clusters Kubernetes. Pour les formations j'ai découvert que c'était vachement bien de filer un cluster aux stagiaires, donc chaque stagiaire a son cluster de 5 noeuds juste avant la formation, puis on leur laisse après quelques jours en fonction de la capacité qu'on a à ce moment là. Donc l'exercice a été de déployer ces clusters sur l'Open Stack d'Enix avec des plants Terraform, et c'est chouette parce qu'on se met dans de vraies conditions et on monte en compétences automatiquement et de la bonne manière. C'est ce que je dis à tous les gens qui nous contactent pour demander« on voudrait un peu d'accompagnement pour faire du Kubernetes en prod », je leur dit « ça te dit pas de commencer en staging par hasard ?». On va aller sur un truc où il n’y a pas trop d'enjeux, mais ça ne veut pas dire que c'est pour rigoler non plus. Ça veut dire qu'on va pouvoir parler de faire du CICD (NDLR : continuous integration and continuous delivery) par exemple : « tiens tu bosses avec Github, Gitlab, ok donc on va te faire truc où à chaque pull request, on te déploie une stack complète avec ta pull request, comme ça tu as un environnement de qualif automatique, créé à la volée, pour chaque pull request que tu fais ». Déjà ça, ça représente pas mal de boulot, mais c'est un apport énorme au lieu d'être là en mode « les trucs qu'on veut passer en prod je te les ai mis sur dev4 »... Commencer faire du déploiement continue comme ça, ça permet d'essuyer les plâtres dans un truc où il n’y a pas trop d'enjeux, et un moment donné on se réveille un matin en se disant qu'on peut aller en production parce que ça fait plus d'un mois ou deux que le staging n’a pas cassé, on a un truc hyper smart, overcomité à fond, mais j'ai des priorités, donc le staging qui a été pushé il y a deux semaines a été automatiquement supprimé pour faire de la place à celui qui a été pushé il y a deux jours... au bout d'un moment on se rend compte qu'on peut aller en production comme ça, et au lieu de tout découvrir parce que tout est tout neuf, ça fait déjà des mois qu'on a une plateforme qu'on a bien maltraitée parce qu'on l'a bien chargée, parce que c'est typiquement le genre de scénario où tu vas consommer de la ressource à tire larigot. C'est un discours que j'aime bien parce que ça permet d'encourager les bonnes pratiques « d'urbanisme du code » vers lesquelles on essaie, je pense, tous d'aller. Mais des fois on est obligé de freiner un peu parce que finalement c'est compliqué de se dire qu'on va déployer une plateforme complète pour chaque dev, chaque commit...
Mathieu Lecarme : on a tiré des conclusions similaires, que le prérequis c'était que les images Docker étaient construites sur la CI et du coup la registry n'était accessible que depuis la CI. Ce qui nous intéressait c'était d'être capable pour pouvoir assurer l'hébergement, ce qui est le métier de Bearstech, et ne pas avoir de surprise. On a une image Docker, mais ce qui m'intéresse c'est le Dockerfile pour voir ce qu'il y a dedans, en discuter et pouvoir avancer. Derrière, une fois qu'on a ça c'est qu'on a une CI, donc des tests unitaires, ensuite on peut fournir les outils pour que les tests soient fonctionnels, et après pareil, le déploiement se base sur l'image… et là on a la garantie de ces bonnes pratiques, on a pas une image sur une machine qu'il faut recopier. On peut penser effectivement que le prérequis est assez énorme mais on peut prendre le problème dans l'autre sens : pourquoi s’embêter à faire un truc spécifique à la main alors que l’on peut avoir un truc automatique systématique et sans surprise ? Quand on reprend le truc quelques mois plus tard on sait qu'on peut remettre les mains dedans et avancer. On a un cas client comme ça qui est passé d’une journée avec un Vagrant à une heure avec un Docker, ils faisaient des inter-contrats. Ils avaient des micro services, ils avaient un trou de deux semaines, ils allaient se taper un sprint, le mec fait son trou d'inter-contrat sur le projet, puis il disparaissait chez un client, et le projet avançait comme ça.
Jérôme Petazzoni : Et ça même avant le discours Kubernetes ou pas, quand j'explique par où commencer quand on fait du container c'est exactement ça : écrire un Dockerfile, un compose file et débrouille toi pour que le process ce soit : étape 1 : installer Docker étape 2 : git clone, étape 3 : compose up étape 4 : va prendre un café et ta stack est up. Nous on a entendu ça chez Atos je crois ou je ne sais plus quelle boite, une grosse usine logicielle, qui trouve ça génial parce que quand on a une personne qui va changer de projet, je ne me souviens plus des chiffres exacts mais au lieu de suivre une procédure longue, là c'est bien plus facile. Et j'explique que même à la limite si on s'arrête là, c'est déjà pas mal, on a gagné quelque chose et si on revient quelques mois plus tard dessus, c'est pas grave. Chaque projet avance à son rythme. Je ne sais pas si chez vous il y a un débat sur le devops autour du thème est-ce que c'est de la culture, est-ce que c'est des outils ?
Mathieu Lecarme : C'est très large, on a des clients qui font des trucs exotiques, et il faut se débrouiller derrière, eux la notion de suivi et de contraintes, ça les dépasse un peu. Après il y a des agences un peu plus organisées, plus intéressées par la pérennité et le suivi avec des développeurs à demeure sur des projets. Enfin tu as des boites très devops, très nouveautés, qui s'orientent vers des trucs super à la mode, et là souvent on intervient pour garantir qu'il y ai une qualité quoi qu'ils fassent. Même s'ils parlent une langue bizarre et qu'ils font plein de gestes, le client à la fin il veut que ça marche.
Olivier Laurelli : Après t'as aussi les hybrides, ceux qui font n'importe quoi dans des containers.
Mathieu Lecarme : Pour l'instant ça va, on a pas eu trop de surprises là dessus, le fait d'imposer le build, s'ils font n'importe quoi ça se voit. C'est pas un truc anonyme style « pouff j'ai fait tomber en marche sur la prod », ça n’existe pas ça. Il y a des gros décalages culturels globalement entre nos clients, mais c'est vrai que le côté culturel est super important, si on a pas les mêmes abstractions et les mêmes modèles à l'esprit, c'est voué à l'échec. La première étape c'est d'avoir le modèle en commun, puis le vocabulaire, la référence... on veut aller au même endroit mais on a chacun une approche, un chemin qui est différent et si on sait où on veut aller, on peut s'adapter, il y a moins de soucis.
Olivier Laurelli : On a de plus en plus de clients qui se prennent la tête à faire des trucs propres
Jérôme Petazzoni : Il y a cette prise de conscience que le devops, ce n'est pas juste dire « on va faire du container, de la CI », c'est une question de culture de process, mais comme tu dis l'objectif c'est d'avancer vers un but commun, s'arranger pour que les gens se parlent, et comme tu viens de dire on peut très bien faire n'importe quoi dans des containers, donc il ne suffit pas de se dire que l'on va adopter Docker, Kubernetes, Terraform ou ci ou ça pour faire du devops, il faut une vraie volonté et une culture.
Mathieu Lecarme : Oui avant on était sur l'action, maintenant on passe sur l'intention. C'était super important de dire comment on fait, qu'est-ce qu'on fait, là aujourd'hui on s'en fiche, le truc a fonctionné on n'a pas souffert pour le faire, tant mieux. Par contre « qu'est ce que t'as voulu obtenir ?», là je veux bien discuter. Le gros changement de Docker, c'est le Docker File. Il n’y a personne qui va te dire "j'arrive pas à le lire un Docker File". Tu prends le chef de projet il arrivera à comprendre ce qu'a voulu faire le développeur, s'il manque un truc etc. On a une base de discussion commune pour avancer et ensuite derrière on branche tout le bazar. Après les Vagrant, les Terraform, les machins comme ça c'est important pour appuyer sur le bouton pour le lancer, par contre savoir quand on veut changer quelque chose ou pire, ou pire quand l'appli est crashée, comment décoincer la situation, là c'est une vraie compétence. Quand c'est un service c'est normal que ce soit délégué, quand c'est un outil, là ça devient très vite compliqué. Quand on arrive pas à relancer un build, faire évoluer un truc ou qu'il est tout cassé, ça part en sucette très vite. Donc il faut arriver à avoir des trucs simples, une routine, un côté discipliné, c'est un vrai confort.
Jérôme Petazzoni : Tout à fait, j'ai bien aimé ce que tu as dit sur le fait qu'à un moment on est utilisateur au niveau de la stack, genre Terraform on veut pouvoir appuyer sur un bouton et que ça marche. C'est un truc sur lequel je pense avoir mûri cette dernière décennie. D'un côté tu as envie de comprendre toute la stack mais d'un autre côté tu te retrouves limité par ce que tu vas pouvoir sortir. Un moment donné tu en as plein les bras et tu sais plus quoi en faire. Maintenant au lieu d'aller monter un cluster de VM, j'utilise un Open Stack avec un plant Terraform que j'ai monté vite fait avec quelqu'un, mais s'il fallait que j'explique ça à quelqu'un, il faudrait que je réfléchisse un petit peu. Ce n'est pas grave parce que là je peux appuyer sur un bouton. Une autre petite anecdote au sujet des slides de nos formations, on utilise un truc qui s'appelle Netlify , c'est un truc qui est spécialisé dans l'hébergement de sites web statiques. Je pense qu'il y a deux ans, on m'aurait dit que j'utiliserai un truc comme ça, je n'y aurait pas cru...
Olivier Laurelli : On trouve une blinde de CMS statiques maintenant oui.
Jérôme Petazzoni : Exactement et c'est en commençant à l'utiliser que je me suis dit mais c'est dingue en fait. Au début j'avais un peu de html statique, puis j'ai commencé à avoir du Markdown que je « compilais », entre guillemets, à partir d'un YAML, enfin un truc tout pipeau, un script Python qui concatène 5 bouts de fichiers ensemble… mais d'être capable de mettre ça dans un dépôt Git et faire en sorte que quand je push mon dépôt il y a un webhook qui va réveiller Netlify, qui va tout de suite récupérer le dépôt, faire le build, le déployer sur un CDN, et que 30 secondes après le push, le résultat soit visible partout, là je fais « ok c'est de l'hébergement statique auquel je peux souscrire volontiers parce qu'il y a une vraie valeur pour moi de me dire que le truc va être servi wordlwide ». Là je suis en France mais des fois je présente des trucs aux USA, c'est bête mais c'est toujours plaisant quand tu as un truc qui est rapide partout et où tu n’as pas besoin de te dire là...
Olivier Laurelli : « attends lui il a une interco pourrie avec untel... »
Jérôme Petazzoni : Voilà… et « là je viens de faire un push en urgence donc faut que j'invalide sur le CDN, et m** »... Utiliser plein de petits services comme ça c'est un discours que j'avais déjà à l'époque puis tu finis quand même par faire les chosses un peu toi même parce que tu as le goût des choses bien faites, puis tu te rends compte que des gens ont creusé le truc beaucoup plus que toi et que finalement, ils feront beaucoup mieux que tu ne pourrais le faire, même en passant deux ans dessus, et ça soulage pas mal en fait de te dire je vais avoir des services que ce soit un projet libre, un SAAS ou n'importe quoi qui va me coûter pas cher et qui proposera un meilleur service que même si moi et mes potes de garage avions planché dessus. Pour moi ça a été un peu une sorte de révélation où comme tu disais, je vais juste appuyer sur le bouton sans forcément comprendre ce qu'il se passe mais ça va me permettre de me concentrer sur l’essentiel.
Mathieu Lecarme : C'est l'histoire des 80 / 20 ou tu vas passer 80% sur les finitions, le peaufinage, c'est un temps infini, puis c'est un état d'esprit pour arriver à faire des finitions correctes.
Olivier Laurelli : Ouais les finitions... ce moment où tu te rends compte que t'as pas de specs. Pour résumer on peut dire que le devops c'est donc apprendre aux développeurs à bosser ensembles ?
Mathieu Lecarme : C'est un point central sur lequel tu peux discuter. Par exemple tu dis « ton serveur il est mal installé », « ouais mais donne moi les erreurs ou ce que tu as mieux fait ». Si tu ne peux pas lister, comparer tu restes dans l'appréciation.
Sébastien : Surtout que les paradigmes changent avec Docker. Quand une tu as une boite avec une équipe qui développe en Java et une autre qui développe en machin et que tu as l'équipe opération qui se retrouve en plein milieu de tout ça, elle finit par te faire des spécifications horribles que personne ne peut respecter... Docker a beaucoup aidé pour mettre en place le devops et que les développeurs se mettent à faire du travail propre. Et il ne faut pas oublier que pour toute la partie héritée aussi c'est vraiment bien. Le jour où tu te retrouves à devoir installer du Mono sur ton serveur pour faire tourner une vieille application, tu es trop content de pouvoir te dire que c'est dans un container, et que quand le process crash, ça te relance le container.
Mathieu Lecarme : On a eu un cas avec des scientifiques, qui avaient un bout de code horrible, "ouais mais il est historique", là tu te dis : "ok bouge pas".
Olivier Laurelli : Et « vous pouvez laisser la poussière ! »
Jérôme Petazzoni : « On va mettre un container étanche ».
Sébastien : Et puis ça marche, ça te fait du déploiement bleu vert... ça marche. Un mauvais développeur peut te faire un container tolérable alors que... on a tous installé des Plones dans notre vie.
Olivier Laurelli : Je ne vois pas de quoi tu parles... avec les 27 installeurs différents. Mais n'empêche que ça nous a tous guidé vers le statique !
Jérôme Petazzoni : Le retour de balancier.
Olivier Laurelli : Oui on est passés sur Lektor, un très bon CMS.
Sébastien : Pour un site vitrine c'est vrai qu'il y a jamais eu de bonnes raisons de faire autre chose que du statique.
Mathieu Lecarme : Tu as des acharnés qui font aussi du commentaire en statique : ça modifie le Markdown, ça commit dans le Git et ça régénère tout, tu as des produits qui font ça.
Jérôme Petazzoni : Il y a un truc dont j'étais assez content à l'époque Dotcloud : on faisait notre wiki de knowledgebase interne avec, c'était un dépôt Mercurial à l'époque, on utilisait un truc, un wiki avec un backend Mercurial, c'était super classe. Tu édites une page, ça te fait un commit dans le dépôt et c'est parti, du coup tu pouvais éditer offline en faisant des push dedans... la révélation, c'était génial.
Sébastien : C'est vrai que choisir un wysiwyg c'est pas un truc structurant dans ta vie.
Olivier Laurelli : Tu restes un peu sur Paris là Jérôme ?
Jérôme Petazzoni : Jusqu'au 26 septembre, puis direction Mineapolis, puis New York pour une formation de deux jours la bas, puis je vais passer le mois d'octobre je pense à zoner un peu sur la côté est, puis début novembre je serai à San Francisco pour une autre conférence. Enfin je pense qu'en début décembre je serai à Kubecon à Seattle, et revenir ici pour un autre cycle de formations.
Olivier Laurelli : Quand est-ce que vous mettez en ligne votre offre de hosting Kubernetes ?
Sébastien : C'est imminent, un des derniers arrivants chez Enix, un peu plus structuré que le geek de chez nous est en train de travailler sur le nouveau site et de créer des offres. C'est le 5e redesign de site web en 12 ans.
Olivier Laurelli : Notre Plone a duré 7 ans !
Jérôme Petazzoni : à jour ?
Olivier Laurelli : Ben non, tu ne pouvais pas le mettre à jour. C'est un peu le concept de Plone, c'est comme un dist-upgrade sur Ubuntu, en théorie la feature existe, il y en a qui ont essayé, ils ont eu des problèmes.
Jérôme Petazzoni : C'est vrai qu'un upgrade de Plone coûte plus cher qu'un redesign.
Merci messieurs... beer time !
Visitez la page des formations de Jérôme sur le déploiement d'applications avec Kubernetes.
