Docker Hub 2.0 has just been announced. What a nice opportunity to discuss Jenkins integration with it!
For this blog post, I’ll present a specific Docker Hub use case: How to access the Docker Hub registry and manage your credentials in Jenkins jobs.
The Ops team is responsible for maintaining a curated base image with a common application runtime. As the company is building Java apps, they bundle Oracle JDK and Tomcat, applying security updates as needed.
The Ops team uses the CloudBees Docker Build and Publish plugin to build a Docker image from a clean environment and deploy to Docker Hub on a private repository. Integration with Jenkins credentials makes it easy, and the plugin allows them to both deploy the base-image as “latest” and track all changes with a dedicated tag per build.
The Dev team is very productive, producing thousands of lines of Java code and relying on Jenkins to ensure the code follows coding and testing coverage standards whilst packaging the application.
During the build, they eventually include the packaged WAR file in a new Docker image, relying on Ops’ base-image. To do this, they just had to write a minimalist Dockerfile and add it to their Git repository. They can use this image to run some advanced tests and reproduce the exact production environment (even on their laptop for diagnostic purposes, if needed). The Ops team is confident with such an image as they know the base image is safe.
They also have installed the Jenkins Docker Hub Notification plugin, so they can configure the job to run when the Docker base-image is updated on the Hub. With this setup they know the last build will always rely on latest base-image, including all important security fixes that the Ops team is concerned about.
This scenario has been tested on Docker Hub 2.0 and works like a charm. Updating the base image sources on GitHub triggers a build for base-image job, which is then published to Docker Hub 2.0. Jenkins detects these changes to the Docker Hub hosted images, and jobs that depend on the upstream base-image* will be rebuilt, tested and published (and possibly released).
The Ops team is happy with this, as their fears of developers running ancient Docker images full of security holes are calmed by knowing that by simply updating the base-image, all projects that depend on it will be notified and updated automatically:
An actual company would probably have a more sophisticated deployment pipeline than outlined above, with validation steps (and possibly approval) for each image.
To learn more about Docker integration with the CloudBees Jenkins Platform, be sure to read additional blogs on https://www.cloudbees.com/blog, including Architecture: Integrating CloudBees Jenkins Platform with Docker Hub 2.0.
You can read more documentation about CloudBees and Docker containers here.
* Note the new Docker-Workflow feature will automatically register for changes to base images if you use that way to build out your pipeline:
Team’s logos are from commitstrip.com, which I recommend you follow - you may not learn much but you should get some good laughs.
Nicolas De Loof