[GSoC 2016] Integration of Docker plugins with Jenkins 2.0 features

[Ben Navetta]

Hi everyone,

I'm Ben, a freshman at Brown University in the United States. I've been programming with Java and Groovy for several years and have used Jenkins fairly regularly. Since I have a decent amount of Docker experience, integrating Docker with Jenkins 2.0 things like Pipeline as Code looks really interesting, and I'd love to participate. I poked around in some of the GitHub repositories for Jenkins, but wasn't really sure where the Pipeline as Code portion lived. I'm hoping someone can point out where to start looking!

Thank you,
Ben Navetta

[Oleg Nenashev]

Hi Ben,

Thanks for contacting us!
I've added Nicolas and Yoann to Cc. They are potential mentors for the Docker project, so they will be able to discuss the project with you.

Pipeline-as-code is rather an ecosystem than a single plugin. Now it evolves very quickly, so I'm not sure there are detailed overviews of the current state. Several links:

    https://wiki.jenkins-ci.org/display/JENKINS/2.0+Pipeline+as+Code
    "Continuous Delivery as Code with Jenkins Workflow" video, https://www.youtube.com/watch?v=Q2pZdzaaCXg
    https://github.com/jenkinsci/workflow-plugin
    https://github.com/jenkinsci/docker-workflow-plugin
    https://github.com/jenkinsci/pipeline-examples

Maybe Jesse or Andrew could provide "right" links.

Best regards,
Oleg Nenashev

четверг, 3 марта 2016 г., 21:13:54 UTC+3 пользователь Ben Navetta написал:

[Ben Navetta]

Hi Oleg,

Thanks for getting back to me! I'll start digging in, and I think I have some ideas of where to start.
Can't wait to start discussing it further!

Thank you again,
Ben Navetta

[nicolas de loof]

Hi Ben.

I've been working on few docker plugin in the past: docker custom build environment (aka oki-docki) then docker-slaves. The later is much a prototype to demonstrate a new approach, and I'm now working with Yoan on getting this mature.

Our first step is to introduce a new paradgim by reversing the slave / build relation : we don't want a slave to host builds, but a build to define it's slave and get this one provisionned then destroyed as part of the build. This has been implemented relying on hacks, but helps us to understand impacts (especially considering pipeline) and introduce the required hooks in jenkins core.

Next step will be about using docker as a remote process launcher in replacement for remoting to a slave JVM to run a process. Same could apply to FilePath abstraction, need to investigate more on this topic ...

[Oleg Nenashev]

Hi Ben,

We are conducting Office hours on the next week in order to discuss the project ideas with students and mentors. Dates - March 7th and March 9th.

See the schedule here: https://wiki.jenkins-ci.org/display/JENKINS/Google+Summer+Of+Code+2016

Best regards,
Oleg Nenashev

пятница, 4 марта 2016 г., 3:11:01 UTC+3 пользователь nicolas de loof написал:

[Ben Navetta]

Hi Nicolas,

Sorry about the delay. I've been looking at ExecutorStepExecution in terms of what hooks need to be configured for a Docker execution. I think a lot of the docker-slaves work should be applicable, and we can probably spin up a container to run steps instead of queueing a task to run on a node. Some of the filesystem-based hooks might be a bit tricky, but do you think injecting code into the Docker containers might be feasible? Having some access from the inside could help with things.

[Ben Navetta]

After looking into Jenkins' slave system a bit more, I think this would need to have access to the Docker container to run slave.jar. That would mean that any Docker images people want to execute on would have to have a JVM in a reasonably well-defined location. Adding slave.jar in the pipeline code with docker cp could work with that, so there wouldn't be too many restrictions on image selection. Nicolas, do you think some of the one-shot executor logic could be reused for this, or is it more targeted at a standard build?

[nicolas de loof]

You're right, Jenkins is higly tied to it's remoting agent. We have workaround for some calls (like launching a process) but generally speaking we need this agent running on slave.

Yoann and I have developed an alternate approach based on a set of containers (aka a "pod") here one of them comes with a JVM and slave.jar and will handle remoting stuff, and another one do host the build command. They share network and workspace as a volume. Can also have some more container added to this set, for sample to run a selenium browser, without need for xvnc hack during the build.

We also use plain docker run stdin/stdout as a channel between master and slave. No need for sshd in docker image, nor callback JNLP URL - which requires jenkins to be reachable from the slave. Removal for this Launcher complexity makes it trivial to run a docker container as a slave.

this approach offer a great flexibility, see https://github.com/ndeloof/docker-slaves-plugin for details

We have also considered a possible optimisation to create a docker container when jenkins starts to use a base image + Jvm, inject slave.jar (docker cp as you suggested) as well as jenkins jars into remoting cache, then commit the image. This image could then be used for all build, would perfectly match the jenkins installation, and as a result the remoting would start immediately without need for classes exchange. This is just an idea, not required, but something we have in mind for future.

The One-Shot logic has been designed for this exact scenario, it was initialy mixed into docker-slaves, but as it could benefit other plugins (Kubernetes, Amazon ECS, maybe mesos as well) it made sense to just extract it. It's feature complete but implementation details would need some polish and additions for new hooks into jenkins-core, but is usable today : you can wait for a future release for a "cleaner" implementation, but the API is well defined.

[Ben Navetta]

Hi Oleg and Nicolas,

I've put together an initial proposal for executing Pipeline as Code steps in Docker. I think it incorporates most of what we discussed with regard to executing on arbitrary containers and where to integrate with the pipeline API, and a couple areas to extend it. Please let me know what you think!

Ben