new Blog( perso );

Je viens de finir le deuxième tome de "Prenez le temps d'e-penser", le bouquin de Bruce Benamran, célèbre pour sa chaine Youtube de vulgarisation scientifique dont le succès ne faiblit pas.

J'ai eu le plaisir de rencontrer brièvement Bruce (je me permet donc de l'appeler par son prénom) lors d'une séance de dédicace du tome 1. Le bonhomme est souriant et disponible, aussi j'espère qu'il  appréciera mon honnêteté dans ce billet - en supposant qu'il le lise, c'est un autre histoire, le Bruce étant très demandé je n'arrive pas bien à me représenter à quoi doit ressembler son agenda.

Pour commencer, un petit mot : Bruce est pour moi un modèle, ses capacités pédagogiques naturelles me laissent sans voix, le seul auteur qui m'ai laissé cette impression est Richard Feynman c'est dire. C'est en suivant ça chaîne que j'ai décidé de lancer la mienne, frustré par le format trop linéaire des conférences que je présente par-ci par là. Voilà.


Je vous livre donc mon avis de lecteur.

D'abord sur le Tome 1.

Bon commençons par dire que c'est un excellent bouquin à mettre entre toutes les mains. Sympathique, sur le ton de la conversation pleine de pointes d'humour, de références geek et autres détours qui rendent le texte très agréable, j'ai dévoré ce livre en 2 jours. Je m'attendais à ce qu'il reprenne des sujets et anecdotes déjà présentés en vidéo, aussi ce n'est pas un point qui m'a déplu, le contraire m'aurait en fait déçu, le livre étant ainsi la pleine continuité de la chaîne Youtube.

Je suis par contre un peu resté sur ma faim sur deux aspects : l'explication de la relativité du temps et de l'espace et un sujet foutrement compliqué, qui brutalise notre sens commun, et qu'il est bien délicat d'expliquer sans un tableau blanc et quelques schémas. Bruce à fait le choix de se concentrer sur du pur texte, ce qui rend ce chapitre étrangement difficile par rapport à la fluidité d'explication et aux analogies ingénieuses auxquelles il nous avait habitué. Bon clairement, je vois mal comment présenter le sujet autrement, je ne dis pas qu'on puisse faire tellement mieux ... mais de mémoire il me semble que j'avais plus tilté à la lecture de (l'excellent) Univers Elegant. Ou alors j'ai peut être juste eu le temps de digérer le truc ? Comme Bruce s'est en plus amusé à nous faire une révision des présidents de la 5ème république, je me demande s'il n'a pas fait exprès de nous mettre un chapitre destiné à être lu deux fois (ou plus) histoire qu'on soit bien imprégnés.

Second aspect, qui m'a fait retirer un dixième de point dans mon classement des livres indispensables que j'achèterais en triple pour les offrir à mes gamins, le chapitre sur la mécanique qui se présente comme une suite de concepts, annoncés comme un mal nécessaire. C'est très inhabituel de la part de Bruce qui met un point d'honneur à rendre tout sujet à la fois clair, amusant et immédiatement compréhensible.

Pour avoir été moi même auteur (Apache Maven - 1500 exemplaires vendu, j'aurais peut être du choisir un sujet un peu plus large) je sais aussi qu'il faut parfois savoir jongler avec les délais de l'éditeur et que - malheureusement - certains chapitres en souffrent. Tout le monde n'est pas un George R.R. Martin... Bon ceci dit ce n'est qu'une spéculation appuyée sur du vent, peut être que Bruce voulait faire ça comme ça et puis c'est tout, lui seul le sait et il fait ce qu'il veut de toute manière, et le succès des ventes du livre semble montrer que ça n'a gêné personne...

Donc en résumé, une oeuvre qui est un morceau de choix pour tout lecteur intéressé un temps soit peu à la science, et à laquelle j'ai trouvé quelques critiques juste par ce que je suis un éternel insatisfait.

Passons au Tome 2

Dans ce tome, on attaque (entre autre) des sujets qui annoncent une sacré migraine : mécanique quantique, big bang, cosmologie, trou noirs et théorie de cordes...

Et là, je retrouve le Bruce que j'apprécie : AUCUN chapitre n'a relevé pour moi un quelconque point négatif. Malgré le sujet pourtant ardu et profondément imbitable pour le sens commun,  Bruce arrive à nous préparer avec soin et à présenter chaque sujet, toujours avec ce fabuleux mélange d'humour, d'histoire des sciences, et d'analogies - et quand on parle de mécanique quantique, faut avoir une sacré imagination pour en trouver.

Je me dis que pour ce tome 2, Bruce était plus rodé, confiant, peut être moins pris avec la fin de la tournée de l'eXoConférence ? Avec la chaine en anglais j'en doute, mais bon. En tout cas, c'est un vrai régal. Et oui, sur ce coup là je n'ai rien à redire, pas le moindre petit truc à relever. Mince alors. Je vais le relire pour être sur...

Ah si : énorme déception d'apprendre qu'il n'y aura pas de tome 3. Sur sa chaîne Bruce ne se contente pas de présenter les sciences dures (i.e physique fondamentale) mais aussi beaucoup d'autres sujets, traités avec le même soin et toujours des références approfondies, concernant la biologie, le fonctionnement étonnant du cerveau, abordant parfois des problèmes qui touchent à la sociologie, ou bien des aspects méconnus de mécanique, enfin bref ça part dans tous les sens pour le plus grand plaisir des abonnés. Les deux bouquins abordent aussi ces sujets, mais dans une moindre mesure. Il y aurait donc matière pour un tome 3, 4, ... Mais bon, l'auteur fait ses choix, c'est le principe d'un auteur, c'est lui qui décide.

Donc bref, j'ai adoré ce bouquin et je suis extrêmement déçu d'avoir raté la dédicace à Rennes cette semaine - j'étais en vacances dans le Finistère, avec la crève en prime :'( - qui m'aurait donné l'occasion de féliciter Bruce de vive voix pour ce deuxième acte de son oeuvre. Vous l'avez deviné, je suis un fan, j'ai même tenté d'emprunter son style dans une de mes vidéos (après m'être tenté à imiter Karim, Fred ou François) ... comme quoi c'est pas si simple


Je profite de ce billet pour faire savoir à ceux qui ont raté l'info (?) que Bruce a mis à jour son site vitrine e-penser.com qui propose maintenant des annonces et du contenu exclusif.

Donc bref, pour noël ou n'importe quel autre prétexte, n'hésitez pas à sortir 19,90€ (x2) pour faire des heureux.

@ndeloof w00t ! Best plugin ever !

— Damien Duportal (@DamienDuportal) September 14, 2016

Dcoker-swarm est mort, vive docker swarm

Compose se fait tailler un short

Most Docker newcomers are disappointed when,  at some time, after various experiments with Docker, they hit a no space left on device issue. Docker indeed do store all containers, images and volumes in /var/lib/docker, which can quickly grow to gigabytes.

One can find tons of blog post about how to cleanup this folder. Here I'd like to give my own tips, and to explain them in detail, so you don't run random command found by Googling the Internet.

/var/lib/docker is used to store :

• docker images
• docker container descriptors
• docker networks descriptors
• docker volumes
• containers' layers (depends on the storage driver you used. Typically AUFS)

Terminated containers

Captains is a Docker program to organize their best advocates around the world, give them first class informations and contacts in Docker community, help them to experiment and spread the world with great Docker related content.

Thanks to Docker captain program, we got access to Docker4Desktop before it was publicly announced, we get online webinars with engineering, and we now have a cool logo !

I'm pleased to have been selected as a Captain, even my Youtube Channel Quoi d'Neuf Docker is limited to French audience (maybe I should launch an english spoken one ?).

Java has Java Champions program, I never have been invited to join, despite my awesome Apache Maven book and talks at major conferences, seems it's easier to become a Docker star :P

History

So, is this the definitive CFP we need ?

No prerequisite on Docker images

Build specific Docker executor

Jenkins Remoting

Pipeline Support

dockerNode(image: "maven:3.3.3-jdk-8", sideContainers: ["selenium/standalone-firefox"]) {
  git "https://github.com/wakaleo/game-of-life"
  sh 'mvn clean test'
}

Ca faisait un bail, pas vrai ?

J'écris ce billet pour faire savoir que je participe cette année au Google Summer of Code en tant que mentor.

GSoC est un programme de Google qui consiste à mettre des étudiants entre les mains de mentors sur des projets open-source reconnus. Après un premier mois d'immersion, ils doivent bosser deux mois pendant l'été sur le projet, et leur contribution est évaluée par leur mentor et Google pour valider leur participation. Google rémunère alors les étudiants qui ont rempli leur contrat.



Ce n'est donc pas un stage, encore moins avec une belle convention de stage comme on les aime en France. Par contre c'est passionnant et une excellente carte de visite. Donc ça peut être difficile à faire passer auprès de votre direction des études, mais ça vaut le coup de tenter de les dépoussiérer un peu !

Je propose un sujet dans le cadre de Jenkins : "Jenkins et Docker sont dans un bateau ..."

L'idée est de tordre un peu Jenkins pour remplacer son mode synchrone, basé sur un mécanisme semblable à RMI, pour contrôler des process sur une machine de build distante.

A la place, nous voulons utiliser le support natif de Docker pour contrôler des process distant et de manière asynchrone - et sans se prendre un CVE sur la sérialization Java (sic).

Et bien sur, le tout de manière backward compatible (ben oui, c'est Jenkins) ce qui promet quelques heures de réflexion intense.



Bref, si vous êtes intéressé, commencez déjà par aller voir https://summerofcode.withgoogle.com/ pour comprendre le process du GSoC, ensuite on en discute sur la mailing list jenkins-dev !

Salut  à tous,

dans mon dernier post - sur ce blog qui n'est plus très actif, je dois l'admettre ... - je vous parlais de la chaîne Youtube que j'ai montée pour partager mon enthousiasme sur Docker.

Depuis ce dernier billet, d'une part le crowdfunding Ulule s'est terminé avec succès (107%!), et j'ai comme convenu commencé à mettre en oeuvre les contreparties, dont la merveilleuse chanson du merci


J'ai aussi publiée trois épisodes, avec des niveaux successifs - du plutôt accessible "Docker 101" au significativement plus touffu "Le grand plongeon". Certains m'ont fait remarquer cette différence importante de niveau. Je compte mixer des vidéos plutôt techniques (pas trop rassurez vous, car ça me demande pas mal de préparation) avec des sujets plus légers.

En parlant de légèreté, une issue un chouille provocatrice que j'ai créée à provoqué un déferlement de créativité de la part des Francophiles et tout poils, et j'ai voulu leur rendre hommage avec une nouvelle vidéo - pas du tout technique celle-là : ET Si ... Docker était resté Français.

Vous l'aurez compris, cette chaîne est un soigneux mélange de genres, et est surtout pour moi l'occasion, comme je l'avais annoncé sur le projet Ulule, de mettre en pratique des idées et des technique de tournage/montage vidéo. Je m'essaye à copier tant bien que mal le style de plusieurs Youtubeur que j'affectionne, pas forcément toujours avec le résultat escompté mais qui ne tente rien...

Bref, Quoi d'neuf Docker est lancé, et bien lancé (j'ai une TODO-list assez conséquente) et j'ai beaucoup d'idées de mise en scène à expérimenter :D Votre aide sur le crowdfunding m'a ouvert de nouvelles portes avec un magnifique Canon 70D et un objectif très lumineux, de quoi occuper quelques heures d'apprentissage.

Par ailleurs, la chaîne compte déjà plus de 700 abonnés - oui, 700, même sur un sujet aussi ciblé - et je commence à rêver du Youtube Space Paris, réservé aux chaînes ayant plus de ... 1000 abonnés.

Je n'ai donc pas à vous dire ce qu'il vous reste à faire...

Et comme certains d'entre vous n'ont pas vu le Ulule à temps et veulent tout de même contribuer à la chaîne (sic), j'ai mis en place un Tipee, en gros un crowdfunding sans limite de temps. Je n'attend pas particulièrement à ce que cela m'apporte grand chose, mais qui sait, cela pourra participer à financer du matériel plus spécifique, et/ou des frais de déplacement - DockerCon Seattle, je pense à toi

Merci à tous pour votre soutien, vos encouragements, et rendez-vous très très bientôt (enfin, si le tournage de ce soir se passe bien ...)

Comme le prouvent les vidéos que nous publions chaque année pour faire la promotion du BreizhCamp, je prend un grand plaisir à manipuler la vidéo comme média de communication.

Je suis impressionné par le succès des chaînes Youtube des pointures du Net Français : JoueurDuGrenier, e-Penser, Axolot, Salut les Geeks ou Antoine Daniel apportent tous à leur manière une expression libre sur le web avec un talent certain.

Je n'ai pas la prétention de me comparer à ces références, mais le format employé m'attire sans conteste. Aussi, je lance une chaîne Youtube, sur un sujet de niche : Docker ...

"de niche" parce que pas du tout grand public. Oublions donc tout de suite les millions de vues, promesse de toucher un chèque signé "Youtube". L'idée est ici de présenter Docker et son écosystème, comme je le fais en conférence, mais en exploitant le média vidéo, c'est à dire pas sous forme de conférence filmée, linéaire, mais en exploitant les possibilités données par le montage et la mise en scène.



La chaîne est encore naissante et a donc pour le moment une URL à chier, il faudra attendre 500 abonnés pour régler ça, mais pour ça il faut déjà proposer du contenu.

Ce contenu est déjà en préparation, mais je veux profiter de cette occasion pour aller plus loin que ce que j'ai produit jusqu'ici, en particulier en raison des limitations de la caméra que j'ai à ma disposition via le BreizhCamp. J'aimerais passer au tournage sur boitier Reflex, profiter de l'expérience en photo de plusieurs collègues pour choisir les bons objectifs et trouver des astuces de cadrage, etc.

Bref, il va falloir investir, et pour cela je fais appel aux bonnes volontés, via un financement participatif sur Ulule : http://fr.ulule.com/neuf-docker/

Je prépare un premier épisode pilote en tant que "proof of concept" et pour montrer ce que j'ai en tête, en espérant que cela déliera les portefeuilles. J'ai placé le premier niveau de contribution à 5€ en espérant que cela motivera ceux qui ne sont pas des connaissances directes, comme on dit "les petits ruisseaux font les grandes rizières"

Bref, à vot' bon coeur.


UPDATE
Je viens de publier un épisode pilote, pas vraiment technique, mais qui donne une idée de ce que j'ai en tête. j'espère qu'il vous amusera.

(based on https://gist.github.com/ngpestelos/4fc2e31e19f86b9cf10b)

I've seen a bunch of project with a Dockerfile to package some app into a production docker image. Most of them do rely on some pre-existing binary they just ADD / curl into the image. This demonstrates some missing piece in the equation, as this binary has to be built from source, and as such you loose the traceability of your built image.

On the other side, some try to setup a full "build from source" Dockerfile, but as a result end with source code and many unnecessary dependencies and intermediate files present in the image: compiler, test libraries, binary intermediate objects, etc. This isn't pleasant, and makes your docker image bigger.

#7115 is a proposal to offer a multi-step Dockerfile, which could solve this issue but introduce some significant complexity in Dockerfile syntax. Also, this is still discussed and I don't expect this to be implemented in a near future.

So, here's my way to handle such a Continuous Delivery Pipeline based on Dockerfiles.


Here is my "build phase" Dockerfile, which I name by convention Dockerfile.build :

FROM maven:3.3.3-jdk-8

ADD / /work
WORKDIR /work

ENV NODE_VERSION 4.2.2

RUN curl -SL "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.gz" | tar xz -C /usr/local --strip-components=1 

RUN npm install -g bower gulp
RUN npm install
RUN bower --allow-root install
RUN gulp build
RUN mvn package

CMD cp /work/target/*.war /out/app.war

This Dockerfile do define my build environment, relying on Maven and NodeJS to build a modern java application. Such a Dockerfile is designed to fix the build requirements and offer an isolated, reproducible build script, not to create an actual docker image to be ran. But I also added a CMD, which role is to let me export the built binary to a pre-defined location. So I can run :

docker build -f Dockerfile.build -t build .
docker run -v $(pwd):/out build

I also tried to output the war to stdout, so I can run docker run build > app.war,  but got some odd extra character in the stream, and didn't investigated more. I could also rely on docker cp to extract binaries form a container created from build image.
Doing this, I'm building from source and after completion get the application binary for a further step. Next step is for me to create my deployment docker image, using Dockerfile.prod :

FROM jetty:9
ADD application.war /var/lib/jetty

And my full pipeline execution script become

docker build -f Dockerfile.build -t build .
docker run -v $(pwd):/out build
docker build -f Dockerfile.prod -t application .

I could just push the build application image to my repository, but can also have further steps to run it with required middleware (database, etc) and execute some additional automated tests.

For this purpose I rely on docker-compose, to setup the test environment and execute my test suite

test:
  build: .
  dockerfile: Dockerfile.tests
  links: 
    - application
    - selenium

selenium:
  image: selenium/standalone-firefox

application:
  image: application
  ports:
    - "80:8080"
  links:
    - database

database:
  image: mysql

Running docker-compose up will (build and) run my test suite based on selenium acceptance tests.

Last step is just to tag and push the image to my registry.

A future improvement is for me to find a cool way to integrate this in Jenkins as a declarative syntax, vs a plain shell script. Wait and see.

I went to DockerCon Europe'15, and will post some feedback about this conference on this blog later next week, but in the meantime I'd like to share with you a major information from Docker Inc :

They updated the Lego Moby Dock design !

Last year at DockerCon Europe, they offered all keynote attendees a lego set to build a small docker whale. You could then pick up "containers" to plug on it from sponsors booth. Was lot's of fun.

At Barcelona, they did the same, but used a more advanced Moby Dock model, bigger and with rounded body. This one is another proof of nice Lego design expertise, but as the previous model I'm disappointed by the tail design. Due to it's shape and angle with whale body it's hard to find adequate lego brick for this job.



Back from Barcelona, I spent some time (don't tell my boss) searching in kid's legos for the adequate block. Here is the result :


Tail is a bit to big compared to original design, but looks better imho. As I wasn't able to find where to send a pull-request for this, here is the instructions for you to do the same.

You'll need those extra block :

• Remove existing tail, drop the 2x1 plate you won't need. 
• Plug the two roof tile 45° blocks (304023) into the special angular 1x1 brick (407023). One on the standard mounting hole, the other on the back, which on this brick is a square hole with adequate weight to plug a brick. 
• Add the two opposite slopping block from original set to complete the tail.

I made a lego digital designer model as this isn't such a trivial thing to explain this :)



If you can't find the angle brick, you also can use a 1x1 brick with two round slots (4583862) and plug the upper tail in opposite side.

I also made larger containers, to mimic the Docker logo. They're a bit too large for the model, but look nice. Just need to get some profile 2x1 brick (4210636) for the adequate container look.


Building instruction is left as an exercise to the reader :)

Ca fait un moment que je me dis qu'il faut que j'apprenne à coder en Go.

Pourquoi ?

text := LinesOfText{
 []byte("Now is the time"),
 []byte("for all good gophers"),
 []byte("to bring some fun to the party."),
}

If you didn't saw the announcement, I'm part of the winner team for DockerCon RPi Challenge. This blog post is about giving some details on our setup to get such a high number of webservers on a small device.

Some might thing you have to make your Docker image as small as possible, but this isn't actually the case. The image will result into space on disk for /var/lib/docker but not memory consumption. Also, a big process loaded into memory would only consume memory once, then kernel will share code page between equivalent processes, so hundred of them would only consume memory once. My first idea was to build a webserver to include the html and image content into source code. But then Yoann explained me sendfile can be used to fully delegate this to kernel and make the process even simpler. For Java developers, consider sendfile as some kernel-level IOUtils.copy(File, OutputStream).
We used hypriot's nano http image. This one is a webserver developped in assembly code to just serve files from disk using kernel sendfile call. Such a program as a minimal memory footprint and a 1-depth stack. The memory allocation for kernel to handle such a process can then be as compact as possible.

Next step was to run some tests and tweak Docker to run as much webservers as possible. We applied various strategies, without any methodology but just apply various recipes we had in mind and check the result (it takes hours to run thousand servers...)

Free memory

We tweaked the Raspberry and OS to reduce memory usage. Some low level tweaks allow to disable useless features at boot, some system level one are used to disable linux feature we don't need for this challenge.

Swap !

Tweak docker command

Tweak docker process

Linux also allows to tweak the way a process is managed in kernel, we used it to ensure docker run with minimal required resources and use swap

Tweak docker daemon config

More

We also wanted to know the upper limit. We made experiments running the plain httpd webserver without docker, and were able to run 27000 of them on the Raspberry. Docker daemon actually grows in memory usage and at some point as some bad impact on the system so you can't run more process. Please note this isn't relevant for arguments against docker on production system, until your business is to run thousands containers on a extra small server.

So, we hacked docker source code to force the MaxThread limit to 12000, built ARM docker executable and ran the script. We were able to run ~2740 web servers before we reach our first, real OOM

What's next ?

We'd like to better understand Docker threading model, and discuss this issue with docker core team. Using Non-Blocking IO might be an option to rely on a minimal set of threads. I have no idea yet how Golang do handle NIO, I just know it's a pain in Java so I wouldn't do it until I have good reasons to...