DockerCon Europe #1

Containers, Docker, Consul, Mesosphere, Fig, micro-services… Tous ces buzzwords qui semblaient réservés aux Grands Du Web ® (Twitter, Ebay et consorts) débarquent aujourd’hui sur nos projets et dans les datacenters. Nous avons dégusté les vidéos de la DockerCon de San Francisco, c’est pourquoi nous sommes particulièrement excités d’être présent à la toute première conférence Docker sur le sol européen, à Amsterdam. Nous espérons en ramener des scoops croustillants (3 slots mystères ont été annoncés après la keynote !), mais aussi et surtout y trouver une puissante source d’inspiration pour les architectures à venir.

Voici un petit résumé de ce qu’on a réussi à capter au milieu du port d’Amsterdam.

Panorama

Pour commencer, parlons un peu du lieu. Nemo, l’équivalent du Palais de la Découverte à Paris, était le lieu idéal pour cette conférence. Il suffisait de voir le nombre de conférenciers présents à la démonstration de la machine de Rube Goldberg, il y avait plus de geeks adultes que d’enfants ! Ensuite, l’assistance : des passionnés, venus de toute l’Europe, voire même de plus loin, animés par une même foi dans ce projet open source, et convaincus qu’il peut apporter une révolution dans les SI dans les années qui viennent. Un intervenant a bien résumé la tendance durant une keynote :

En 2014, personne ne s’intéressait à Docker. En 2015, il est au programme de toutes les entreprises.

En parlant d’enthousiasme, un fait est révélateur : lors de la keynote de Solomon Hykes, jeudi soir, on se serait cru à une keynote de Steve Jobs annonçant le premier iPhone.

Docker et Docker inc

Une grande partie de la conférence a tourné autour de Docker et de ses nouveautés, mais aussi beaucoup autour de la formidable communauté qui s’est bâtie autour du produit. Les annonces de produits en bêta ont déjà été largement relayées, concentrons nous sur la matière vivante (The Human Stack), qui fait de Docker ce qu’il est aujourd’hui.

Nous avons beaucoup apprécié, dans toutes les interventions des employés de Docker Inc, la volonté farouche de mettre la communauté en avant, et de séparer le produit et l’entreprise.

Les chiffres officiels sont relativement éloquents : en 20 mois, plus de 700 contributeurs et 5000 pull requests (PR)… En revanche, ce qui est plus étonnant est que le board sépare ces chiffres officiels en deux catégories : les PR provenant de Docker Inc, et les PR provenant de la communauté. D’après Solomon, un projet sain est un projet où les reviewers ne privilégient pas les contributions en provenance directe de leur entreprise. Les temps de traitement d’une Pull Request, ainsi que le % de Pull Request acceptées devraient, à terme, être équilibrées.

L’ensemble des keynotes portait un accent fort sur l’attachement porté à faire de Docker une innovation communautaire, en conservant à tout prix son design ouvert et sa gouvernance partagée. L’initiative n’est pas nouvelle, mais les moyens dont les fondateurs du projet se dotent, et les règles srictes qu’ils s’imposent, devraient – espérons le – les garder sur la bonne voie.

Un Disneyland DevOps

Le ton a été donné très rapidement : dès la deuxième conférence, Henk Kolk, chief architect d’ING lâche :

En 2009, nous avons décidé de supprimer les postes de testeurs, de chef de projets. Chez nous, aujourd’hui, tout le monde doit être ingénieur.

Le reste de la conférence est à l’avenant : les 500 applications du groupe ont été refactorées pour être compatibles avec une approche micro-services. Les approches ESB ont été éradiquées. Les Dev et les Ops ne sont plus deux entités séparées mais une seule et même fonction. L’entreprise s’est complètement réogarnisée pour tourner autour de 180 équipes DevOps. Chez ING, tout le monde doit maintenant savoir développer, même le CEO, qui s’est auto-formé à Java, pour un résultat, et je cite : « pas si catastrophique ». Pour finir : « IT is the bank and the bank is IT ». Comme dirait mon voisin : « C’est pas tous les jours qu’un banquier m’arrache une larme… ».

Micro services

Durant toute la conférence, nous avons eu droit à des sessions sur les micro-services. A tel point que parfois l’amalgame entre contenairisation et micro-services était explicite.

Adrian Cockcroft, l’ancien architecte en chef de Netflix, nous a présenté 4 architectures micro services, qui présentaient toutes des caractéristiques transverses, qu’on peut résumer dans ce tableau :

En revanche, désolé pour les gens chargés de maintenir les diagrammes d’architecture technique, votre travail va devenir infernal, en voici pour preuve le schéma d’architecture de Netflix.

Néanmoins, même si il est parfois difficile de faire la part des choses, un des participants de la table ronde finale a très bien résumé le point : contenairisation, micro-services, architectures composables, tout cela n’a qu’un but : donner le pouvoir aux développeurs de faire du logiciel de qualité, rapidement.

Les slots de conférenciers

Deux thèmes principaux ont émergé lors des conférences : la contenairisation de l’usine logicielle et l’orchestration autour de Docker.

Depuis la mise en place de l’agilité, les équipes IT développent plus régulièrement des versions du logiciel. Afin de pouvoir livrer ces versions en production, plusieurs société se sont positionnées sur du « continious delivery », avec l’aide de Jenkins et Docker. C’est le cas de la SGIB (cocoricoooo) et de la BBC, qui ont chacune présenté leur démarche d’isolation d’une infrastructure complète à l’intérieur de leur usine logicielle.

Pour cela, ils encouragent les pratiques inspirées du mouvement software craftmansship (TDD, BDD) et DevOps. Docker rentre dans le cadre de ces bonnes pratiques. Il permet de s’assurer de l’immutabilité du livrable, et donc que le comportement de l’applicatif sera le même sur l’ensemble des environnements.

Le second grand thème qui a émergé est, comme attendu, l’orchestration. La totalité des annonces de Docker Inc. tournait autour de ce sujet. S’il est simplissime de faire communiquer des containers sur un même hôte, l’exercice est plus délicat si ceux-ci sont sur des hôtes différents. De nombreuses conférences ont donc tourné autour de ce sujet. Que ce soit des hacks plus ou moins propres (le vainqueur du Global Hack Day a présenté une solution « customisée » de Fig pour déployer en multihost), des projets open source, ou des sociétés qui tentent de conquérir ce marché, le constat est le même : tant que Swarm ne sera pas sorti, il faudra s’appuyer sur des outils externes pour réellement déployer Docker en production. Nous allons zoomer sur trois de ces outils qui nous tiennent à coeur.

Consul et Terraform

Mitchell Hashimoto, participant déjà à des projets comme Vagrant ou serf, nous a présenté Consul et Terraform. Le premier (Consul) se base sur une base de donnée distribuée type clef / valeur (comme etcd), pour fournir les services suivants : service discovery, health Checking et stockage, le tout fonctionnant sur un ou plusieurs datacenter. Pour le service discovery, Consul propose deux approches, soit à l’aide d’un DNS, soit à l’aide d’une interface HTTP. Le DNS a l’avantage de ne pas impacter les anciennes applications, qui peuvent ainsi fonctionner sans même savoir que consul existe, tandis que l’interface HTTP permet d’accéder à des metadata supplémentaires, et « de s’abonner » à des évènements qui notifieront l’application, par exemple de l’arrivée d’un nouveau service sur le cluster.

Terraform est un outil qui permet de construire et de gérer son infrastructure. Vagrant permet facilement de se créer son cluster de machine virtuelle, Terraform permet de faire la même chose sur un cluster réel. Vous pouvez par exemple créer votre cluster sur amazon en spécifiant le type de machine, le nombre d’instances, … La configuration est faite par type de machines (base de données, service web, …), et vous pouvez facilement rajouter une ou plusieurs instances d’un serveur web. Il est également possible de lancer le provisionning de ces machines à l’aide d’outils comme puppet ou ansible.

Building web scale apps with docker & mesos

Alex Rukletsov, de la société Mesosphere, nous a présenté le projet Apache Mesos. Il s’agit, pour résumer, d’un OS distribué pour datacenter. C’est un OS dans la mesure où Mesos est chargé de l’attribution de ressources aux tâches que vous souhaitez lancer sur votre ensemble de machines. Mesos proposait – avant Docker – une approche container-like, pour faire tourner divers plateformes sur les noeuds d’un cluster, en s’assurant de l’isolation des ressources et de la haute disponibilité des jobs. Parmi les différents types de jobs, le support des images Docker ne s’est pas fait attendre. Dans ses différentes annonces, Docker a annoncé un partenariat avec Mesosphere, qui va devenir un des orchestrateurs officiel de la solution Docker. C’est donc Mesos qui pilotera docker-swarm pour assurer la bonne distribution et la cohérence des déploiements à travers des Vrais Cluster ®.

Mesosphere apporte, autour de Mesos, les projets Marathon, pour avoir une GUI et une API REST pour déployer sur Mesos, ainsi que fournir du Service Discovery. Le projet Chronos, initié par AirBnb, s’ajoute à l’écosystème et assure lui l’équivalent d’un cron, distribué sur un cluster Mesos.

Alex a passé en revue les différents apports de Mesos et Mesosphere au projet Docker, puis a décrit plusieurs topologies de cluster applicables. Une excellente introduction au sujet. Pour ceux qui souhaiteraient creuser le sujet, sachez que les tutoriels de chez Mesosphere sont assez bien écrits.

Clocker

Clocker, sous licence Apache, a pour ambition de manager des « Clouds » Docker. Le projet repose intégralement sur Apache Brooklyn, qui permet, comme Marathon, de gérer des « Blueprints » de déploiement. Clocker y ajoute la gestion des containers. Le déploiement multi-hosts et multi-containers est pris en charge, sans avoir à se soucier du réseau. Mais, car il y a un mais, Clocker présente une faiblesse en ce qui concerne son utilisation en production. En effet, pour abstraire la complexité de monter un réseau multi-hôtes, le projet repose sur Weave, qui a l’avantage de la simplicité, mais qui présente des soucis de performance sous charge. Les leaders du projet envisagent de passer à une implémentation réseau plus solide, qui permettrait un passage en production.

Il faut noter que Clocker est d’ores et déjà en production, puisqu’il est l’implémentation sous jacente qui permet à IBM de proposer le service BlueMix.

Conclusion

Parfois les conférences ont pu paraitre décevantes : en effet, un grand nombre des participants était déjà convaincu du bien fondé de Docker, et était déjà allé beaucoup plus loin que le simple HelloWorld parfois présenté par les conférenciers. Pour résumer, nous n’avons pas appris grand chose lors de cette conférence. Néanmoins, et comme souvent, les à-cotés étaient passionnants. La communauté est riche, vibrante, pleine d’idées et les échanges, jusque tard dans la nuit, sont extrêmement intenses.

De plus, les organisateurs avaient eu l’excellente idée de convier deux scientifiques (un génomiste et un astrophysicien) qui ont exposé leur utilisation de Docker dans des contextes totalement inattendus. Après ces deux conférences, nous étions en droit de nous interroger : Docker (ou son successeur) va révolutionner la façon de développer, déployer et consommer des applications informatiques. Il se pourrait que cette révolution impacte bien plus largement d’autres secteurs, comme celui de la recherche, où certaines publications passeront du papier au conteneur !