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 MAINTAINER Ervin Varga 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 EXPOSE 22 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:
- Docker Build and Publish plugin
- Docker Slaves with the CloudBees Jenkins Platform
- Jenkins Docker Workflow DSL
- Docker Traceability
- Docker Hub Trigger Plugin
More information can be found in the Jenkins Cookbook.
Tracy Kennedy
Associate Product Manager
CloudBees
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 .
Learn More
There is a transformation occurring within IT that is enabling IT departments to provide more value faster to the business, and ultimately consumers and end users. In this paper, we will look at the rapid move to container technology and will discuss how Docker, Jenkins and DevOps are coming together to accelerate innovation.
Download your copy to learn about:
- The innovation catalysts as we see them today
- The next generation of continuous integration and continuous delivery
- Jenkins and Docker working together