new Blog( perso );

Quand on vous dit que les choses vont très vite dans l'écosystème Docker ...

Il y a quelques heures, David publiait son fiboid à base de docker imbriqués, il n'a pas fallu attendre bien longtemps pour voir les premiers commentaires, et en particulier celui de Solomon Hykes, fondateur de Docker...

Imbriquer des conteneurs Docker c'est possible mais évidemment on send que ce n'est pas une solution très "naturelle".

Docker étant basé sur un démon, auquel parle un client (la ligne de commande docker, ou tout autre client via une API REST), il est plus simple d'expose le démon de l'infrastructure aux containers qui ont besoin de lancer d'autres containers.

L'idée est simple : monter dans le container le socket exposé par le démon.

-v /var/run/docker.sock:/var/run/docker.sock

Du coup, quand dans un container qui a été outillé de cette façon on lance une command "docker run ..." c'est le démon de l'hôte qui va répondre, et lancer un nouveau container, non plus imbriqué, mais côte à côte. Plus besoin de bricoler pour pourvoir faire tourner un démon docker dans le container, exposer les cgroups, etc. C'est tout de même un peu moins "hack-ish" :P


Deux petits schémas pour résumer ça :

Lancer un container DANS un container - possible, mais on sent comme un truc pas net

Lors de notre session au Ch'tiJug, expliquant entre deux anecdotes que Docker peut même être lancé à l'intérieur d'un autre container Docker, on (amis, j'ai oublié ton nom) nous a suggéré de faire un calcul récursif de suite de Fibonacci via des containers Docker.

Il n'en fallait pas autant pour lancer David sur la piste d'un projet aussi inutile qu'indispensable, dont il a publié le résultat : https://github.com/dgageot/fiboid "Fibo Inside Docker". Ce gars ne dors jamais, ou bien il est vraiment cinglé, ou peut être les deux, en tout cas svp ne l'encouragez pas.

A quoi ça sert ?

Sur l'exemple de David : a rien - enfin si, à tester la capacité de Docker à fonctionner en mode "poupée russe" et voir jusqu'où il peut aller.

Dans l'absolu, je suis longtemps resté perplexe, mais j'ai depuis vu passer plusieurs usages.


1. Builder des images Docker.

eBay a adopté Mesos et Docker, et a publié un papier dessus. Depuis Jenkins, un container Docker est donc lancé sur le cluster Mesos pour héberger chaque build. Jusque là, c'est simple, sauf que ce build veut lui même construire et tester des images Docker, et va donc lancer Docker dans l'image Docker. On a donc un premier niveau d'imbrication.

2. Packager un environnement multi-noeud.

A moins de vivre dans une grotte, vous n'avez pas pu rater l'annonce de Docker 1.0-FINAL production ready.

Il y a tout de même un petit bémol à prendre en considération sur ce "production ready".

Docker utilise les capacités du noyau Linux pour isoler et contrôler des groupes de process (respectivement : namespaces et cgroups). La promesse est donc que chaque container se comporte quasiment comme une VM, en beaucoup plus léger, assurant l'étanchéité et l'indépendance de chaque application par rapport à ses voisines qui sont au final co-locataires de la machine hôte.

Seulement dans la vraie vie, il reste une issue non encore résolue : pour lancer un container, il faut être root. Les process qui tournent dans le container sont root (le root du container) par défaut. On peut bien sur tourner dans le container avec un autre user, mais si on autorise à faire tourner n'importe quelle image, on doit partir du principe que l'utilisateur du container est root - ou peut le devenir en hackant son container en installant volontairement un soft dont il connait une faille de sécu, il ne suffit donc pas de forcer le USER.

Que se passe t-il si notre utilisateur dans le container, qui s'y connais bien et a des intentions indélicates, arrive à sortir du conteneur, exploitant la faille X de la version Y du noyau pas encore mis à jour sur l'infra ? Et bien notre petit malin va se retrouver root sur la machine hôte - et ça c'est pas glop. Tiens d'ailleurs, si quelqu'un connais une (vielle) version du noyau / distro qui aurait un bug de ce type ce serait sympa pour en faire une démo.



Cette contrainte, on peut vivre avec, surtout sur des environnements privés : dans votre DataCenter, le risque d'un hack de ce type est quasi nul vu que vous ne déployez que vos propres applis. Sur un environnement réellement multi-tenant comme un Cloud public par contre ...

Le noyau Linux fournit le mécanisme de user namespace, qui permet à l'utilisateur root du container (id=0) d'être en fait l'utilisateur tartempion avec des droits standard sur la machine hôte. Le jail-break, sans être complètement anodin, n'a alors plus du tout le même impact.

Docker pourrait utiliser ce namespace, qui nécessite "juste" un noyau très récent. Vous pouvez lire les commentaires sur cette issue par exemple, qui n'aborde qu'une partie d'un possible fix, pour comprendre que ce n'est pas si simple, et qu'écarter ce point pour une 1.0 avait du sens. Comme dit plus haut, cela n'interdit pas d'utiliser Docker dans un environnement privé et contrôlé.

Par contre c'est un gros frein pour son utilisation massive par les hébergeurs Cloud, sauf à y adjoindre un autre niveau de sécurité. Sans surprise, le support Docker proposé par Google utilise une VM par déploiement, ce qui en soit est une régression de la part de l'éditeur qui utilise des containers en interne depuis presque 10 ans.



Je m'interroge sur les solutions retenues par les autres hébergeurs qui proposent du Docker aujourd'hui. S'ils veulent bien me contacter pour en discuter en privé je serais ravi d'échanger sur le sujet.

Vous pouvez aussi lire http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/ pour en savoir plus sur ce thème.

Regardez aussi cette vidéo qui montre ce qui se passe lorsqu'on sort du container et qu'on rencontre la protection SELinux, qui évite à "root" de devenir "root" :-\

Pendant deux jours, Docker a été à l'honneur avec la première édition de la DockerCon, à laquelle participait mon collègue Michael Neale que je maudis pour avoir eu une place et pas moi.

1. Docker production ready 1.0 - ok, ça fait conference-driven-development, et un 1.0.1 va évidemment suivre, ceci dit la version 0.12 qui a précédé était déjà super-stable, donc ce n'est pas que du marketing.
2. Des témoignages d'acteurs majeurs. RackSpace, NewRelic, Ebay, Twitter ... autant d'innovateurs qui ont déjà commencé a adopter Docker dans leur boite à outil. J'espère que vous allez leur emboiter le pas :)
3. Le re-vamping de l'index (build et hébergement des images Docker) en "DockerHub". Michael a discuté avec eux de l'intégration Jenkins, présentée en keynote de la conférence. L'idée est de "laisser faire Jenkins pour valider une image, chacun son taf" et j'ai donc préparé l'indispensable plugin qui va avec, n'allez pas voir pour l'instant il ne fait rien :) Je vais surtout bosser sur une intégration OAuth propre, la partie "validation d'une image" ayant par définition une signification différente pour chacun.
4. Des annonces en tout genre, entre autre le positionnement très fort de Google sur Docker. Il faut dire que Google est à l'origine de cgroup donc fait partie de l'écosystème des containers depuis un moment.
5. De nouvelles briques pour l'écosystème Docker. Si vous avez vu notre prez', Docker gère le container mais laisse aux outils tiers l'orchestration de l'infrastructure. CoreOs et Mesos sont les gros-mots qui reviennent souvent sur ce sujet, mais l'équipe Docker a aussi lancé libChan (communication entre containers) et libSwarm (composition de services à base de containers).

En tant qu'organisateur du BreizhCamp, un stress particulier concerne la programmation de la conférence. Les thèmes choisis reflètent-ils les attentes ? Notre sélection de speakers a t-elle été la bonne ?

Obtenir du feedback du public est donc indispensable. Nous avons testé le tableau de post-it pour collecter votre avis général sur la conférence, mais cela ne nous informe pas sur les sujets eux-même.

En 2013 nous avions placé en sortie de salle des feuilles de vote proposant trois smileys, et vous demandant de cocher celui qui correspond à votre état d'esprit. Si d'un point de vue logistique cette solution est simple, elle ne rencontre pas un succès terrible, peu de personne prenant le temps de s'arrêter pour choper un stylo, cocher, remettre le bouchon. Certains ont également regretté l'absence d'un mode d'emploi pour expliquer clairement nos attentes face à une feuille vierge.

Très clairement, la facilité et la rapidité de vote est un facteur important.

Lors de DevoxxFrance, Xebia avait mis en place des boitiers de vote à la sortie de chaque salle :



J'ai vu peu de monde s'attarder pour voter, même si les données recueillies ont été très utiles pour les organisateurs. Un souci important était de mon point de vue la complexité excessive du système :

• 5 boutons, donc un choix assez délicat. J'ai du mal à imaginer que le bouton "très mauvais" ai beaucoup été utilisé. Le median non plus d'ailleurs, pourquoi s'arrêter pour voter si on a pas un avis spécialement tranché ? Accessoirement, sans repère visuel sur les boutons, leur sens n'était pas évident. Résultat, passer au vote nécessitait une réflexion et donc un frein à l'expression spontanée.
• Une identification NFC, destinée à éviter les votes multiples. Si vous avez déjà vécu la sortie d'une salle Devoxx vous savez qu'on a guère le temps de voter, alors voter 3 fois ... Sans parler de la question fatidique "mais heu, c'est vraiment anonyme du coup ?

Leçon #1 : ne pas laisser trop de choix, sous peine de perdre en compréhensibilité et donc en spontanéité du vote, et au final en nombre de votants.

Leçon #2 : ne pas mettre en place de barrières à l'expression des votants. Le vote doit être quasi instantané et ne pas ralentir la sortie de la salle.

Devoxx.be a de longue date tenté de récolter les avis des participants à chaud. La formule retenue est basée sur ce qui a participé au succès de FaceBook, les "like".


Ici aussi, on identifie le participant par puce NFC, cependant il n'y a que deux états "content" / "pas content". En 2013 ils avait rajouté au centre un capteur pour ajouter la session dans votre compte parleys, afin que les déçus de la salle pleine à craquer puisse avoir une seconde change offline.

Le système est simple, de compréhension évidente (surtout ce modèle avec les pouces intégrés dans la forme du boitier, mieux qu'en 2011). Le NFC reste un léger frein à la fluidité de la sortie de salle, et maintien une certaine interrogation sur l'exploitation des données personnelles,mais globalement le système fonctionne bien.

Leçon #4 : proposer une user-interface aussi explicite que possible.

Leçon #5 : le côté Geek du matos apparaissant en transparence est un élément clé de l'intérêt du public à expérimenter les systèmes de vote. De ce point de vue le boitier en alu brossé utilisé par Xebia était contre-productif (sans même évoquer les problèmes de masse qui leur a plombé leur nuit pré-devoxx).


Pour JavaOne, les organisateurs avait mis en place des boitiers avec 4 boutons de vote, du vert au rouge avec un joli dégradé de smileys.



J'ai vu bien peu de personnes prendre le temps de voter sur ces boitiers, mais l'approche est simple, explicite, et saine sur la nature des "données" fournies au système. Ici je passe devant et j'ai juste à mettre un coup de poing sur le bouton de mon choix.

Pour le BreizhCamp, nous n'avions pas l'intention de faire des bracelets avec puce NFC, entre autre en raison du coût de ces gadgets. Une solution de ce type était donc clairement ce qui nous correspondait le mieux.

Comment éviter les votes multiples ? D'ailleurs, qu'est-ce qu'un vote multiple ?

Celui qui est super-super-content et va rester 3 minutes devant la machine pour exprimer son contentement en votant 10 fois, finalement fournit une information utile. Le tout est de savoir l'exploiter (problème de BigData :P). Evidemment il y a le cas du Aurelien qui durant toute sa pres' vient voter +1 chaque minute, mais ça reste un cas isolé et très facilement identifiable.

Nous avons donc défini notre cahier des charges :

1. le boitier doit être d'utilisation limpide, sans aucune interrogation sur sa bonne utilisation. Deux boutons +1 / -1 suffisent, et obligent à se positionner plutôt qu'à voter "neutre".
2. le vote doit être physique, par bouton, pour être rapide et implicitement anonyme. 
3. le double vote involontaire (rebond du bouton) doit être évité, pas forcément le vote multiple absolu
4. le boitier doit être geek, fun, donc transparent. L'idée est rapidement venu d'intégrer leds / bip / écran pour signaler la prise en compte du vote.
5. le boitier doit être costaud. Bouton coup-de-poing industriel, plexi de 8mm, pied d'enceinte 50kg.
6. le CPU dédié à enregistrer les votes ne risquant pas la surcharge, la sortie vidéo HDMI est exploitée pour afficher programme, tweetwall, etc
7. l'accès réseau se fait en filaire. Nous savons tous ce que donne le Wifi en conférence.