Templating Jenkins Build Environments with Docker Containers

Builds often require that credentials or tooling be available to the slave node which runs it. For a small installation with few specialized jobs, this may be manageable using generic slaves, but when these requirements are multiplied by the thousands of jobs that many organizations running per day, managing and standardizing these slave environments becomes more challenging.

What is Docker?

Docker is an open-source project that provides a platform for building and shipping applications using containers. This platform enables developers to easily create standardized environments that ensure that a testing environment is the same as the production environment, as well as providing a lightweight solution for virtualizing applications.

Docker containers are lightweight runtime environments that consist of an application and its dependencies. These containers run “on the metal” of a machine, allowing them to avoid the 1-5% of CPU overhead and 5-10% of memory overhead associated with traditional virtualization technologies. They can also be created from a read-only template called a Docker image.

Docker images can be created from an environment definition called a Dockerfile or from a running Docker container which has been committed as an image. Once a Docker image exists, it can be pushed to a registry like Docker Hub and a container can be created from that image, creating a runtime environment with a guaranteed set of tools and applications installed to it. Similarly, containers can be committed to images which are then committed to Docker Hub.

Docker for Bootstrapping and Templating Slaves

Docker has established itself as a popular and convenient way to bootstrap isolated and reproducible environments, which enables Docker containers to be the most maintainable slave environments. Docker containers’ tooling and other configurations can be version controlled in an environment definition called a Dockerfile, and Dockerfiles allows multiple identical containers can be created quickly using this definition or for more customized off-shoots to be created by using that Dockerfile’s image as a base.

The CloudBees Custom Builds Environment Plugin allows Docker images and files to serve as template for Jenkins slaves, reducing the administrative overhead of a slave installation to only updating a few lines in a handful of environment definitions for potentially thousands of slaves.

Building with Docker Containers

This plugin adds the option “Build inside a Docker container” in the build environment configuration of a job. To enable it, simply scroll to the “Build Environment” section of any Jenkins job and select the “Build inside a Docker container” option. You will then be able to specify whether a slave container should be created from a Dockerfile checked into the workspace (e.g. the file was in the root of the project) or whether to pull an explicit image from a Docker registry to use as the slave container.


Customized Slave Environments

For generic builds, you can leverage the most popular Jenkins slave image in Docker Hub called evarga/jenkins-slave or create a new image with a custom Dockerfile for any specialized builds that requires some build dependencies which should need to be available in the workspace, such as credentials.

To create a custom environment, you will need to create your own Docker slave image. This can be done by creating a new Dockerfile or running an existing slave image such as “evarga/jenkins-slave”, then installing the necessary custom tooling or credentials and committing your changes to a new image.

To create a new image from a Dockerfile, you can simply edit the below copy of the “evarga/Jenkins-slave” file using the Dockerfile guidelines and reference

FROM ubuntu:trusty


RUN apt-get update

RUN apt-get -y upgrade

RUN apt-get install -y openssh-server

RUN sed -i 's|session required pam_loginuid.so|session optional pam_loginuid.so|g' /etc/pam.d/sshd

RUN mkdir -p /var/run/sshd

RUN apt-get install -y openjdk--jdk

RUN adduser --quiet jenkins

RUN echo "jenkins:jenkins" | chpasswd


CMD ["/usr/sbin/sshd", "-D"]


Builds which are built within a Docker container will be identifiable by the Docker icon displayed inline, within a job’s build history.

Where do I start?

The CloudBees Docker Custom Build Environment 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.

Other plugins complement and enhance the pipelines possible with this plugin. Read more about their uses cases in these blogs:

More information can be found in the Jenkins Cookbook.

Tracy Kennedy
Associate Product Manager

Tracy Kennedy is an associate product manager for CloudBees, based in Richmond, VA.

Read more about Tracy in the Meet the Bees blog post about her and follow her on Twitter.



Blog Categories: 


I need some help in integration of VSTest in Jenkins. After configuration of VSTest in Jenkins I am getting below error and it is also not creating batch file in temp folder after build. it will be great if you can share some data point on this. Your help will be appreciated. Path To VSTest.console.exe: C:\TestWindow\vstest.console.exe. Executing VSTest: cmd.exe /C C:\Windows\TEMP\vstest907446097964687148.bat && exit %ERRORLEVEL% [GIT-Temp] $ cmd.exe /C C:\Windows\TEMP\vstest907446097964687148.bat && exit %ERRORLEVEL% E:\GIT-Temp>"C:\TestWindow\vstest.console.exe." "E:\GIT-Temp\CITI.YSA\Citi.YSA.WebUITests\bin\Debug\Citi.YSA.WebUITests.dll" /Enablecodecoverage /UseVsixExtensions:false /Platform:x86 /Framework:framework45 /Logger:trx '"C:\TestWindow\vstest.console.exe."' is not recognized as an internal or external command, operable program or batch file. Build step 'Run unit tests with VSTest.console' marked build as failure Finished: FAILURE

Hi Ritesh, I'm a Java developer, and so I don't have any experience with VSTest. However, it looks like your Jenkins instance just can't find vstest.console.exe. Are you using the VsTestRunner plugin : https://wiki.jenkins-ci.org/display/JENKINS/VsTestRunner+Plugin? If so, you should try reconfiguring the location or ensuring that vstest.console.exe is indeed available in the TestWindow folder. It's also unclear to me from the docs, but it may be that this configuration needs to point to the tool installer location on whatever node runs this test - e.g. your slave node should have VSTest installed to it. If you are a CloudBees customer, you can contact our support team at http://cloudbees.zendesk.com and they'll work with you to figure out the root cause of this. Otherwise, you may have some luck in the Jenkins IRC: https://wiki.jenkins-ci.org/display/JENKINS/IRC+Channel Or the Jenkins user mailing list: https://jenkins-ci.org/content/mailing-lists Cheers! Tracy

Add new comment