Refactoring Docker build repositories for Horizon, Minion and Sentinel



We currently have a pretty scattered set of repositories to build docker container images:

Beside them we have a different Horizon/Minion/Sentinel pipeline maintained in the System API tests and we have to maintain some intermediate base images as build dependencies, so they are cachable, versioned and interchangeable such as:

  • Vanilla CentOS 7
  • OpenJDK
  • Oracle JDK

The release is triggered by a manually workflow. For the reason we started to use Docker container images also in our System Test API we should considering the following steps:

  • Make Docker images for Horizon, Minion, Sentinel a first class artefact automatically built with CI/CD
  • Publish releases to our Docker Hub repository
  • Consolidate intermediate dependency images in a central repository and allow controlled updates and rollbacks into the build infrastructure


Here is a first result of my refactoring efforts and open for discussions. The branch for this Proof-of-Concept is located in branch rt/container-poc.

Major changes

Introduced the directory opennms-container with a project directory for Horizon, Minion and Sentinel. Each have their own Dockerfile.

  • The Dockerfiles are now very flexible during docker build. The most important things are, you can define which is the base image, e.g. do you want to build on OpenJDK or OracleJDK and which version.
  • Allow to pass PACKAGES into the build which are installed with yum install
  • Add ./rpms directory convention which is available in the docker build context and all RPM files which are dropped into this directory will be installed automatically.

The ./ and ./ are just for convenience. Integrated into our CI/CD the docker build command could be used with the appropriate build arguments.

With help from @mvrueden I added also a convenience script which allows to fetch RPM artefacts from a bamboo build as an example.

cd opennms-container

It will get the RPMS from the build artefact for Horizon, Minion and Sentinel, stores them into the RPMS directory of the project. You can then run in parallel the docker build steps for each component.

A next step would be how to integrate these in our CI/CD environment and persist a container image as a downloadable artefact.

Dependency repository

Introduced a consolidated repository to gain control for build dependencies: with the following features:

  • Build versions of dependencies in CircleCI and publish them to a repository
  • Build for projects is only triggered if the directories have changed
  • Control about artefact version numbers to allow rollbacks and controlled updates in the build infrastructure

Feedback is always welcome.