new Blog( perso );

solomonstre 1) interface to the app and developer should be standardized, and enforced ruthlessly to prevent fragmentation #dockerway 01/12/2014 22:11

solomonstre 2) infrastructure should be pluggable and composable to the extreme via drivers & plugins #dockerway 01/12/2014 22:11

solomonstre 3) batteries included but removable. Docker should ship a default, swappable implementation good enough for the 80% case #dockerway 01/12/2014 22:11

solomonstre 4) toolkit model. Whenever it doesn't hurt the user experience, allow using one piece of the platform without the others. #dockerway 01/12/2014 22:11

solomonstre 5) Developers and Ops are equally important users. It is possible and necessary to make both happy. #dockerway 01/12/2014 22:12

solomonstre 6) If you buy into Docker as a platform, we'll support and help you. If you don't, we'll support and help you :) #dockerway 01/12/2014 22:12

solomonstre 7) Protect the integrity of the project at all cost. No design decision in the project has EVER been driven by revenue. #dockerway 01/12/2014 22:12

solomonstre 8) Docker inc. in a nutshell: provide basic infrastructure, sell services which make the project more successful, not less. #dockerway 01/12/2014 22:12

Rennes edition for local hack day was not what I expected it to be as we didn't actually hacked much during the evening meeting, but during the week-end, remotely from home, with my colleague Yoann.

Our contribution is focussing on Docker use for Jenkins Continuous Integration - what a surprise!. We used a proof-of-concept I wrote earlier and made it production ready (more or less) using latest Docker version docker exec command.

So let me introduce Oki-Docki !


This plugin is designed to let your build run in a clean and controlled environment, managed as a Docker container, that you can define explicitly as a Docker image ID in jenkins job configuration, or as a Dockerfile you store with your project source code.

First usage (Docker image ID) can be considered a way for you to have custom build slaves based on Docker images, something comparable (but implemented a distinct way) to docker-plugin, without any constraint on the Docker image to use.

Second usage is something more subtle but imho more useful in terms or Continuous Delivery / reproducibility. As a developer, I like my build to run on a fully controlled environment, so I can reproduce it at any time. Docker allows me to get this up-and-running in few seconds without a long list of prerequisites to check. It also let me define this build environment as a plain text file (Dockerfile), that I can just store in project SCM. I'd like my continuous integration server to do the same.

Oki Docki plugin can use any jenkins slave that has docker installed, so you can fully benefit jenkins elasticity to connect additional slave boxes or even use a cloud provider. The SCM checkout runs a classic way on slave, but then a Docker container is build from project Dockerfile and ran to host the build. All subsequent build commands are ran inside the container (using docker exec).

After we got the initial setup done and sanity test running echo "hello docker" on build log, Yoann went further and tested using this plugin to run a debian package build job. Such a job works like a charm on my OSX / Boot2docker installation - If you ever tried to do cross-system packaging you understand the immediate benefit !

Generally speaking, this plugin let you fully define your build environment (which java, maven, ruby, compass, whatever version your build requires) just as a reproducible Dockerfile recipe. Maven tried to address this issue some way but don't have much control on the environment to fully address such an issue. So thanks to Docker we moved from "maven reproducible builds" to "docker fully reproducible builds", and Oki Docki makes this perfectly fit in you CI system.

If you like this idea, please vote for it on https://www.docker.com/community/globalhackday/14/ (just a tweet / G+ to send)