2016 :: new Blog( perso );

13 décembre 2016

Quoi d'neuf Docker ? ... ben rien justement

Il y a quasiment un an jour pour jour je me lançais dans l'aventure Quoi d'neuf Docker, avec le soutien inespéré de nombreux internautes pour mener au bout une campagne de Crowdfunding, suivie d'une série de vidéos pour lesquelles j'ai pu tester différents styles et en même temps en apprendre beaucoup sur Docker.

Force est de constater que, depuis la dernière vidéo diffusée en Juillet, la chaîne montre un encéphalogramme plat. Il est donc temps pour moi de déclarer sa mort clinique.

Pour faire court, depuis Juillet j'ai changé de poste, et j'ai nettement moins de temps libre avec en plus de régulières réunions en soirée (merci les 9 heures de décalage horaire avec la côte Est). J'ai aussi de nouvelles contraintes familiales à considérer, et par dessus cela ces derniers temps des soucis qui me bouffent le peu qui me restait de "temps libre".

Disons les choses clairement, même si l'envie de filmer une nouvelle vidéo revient régulièrement, si ce n'est pas la préparation du contenu qui pose problème, si même mon public est encore assez sympa pour m'encourager, je sais que de longues heures de montage m'attendent, et que cela va s'éterniser.

J'ai ainsi un tiers de vidéo "docker-swarm" qui dort sur mon disque dur depuis deux semaines, et qui va rester dans cet état inachevé car je me rend bien compte que je ne trouverais pas le temps ni l'énergie pour en venir à bout.

Plutôt que de bâcler, je préfère renoncer, et laisser les nombreux Docker Captains qui en ont encore l'énergie vous abreuver des informations que vous attendez d'eux. Je me doute que quelques un seront déçus, mais rassurez vous d'ici quelques jours ce sera oublié.

Merci à tous ceux qui m'ont soutenu et encouragés pendant cette expérience très riche d'enseignements.

30 octobre 2016

J'ay pris le temps d'e-lire

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.

13 septembre 2016

Docker-Slaves 1.0 released

This week is JenkinsWorld, and I won't be there ... but this doesn't mean I won't be part of it.

I'm pleased to announce Docker-slaves-plugin has reached 1.0.

Docker-slaves was created on year ago, as Yoann and I joined forces during DockerHackDay, with complementary ideas in mind to re-invent Jenkins in a Docker world. We are proud we were able to develop a working prototype within 24 hours and won 3rd prize on this challenge !

What makes Docker slaves such a revolution ?

Docker-related Jenkins plugins so far use a single docker container to provide a Jenkins agent (aka "slave"), which will host a build. Such a container is running a Jenkins remote agent and as such has to include a JRE, and allow connection from master or connect to master by itself. In both cases, this introduces significant constraints on the Docker image one can use. We want this to disappear.

With Docker-slaves, you can use ANY docker image to run your build.

To communicate with remote agent, Jenkins establish a communication channel with slave. On ssh slave, this communication uses the ssh connection as a tunnel. Other slave launcher uses various tunneling techniques or explicit port allocation to create this channel. But docker also has an interactive mode to run a container, which let us establish a stable (encrypted) connection with a remote container. Running `docker run -it` is very comparable to running a ssh client to connect to a remote host. So we use this capability to create the remoting channel directly on top of docker's interactive mode.

SSHD in docker container is evil. Docker-slaves don't need one, and does not require your master to expose JNLP on the Internet

Docker is not just about container, it's also about containers. docker-compose is a popular tool and demonstrate need to combine containers together to build useful stuff. We think a build environment has the same requirement. You need maven to build your project, but you also need a redis database and a web browser so you can run Selenium functional tests. Just create 3 containers, and link them together ! This is exactly what Docker-slaves does, so you can define your build environment as a set of containers.

Docker-slaves let you compose your build environment

... and you can even define those containers using a Dockerfile you store in SCM ! If you love infrastructure as code, you'll be happy to get both your source code, continuous deployment pipeline script, and build environment stored all in your project SCM with plain Dockerfiles. Docker-slaves will build the required image on demand and run the build inside this container.

Docker-slaves bring Continous-Delivery-as-Code to next level

Docker slave also adds a transparent "remoting" container so Jenkins plumbing is well setup and all Jenkins plugins work without any change. This includes Pipeline plugin. This plugin used to require a classic jenkins slave as node() to run build step, and this node to host a docker daemon if you want to run anything docker related. With docker slaves, just write your Jenkinsfile without need for a single classic Jenkins executor.

dockerNode("maven:3.3.3-jdk-8") {
    sh "mvn -version"
}

How does this compare to docker-pipeline's docker.inside ? There's no need for a host jenkins Node here, nor a local Docker daemon installed on your jenkins slaves. You can rely on docker swarm to scale your build capacity.

Docker-slaves do embrace Pipeline

Last but not least, Jenkins docker-related plugins use to start with a fresh, new slave, which require to run a full SCM checkout and populate project dependencies. Docker-slaves uses a volume as build workspace, so this one is persistent between builds. There is huge room for improvement here, with assistance for docker's volume-drivers, typically to provide snapshot capability so you can browse workspace for a specific build (to diagnose a build failure) or replicate workspace on cluster.

Docker-slaves workspace is persistent

If you have opportunity to give it a try, please send me feedback @ndeloof

UPDATE:
For some odd reason (who said "conspiracy" ?) docker-slaves 1.0 was not published in update center (yet). Will need to investigate with Jenkins infra team, but with Jenkins World they are all higly busy this week.

@ndeloof w00t ! Best plugin ever !
— Damien Duportal (@DamienDuportal) September 14, 2016

20 juin 2016

DockerCon : quand docker-swarm laisse la place à docker swarm

tl:dr;

docker 1.12 = docker 1.11 + swarmKit + server-side docker-compose

Dans ma dernière vidéo je vous parlais du changement d'architecture de Docker 1.11 et du fait que le démon docker ne fait "plus grand chose" - à part l'authentification et la gestion des images, quelques bricoles quoi.

Il faut croire que, comme la nature, l'équipe Docker a horreur du vide, puisqu'elle s'est empressée de remplacer ce déficit de fonctionnalités dans la version 1.12 (Release Candidate 2) annoncée ce matin en keynote de la DockerCon - et oui, j'étais au courant avant, nananèreu

Dcoker-swarm est mort, vive docker swarm

Vous aviez sans doute vu passer l'annonce de swarmKit, un projet issu de l'architecture de docker-swarm mais plus générale (on parle ici de "tâches", pas forcément de conteneurs docker). En fait ce projet est reparti de la page blanche, en reprenant ce qui a bien marché dans docker-swarm et en choisissant d'autres pistes pour ce qui marchait moins bien.

Typiquement, oubliez votre etcd / consul et le zookeeper qui va bien pour gérer un cluster swarm. Jusqu'ici, swarm avait besoin d'un service externe "clé/valeur" pour stocker la configuration du cluster. En plus de compliquer le setup pour assurer de la haute disponibilité, cela introduisait pas mal de délais dans le traitement asynchrone de la transmission de ces infos.

SwarmKit utilise Raft, protocole d'élection d'un noeud maître, et son implémentation par etcd. Plus besoin de service externe, un cluster swarm se suffit à lui même out-of-the-box pour distribuer ses métadonnées et élire son noeud "leader".

Mais l'annonce de SwarmKit n'était que la partie visible de l'Iceberg, qui d'ailleurs à trompé pas mal de monde, car comme toujours les évolutions de Docker sont visibles sur le projet open-source pour qui sait lire entre les lignes des Pull-Requests.

Docker 1.12 annonce donc l'intégration native de swarmKit, pour former un cluster swarm sans quoi que ce soit d'autre que le démon Docker. Cette nouvelle feature n'est pas active par défaut (la compatibilité restant la première priorité). Il vous faudra explicitement passer en "mode swarm": docker swarm init

Docker 1.12 introduit aussi le concept de services, et permet de déployer N instances d'un conteneur sur le cluster (voir, sur tous les noeuds du cluster - parfait pour l'exploitation), de gérer leur re-schedule automatique en cas de défaillance, le load-balancing de ces N instances, les mises à jour en rolling-upgrade, etc. Bref, ce que vous faisiez jusqu'ici avec docker-swarm ou avec votre orchestrateur docker préféré (sic), vous pourrez le faire en natif avec le docker engine de base, dans le cadre d'un cluster swarm - le nom reste, je reconnais que ça peut être source de confusion, mais bon en même temps au final c'est le même concept.

Le load balancing c'est une nouveauté importante qu'il va falloir que je teste plus en profondeur. S'il est toujours possible d'utiliser le DNS avec la liste des IP associées à un service, ce qui suppose que votre code client gère ça correctement (sic), la nouvelle approche consiste à faire du load balancing en se basant sur IPVS (i.e passer par le noyau Linux). Les interactions exactes entre un service déployé de cette façon, les conteneurs qui lui permettent de tourner, et les réseaux / ports associés sont encore assez flous pour ce qui me concerne, cela nécessitera quelques tests plus appuyés.

De son côté, le projet docker-swarm, s'il va vivre encore un moment (support client oblige) va rapidement être dépassé par ce support natif dans docker-engine.

Compose se fait tailler un short

Seconde annonce majeure : l'ajout du concept de "service“ à l'API docker, avec des réplicas et un load balancing natif sur le cluster swarm.

Ca parait abstrait comme ça ? En pratique, vous allez déployer non plus un conteneur (même si vous pouvez encore) mais un "service" utilisant une image :

docker service create --name foo --network bar ma_super_appli:1

Sur TOUS les noeuds de votre cluster swarm, et sur l'overlay network bar indiqué, vous pourrez discuter avec ce conteneur. Et si vous augmentez le nombre d'instances :

docker service update foo --replicas 5

.. docker se chargera de faire du round-robin sur ces conteneurs pour distribuer la charge. Evidemment il y a toutes les possibilités de contraintes / affinités / labels de swarm pour jongler finement lorsque c'est nécessaire.

Pour faire simple, jusqu'ici vous utilisiez docker-compose pour lancer une grappe de conteneurs. Rassurez-vous, vous allez sans doute continuer à faire ça en développement, et le format docker-compose.yml n'est pas remis en question. Par contre, sur un cluster swarm docker-compose est exposé à une limite :

Docker-compose utilise l'API docker pour faire de l'orchestration, mais un déploiement compose n'est pas atomique. Comprenez que si vos deux premiers conteneurs trouvent leur place sur un noeud, et que le troisième ne rentre pas faut de resources disponibles, et bien votre déploiement échoue, point barre. En gros, docker-compose est un orchestrateur côté client, en mode optimistic transaction.

Docker 1.12 introduit le concept de "bundle", dont le format est encore très récent et sujet à évolutions (i.e ne vous attardez pas dessus pour le moment), qui définit un groupe de containers et comment les lier ensembles.

Oui, c'est tout pareil que docker-compose. D'ailleurs, docker-compose bundle vous permettra de générer une spécification de bundle à partir de votre fichier docker-compose.yml, il ne s'agit donc pas de remplacer compose, mais plutôt de le booster en lui fournissant une API à la hauteur de ses ambitions.

Ce bundle (un fichier JSON à ce stade, mais ça peut encore bouger), vous le passerez à votre démon docker via la commande docker deploy. La différence avec compose, c'est que le déploiement se fait alors "côté serveur", avec la sélection des noeuds en connaissance de cause.

Contrairement à docker-swarm, docker-compose va par contre subsister puisque son mode de fonctionnement continue à être pertinent en mode "classic" (non-swarm) - typiquement sur le poste de développement - et assurer la liaison avec le format de bundle.

BREF

docker-swarm vient de se prendre un balle, et docker-compose s'est fait couper les jambes par l'annonce de Docker 1.12. Ce qui est intéressant ici, c'est de voir que ces deux outils, conçus sur la base de l'API docker, avec ses contraintes et limites, voient au final leur fonctionnalité coeur intégrée dans docker-engine. Et vont donc pouvoir renaître en inventant de nouveaux usages et patterns, lesquels seront peut être un jour intégrés à leur tour...

Ce cycle peut paraître surprenant quand on investi sur un outillage qui peut devenir obsolète au détour des annonces d''une keynote, mais il montre la dynamique raisonnée de l'écosystème Docker : si une fonctionnalité démontrer son intérêt, elle finit par être prise en charge nativement dans l'engine, vidant l'outil de sa raison d'être première, mais au final montrant que l'approche était bonne, et ouvrant la voie pour le cycle suivant.

A ce stade 1.12 n'est qu'une Release Candidate, et l'effet d'annonce pour la DockerCon a limité la période de test par la communauté (très occupée à s'accaparer SwarmKit). La version 1.12, bien qu'activement testée par de nombreux partenaires, va mettre donc encore quelque semaines à murir, sous les assauts d'une communauté qui ne va pas se priver de la secouer dans tous les sens pour vérifier que

ça continue de marcher comme avant
le nouvelles fonctionnalités tournent dans la vraie vie comme indiqué dans la doc

Dans tous les cas, Docker 1.12 va changer pas mal de choses dans votre façon de déployer Docker, en intégrant les concepts de clustering et de déploiements composites au coeur de docker-engine.

31 mai 2016

Docker Cleanup

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

I use docker a lot to experiment unix commands, so use to run docker run --it ubuntu bash. When you run a container without the --rm option, container still exists on disk after the command complete. So doing this will create tons of containers, and layers for things I modified on container's filesystem. For this reason I created an alias docker-run to ensure I don't forget this option. But this option can't be used with -d (run in background) so I can't use it when I want to run some backend service for testing purpose.

As the end of the day, I have tons of stopped containers that I don't use anymore, and will just consume disk in /var/lib/docker. So I use this command to run some cleanup :

docker rm -v $(docker ps --filter status=exited -q)

this command do list all exited containers (thanks to status filter), and only dump their ID (-q). This ID list is used by the remove command to cleanup containers, including volumes they where using.

Unused volumes

Volumes ? Yes, when you run a container which has been built with a VOLUME command in it's Dockerfile, docker do implicitly create a volume on disk, and may copy data from container image in this volume. This can result in significant disk consumption. Removing a container with -v option do force docker to remove such volumes. This doesn't apply to bind mount volumes, only to volumes created by docker daemon.

If you already removed your containers without using -v, volumes remain orphaned in /var/lib/docker. You can remove them as well using :

docker volume rm $(docker volume ls -q -f 'dangling=true')

the "dangling" filter do select volumes that aren't referenced by any container.

Note: one can find many scripts to do comparable cleanup by directly making changes to /var/lib/docker. Those script where written before docker volume command was introduced in 1.9. Don't use them. Directly hacking your docker daemon storage isn't a good idea when you have a clean API for this purpose.

Unused images

You can also use a comparable dangling filter with images, this one will detect image layers that are not referenced by a tag, which in many cases is the result of running docker builds.

docker rmi $(sudo docker images -f "dangling=true" -q)

what about obsolete / unused images ?
You can find some script to detect images which aren't used by a container on your system. For production environment this can make sense, but for my workstation this would remove mostly all docker images, as most container I run don't keep running all day long.

Docker doesn't track image use by containers, this issue is tracking attempt to change this, so writing a garbage collector would be simpler. So far I'm using https://github.com/ndeloof/docker-gc to collect image usage based on docker events. Not perfect, but does the job.

Hope this helps.

27 avril 2016

I'm now a Docker Captain

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

25 avril 2016

cfp.io

I'm very excited to announce the launch of a long term project of mines: cfp.io

TLDR; Are you event organizer ? Need a free call-for-papers? Contact us, we will host it for you.

History

As a conference organizer, I've been handling call-for-papers for a while, and have actually worked on developing 3 of them (sic).

We started in 2012 with a simple google form to collect speakers proposals. This was a poor experience, but did the job. Anyway as developers we decided we need a dedicated tool to offer a better service.
In 2013 we created our own CFP, and worked on it during the pre-event period so it match our needs. Main issue took place in 2014 when we tried to restart it from the initial collect phase, as the later changes had unexpected impacts (soc)
In 2015, DevoxxFrance offered to share his custom CFP application codebase. We forked it, and adapted to our needs. The codebase is written in Scala, and just for this reason I hardly was able to found volunteers to help us on this topic. Also, this application do cover lot's of Devoxx specific things, hidden in codebase. We ended with few speakers not being registered, as Devoxx do only offer a pass to the first two speakers, and we have labs with up to four of them :'(
In 2016, we forked DevFest Nantes Call for Papers application. This one was written in Java/Spring/Angular, had a nice look and feel, so was a great candidate. We noticed many glitches in backend, so decided to fix them ... and after few months had it mostly fully rewritten. Anyway, this was a smooth migration, and 4 volunteers where able to make it a great app.

Our CFP worked like a charm, and was then forked by NCfrats.io for their own need.

So, is this the definitive CFP we need ?

No: main issue here is to maintain forks of each others. As a sample, we discovered a security issue with our CFP, fixed it, but as this happened two weeks before the event, we didn't took time to let DevFest guys know about it (sorry guys). Also, people at NCrafts could introduce interesting features, and even git make it easy to backport such code, this could quickly become a hard task to keep everything in sync.

We believe a better approach is to colocate our Call-for-papers. a CFP is a low traffic application, limited data volume, and limited complexity. It's very easy to make our codebase multi-tenant, and we plan to offer free hosting for call for papers on our server. Each tenant will get access as https://{{my_awesome_event}}.cfp.io and will be able to manage his own stuff, without need to bother with infrastructure.

As code is open-source (AGPL) we will welcome contribution to offer additional features. If you have designed an integration with third party web service, then please contribute this new feature. Other platform users will then get notified about this new feature and can chose to use it as well. We expect this to be the best way for cfp.io to become the place to be for event organizers, covering all aspects of event management.

Emerging features

A side effect of co-hosting call for papers is to build sort of a speaker social network :

As a speaker, I have to copy/paste my bio and favorite talk abstract on various events' call-for-papers. With cfp.io, I can just reuse my bio, and select a talk I already proposed at eventA so I can apply to eventB. I also can discover events I didn't heard about, just because their CFP is hosted by the platform.
As an event organizer, I can check a speaker already talked at other events, and maybe this specific talk was recorded and available online. This will be a great assistance for program committee to select speakers.

Business model

Do we plan to create a company here ? No. we are a non-profit organization, and this is all just for fun ! We are just geeks, trying to make something cool and useful. Our "business plan" is for each hosted conference to get a free pass. Some of them will be use for our own pleasure to join great events, some of them might be sold to pay for the server, or to help us pay for travel.

If you are event organizer, feel free to contact us to get your CFP setup on our infra - we plan to make this automated as well on a self-service basis, but this isn't implemented yet.

24 avril 2016

Docker Slaves Jenkins plugin has been released !

At Docker Hack Day 2015, Yoann an I created Docker Slaves Plugin, an alternative way to rely on Docker for Jenkins to get build nodes. This initial implementation was the summary of a summer hacking Jenkins APIs and internal design, it was very helpful for us to suggest required changes in jenkins-core and offer a more flexible approach.

How does Docker-slaves differ from other Jenkins' Docker plugins ?

No prerequisite on Docker images

Jenkins uses a Java agent on build machine to manage build operations from master remotely. As a side effect, plugins like docker, amazon-ecs or kubernetes -plugins do require the Docker image configured to host builds to have a JVM, expected permissions, and sometime even a ssh daemon running.

We think this is a non-sense. You should not have to bake Jenkins specific images. Especially, if you don't code in Java but use Jenkins for CI, growing your Docker images by 200Mb of JDK is terrible.

We already explored this goal with Docker Custom Build Environment Plugin but this one also has some contraints : relying on bind mount, it require your Jenkins "classic" build node to have a local docker daemon installed. It also suffers some technical limitations :'(

Docker Slaves Plugin let you use any arbitrary image.

More than just one Docker image

Docker, amazon-ecs and kubernetes -plugins all rely on running a single docker image for the build. They some way admit a common misunderstanding aobut containers, considering them as ligthweight virtual machines. As a result, you can find some docker images to include tons of build tools and also start a selenium environment, like cloudbees/java-build-tools.

Why try to get all this shit in a single docker image ? Couldn't we combine a set of more specialized docker images into a group ("pod") of containers configured to work together ?

We used this exact approach. Every build will executre with at least 2 containers :

a plumbing 'jenkins-slave' container to run required Jenkins slave agent
your build container
some optional additional containers, for sample selenium/standalone-firefox to run browser-based tests, or a test database, or ... whatever resource your build require.

All those containers are set to share build workspace and network, so they can work all together without extra configuration.

Docker Slaves Plugin let you define build environment and resources as a set of containers.

Build specific Docker executor

Jenkins use to maintain a pool of slaves, which can be automatically provisioned by a Cloud provider. When a job is executed, such a slave get the task assigned, creates a log for the build, and start executing. After completion, the slave goes back to available pool. Docker-plugin and few other do hack this lifecycle so the slave can't be reused, and enforce a fresh new provisioned node.

This has an odd effect : when the docker infrastructure has issue to run your container, and so the slave doesn't come online, Jenkins will try to run another slave. Again and again. You won't get notified about failure as your build didn't even started. So, wafter few hours when you connect to Jenkins, you'll see hundred disconnected slaves and your build pending...

We wanted to reverse the Slave :: Build relation. We also wanted the slave environment to be defined by the job, or maybe even by content of the job's repository at build time - typically, from a Dockerfile stored in SCM.

When docker-slaves is used by a job, a slave is created to host the build but it's actual startup is delayed until the job has been assigned, and a build log created. We use this to pipe the container launch log in the build log, so you can immediately diagnose an issue with docker images or Dockerfile you used for the build.

Docker Slaves Plugin creates a one-shot executor, as a main element of your build.

Jenkins Remoting

Jenkins communicates with the slave agent using a specific "remoting" library, comparable to Java RMI. It relies on this one so the master can access remote filesystem and start commands on slave.

But we use Docker, and docker client typically can be considered a way to run and control remote commands, relying on docker daemon as the remote agent.

Docker Slaves bypass Jenkins Remoting when master has to run a command on slave. It relies on plain docker run for this purpose. We still need Remoting as it is also used for plugins to send Java code closures to be executed on slave. This is the reason we have a jenkins-slave container attached to all builds, which you can ignore, but is required for all Jenkins plugins to work without a single change.

Docker Slaves Plugin reduce Jenkins Remoting usage.

Pipeline Support

Last but not least, Docker Slaves to fully embrace Jenkins Pipeline. Being main component for Jenkins 2.0, we could not just let Pipeline integration for further implementation effort.

Docker Slaves do introduce dockerNode Pipeline DSL, as an alternative to node used to assign a classic Jenkins slave. dockerNode takes as parameter the set of container images to be ran, then act as a node and you can use all your Jenkins Pipeline construct to script your CI/CD workflow.

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

Docker Slaves Plugin embrace Pipeline.

What's next ?

There's still some point we need to address, and probably some bugs as well, but Plugin is working fine already. If you give it a try, please send us feedback on your usage scenario.

Something we want to address as well is volumes management. We re-attach the jenkins-slave container on later builds so we can retrieve a non-empty workspace. But we'd like to fully manage this as a volume and manage it's lifecycle. Especially, we'd like to experiment use of docker volume plugins to improve user experience. For sample, use of Flocker would allow us to snapshot workspace on build completion. This could be useful to offer post-build browsing of the workspace (for diagnostic on failure for sample) or to ensure a build starts from the last stable workspace state, which will offer pre-populated SCM checkout and dependencies, without the risk to get a corrupter environment from a build failure.

We also would like to investigate adapting this approach on container orchestrator like Kubernetes. Not sure they offer the adequate flexibility, maybe only a subset of the plugin could be enabled on such an environment, but makes sense to give it a try.

As a resume, still some long hacking nights in perspective :)

In the meantime, please give it a try, and let us know if it would be helpful for your Jenkins usage.

04 mars 2016

Google Summer of Code

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 !

26 janvier 2016

Quoi d'neuf sur Quoi d'neuf Docker ?

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 ...)