Orchestrating Workflows with Jenkins and Docker

From a traditional job, this becomes a pulldown option in the project configuration screen, and from a Workflow, you can use the tool step:

node('libqwerty') {
 withEnv(["PATH=${tool 'Ant 1.9.0'}/bin:${env.PATH}"]) {
   sh 'ant dist-package'
 }
 archive 'app.zip'
}

While this is a little better, this still leaves a lot of room for error. What if you need Ant 1.9.3—do you wait for a Jenkins administrator? If you want to scale up to hundreds of builds a day, who is going to maintain all those machines?

FROM webratio/ant:1.9.4

RUN apt-get install libqwerty-devel=1.4.0

// OK, here we come
node('docker') {
 // My project sources include both build.xml and a Dockerfile to run it in.
 git 'https://git.mycorp.com/myproject.git'
 // Ready?
 docker.build('mycorp/ant-qwerty:latest').inside {
   sh 'ant dist-package'
 }
 archive 'app.zip'
}

Embedded in a few lines of Groovy instructions is a lot of power. First we used docker.build to create a fresh image from a Dockerfile definition. If you are happy with a stock image, there is no need for even this:​

 

node('docker') {
 git 'https://git.mycorp.com/myproject.git'
 docker.image('webratio/ant:1.9.4').inside {
   sh 'ant dist-package'
 }
 archive 'app.zip'
}

docker.image just asks to load a named image from a registry, in this case the public Hub. .inside asks to start the image in a new throwaway container, then run other build steps inside it. So Jenkins is really running docker exec abc123 ant dist-package behind the scenes. The neat bit is that your single project workspace directory is transparently available inside or outside the container, so you do not need to copy in sources, nor copy out build products. The container does not need to run a Jenkins slave agent, so it need not be “contaminated” with a Java installation or a jenkins user account.

 

The power of Workflow is that structural changes to your build are just a few lines of script away. Need to try building the same sources twice, at the same time, in different environments?

 

def buildIn(env) {
 node('docker') {
   git 'https://git.mycorp.com/myproject.git'
   docker.image(env).inside {
     sh 'ant dist-package'
   }
 }
}
parallel older: {
 buildIn 'webratio/ant:1.9.3'
}, newer: {
 buildIn 'webratio/ant:1.9.4'
}

Simplified application deployments
So far everything I have talked about assumes that Docker is “just” the best way to set up a clear, reproducible, fast build environment, but the main use for Docker is to simplify deployment of applications to production. We already saw docker.build creating images, but you will want to test them from Jenkins, too. To that end, you can .run an image while you perform some tests against it. And you can .push an image to the public or an internal, password-protected Docker registry, where it is ready for production systems to deploy it.

 

1. The CloudBees Docker Workflow plugin is an open-source plugin, so it is available for download from the open-source update center or packaged as part of the CloudBees Jenkins Platform.
2. Documentation on this plugin is available in the CloudBees Jenkins Platform documentation
3. A more technical version of this blog is available on the CloudBees Developer Blog
4. More information on this feature is available in the new Jenkins Cookbook
5. Other plugins complement and enhance the ways Docker can be used with Jenkins. Read more about their uses cases in these blogs.
   1. Docker Build and Publish plugin
   2. Docker Slaves with the CloudBees Jenkins Platform
   3. Docker Traceability
   4. Docker Hub Trigger Plugin
   5. Docker Custom Build Environment plugin

Jesse Glick
Developer Extraordinaire
CloudBees

Jesse Glick is a developer for CloudBees and is based in Boston. He works with Jenkins every single day. Read more about Jesse on the Meet the Bees blog post about him and follow him on Twitter.