I have started looking at tooling for automated image builds and what I came up with mostly follows Eric’s RFC, initial effort can be seen at https://github.com/theforeman/grapple/pull/2
A notable point is a build mechanism - after looking at quay.io, I decided not to use it as an external build service because we need more customized builds than what quay.io currently offers.
Reasons why quay.io is not the best choice for us as a build service:
Quay.io expects Dockerfile to be present in a repository together with code. In our case, Dockerfile is a build artifact that gets generated from a template based on what plugins will be included in an image and we would need to commit it for quay.io to have access to it.
Even if we commit a generated Dockerfile, the application code does not live in grapple. It is not a concern now as we leverage packaging in image builds but it will become a problem once we move to building from source. We would essentially need to git clone inside Dockerfile for core and every plugin we want inside the image. I’d rather go the other way around and prepare build context to keep Dockerfile as short as possible.
Additional concern is that by using quay.io as builder, we show that as a way to build foreman images. This significantly raises a barrier for anyone in community who would like to quickly build an image with a custom set of plugins as they would essentially need to replicate our build infrastructure - not to mention they will not see how our builds are set up in quay.
With these points in mind I opted for providing Ansible playbook that would build an image locally with optional push into a registry of choice, which gave me a simpler workflow and better control over the whole build process. I have also included a github action that runs the playbook and can be triggered manually. The intended workflow is that repo mashing in Jenkins triggers the github action that works as a builder and pushes the images into registry on successful build. To make this happen, the following things are needed:
- add a step into Jenkins release pipeline that triggers the github action
- make sure Jenkins is allowed to trigger that action
- set up secrets so that github action can push into registry
Which brings me to a question which registry to use for our images. We might use the existing foreman organization in quay.io, which would mean stopping the experimental image builds based on Dockerfile in foreman repo. Or should we use something else instead?
Once we have the images in registry, we can move forward with using them for demo in containers.
Thoughts?
