In many organizations, it is a struggle for developers to get custom Jenkins container images created. Fortunately, in engineering, there is often more than one way to get the job done. In this article, I show you how to create your own custom Jenkins container image by aggregating readily available containers in a pod template.
Note that I'm using Kubernetes Plugin for Jenkins version 1.18.2 for my example application, which is running in Red Hat OpenShift. If you are using a different version, use its documentation.
Configuring the Jenkinsfile
As you would expect of any best practice with Jenkins, we'll start with a Jenkinsfile. Ideally, you should locate this file in the root of your Git repository. For my example, I use a declarative pipeline. See the Jenkins documentation if you prefer using a scripted pipeline.
The example is a simple Java project. We will need just two containers: One for the Java Network Launch Protocol (JNLP) agent and one for the Java tooling. The URL for the JNLP agent image on the Red Hat Registry is registry.redhat.io/openshift4/ose-jenkins-agent-base.
For the Java tooling image, we have a few options:
- Use a source-to-image (S2I) image for Red Hat Enterprise Linux 8 (RHEL 8) with OpenJDK 11, found at
registry.redhat.io/openjdk/openjdk-11-rhel8. - Use a CodeReady Workspaces (CRW) image, found at
registry.redhat.io/codeready-workspaces/stacks-java-rhel8. - Choose to use a Universal Base Image (UBI) or community image that your organization has already adopted.
I will use the CodeReady Workspaces (CRW) image, which ensures I get the same results in my CRW IDE as on the Jenkins pipeline. Figure 1 shows the Jenkinsfile so far.
Note that every Jenkins agent pod must have a container named jnlp. If you don't provide this container, Kubernetes Plugin for Jenkins is hardcoded to add one (here is an example of that behavior). Unfortunately, the hardcoded image is not compatible with the Red Hat OpenShift Container Platform (OCP) Jenkins image. A future release of OCP Jenkins will provide a default JNLP container via a default pod template.
You might also notice the imagePullSecrets configuration in Figure 1. I included that because I am pulling the images directly from registry.redhat.io, and the registry requires authentication. You also don't have to use OpenShift secrets; you can explore a variety of options to see what works best for you.
Build the basic application
The Jenkinsfile produces a pod with two containers, as specified. The two containers share a working directory and a volume mount that defaults to /home/jenkins/agent. The jnlp container takes care of the declarative checkout source code management (SCM) action. Unless otherwise specified, all other actions are executed in the Jenkins pipeline workspace. Figure 2 shows more of the Jenkinsfile, where we now begin to build the Java application.
Notice how I use the closure container to specify the java container, which is the YAML configuration from the pod template. The jnlp container is the default execution container. I won't show much more of the example application in this article, but you can find the complete version here.
Add all of the containers you need
After adding the jnlp container, you can add as many containers as you like to your pod template. Does your application need to execute Ruby? Try adding the configuration shown in Figure 3.
Once you've added a container, you can use it by entering a command like the one shown in Figure 4. Notice that the container names must match between the pod template and the closure.
If you are using CodeReady Workspaces, then you should use the same images in your devfile.yaml and your Jenkinsfile. Using the same image in both of these files ensures that you always get the same results in your workspace, which becomes more critical once you get into your pipeline.
Conclusion
In this article, I've quickly shown you how to aggregate readily available containers into a pod template. This is an efficient way to publish a custom Jenkins container without having to worry about organizational barriers—instead, you can get back to delivering your application. As a developer, I hope this approach makes your life easier.
If you want to learn more from the example application I used in this article, you can study the complete application code, which includes a devfile, as well as the Jenkinsfile that we developed together. For even more about developing Jenkins pipelines on OCP, see my video.
