Le 6 Octobre prochain, ops et développeurs vous donnent rendez-vous au TIAD Camp Docker, pour échanger et partager autour du déploiement de Docker en production. Parmi les speakers qui seront présents, Maxime Visonneau, Lead Ingénieur Devops et Paul Bonnaud, Ingénieur Infrastructure chez Trainline, viendront partager leur retour d’expérience sur la migration des pipelines de CI/CD sur AWS avec des containers Docker.

TIAD Camp s’inscrit dans la même philosophie que le TIAD, celle de donner à la communauté de l’automatisation un espace de partage, de rencontre et d’expérimentation. TIAD Camp vous propose des deep dive techniques plus réguliers, tout au long de l’année, sur les sujets techniques qui font l’actualité. En préparation du TIAD Camp Docker, nous avons rencontré Maxime et Paul pour échanger sur la migration de leur infrastructure de build en containers Docker.

Quelle expérience aviez-vous de Docker avant de vous lancer dans ce projet ?

Paul : J’ai mené plusieurs projets personnels, et j’ai également expérimenté Docker sur le lancement d’un nouveau service qui devait être déployé rapidement en production. C’était l’occasion de tester une solution de conteneurs, dont le résultat s’est avéré probant.

Maxime : Comme Paul, j’ai commencé à me familiariser avec Docker sur des projets personnels. J’ai également travaillé pendant environ deux ans sur une implémentation en production pour Medallia qui utilisait essentiellement Docker, Mesos et Marathon. Cela m’a permis de commencer le projet de migration avec une expérience de production, une idée des différentes architectures, façons de procéder ainsi que les éventuelles problématiques que cela peut apporter.

Pourquoi avez-vous choisi Docker pour vos pipelines de test ?

Paul : L’objectif était de se simplifier la vie pour les environnements de build. En termes de résilience et de scalabilité, les procédures étaient relativement compliquées et nous voulions simplifier tout ça. Nous souhaitions également donner plus de pouvoir à nos équipes de développement. Chacune peut avoir envie ou besoin d’installer une nouvelle libraire système ou de tester une nouvelle technologie, et nous voulions pouvoir leur offrir cette liberté. Les développeurs peuvent maintenant gérer eux-mêmes la configuration des prérequis et des environnements de leurs pipelines grâce à un dockerfile versionné et joint à chacun de leurs projets. Il est beaucoup plus facile et rapide de suivre l’évolution des projets et d’identifier les problématiques opérationnelles avant d’arriver en production.

Maxime : Nous voulions simplifier la vie des développeurs, mais aussi la nôtre ! Jusque-là les environnements de test et de build étaient gérés manuellement. Passer à Docker nous permet de déclarer ces environnements de manière fiable et reproductible, ainsi que d’adopter les bonnes pratiques de l’infrastructure-as -code et du devops.

Un des principaux intérêts de Docker est de pouvoir avoir des images immutables de ses applications et de leurs prérequis. Ce que l’on cherche avec des processus de CI, c’est de pouvoir répéter des actions similaires sur tous les environnements avec une garantie de la conformité du résultat à l’exécution. L’usage de Docker pour faire fonctionner des pipelines de CI prend tout son sens avec des images complètement immutables, qui assurent que l’ensemble des dépendances soient présentes. Il est beaucoup plus rapide de récupérer l’ensemble des dépendances dans la version et l’état souhaité à travers une image Docker qu’en utilisant un outil de gestion de configuration. Notre besoin étant d’effectuer un grand nombre de tâches différentes, nécessitant des dépendances et des configuration toutes différentes les unes des autres, l’usage de Docker est de loin la solution la plus simple et adaptée. Il nous aurait fallu un nombre incommensurable de machines physiques ou bien virtuelles afin de pouvoir obtenir le même résultat final.

Paul : Historiquement, nos machines de production sont provisionnées de façon automatisée avec un outil de gestion de configuration. Ce n’était pas le cas des machines de build, et puisque nous voulions donner plus de responsabilités aux équipes projets, l’idée était de leur donner la possibilité de provisionner sans avoir besoin de se lancer dans Ansible ou Puppet. La courbe d’apprentissage est beaucoup plus rapide et il est plus facile de motiver les équipes de travailler de cette façon plutôt qu’en gestion de configuration.

Avez-vous rencontré des difficultés ?

Maxime : L’usage de Docker impose de revoir sa façon de voir les choses. L’immutabilité, l’éphémérité des environnements, le packaging minimal des images… tout cela implique de réfléchir différemment.

Paul : Il est difficile de faire quelque chose de simple du premier coup. Sur beaucoup de projets, nous avons été amenés à revoir des choses et à les faire plus simplement, et mieux. Concernant les dépendances, lister toutes les dépendances en amont pour faire fonctionner nos pipelines dans Docker nous a permis de découvrir des dépendances qu’on avait complètement oubliées ! Nous avons pu mener un véritable inventaire des dépendances. C’est un coût en termes de temps, mais aujourd’hui cela nous apporte une meilleure visibilité. Chaque projet est isolé et rationalisé, et chaque service peut tourner sur n’importe quelle machine ou VM, ce qui n’était pas possible auparavant en raison de la dépendance à d’autres services.

Quels gains avez-vous constaté ?

Maxime : Côté ops, nous pouvons maintenant faire tourner nos pipelines de build n’importe où, sur n’importe quel type de machine. C’est un vrai confort de pouvoir disposer de nos machines physiques et de nos instances comme on le souhaite. De pouvoir les mettre à jour facilement, de façon cloisonnée par projet. Et les gens sont beaucoup plus responsabilisés sur leurs projets, en termes de prérequis et de sécurité. Si demain on détecte une faille de sécurité dans une librairie, le développeur est capable de gérer la mise à jour nécessaire sans faire appel à l’opérationnel.

Paul : Nous pouvons maintenant scaler à volonté, spawner des VMs dans tous les environnements, tout fonctionne dans des containers et on peut tourner dans n’importe quel runner. Actuellement un de nos développeurs travaille sur le pipeline de CI pour diviser un job par machine et passer de 8mn à 2mn. On peut maintenant faire de la parallélisation sans impacter les autres projets. Si on a 1000 tests à faire, on peut le faire sans ralentir les autres pipelines.

Maxime : même si l’aspect financier n’était pas un moteur au départ, nous pouvons maintenant envisager de mettre en oeuvre du dimensionnement dynamique (auto scaling) de notre infrastructure de CI afin de réduire nos coûts opérationnels. Ce qui aurait été beaucoup plus difficilement envisageable auparavant.

Est-ce que Docker favorise la mise en place d’une organisation Devops ?

Maxime : Aujourd’hui c’est un outil incontournable. Est-ce qu’il le sera encore dans les années à venir, je ne sais pas. Ce qui est sûr c’est que cela permet de lancer des projets de manière très simple et d’on-boarder très rapidement les gens sur les projets de développement. N’importe qui sachant utiliser un clavier peut récupérer Docker Engine, le faire tourner sur son OS et lancer un environnement de développement en quelques minutes. Vagrant a été un premier pas pour faire cela, mais pour la majorité de nos cas d’usage, Docker est beaucoup plus efficace.

Paul : l’avantage majeur de Docker est de décaler la responsabilité sur les développeurs et de pouvoir tester dans des conditions de production grâce à l’abstraction de l’OS fournie. C’est un incontournable pour se focaliser sur le développement et ne pas avoir de surprises en prod.

Qu’en est-il des enjeux de sécurité ?

Paul : Docker apporte une couche supplémentaire de sécurité, notamment l’analyse d’image. La construction par couches permet de savoir exactement quel binaire est installé dans l’image et de voir immédiatement si une version est impactée par une faille de sécurité. Mais la simplicité apportée par Docker fait aussi qu’on peut installer plus de choses. Le développeur a plus de responsabilités, et donc potentiellement il y a plus de risques de sécurité. Mais c’était déjà le cas avant Docker, avec par exemple Node.js et ses très nombreux modules et dépendances.

Encore une fois la sécurité est de la responsabilité du développeur, qui doit se poser les questions suivantes : est-ce que j’ai besoin de cette librairie? est-ce que j’ai conscience des problèmes de sécurité potentiels? est-ce que j’ai les outils nécessaires pour détecter ces problèmes?

Maxime : Il y a aussi la partie réseau, qui a toujours été un sujet sensible sur Docker. Beaucoup de sociétés travaillent sur le sujet et il y a d’ores-et-déjà un grand nombre de solutions qui émergent afin de répondre aux problématiques de sécurité de la stack réseau. En ce qui nous concerne, si nous devions passer Docker en production à l’avenir, on se pencherait clairement plus sur les questions de sécurité. Pour l’instant, le service que l’on offre utilisant cette techno étant uniquement exposé à l’interne rend la criticité différente.

Paul : Mais si nous devions passer plus de workloads en production, nous pourrions capitaliser sur ce que nous avons appris durant cette migration. C’est l’idée de notre talk au TIAD Camp : réaliser une première étape, passer les pipelines d’intégration sur Docker, est un bon premier pas pour appréhender Docker et réfléchir à comment amener notre solution actuelle à tourner complètement dans des conteneurs. Si on ne veut pas faire du Docker en production, commencer par ses pipelines build donne un très bon avant-goût.

Maxime et Paul animeront le talk « Usecase @ Trainline : A smooth migration to Docker focusing on our build pipelines » lors du TIAD Camp Docker le 6 octobre prochain :