{ "componentChunkName": "component---src-templates-post-js", "path": "/blog/2016/08/08/docker-pipeline-environments/", "result": {"data":{"blog":{"html":"
\n\n\n\n\n\n
\n\n\n
\n

This is a guest post by Michael Neale, long time open\nsource developer and contributor to the Blue Ocean\nproject.

\n
\n
\n
\n
\n

If you are running parts of your pipeline on Linux, possibly the easiest way to\nget a clean reusable environment is to use:\nCloudBees\nDocker Pipeline plugin.

\n
\n
\n

In this short post I wanted to show how you can avoid installing stuff on the agents, and have per project, or even per branch, customized build environments.\nYour environment, as well as your pipeline is defined and versioned alongside your code.

\n
\n
\n

I wanted to use the Blue Ocean project as an\nexample of a\nproject that uses the CloudBees Docker Pipeline plugin.

\n
\n
\n

Environment and Pipeline for JavaScript components

\n
\n

The Blue Ocean project has a few moving parts, one of\nwhich is called the \"Jenkins Design Language\". This is a grab bag of re-usable\nCSS, HTML, style rules, icons and JavaScript components (using React.js) that\nprovide the look and feel for Blue Ocean.

\n
\n
\n

JavaScript and Web Development being what it is in 2016, many utilities are\nneed to assemble a web app. This includes npm and all that it needs, less.js\nto convert Less to CSS, Babel to \"transpile\" versions of JavaScript to other\ntypes of JavaScript (don’t ask) and more.

\n
\n
\n

We could spend time installling nodejs/npm on the agents, but why not just use\nthe official off the shelf docker image\nfrom Docker Hub?

\n
\n
\n

The only thing that has to be installed and run on the build agents is the Jenkins agent, and a docker daemon.

\n
\n
\n

A simple pipeline using this approach would be:

\n
\n
\n
\n
node {\n        stage \"Prepare environment\"\n          checkout scm\n          docker.image('node').inside {\n            stage \"Checkout and build deps\"\n                sh \"npm install\"\n\n            stage \"Test and validate\"\n                sh \"npm install gulp-cli && ./node_modules/.bin/gulp\"\n          }\n}
\n
\n
\n
\n

This uses the stock \"official\" Node.js image from the Docker Hub, but doesn’t let us customize much about the environment.

\n
\n
\n
\n

Customising the environment, without installing bits on the agent

\n
\n

Being the forward looking and lazy person that I am, I didn’t want to have to\ngo and fish around for a Docker image every time a developer wanted something\nspecial installed.

\n
\n
\n

Instead, I put a Dockerfile in the root of the repo, alongside the Jenkinsfile:

\n
\n
\n
\n\"Environment\"\n
\n
\n
\n

The contents of the Dockerfile can then define the exact environment needed\nto build the project. Sure enough, shortly after this, someone came along\nsaying they wanted to use Flow from Facebook (A\ntypechecker for JavaScript). This required an additional native component to\nwork (via apt-get install).

\n
\n
\n

This was achieved via a\npull\nrequest to both the Jenkinsfile and the Dockerfile at the same time.

\n
\n
\n

So now our environment is defined by a Dockerfile with the following contents:

\n
\n
\n
\n
# Lets not just use any old version but pick one\nFROM node:5.11.1\n\n# This is needed for flow, and the weirdos that built it in ocaml:\nRUN apt-get update && apt-get install -y libelf1\n\nRUN useradd jenkins --shell /bin/bash --create-home\nUSER jenkins
\n
\n
\n
\n

The Jenkinsfile pipeline now has the following contents:

\n
\n
\n
\n
node {\n    stage \"Prepare environment\"\n        checkout scm\n        def environment  = docker.build 'cloudbees-node'\n\n        environment.inside {\n            stage \"Checkout and build deps\"\n                sh \"npm install\"\n\n            stage \"Validate types\"\n                sh \"./node_modules/.bin/flow\"\n\n            stage \"Test and validate\"\n                sh \"npm install gulp-cli && ./node_modules/.bin/gulp\"\n                junit 'reports/**/*.xml'\n        }\n\n    stage \"Cleanup\"\n        deleteDir()\n}
\n
\n
\n
\n\n\n\n\n\n
\n\n\nEven hip JavaScript tools can emit that weird XML format that test\nreporters can use, e.g. the junit result archiver.\n
\n
\n
\n

The main change is that we have docker.build being called to produce the\nenvironment which is then used. Running docker build is essentially a\n\"no-op\" if the image has already been built on the agent before.

\n
\n
\n
\n

What’s it like to drive?

\n
\n

Well, using Blue Ocean, to build Blue Ocean, yields a pipeline that visually\nlooks like this (a recent run I screen capped):

\n
\n
\n
\n\"Pipeline\"\n
\n
\n
\n

This creates a pipeline that developers can tweak on a pull-request basis,\nalong with any changes to the environment needed to support it, without having\nto install any packages on the agent.

\n
\n
\n

Why not use docker commands directly?

\n
\n

You could of course just use shell commands to do things with Docker directly,\nhowever, Jenkins Pipeline keeps track of Docker images used in a Dockerfile\nvia the \"Docker Fingerprints\" link (which is good, should that image need to\nchange due to a security patch).

\n
\n
\n
\n
\n

Links

\n
\n\n
\n
","id":"649a2e8e-4f2f-56eb-99f1-8897de882a49","title":"Don't install software, define your environment with Docker and Pipeline","date":"2016-08-08T00:00:00.000Z","slug":"/blog/2016/08/08/docker-pipeline-environments/","links":{"discourse":""},"authors":[{"avatar":{"childImageSharp":{"gatsbyImageData":{"layout":"constrained","backgroundColor":"#181818","images":{"fallback":{"src":"/gatsby-jenkins-io/static/75c8520897a1db139d524965f5bb7ccc/19e71/michaelneale.jpg","srcSet":"/gatsby-jenkins-io/static/75c8520897a1db139d524965f5bb7ccc/77b35/michaelneale.jpg 32w,\n/gatsby-jenkins-io/static/75c8520897a1db139d524965f5bb7ccc/d4a57/michaelneale.jpg 64w,\n/gatsby-jenkins-io/static/75c8520897a1db139d524965f5bb7ccc/19e71/michaelneale.jpg 128w","sizes":"(min-width: 128px) 128px, 100vw"},"sources":[{"srcSet":"/gatsby-jenkins-io/static/75c8520897a1db139d524965f5bb7ccc/ef6ff/michaelneale.webp 32w,\n/gatsby-jenkins-io/static/75c8520897a1db139d524965f5bb7ccc/8257c/michaelneale.webp 64w,\n/gatsby-jenkins-io/static/75c8520897a1db139d524965f5bb7ccc/6766a/michaelneale.webp 128w","type":"image/webp","sizes":"(min-width: 128px) 128px, 100vw"}]},"width":128,"height":128}}},"blog":null,"github":"michaelneale","html":"
\n

Michael is a CD enthusiast with a interest in User Experience.\nHe is a co-founder of CloudBees and a long time OSS developer, and can often be found\nlurking around the jenkins-dev mailing list or #jenkins on irc (same nick as twitter name).\nBefore CloudBees he worked at Red Hat.

\n
","id":"michaelneale","irc":null,"linkedin":null,"name":"Michael Neale","slug":"/blog/authors/michaelneale","twitter":"michaelneale"}]}},"pageContext":{"next":"/blog/2016/08/09/ewm-beta-version/","previous":"/blog/2016/08/03/st-petersburg-jam-3-4-report/","id":"649a2e8e-4f2f-56eb-99f1-8897de882a49"}}, "staticQueryHashes": ["1271460761","3649515864"]}