View CloudBees Docker Custom Build Environment on the plugin site for more information.
This plugin allows to define the environment for your build using a Docker container.
A major requirements for a Jenkins-based Continuous Integration/Delivery setup are
- ensure the build/test environment will exactly reproduce a pre-defined setup.
- ensure the build/test environment is well isolated from other builds executed on the same infrastructure
Docker is a great way to bootstrap reproducible and isolated environments. Compared to a Virtual Machine, it's faster to launch and lighter to use. Another benefit is the Docker image can be defined both as a binary image pulled from repository, or as a plain text Dockerfile you can store in SCM, with project source code, so they evolve in a common way.
CloudBees Docker Custom Build Environment Plugin has been designed to make Docker Images / Dockerfile as a first class citizen in Continuous Delivery setup, as the simplest way for a development team to manage the exact bits of the build environment, while the infrastructure team only has to focus on available resources hosting arbitrary docker containers.
CloudBees Docker Custom Build Environment Plugin can be used from any job type, it appears in the "build environment" section and let you configure your build to run inside a Docker container.
You can :
- Select the Docker image to run the build as a Docker image to be pulled. This is comparable to docker-plugin approach to offer jenkins-docker-slaves, but without any prerequisites on the Docker image nor need for Administrator privileges to configure the adequate slave template.
- Configure the plugin to build a container image from a Dockerfile stored in project repository. With this setup, you get both the project source code and build environment defined in SCM. This is my preferred way to use this plugin.
SCM checkout will run within a classic jenkins slave execution context - this is required to access the project Dockerfile then build and run the required container.
The slave executor(s) running jobs need docker installed and daemon running. We suggest you use a "docker" label for such slaves, so you benefit jenkins slave management and Cloud capabilities.
If you want to run this plugin on Windows / OSX for development, please note the plugin will bind mount the temporary directory inside container, so you probably will have to run jenkins JVP with -Djava.io.tmpDir=$HOME/tmp as only user home is accessible when using boot2docker.
Initial release as "CloudBees Docker Custom Build Environment Plugin".
The docker container is ran after SCM has been checked-out into slave workspace, then all later build commands are executed within the container thanks to docker exec introduced in Docker 1.3. When configured to build container from Dockerfile, the plugin compute Dockerfile checksum and use it as container ID, so it can detect the image exists on slave and build it first time requested.
Compared to docker plugin,
- this plugin can use arbitrary docker image, there is NO prerequisite to get a specific user set, ssh daemon, or even JDK available in docker container you use for the build - no need for CI-specific docker image, can use the exact same docker image you use on developer workstation to run/test your project.
- change to the project that require new tools / version upgrades can be reflected in the Dockerfile within an atomic commit. No need to reconfigure the job or wait for the adequate slave to be setup. Can also use a distinct Dockerfile per project branch.
- user don't need Administrator privileges to setup a docker-slave template, just need to commit a Dockerfile
- docker-plugin abuse jenkins Cloud API. i.e. you have to define a fixed IP address and can't benefit a Cloud slave provider, or a pool of generic slaves. oki-docki will rely on slaves which have docker installed, and Jenkins will provision/pick-up available ones using all available slaves provider plugins.