As our blog series has demonstrated so far, Docker containers have a variety of uses within a CD pipeline and an organization’s architecture. Jenkins can package applications into Docker containers and track them through a build pipeline into production. Builds themselves can be run in Docker containers thanks to Jenkins Workflow and the Custom Build Environments plugin, guaranteeing standardized, isolated, and clean environments for build executions. Pools of Docker hosts can also be shared between Jenkins masters using the CloudBees Jenkins Platform, creating the redundancy needed to ensure enough slaves are always online and available for masters. Combined, these solutions offer a great way to manage and create a Docker architecture for Jenkins and other internal applications, but what happens when it’s time to upgrade these runtimes for security updates or new application releases? With Docker, changes to the base image require a rebuild of all containers in production from the new base image. But before we get too far into what this means, let’s first review what Docker is.
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 Hub is a Docker image registry which is offered by Docker Inc. as both a hosted service and a software for on-premise installations. Docker Hub allows images to be shared and pulled for use as containers or as dependencies for other Docker images. Docker containers can also be committed to Docker Hub as images to save them in their current state. Docker Hub is to Docker images what GitHub has become for many developers’ code — an essential tool for version and access control.
When the music fades…
There will inevitably be a time when the painstakingly-crafted Docker images that your organization has created will need to be updated for whatever reason. While Docker is fun and popular, it isn’t (yet) so magical that it eliminates this evergreen maintenance. However, these upgrades need not be painful, so long as they are tested and validated before being pushed to production.
Jenkins can now trigger these tests and re-deploys using the CloudBees Docker Hub Notification plugin. This plugin allows any changes to images in Docker Hub to trigger builds within Jenkins, including slave re-builds, application packaging, application releases via Docker images, and application deployments via Docker containers.
Monitoring for changes with Docker Hub
This plugin adds new a build trigger to both standard Jenkins jobs and Jenkins Workflows. This trigger is called “Monitor Docker Hub for image changes” and allows Jenkins to track when a given Docker image is rebuilt, whether that image is simply referenced by the job or is in a given repository.
Once a job has been triggered, the build’s log will state what the trigger was (e.g. “triggered by push to ”).
Docker Hub Hook Chaining
Docker Hub itself supports webhook chains, which you can read more about in Docker’s webhook documentation
. If you have added several webhooks for different operations, the callback that each service is doing is done in a chain. If one hook fails higher up in the chain, then any following webhooks will not be run. This can be useful if using the downstream Jenkins job as a QA check before performing any other operations based on the pushed image.
/jenkins/dockerhub-webhook/details will list all events triggered by all hook events, and you will be linked directly to the build, while Docker Hub’s webhook will link back to the Jenkins instance. You can also push tags to the Docker Hub repository.
Docker Image Pulls
This plugin also adds a build step for pulling images from Docker Hub. This is a simple build step that does a “docker pull” using the specified ID, credentials, and registry URL, allowing the Docker image that triggered the build to be pulled into the workspace for testing.
Where do I start?
Other plugins complement and enhance the pipelines possible with this plugin. Read more about their uses cases in these blogs: