Docker : la face nord !

J’avais déjà testé quelques dépôts GitHub et synthétisé quelques informations dans un article qui envisageait la comparaison entre docker et Vagrant.

Je rédigeais cet article et puis je me suis aperçu que je refaisais pratiquement l’article vagrant/docker. Duplicate ! Je vais essayer de le prolonger ici et de préciser mon propos.

🔗 Disclaimer

Docker est pas mal utilisé par les hébergeurs et autres services, pour du déploiement, de l’intégration continue, c’est pas du tout ce que j’aborde ici. Je vais parler d’un point de vue workflow de dév et pour gérer plusieurs projets en même temps.

🔗 1ers pas docker

La documentation se suffit, ça peut très bien se passer comme planter royalement donc attendez-vous à quelques stackoverflows pour les incompatibilités et autres joyeuseries d’OS malgré tout. J’ai beau apprécier l’exploration, au bout d’un moment c’est saouuulant. 2017 et c’est toujours bourré d’incompatibilités, de bugs parce que les mecs veulent pas se mettre d’accord sur de vrais standards, etc. Mais c’est un autre débat.

L’exemple de la doc marche, on récupère un WordPress en local, fin de l’histoire me direz-vous ? Eh bien non, début des emmerdes !

🔗 Penser Docker, penser Vagrant, rien à voir !

Comme je le dis dans mon article cité plus haut, comparer les deux c’est un non sens AMHA. En revanche rien n’empêche de comparer leurs apports pour le dév WordPress.

Le premier souci qui peut se poser, c’est de vouloir calquer son expérience de Vagrant sur Docker, je vous arrête tout de suite si c’est votre cas, ça va pas aboutir. Ça n’a rien à voir. Un container (on va revenir sur la notion après) c’est pas du tout une machine virtuelle !

🔗 Machine virtuelle ?

On émule quoi. On fait comme si on avait un autre ordinateur dans l’ordinateur avec son propre système d’exploitation, ses processus, etc.

Mais pourquoi on fait ça au fait ? Dans mon tuto sur VVV, je vous présente une trousse à outils de développeur WordPress. Grâce à une machine virtuelle, on va lancer un environnement de développement local assez complet et le tout en une seule ligne de commande ! Au final, on récupèrera :

et on commence à bosser, basta !

L’avantage c’est que c’est que c’est prêt à l’emploi, l’inconvénient c’est que c’est un tantinet lourd, donc sur des bécanes mal affutées ça risque de mouliner sévère !

🔗 Pendant ce temps-là chez Docker

Docker raisonne pas du tout comme ça. Docker va isoler des containers. Les « containers », ça vient de chez Linux, et, pour faire simple, ça permet de cloisonner des environnements sur une même machine qui vont partager le même noyau (des ressources communes pour le dire plus simplement).

Donc là ou Vagrant va carrément lancer toute une machine avec son propre OS, ses propres ressources pour chaque environnement de travail, Docker va quant à lui mutualiser tout ça et n’embarquer que le strict nécessaire.

Concrètement, installer une machine virtuelle n’est pas gratuit, il va falloir allouer de l’espace et de la RAM, et c’est très gourmand un système d’exploitation. Docker, lui, va utiliser l’existant et isoler chaque brique supplémentaire qui seront nécessaires à l’environnement : une brique Apache2 ou nginx, un serveur mysql, un serveur php*-fpm.

L’approche Docker c’est de dire « de quoi a besoin mon application pour tourner ? », et pour chaque besoin je créé un container ou si vous préférez un processus associé. Ça c’est le workflow Docker !

🔗 Quel rapport avec WordPress ?

L’analogie avec WordPress c’est un peu le mode multisite. On va pouvoir trouver un intérêt dans docker dans le travail collaboratif. Chacun sa machine, chacun sa config, chacun ses bugs, et ça nous donne un joyeux bordel et un max de perte de temps rythmé au funky son du :

chez moi ça marche !

Sur des projets où ça scale à fond les ballons, genre une équipe de 70 dévs, ça devient ultra-critique. Chacun viendrait poser sa pêche et le tout serait déployé en production au final et chacun pour soi et Dieu pour tous ? Impossible ! T’imagine, l’un a développé sous PHP5, l’autre sous PHP7, l’autre avec mysql xxx, encore un autre avec Maria DB, l’un avec un ordi de compét à la sauce geek, l’autre avec une bouse qui rame, bref ! Personne sur la même longueur d’onde.

Docker vient remédier à ça. Consistency comme on dit dans le jargon. Ces petits containers sont tellement souples qu’ils vont tourner partout de la même façon, ISO, on vous dit, et tant qu’à faire ISO avec la production.

🔗 Tu crois que t’as compris ?

Je t’ai vaguement expliqué la différence et si je reprenais rapidement ça ferait : Vagrant c’est une machine par environnement, Docker c’est plusieurs environnements sur une même machine.

T’as compris ou tu crois que t’as compris ? Au pire t’auras retenu que Docker c’est plus léger, plus rapide,Vagrant plus complet. Essayons d’aller plus loin. Le workflow Docker va découper les besoins en autant de container que nécessaire et chaque container va contenir une image qui aura un but précis et unique, par exemple une image WordPress, une image pour le mysql, une image pour l’interprêteur PHP, etc.

On descend ? Allez au niveau de l’ « image » justement que se passe-t-il ? C’est quoi une image docker ?

a filesystem and parameters to use at runtime. It doesn’t have state and never changes. A container is a running instance of an image.

Donc en français un système de fichiers et de paramètres à utiliser au moment de l’exécution. #kamoulox

Voici la suite :

An image can start software as complex as a database, wait for you (or someone else) to add data, store the data for later use, and then wait for the next person.

Source

L’image va pouvoir aussi bien exécuter une simple commande comme lancer une base de données, ajouter et stocker des données qui pourront être réutilisées. Est-ce que si je te disais que moi j’ai compris et que pour le coup pas toi, à quoi ça t’avance ?

On descend encore plus bas.

Dans l’image, y a une succession de couches comme décrites dans la doc :

Each Docker image references a list of read-only layers that represent filesystem differences. Layers are stacked on top of each other to form a base for a container’s root filesystem

Source

via GIPHY

Une image c’est une collection en fait. T’as toujours pas compris ? twisted

🔗 L’analogie de la mort qui tue

En fait, si je ne prends pas une analogie avec des éléments qui te sont familiers tu ne vas pas comprendre. Attention, elle est perso, enfin d’autres auront pu l’avoir avant moi, parce que faut pas déconner non plus, bon je la tente quand même :

Le container est une instanciation de l’image

Alors ? ça vient ? Toujours pas. Alors écoute disons donc que le container est une instance, donc un objet et l’image est une classe qui va donc décrire le comportement de l’objet, enfin du container, enfin tu m’as compris.

On s’arrête un instant. Je viens de prendre la programmation orientée objet comme analogie pour simplifier l’explication de docker. #inception ou comment tenter d’accéder à une abstraction avec un autre abstraction. Autant dire que le peu que j’aurais compris, j’aurais tenté de le vulgariser ici avec un concept qui est déjà relativement complexe lui-même.

via GIPHY

🔗 Ça dit quoi tout ça ?

Ça dit que Docker, c’est la théorie du mille-feuille. Ça dit que dans une logique d’industrialisation à grande échelle pour des grosses grosses équipes je comprends tout à fait l’engouement, les économies d’échelle car le casse-tête intellectuel en vaut la chandelle largement.

Pour des équipes de 1/2/3 dévs par projets ça me paraît over complexe avec un coût d’industrialisation important. Pas étonnant dans ces conditions que des business entiers se soient construits rien que sur cette partie à très forte valeur ajoutée.

🔗 Conclusion

Je pense donc que si l’idée c’est d’explorer, d’essayer de saisir les subtilités, ça a un sens.

En revanche, s’il s’agit de bosser pour de vrai, la tentation va être grande d’essayer de reporter le schéma machine, donc plutôt vagrant, sur Docker et au bout :

c’est le platane assuré en revenant de Louvin-la-neuve.

L’engouement se comprend à grande échelle, beaucoup moins à taille humaine. Je serais néanmoins curieux de savoir si certains ont déjà expérimenté voire mis en place un workflow WordPress viable avec Docker, je parle en interne comme processus d’agence par exemple et pas en externalisant car il existe des offres en la matière ^^. Docker est à mon sens pas assez mature mais me trompe-je ? me gourre-je ?