Docker Con EU 2014 a eu lieu à Amsterdam il y a quelques jours. En plus d’être tenue dans cette ville très sympathique, cette conférence était d’un très bon niveau. Comparativement à Docker 2014 aux USA, deux différences principales:
- On y parlait un peu moins de technique et un peu plus d’architecture et d' »adoption » (au sens américain)
- Docker inc. a fait plusieurs annonces de fonctionnalités majeures, qui ont été très appréciées.
Le post précédent fait le bilan des annonces de fonctionnalités majeures avec des exemples de code ici.
1er jour
Keynote
Le thème le plus marquant de la keynote est qu’avec le cloud, internet n’est plus seulement une plateforme de publication mais une plateforme de calcul. Certes on le savait mais j’ai trouvé la formulation concise et marquante. Dans ce contexte général, Docker s’inscrit plus précisément comme un moyen technique permettant d’implémenter une architecture micro services. Au début, Docker ne permettait « out of the box » d’implémenter des applications à un seul container, car le container linking (visibilité d’un container depuis un autre container) n’existait pas et il fallait tout faire manuellement. Le container linking est maintenant supporté nativement depuis longtemps (à l’échelle de temps de Docker), et permet d’implémenter facilement des applications multi-container. L’orchestration des containers reste cependant plus difficile; à l’avenir la même facilité d’utilisation sera offerte dans le cas le plus général multi-containers multi-hosts que dans le cas mono-container (plus besoin de pattern Ambassador).
Revamping dev and testing with Docker
les slides
Intervention de Henk Kolk, architecte chez ING. Problème bien connu du monde IT bancaire, la difficulté de changer un existant! Cette difficulté ne vient pas seulement de la complexité de l’existant, mais aussi de systèmes de croyance trop enracinés culturellement.
Le seul moyen de vaincre cette inamovibilité est une approche bottom-up, c’est-à-dire dans le contexte Docker de containeriser des services existants, de façon à ce que la simplicité et la reproductibilité suscitent l’envie. Il ne faut pas proposer de changer la prod, mais attaquer par le biais des environnements de dev/test/intégration. Dans ces environnements, l’avantage comparatif de Docker est flagrant pour un risque modéré. En effet, Docker permet facilement d’instancier des environnements de façon reproductible: 
Par contre, l’utilisation de Docker pour instancier les environnements de production, ou l’utilisation du Docker Hub comme outil de continuous delivery se heurtent souvent à l’objection de la localisation de l’infrastructure qui DOIT être hébergée localement chez l’entreprise (« on premises », c’est-à-dire sur place), par exemple pour des raisons légales ou réglementaires. C’est une objection extrêmement fréquente (et justifiée), et on verra dans les résumés des présentations des nouvelles fonctionnalités que Docker inc. a l’air d’être conscient de cet état de fait, et de faire le nécessaire pour étendre l’utilisation de Docker au cas d’un private cloud.
State of the art in micro services
Présentation d’Adrian Cockcroft; Les slides
Docker facilite l’implémentation d’une architecture micro services, les containers étant des building blocks déployés indépendamment. Son avantage comparatif est d’autant plus important que l’application est hétérogène (N langages). Cette présentation était une des plus intéressantes de la journée.
Les outils apportés par Docker à cette fin peuvent être classés en plusieurs catégories:
- Tooling (le CLI/API Docker de base)
- Configuration (Fig/Docker compose)
- Discovery/Routing (container linking, le remoting transparent à venir, sans Ambassador)
- Observability (la commande docker events)
Si la roadmap de Docker présentée lors des annonces de fonctionnalités tient ses promesses, l’approche micro services sera aussi facilitée par les facteurs suivants:
- moins besoin d’outils complexes d’orchestration: les fonctionnalités d’orchestration seront intégrées nativement dans le CLI (ou API équivalente)
- le Docker Hub comme « enterprise app store »: réutilisation de services commerciaux
La parties les plus intéressante était la définition de patterns d’architectures micro services, qui aident beaucoup en début de projet (syndrome de la page blanche). En voici quelques uns, qu’on peut retrouver sur slideshare: slideshare
Le template d’architecture est le suivant: 
L’implémentation de ce template abstrait par Twitter: 
Quelques autres points soulevés par l’intervenant en conclusion:
- L’approche micro services s’impose de plus en plus en remplacement des applications monolithiques
- Le langage Go a l’air de s’imposer dans cet écosystème. Cela semble naturel pour un langage de programmation système « C en moins dur/risqué »
- Il recommande le livre « Lean enterprise ». Vu la qualité de son intervention je vais y jeter un coup d’oeil
A Docker CD pipeline
Les slides
Les deux buts principaux de Rafe Colton (ModCloth), en intégrant Docker à son pipeline de Continuous Delivery,étaient:
- Supporter une variété de langages
- Faciliter le déploiement reproductible des différents environnements
Comme ils ont commencé à utiliser Docker dans sa version 0.6, initialement leur modèle était de déployer 1 container (modèle « mini-VM »): 
Ensuite l’évolution technique de Docker, et leur meilleure connaissance de la plateforme, leur ont permis de passer à une architecture respectant mieux le principe de séparation des responsabilités:
- En mettant à profit le container linking, pour éclater leur mini-VM en N containers: principe général « une responsabilité par container »
- En comprenant mieux ce qui relève de la responsabilité de chaque container ou de celle du host (logs centralisés pour toute l’application):
J’ai bien aimé la formule de « canonical building block » pour définir le rôle de chaque container lors des étapes de packaging et de distribution.
Plus techniquement, ils ont retirés de leur expérience quelques patterns d’implémentation pour les Dockerfiles:
- Mettre les directives qui peuvent provoquer un changement en dernier, pour bénéficier du cache de build au maximum (accélérer le cycle de développement)
- Grouper en 1 directive RUN les commandes liées logiquement (télechargement + dezip pour installer un composant par exemple)
J’ai profité des questions pour demander à l’intervenant si mon choix simpliste posait problème: ajouter dans Jenkins une étape post-build à la génération d’un war, consistant à appeler (via ssh) un script de build/run (sur une des VMs où nous avons installé le Docker daemon). Pas de problème a priori, ce choix est moins joli que de construire l’image sur Jenkins mais plus simple techniquement, et donc fera l’affaire dans un premier temps.
A noter un point intéressant: le CLI (command line interface, comprenant docker run etc) traduit les build/run/etc en invocations de l’API REST.
Enable Fig to deploy to multiple servers
Présentation de Willy Kuo (Docker inc). Les slides
Un fichier yaml de Fig comprend des direc
tives de build et de run, cette approche déclarative permet de builder les images et lancer les containers avec une seule commande fig up. La grosse nouveauté présentée est la possibilité de déclarer les hosts sur lesquels on veut instancier les images. Pour ce faire les daemons Docker et les clients doivent être configués pour https; la documentation officielle explique comment cette configuration. Attention, cette fonctionnalité prend en charge uniquement le déploiement, mais pas le remoting inter-containers; il faut pour l’instant toujours utiliser le pattern Ambassador, ou attendre l’évolution de Docker permettant le linking inter-hosts transparent.
Opinionated containers (game servers)
Quelques patterns pas uniquement valables pour des serveurs de jeux:
- Un container, un process: éviter de lancer des process daemon en plus du process entrypoint dans un container, car cela crée des problèmes techniques de détection de l’arrêt du container. De toute façon c’est ce que dit de faire le principe de séparation des responsabilités. D’autre part une des raison principales pour laquelle les gens rajoutaient un daemon dans les containers était sshd pour se connecter au container, mais on a docker exec à partir de 1.3
- Séparer les data stores pour faciliter le déploiement en cluster: un datastore par fonctionnalité
- Point relié au précédent, pas d’état dans les containers: préférer des containers stateless, externaliser l’état dans des containers spécialisés (ou au pire dans le host)
De façon générale, containeriser une application (écrire les Dockerfile et les scripts) est facile, mais la déployer en cluster est difficile. La gestion de l’état persistant est d’autant plus critique dans un cluster, donc il faut absolument respecter la séparation des préoccupations.
2eme jour
Open design at scale
Les slides
Docker est open-source (même si Docker inc. est une entreprise commerciale). Les commits proviennent d’employés de Docker inc. et de personnes externes. Solomon Hykes est un des fondateurs de Docker inc et a le statut de BDFL (« benevolent dictator for life »). Il explique comment ces nombreux commits sont coordonnés:
- Le contributeur crée une pull request, les vérificateurs examinent les pull request et font le merge.
- « The organisation is code »: le processus est défini précisément par une spécication « Open design API » qui décrit les interface entre le projet d’une part, et les contribueurs et vérificateurs d’autre part.
- Le modèle de pull request n’est pas adapté pour des très gros merges, les grosses features donnent dorénavant lieu à des sous-projets (ex: les nouvelles fonctionnalités compose/swarm/…)
BBC: CI problems and our solutions
La BBC utilise Docker pour:
- Factoriser leur « language stacks » (java, php). La directive Dockerfile ONBUILD introduite par 1.3 permet de factoriser les actions à exécuter pour une language stack donnée quelque soit l’image concrète buildée avec cette stack (analogue au pattern OO Template method).
- Permettre le déploiement isolé de N versions de chaque version (canary deployment, tests)
En moyenne ils obtiennent un feedback plus rapide avec un pipeline de CD incluant Docker.
Mesos: building web scale apps
Les slides
Mesos est présenté par Alex Rukletsov (Mesosphere) comme un « datacenter kernel », prenant en charge l’orchestration de containers, et le clustering. Mesosphere étant désormais un partenaire Docker, et officiellement supporté par Kubernetes, l’intégration de ces plateformes devrait être plus facile à l’avenir.
Ce partenariat est techniquement intéressant dans les deux sens:
- Intérêt de Docker pour Mesos: les containers Docker sont une unité de déploiement intéressante du point de vue de Mesos, car contrairement aux VMs traditionnelles, dimensionnées au démarrage, un container ne prend sur le host que les ressources réellement utilisées
- Intérêt de Mesos pour Docker: Mesos implémente des fonctionnalités de clustering dont Docker ne s’occupe pas: failover/HA, scheduling avancé (ex: critères géographiques), IHM de surveillance/administration du cluster
Concrètement, l’intégration des deux se manifestera par:
- Le support natif de Docker dans Mesos/Marathon
- Docker Swarm pourra (via un driver spécifique) instancier des containers dans un cluster Mesos:
Hormis Docker, il explique que Mesos n’est pas seulement « pour les gros »: on peut provisionner un cluster Mesos sur AWS/Digital Ocean/Google en spécifiant ce fournisseur dans un fichier de conf Mesos: 
Keynote: annonces de nouvelles fonctionnalités
La conférence a été l’occasion d’annoncer une palanquée de nouvelles fonctionnalités (le contenu plus précis de chacune a été ensuite détaillé dans les « break-out » du deuxième jour). Je trouve qu’elles répondent à des besoins techniques ou demandes du client récurrentes:
- Docker Machine
- Compose
- Swarm
- Trust-provenance
- Docker Hub enterprise
La série de présentations « Break outs » reprenait les annonces de fonctionnalités majeures de la veille, chacune était présentée par un développeur du sous-projet correspondant.
D’autre part, ce point n’a pas donné lieu à un break out, mais ils ont aussi annoncé la prise en charge du container linking inter-host de façon transparente, ce qui évitera de compliquer son architecture avec des containers supplémentaires (pattern Ambassador).
Break out: Docker Machine
Présentation de Aanand Prasad de Docker inc. Les slides
Le but est de raccourcir le « zero to docker », c’est à dire de permettre de créer un daemon docker dans le temps le plus court possible pour un utilisateur lambda, même s’il est sur windows ou mac. Jusqu’à maintenant il fallait utiliser boot2docker ou vagrant, mais boot2docker ne fonctionnait pas dans certains environnements (chez moi, reste bloqué à « starting… ») et vagrant demande d’être capable de comprendre et modifier le Vagrantfile. Docker machine continuera à marcher avec VirtualBox, mais son utilisation sera plus transparente avec une simple commande machine create; le flag -d permet de spécifier un « driver », par exemple -d digitalocean. Ensuite on utilise machine url pour accéder au daemon créé. Plusieurs daemon peuvent être créés sur un host, on peut les lister avec machine ls.
Machine ne sera pas seulement utile à ceux qui ne disposent pas d’un environnement linux. J’aime bien l’idée d’installer Docker en local ou dans le cloud avec un simple flag spécifiant le driver: 
La roadmap prévoir l’intégration avec Swarm: cela permettra de déployer des containers sur un host ou Docker n’est pas installé initialement.
Break outs: Docker Swarm
Présentation de Victor Vieux de Docker inc. les slides
Le but de Swarm est de faciliter le clustering Docker qui pour l’instant repose entièrement sur des outils externes. Pour une applicatio
n complexe, l’approche « 1 container mini-VM » n’est pas adaptée, veut aider à faire du multi-containers + multi-hosts.
Ce sujet étant potentiellement très vaste (scale up/down du cluster, HA, ..), ils ont commencé par implémenter la fonctionnalité la plus facile: le déploiement initial d’un container, en abstrayant pour l’utilisateur la topologie du cluster:
- La personne chargée de configurer Swarm commence par créer un noeud particulier « master » de Swarm avec la commande
swarm create, qui retourne un jeton identifiant le cluster. Ce jeton est ensuite utilisé par les autres noeuds pour rejoindre le cluster (swarm join). Une fois le cluster créé, il peut être administré avec les commandes list/manage:
- L’utilisateur peut alors considérer le cluster comme un gros virtual host, dans lequel il instancie des containers avec les commandes habituelles de façon transparente (
docker run, ..).
Les critères pris en compte pour déterminer (scheduling) le noeud sur lequel instancier le container incluent (à des stades d’avancement divers):
- Les ressources nécessaires: Swarm déploiera un container sur un noeud dont l’utilisation actuelle permet de satisfaire la mémoire/cpu demandés par docker run (flags
-met-c) - Les ressources uniques: Il déploiera un container sur un host où le port HOST voulu est disponible (
-p HOST:CNT) - Flags de contraintes spécifiques à Swarm: les containers pourront spécifier à Swarm des contraintes sous forme de variables d’environnement particulières, quelques exemples: 1/
-e constraint:operatingsystem=fedora2/ déploiement sur un daemon docker particulier (en utilisant le « label » du daemon souhaité, qui est une nouvelle option de lancement des daemons) 3/ par affinités inter-containers positives ou négatives (encore beaucoup de travail)
La roadmap inclut la haute disponibilité:
- Des containers: le « re-scheduling » des containers consiste à mettre dans l’état « pending » un container déployé sur un host tombé, jusqu’il soit redéployé ailleurs dans le cluster
- De Swarm lui-même: pour l’instant le noeud sur lequel on fait Swarm create est un « single point of failure », mais cela va changer
Certaines limitations actuelles de Swarm, seront levées par des évolutions de Docker core:
- Container linking: pour l’instant la façon la plus simple est de spécifier une contrainte de déploiement sur un host particulier, ce qui est antinomique d’un cluster. Swarm sera bien plus utile quand le container linking inter-hosts sera implémentée par le projet core
- Je n’ai pas compris si à l’avenir un volume pourrait transiter d’un noeud à un autre lors d’instanciations successives du container qui le porte (peut-être pour un container data-only?)
Break outs: Docker Compose
Présentation de Aanand Prasad de Docker inc. Les slides
De même que Swarm, Compose répond au besoin d’écrire des application multi-containers. Mais si Swarm prend en charge le « scheduling » (c’est à dire la répartition des containers dans un cluster de hosts), Compose s’occupe plutôt d’orchestration (càd de coordonner le lancement de containers dépendant les uns des autres via du linking, des volumes, .. ).
Citation: « multi-containers apps are a hassle », c’est vrai que c’est répétitif pour une chaîne de dépendance entre containers donnée, d’écrire le script qui builde les images, les script qui crée les containers, le script qui les lance, les arrête, les supprime, .. Il est plus simple de factoriser cette chaîne de dépendances dans un fichier déclaratif une fois pour toutes, puis d’utiliser fig: 
Or Compose intègre désormais fig dans docker, ce qui permet par exemple d’enrichir la syntaxe des commandes existantes: docker rm : supprime tous les containers déclarés dans le fichier group.yml du répertoire courant: 
Break out: Trust/provenance
Docker 1.3 a introduit les images signées (mécanisme habituel basé sur la chaîne de confiance des certificats). L’idée de « trust » est de réaliser une bijection entre les certificats de la chaîne de confiance, et les namespaces Docker. Par exemple le namespace racine des images officielles (celui qui ne comporte pas de préfixe) est associé au certificat racine de Docker inc. Ceci permet alors à chaque namespace d’être garanti par la chaîne de certificat associée. La partie « provenance » était succinte, cet outil est plus particulièrement chargé de vérifier l’origine et le contenu des images.
Break out: What’s new in Docker hub
Les slides
Quelques nouveautés dans le hub standard (non-Enterprise) présentées par Ken Cochrane de Docker inc:
- Granularité plus fine des permissions avec l’introduction des « organisations » et des « groupes »
- Les « web hooks » permettent de d’invoquer des scripts lors du déclenchement d’un auto-build Docker Hub (lui-même déclenché par un commit sur un repo git). Ceci permet par exemple d’invoquer une étape Jenkins
- Les « repository links » permettent de déclencher le build de notre image lorsque son image parente (au sens de la clause FROM du Dockerfile) est buildée
Quelques points intéressants dans la roadmap:
- Généralisation des web hooks, pour pouvoir en placer sur un build arbitraire (et pas seulement le build de l’image parente)
- Introduction d’un dashboard pour surveiller ses builds
La grosse nouveauté est le hub enterprise (les slides)
Bilan
Docker continue d’avancer à la vitesse V. Les deux enseignement principaux que je tire de cette conférence sont les suivants:
- Il semble que Docker inc. ait bien écouté ses utilisateurs; les annonces de nouveautés répondent aux demandes ou aux objections qui reviennent tout le temps: le multi-containers est trop compliqué, le multi-host demande d’utiliser trop de technologies externes et complexes, les entreprises se méfient du public cloud (à raison surtout lorsque l’hébergement est aux USA, cf. Snowden). Les réactions étaient très positives.
- L’adoption passe d’abord par les environnements de développement et d’intégration. Pour convaincre, il vaut mieux faire envie avec la facilité et la rapidité de déploiement reproductible d’environnement isolés. Ces environnements étant souvent le parent pauvre du SI, la comparaison est très flatteuse pour Docker et pourra alors provoquer une réflexion sur l’adoption en production.
- La valeur ajoutée de docker n’est pas seulement technique mais aussi (et peut-être surtout) l’adoption d’un standard de facto:
L’annonce récente de Rocket, un fork-sans-être-un-fork, n’a pas eu l’air de provoquer le doute chez les visiteurs de la conférence.
