Docker : DevOps, teamwork edition

Technique

20 déc, 2018

Non, ce n’est pas le titre du dernier FPS à la mode, n’en déplaise à tous les g33k que vous êtes.

C’est le nom d’une baleine « à la hype », souvent cataloguée comme un simple remplaçant des VirtualBox, VMare et consorts.

IMG8 Docker : DevOps, teamwork edition

Si au départ la beta était testée par des techos avides de sensations fortes (il y en a qui n’ont pas besoin de beaucoup pour se faire plaisir dans la vie), ce sont aujourd’hui des équipes entières qui utilisent Docker pour leurs différents projets, qu’il s’agisse d’une agence web, d’un éditeur, d’une SSII, etc.

Quand on parle d’équipe, on parle de toute la chaîne de vente et de production :

– le développeur chez qui les services Docker tourneront

– le lead dev ou devops qui se chargera de la mise en place et maintenance des stacks et images projets

– le chef de projet qui entendra parler de Docker (ou pas) et ne comprendra pas certains temps passés

– le directeur client, ou commercial, qui ne comprendra pas ce débordement de budget dès le départ du projet ou lors de bugs rencontrés hors contexte de développement

Certes, cela sous-entend que les développeurs et les techs en général abordent le sujet stack locale et Docker en interne. Certains ne le font pas en se disant que c’est trop technique et pas nécessaire d’en parler avec un chef de projet ou un commercial. A tort selon nous.

Haaa Docker. Tout le monde connaît, personne ne maîtrise. Booooom. La phrase de provocation par excellence. Je vais devoir désormais me justifier et l’expliquer…

Docker, tout le monde connaît

Parler de Docker, c’est souvent s’exposer à un hochement de tête vertical: « oui oui, on l’utilise ».

Un docker run par ci, un docker-compose par là, et ça y est, l’expertise est dans la place.

Pourtant, la philosophie de Docker, et les concepts techniques qu’il apporte, sont autant de nouveautés qui marquent un véritable tournant dans notre façon de concevoir et d’utiliser les outils de déploiements, locaux et distants, de nos stacks projets. Il convient de maîtriser ces aspects techniques, d’en comprendre les bases, afin de mieux réfléchir à la façon d’utiliser l’outil.

Car attention, Docker n’est pas une fin en soi, mais bien qu’un outil pour parvenir à nos fins.

Cette philosophie Docker repose sur les piliers :

– flexibilité : découplage des services

– légèreté : un service doit être le plus light possible (oui, c’est toi que je cible, Ubuntu !)

– un service sert un et un seul besoin technique ou fonctionnel (oui, c’est toi que je cible, library/wordpress:latest ! Ignoble image !)

– optimisation : fouillez dans la documentation pour trouver des options intéressantes, il en existe à la pelle

GNU/Linux. Je vais être très clair : bien qu’il soit possible et tout à fait productif d’utiliser Docker sur Windows et MacOS, Docker a été conçu pour et uniquement pour GNU/Linux à la base. Il est donc normal que son utilisation sur d’autres OS n’est ni le rendement ni la stabilité attendus.

Docker, personne ne maîtrise

Pardonnez le côté provocateur de cette petite demie-phrase prononcée en début d’article, mais on note bien souvent que :

– chaque équipe met en place une stack basée sur Docker d’une façon différente (version différente, utilisation d’une clé de configuration deprecated, mise en place différente de réseau, utilisation ou non d’un reverse proxy, etc.)

– chaque membre de l’équipe a une vision à lui de Docker, et de sa façon de l’utiliser. Trop souvent également, le sujet Docker est pratiqué mais pas compris, alors que la difficulté de compréhension reste moindre si la pédagogie est là.

– bien souvent, aucune intention de veille n’est exprimée par l’entreprise et ses membres, puisque, « c’est Docker c’est tout, ça sert à installer des projets ». Et donc, cela n’évolue pas ? Cela ne bug pas ? Qu’est ce que c’est que cette tisane ?!

– il n’est pas question de coupler Docker avec d’autres outils tout aussi utiles (ansible notamment), alors que Docker est totalement fait pour n’être qu’une couche parmi les couches d’outils susceptibles de faire augmenter votre productivité

– aucun guideline n’est proposé par les équipes afin de tous utiliser Docker de la même manière…dangereusement dramatique.

Et donc on se retrouve, le plus normalement du monde, à faire un simple make install, qui au détour d’une expression build lira un Dockerfile sur CHAQUE poste de dev.

En d’autres termes, à chaque fois qu’un développeur rentrera sur un projet, on lui fera build son image localement. Les bugs rencontrés seront « corrigés » individuellement, sans en parler autour de soi, et surtout sans faire remonter le problème à la personne responsable (si tant est qu’il y en ait une) de la stack projet.

Question gain de temps, et normalisation, on a vu mieux.

De même, chacun va modifier le docker-compose de base, sauvagement mis en place par un développeur trop pressé par un contexte multi-projets compliqué, pour ajouter son petit fix.

Tandis que John utilisera Composer ou yarn depuis son host, Jacky les utilisera depuis un service Docker, ce qui, sans être aberrant d’un côté comme de l’autre, ajoute à la complexité de la méthodologie technique utilisée sur le projet. Qui n’a jamais vécu le « bah chez moi ça marche », sorte de point final dont l’argumentation et l’étayage par l’exemple feraient pâlir un renard des neiges (« oh c’est mignon », gnia gnia gnia on s’en fout c’est pas le sujet !).

De même dans son docker-compose.yaml, Maurice a décidé de coupler apache, php et son application web.

Dialogue d’ambiance :

« Comme ça « c’est plus facile à maintenir », soutient-il.

Nous lui répondons avec une virulence digne d’un panda en colère (si si ça existe) :

« WTF ??! Et si je veux monter de version php, qu’est ce que je fais, je mets à jour une image 3 en 1 ? Quand tu veux changer la roue avant gauche de ton automobile, tu changes le pare-brise et le siège bébé ? Idiot ! ».

Enfin, une âme charitable créera un Makefile, contenant une instruction install, qui elle lancera un complexe et plein d’ironie docker-compose up -d. Moi aussi j’adore chasser des moustiques-tigres avec un merlin.

IMG15 Docker : DevOps, teamwork editionMon outil préféré pour chasser les moustiques. Et pas que.

Disclaimer : Vous ne vous reconnaissez pas dans ces quelques lignes pleines de critiques ? Vous pensez que cet article prend la direction du non-sens et que vous êtes bien au-dessus de ça ? Bravo, vous êtes sexy quand vous montez sur une baleine.

IMG12 Docker : DevOps, teamwork editionNon, cette image n’a rien avoir avec Docker, et alors ?

Docker, ce qu’il faudrait faire

Note : on abordera uniquement docker-compose, car Swarm serait hors cadre et trop long à aborder ici.

Docker pour nous développeurs, c’est surtout les scripts utilitaires docker-compose, qui proposent de se baser sur des fichiers de configurations afin de configurer votre stack projets.

Vous déclarez vos services dans un fichier yaml, et au moment de lancer votre stack, tout sera exécuté de manière quasi séquentielle, afin de « monter » votre stack projet très simplement.

A partir de là, Docker propose de respecter certains guidelines, qui sont plutôt sympas, et j’ai décidé d’en ajouter quelques-uns qui me paraissent à la fois simples et bienvenus :

La stack Docker

La stack Docker que vous mettez en place doit répondre au besoin projet. Si vous n’avez pas besoin d’un service, ne le mettez pas dans votre stack. N’ajoutez pas de choses inutiles. Assurez-vous que l’ajout d’un service apporte une véritable plus value à votre équipe.

Par exemple, est-il bien nécessaire d’ajouter systématiquement phpmyadmin à votre projet ? Personnellement, je ne l’utilise pas, et le fait que le port 3306 de ma base de données doive être  systématiquement joignable en externe pour quelque chose que je n’utilise pas me paraît absurde.

Découplez

Docker propose de découpler la stack au maximum : n’essayez pas de faire une image « tout-en-un ». C’est un non-sens car on cherche avec cet outil la modularité, la flexibilité.

Exemple :

IMG13 Docker : DevOps, teamwork edition

Peut sereinement devenir :

IMG18 Docker : DevOps, teamwork edition

On a ici découpé notre service WordPress de base en un service application, un autre langage, ainsi qu’un dernier server. On répond donc au besoin du projet, et on explicite ce besoin dans le docker-compose.

Notez qu’on a évité de nommer nos services « wordpress », « php » et « apache ». En effet ce fichier docker-compose a en quelque sorte valeur de référentiel de notre stack.

Cela signifie que si une personne externe au projet lit le fichier, elle doit être en mesure de savoir de quoi il s’agit. Si les langages et serveurs sont aujourd’hui très connus, on peut très bien imaginer l’ajout d’un service « front » qui serait basée sur node, ou un service « reverse-proxy » basé sur traefik. En lisant traefik, un tiers ne sait pas de quoi il s’agit. En lisant reverse-proxy, il comprend de quoi il s’agit.

Stockez vos images prêtes à l’emploi

Dans la mesure du possible, évitez les instructions build lorsque vous travaillez en équipe. Une fois votre service fonctionnel, construisez l’image via un docker build ou un docker commit puis stockez-la sur un registry, qu’il s’agisse de Docker Hub, ou d’un registry personnel / d’entreprise.

De cette manière vous permettez :

  • la réutilisation de votre travail précédent

– d’éviter aux autres un temps de build parfois très long

– d’éviter les erreurs de type modification de Dockerfile individuelles, ce qui génère des divergences techniques

– de faciliter la maintenance des images en utilisation et un suivi régulier

– et pourquoi pas, de mettre en place une interface permettant de visualiser ce qui est dispo comme images, en utilisant par exemple Portus.

IMG9 Docker : DevOps, teamwork editionLe pastis sent l’anis. Heureusement que ça s’appelle pas le pastus…sinon il y a Portus.

Créez des images légères

Comme dit précédemment, n’embarquez pas ce qui n’est pas nécessaire. Epurez au maximum les contenus de vos images. Un service doit être le plus light possible.

Oui, c’est toi que je cible, Ubuntu !

IMG11 Docker : DevOps, teamwork editionC’est pas la taille qui compte. SI. C’est la taille qui compte.

Comme on peut le constater, l’utilisation d’Alpine Linux permet plus optimal sur ce point.

“Non mais Ubuntu permet de faire bien plus de choses facilement ! ».

Peut-être, peut-être pas. Difficilement quantifiable. A ce jour, je n’ai personnellement pas trouvé de limites qui me poussent à abandonner Alpine pour revenir à Ubuntu, bien au contraire. Certes, Alpine utilise des librairies, notamment C, différentes de celles utilisées par Ubuntu par défaut. Dans certains cas, ces librairies peuvent nécessiter un aménagement, mais là on sort de la majorité des cas dans le monde du web.

Pour beaucoup de cas d’utilisation, Alpine sera tout à fait adaptée à votre projet.

Notons qu’Ubuntu reste un OS taillé pour le Desktop, là où Alpine conviendra bien mieux à une logique de containerisation et donc à Docker.

IMG17 Docker : DevOps, teamwork editionMême le logo avec les petites montagnes il claque !

Lorsque vous configurez une image en profondeur, « from scratch », préférez donc toujours Alpine Linux ou même encore plus light. Cela se montrera beaucoup plus véloce qu’une image telle qu’Ubuntu. Et lorsque vous installerez des paquets, la gestion des dépendances sera moins chaotique et lourde avec apk qu’avec apt-get.

Déléguez au maximum la gestion des volumes à Docker

IMG4 Docker : DevOps, teamwork edition

Souvent, trop souvent, on met en place des partages de volumes en mode « bind-mount », c’est-à-dire en dossier partagé depuis votre host. Si cela revêt un intérêt concernant vos sources du projet, cet intérêt est relatif lorsqu’il s’agit d’une base de données par exemple. Laissez Docker gérer vos volumes au maximum.

Sans rire, à quoi bon utiliser un bind-mount pour /var/lib/docker sans mettre une instruction innodb-file-per-table dans votre configuration ? Et quand bien même cette instruction serait présente, vous avez déjà réussi à copier-coller des tables à la volée sans ne jamais avoir d’erreur SQL, vous ?

Intégrez un schéma d’architecture

C’est souvent perçu comme quelque chose de vieillot, mais c’est bénéfique pour toutes les parties-prenantes du projet. Faire un schéma d’archi, très simple, permet d’avoir une vision graphique de la stack, au-delà du naming des services dans le docker-compose.

IMG10 Docker : DevOps, teamwork editionExemple de schéma d’architecture

Tirez profit du répertoire /docker-entrypoint-initdb.d

Ce répertoire est lu à la création du service, par convention, par les services issus des images telles ques Percona, MySQL, MariaDB.

Note : les dumps présents sous ce répertoire ne sont importés que si aucune base du même nom n’existe déjà dans le système SQL.

Placez un dump mis à jour régulièrement afin que les nouvelles ressources travaillant sur le projet aient une base prête à l’emploi dès l’initialisation de la stack.

Utilisez votre .env !

IMG 1 Docker : DevOps, teamwork editionOui, je pique l’image du projet dotEnv et alors. Essaie d’illustrer un fichier .env par une image, après tu pourras critiquer !

Garnissez votre .env de variables à utiliser sur le projet. Au départ, si vous n’avez pas beaucoup de recul sur Docker et sa configuration, utilisez un USER commun, un GROUP commun, etc. 

Complexifiez petit à petit.

Si vous utilisez un outil tel que GNU/Make, utilisez le pour dynamiser encore plus votre .env au moment de la création de votre image et/ou du lancement de votre service.

Ce qu’il faut bien comprendre, c’est le but à atteindre : une image la plus générique possible, avec un ajout d’un minimum de variables personnelles. C’est par cette généricité que l’on garantit une bonne maintenance, notamment.

Note : ne versionnez pas votre .env. Versionnez uniquement un fichier tel que le .env.dist qui servira de « squelette » à la création du .env, sans quoi des données sensibles pourraient être visibles de l’extérieur (mots de passe, tokens, etc.)

Mettez en place un service de Backup

Si vous utilisez une base de données sur votre projet, faites plaisir à tout le monde en configurant un service de backup, qu’il s’agisse d’un service que vous auriez monté vous-même ou un service plus connu tel que tiredofit/docker-db-backup.

Complexifiez la stack et les configurations petit à petit

Je vais le répéter : complexifiez votre stack et les configurations, voire les outils tiers tels que ansible ou Makefile, petit à petit.

Commencez très simple, puis ajoutez chaque chose brique par brique. Testez à chaque itération.

D’où la nécessité de planifier les avancées attendues, tout au long d’une veille technologique autour des outils de devops/déploiements/maintenance. Ceci vous permettra de créer un workflow d’utilisation autour d’outils définis au préalable et inscrits dans une réelle stratégie technique.

Toi le commercial, vends donc du Docker !

IMG14 Docker : DevOps, teamwork editionLe commercial par excellence

Alors, petite attention particulière quant à l’aspect commercial des portions DevOps dans un projet : dans une entreprise, le but, c’est d’être rentable, et de travailler efficacement, c’est-à-dire avec un client content de payer pour son produit et les services associés.

En 2018, quand on dit « vendre du DevOps », de suite tout le monde monte sur sa licorne, en hurlant que « l’entreprise n’en fait pas encore, mais qu’elle y songe » et que « l’hébergement c’est un métier à part ».

Oui, c’est vrai. Hébergeur, ce n’est pas dev. Et SysAdmin, c’est un métier qui nécessite des compétences différentes, ainsi qu’une aisance avec des concepts système et réseaux souvent bien au-delà de ce que les devs connaissent sur le sujet. Et justement, des outils comme Docker sont là pour limiter cet écart et permettre à un pourcentage croissant de ressources d’administrer et gérer eux mêmes des stacks projet.

Certes, cela ne fait pas plaisir à beaucoup de sysadmin. Il m’arrive d’ailleurs d’entendre ou de lire certains d’entre eux, en bons barbus, dire de Docker que c’est totalement instable, et que rien ne remplace un bon vieux script shell.

Hmmm…on parle bien de cette immonde syntaxe pas du tout human readable là ? Le truc qui varie de syntaxe rien que pour faire un if selon qu’on utilise sh, bash ou zsh par exemple ? Ok Top.

Clairement, du « DevOps » (je n’aime pas ce mot devenu conflictuel), tout le monde ou presque en fait, sans s’en rendre compte, et au niveau le plus basique du projet : localement, sur son poste.

Aujourd’hui, la mise en place de la stack locale n’est souvent pas incluse dans les chiffrages projets, et ce pour diverses raisons :

– les commerciaux ne sont pas formés à la vente de cette partie projet, ou n’en ont même pas connaissance

– le client part du principe que cela n’est pas à lui de payer pour l’initialisation d’un projet sur un poste de développement, car c’est inhérent au bon fonctionnement de l’entreprise de services à laquelle il demande une prestation. Cela se défend, même si je ne pense pas que le boucher se dise « bon allez l’investissement du couteau à viande là c’est pour moi, c’est cadeau », ou que le boulanger se dise « franchement je ne vais pas répercuter le prix de mon nouveau four sur le prix du pain, c’est pas au consommateur de payer ça quand même ». Soyons réalistes.

Au final, le risque ici c’est d’ajouter de la pression au développeur qui doit gérer l’installation de son poste local sur un temps qui n’est pas vendu et qui pourtant aurait dû être valorisé.

IMG2 Docker : DevOps, teamwork editionPensée pour toi, petit développeur abandonné à ton triste sort. Et le pire, c’est que tout est ta faute.

Car si par la suite on rencontre des soucis de déploiements de notre stack, en local, tout au long du projet, de manière récurrente et / ou prolongée,c’est au client que l’on va demander un effort financier et une compréhension quant à un possible décalage de la date de livraison (malheur!). Donc le client devrait payer pour quelque chose qu’il n’avait pas prévu, et parce que l’utilisation de Docker n’avait pas été inscrite dans un workflow commun.

Il risque de se sentir floué, à tort et à raison. A tort parce qu’en un sens cela fait partie du projet, de la gestion technique, même si elle est un peu mauvaise. A raison, parce qu’effectivement c’était à l’agence de ne pas voir la vente de Docker en amont comme une plaie mais plutôt comme une plus value. Et donc de la valoriser de façon claire dans le budget.

Nous, les tech: arrêtons de croire que nos services locaux : serveurs, language, etc. sont statiques et ne bougent pas tout au long d’un projet. Théoriquement, ils ne devraient bouger que pour des mises à jour de sécurité, pas pour des ajouts techniques et fonctionnels a posteriori de la validation client pour le départ du projet. Néanmoins, la réalité est partout différente.

Points-clés dans le contexte commercial

1/Développeurs : sensibilisez vos commerciaux à cet aspect init projet.

2/Commerciaux, ne partez pas du principe que c’est technique et donc indigeste. Exigez une présentation, avec vulgarisation à l’extrême s’il le faut, et intégrez cette portion dans les chiffrages vendus.

3/Directeurs techniques : formez vos équipes. Misez sur le gain de temps à l’initialisation et sur un workflow de maintenance et d’évolution de Docker pérenne en interne. Ittérez, ne partez pas dans des délires techniques irréalisables.

4/Tous : fixez des objectifs numériques tous ensemble, concrets.

Exemple : un ajout ou une optimisation par mois dans votre stack projet (imaginez ce que vous voulez en fonction de vos capacités techniques et des ressources disponibles en interne).

5/Tous : formez-vous. L’auto-formation c’est bien, mais il existe des personnes très capables dans le monde de la tech, partout en France. Faites-les venir. Investissez sur une journée de formation interne. Tout le monde sera content. Et si ce n’est pas le cas de tout le monde, un pourcentage toujours supérieur à 0 de ressources humaines le sera…

6/Commerciaux : sensibilisez vos clients au fait qu’un investissement minimal de base sur l’initialisation projet vaudra mieux qu’une rallonge non-maîtrisée à la fin, lors de soucis rencontrés par la team.

De ce fait, vous permettrez :

– à votre client de prendre conscience que cela prend du temps d’avoir une stack propre

– à vos développeurs du temps pour bien faire les choses

– une démarche qualité au départ du projet

– d’éviter la douloureuse tâche de devoir contacter le client quelque part entre le début et la fin du sprint / projet, en lui exposant la nécessité d’une rallonge budgétaire pour couvrir des temps de debug locaux

ISO-PROD. ISO-PROD. ISO-PROD.

Autre point d’importance : si on voulait être 100% cohérent, on ne devrait finalement pas créer de stack de développement.

IMG6 Docker : DevOps, teamwork edition

Oui. Les seules choses qui devraient varier de la prod à la préprod, au dev en passant par les environnements de recette, ce sont les variables d’environnement. Le reste devrait être ISO-PROD. ISO-PROD. Rien de plus. Rien de moins.

Faire différer la stack technique d’un environnement à l’autre, c’est volontairement nuire à la bonne tenue technique du projet. Souvent, cela ne génère pas de souci particulier. Parfois, cela créée des différences notables. Des bugs que l’on ne comprend pas. La nécessité de « debugger » directement en préprod, voire pire…en prod. J’entends d’ici certains me dire « non mais je vais pas utiliser la même bête de course en recette et en prod, ça va me coûter les yeux de la tête pour rien ».

J’aurais ici deux éléments de réponse :

– c’est un choix risqué, mais qui se comprend par la volonté de réduire les coûts. En revanche on ne peut donc pas, dans ce cas particulier, parler de qualité, car ce contexte met les deux en opposition.

– nous sommes en 2018. Nombre de services de hosting permettent aujourd’hui l’utilisation de docker-compose, swarm, etc. De plus, ils fonctionnent par instances de snapshots facturées au temps passé. Ce qui sous-entend que si vous planifiez correctement votre phase de recette, vous ne démarrez les instances de recette que durant un laps de temps relativement court, et donc peu coûteux.

Evidemment, ça, c’est pour la théorie. Dans la pratique, il existe pléthore de contre-exemples ne permettant pas de faire « bien » les choses. Il faut l’admettre cela se passe rarement comme on le voudrait, que cela soit techniquement, financièrement, côté gestion de projet, etc. Mais là encore, il ne faut pas vouloir réaliser le projet parfait du premier coup : il faut itérer. Tester des solutions sur un projet, en répercuter les bénéfices sur d’autres, et adapter intelligemment, en se rappelant que tout évolue constamment.

Docker is organic

Les projets web sont des entités organiques, qui vivent au-delà de la livraison en production. Leur tenue dans le temps dépend, selon moi, de deux facteurs :

– la capacité de base à imaginer une stack viable, en terme de choix technologiques, sur le moyen et long terme (respectivement 1 an et 3 ans)

– la capacité à mettre en place une stack facilement maintenable, qu’il s’agisse de Docker ou de choix dans les développements

Docker s’inscrit dans cette logique totalement organique. Ses cellules sont les services que vous déploierez. Le type d’organisme variera de simple (docker run à complexe docker swarm).

Conclusion

Pour certains, cet article sera du blabla. « Bullshits » crieront les gens pour qui, passées 10 minutes de lecture, ça devient dur. N’empêche, nous soulevons ici des points réels de réflexion, et proposons des solutions, des guidelines.

Certes, nous n’inventons rien : nous reprenons, avec un minimum de bon sens (nous l’espérons), des choses qui sont écrites et décrites partout sur le web.

Le but est de montrer comment travailler en équipe avec Docker, et non pas chacun dans son coin.

Chez DISKO, nous avons décidé de parier sur Docker. Nous aimons cette techno, et nous pensons que bien avancer avec elle nécessite effectivement de ne pas s’axer uniquement sur la montée en compétences technique, mais également en comprendre les rouages et les concepts afin de décupler nos facultés de compréhension, et pourquoi pas s’ouvrir à d’autres horizons d’ici peu. “Coucou Kubernetes“.

Et si, finalement, à travers toutes ces questions et ces débats techniques et commerciaux, Docker n’avait-il un vrai rôle à jouer également dans l’acculturation interne ? A méditer…

 

Bonus Technique

Comme avec le workflow GIT, Docker nécessite d’être utilisé en suivant une sorte de Workflow et de bonnes pratiques.

Si certaines sont inhérentes à l’outil, et expliquées dans la documentation, d’autres découlent des volontés des équipes, des team leaders, des lead developers, etc.

L’intelligence opérationnelle, du côté de l’équipe technique, se résume à la vitesse et au volume d’adaptation possible d’une équipe vis-à-vis d’un ou de plusieurs outils dans un contexte technique. Pas à sa capacité à respecter coûte que coûte un texte écrit, même s’il s’agit d’un texte d’éditeur.

Respecter les PSR, oui. Appliquer bêtement un workflow lourd et contraignant, non. Et qu’il s’agisse de Docker comme de Scrum, par exemple. Vous pouvez répercuter ce conseil à tous les domaines.

Il est important de se poser autour d’une table et de partager une vision d’ensemble concernant Docker et les outils gravitant autour, qui seront un socle de vie pour l’ensemble de votre stack tout au long du projet, et potentiellement pour vos déploiements en environnements de recette, de pré-production, voire de production.

Makefile

Docker s’utilise aujourd’hui beaucoup avec GNU/Make devant, pour “simplifier les commandes”. Néanmoins, et j’ai pu le constater par moi-même sur des projets, on se retrouve vite à vouloir dynamiser beaucoup de choses et faire comme si Make était un langage de script permettant des conditions et l’implémentation d’une logique. Il n’en est rien. Make doit se cantonner à un rôle de configurateur, d’exécutant.

Les instructions ifeq et compagnie, d’abord, sont imbuvables, et ensuite difficile à maintenir. On pense vraiment que make, bien qu’à la hype également et défendu par beaucoup de gourous de la tech, n’est pas nécessairement adapté à tous les contextes.

De plus, lorsqu’un junior (haha, oui, c’est encore toi qu’on cible petit padawan !) tape make install, bien souvent, il n’a pas le réflexe d’aller regarder ce que fait cette instruction derrière…et ne monte donc pas en compétences. Parfois, c’est justifié. Souvent, c’est fort dommage, pour lui comme pour l’entreprise.

IMG5 Docker : DevOps, teamwork editionJérémie n’a toujours pas compris Docker. Il sera donc notre stagiaire pour toujours.

Attention donc avant d’adopter par défaut cet outil. D’autant que sa syntaxe ne parle vraiment pas à tout le monde : posez-vous quelques instants avec les membres de votre équipe et demandez-leur s’ils comprennent quelque chose à un makefile complexe, puis comparez par exemple avec un playbook Ansible…vous voyez où je veux en venir.

Cool Tools To Use (prononcez-le de plus en plus vite, c’est rigolo !)

Management

Certaines personnes sont allergiques à la ligne de commande. Bien que ces personnes soient totalement indéfendables techniquement parlant, il peut être intéressant de les initier au monde de Docker via une interface graphique.

Pour ce faire, vous avez :

– Docker Kitematic

– Portainer

IMG3 Docker : DevOps, teamwork editionSuper, encore un dashboard…

Ce dernier présente l’avantage d’être un élément à part, dans un service, que vous lancez directement depuis votre docker-compose par exemple. Il possède une somme de fonctionnalités intéressantes, et permet d’administrer des stacks Docker, des images, des volumes, etc. directement depuis un dashboard.

Reverse Proxy

Combien de fois avez-vous du stopper une stack via docker-compose stop pour lancer une autre stack projet, juste parce que le port était déjà pris ?

« Attends Martine faut que je stoppe mes containers le port 80 est déjà pris, ça plante ! »

IMG16 Docker : DevOps, teamwork edition“Tu préfères Traefik ou Fabio ?”

– “Traefik ! T’as vu le logo, il est chanmé !”

En utilisant un reverse-proxy comme traefik, vous vous donnez le droit de lancer plusieurs projets en simultané. Traefik sait également gérer le SSL via Letsencrypt (bien que depuis mars 2018, le challenge HTTP-01 rencontre un problème puisque Letsencrypt l’a supprimé, lol), ou encore le basic auth et les whitelist IP. Il est écrit en Go et permet vraiment de faire beaucoup de choses intéressantes.

Vous pouvez également aller encore plus loin en le couplant à consul et à registrator.

On espère que cet article vous a plu. Si ce n’est pas le cas, faites comme si vous n’aviez rien lu.

Joyeuses Pâques à tous et à toutes.

Laisser un commentaire.