Use the Jenkins Pipeline plugin and Docker to build a containerized build environment

Docker and Jenkins like the DevOps sector of chocolate and peanut butter as their combination has produced countless opportunities, of course, also produced a lot of problems, I will mention these two aspects.

In this article, I assume that the reader is already familiar with Jenkins and Docker, and I will focus on the specific configuration rather than putting the ink on the introductory concept that many blog posts have already introduced.

set a goal

The goal I'm going to achieve is very simple: build a Jenkins master node in a container and build multiple JNLP proxy containers on multiple hosts. These agent nodes can run on different AWS VPCs or ECS.


My goal is to get a generic configuration that can be deployed on any host, and each project defines the respective build environment. So that each development team can control the configuration, without having to build a team through Jenkins. I will try to avoid building a proxy node for a particular set of tools. Container technology can achieve such a build environment, but to really do every detail is absolutely a challenge.

In order to achieve this goal, I also used the Jenkins Pipeline / Workflow plugin. This plugin allows you to use the DSL language to describe the build process very gracefully, for example, simply define:

node('test-agent') {
stage "Container Prep"
// do the thing in the container
docker.image('maven:3.3.3-jdk-8').inside {
// get the codez
stage 'Checkout'
git url: ''
stage 'Build'
// Do the build
sh "./mvnw clean install"

The pipeline will be executed on a Jenkins agent named "test-agent", which will build a container based on the "maven" 3.3.3-jdk-8 "mirror. This pipeline will function properly on the physical node, but in the container In the run will be error.

Docker running in Docker

Running Jenkins' main or slave node in the container, maybe someone would think I needed the privilege mode to use "Docker in Docker", but I did not, Jérôme Petazzoni published an article "Using Docker-in-Docker to Build Continuous Integration surroundings? Please think twice, " you should refer to this article.

If you are still using wrapdocker script, you should ask yourself why, because it is easier to use:

docker run -v ${JENKINS_HOME}:/var/jenkins_home \
-v /var/run/docker.sock:/var/run/docker.sock \
-p 8080:8080 -p 50000:50000 \

This command will start Jenkins and have all the container operation functions, so there is no need for privileged mode to start the container and do not need the "Docker-in-Docker" mode.

There is a place to note: here you can not use the official Jenkins mirror, because jenkins users need to belong to the docker user group, so as to use the socket, which can be in the container Jenkins call docker, and ultimately through Jenkins build and run other containers.

Jenkins JNLP proxy container

In the "System Management" => "management node" page, click "New node", you can add slave:

Jenkins from the node to start the same way with the main node, it also needs to connect docker socket interface, you can start:

docker run -v ${JENKINS_HOME}:/var/jenkins_home \
-v /var/run/docker.sock:/var/run/docker.sock \
--name=jenkins-slave \
-d \
-url http://jenkins-master:8080/ \
a0a1b92971030d5f5dd69bd972c6cd899f705ddd3699ca3c5e92f937d860be7e \

As with the Jenkins master node, you need to make sure that the jenkins user has access to the docker socket interface. I use the Jenkins jnlp slave node so that the slave container can perform the build operation. Note that the secret parameter needs to be specified from the master Slave view.

Ready to start building

It is not difficult to start a build process in a container. The problem is that you must bind the proxy container to a path on a host, <code> $ {JENKINS_HOME}: / var / jenkins_home </ code>, and the container being built Access to this directory.

docker run -t -d -u 1000:1000 -w /var/jenkins_home/workspace/uri-templates-in-docker \
-v /var/jenkins_home/workspace/uri-templates-in-docker:/var/jenkins_home/workspace/uri-templates-in-docker:rw \
-e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** \
-e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** \
maven:3.3.3-jdk-8 cat

This container mounts the / var / jenkins_home / workspace / uri-templates-in-docker directory on the host to a containerized environment for use by Maven and sets this path to the current working path. Can run normally, but in the container, I need to try to do this:

This is obviously not because I mapped the docker socket port to the Jenkins proxy container. All the volumes mounted on the Jenkins agent container are actually references to the path on the host, assuming that the <code> $ {JENKINS_HOME} </ code > Is <code> / opt / jenkins_home </ code>, the following command should take effect:

docker run -t -d -u 1000:1000 -w /opt/jenkins_home/workspace/uri-templates-in-docker \
-v /opt/jenkins_home:/var/jenkins_home/workspace/uri-templates-in-docker:rw \
-e ********
maven:3.3.3-jdk-8 cat

to sum up

It's a very good idea to build a container for the environment, which saves a lot of time.

Note that this code may not just meet your needs, but at least is a demo, I hope this article can help more people use Jenkins container to build applications

About Hi cloud cSphere

Xiyun cSphere is a highly integrated, powerful Docker private cloud platform and class PaaS solution, its architecture designed to draw on the idea of ​​VMWare vSphere. System robustness than VMWare commercial products, products after more than a dozen times a year iterative update, in the internal experience is more than 1000 times the destructive test, is now in the financial, manufacturing, games, security, electricity providers , Education and other areas of landing.

Highlights of cSphere:

  • Platform to adapt to the application, do not need to adapt to the application platform.
  • Multi-application architecture multi-scene support, Xiyun commitment Whether it is 5 years ago, now even after 5 years of application architecture can be perfect support in the Greek cloud
  • Move the existing business, code, architecture without any changes
  • Xi Yun products to self-developed, abandoned the "patchwork" model, a strong guarantee of the quality of the project
  • Truly enterprise-class PaaS, to meet the needs of highly complex projects

Welcome to contact us:

  • Phone 400-686-1560
  • Mail

    Heads up! This alert needs your attention, but it's not super important.