Hello there,
As some of you may be aware, I have been working part-time on a project called Tagger [1]. Its goal is to provide an imagemanagement abstraction layer for Kubernetes. Tagger tries to mimic (to some extent) the behavior of OpenShift's Image
Streams but on a vanilla Kubernetes cluster. Among its features, I can list:
- Automatic deployment whenever a new image is pushed.
- Allow for easy rollback and roll forward among distinct versions (generations) of the same container image (today’s “latest”
vs yesterday’s “latest”).
- Kubectl plugins for pushing and pulling images directly to the cluster (an attempt to abstract the registry existence, currently
supports “podman” container storage).
- Integration with
quay.io and
docker.io webhooks.
I have recorded a brief presentation (~8min) on what Tagger can achieve [2]. Now to the meat of this email: I have been thinking
about what the next step for the project is and it seems to me it might be a good fit for tighter integration with shipwright as an
opt-in feature. Some points where I think Tagger could be beneficial when used together with shipwright:
- Trigger new builds whenever a new Image is pushed.
- Should one’s build be triggered every time a new base image shows up? We can cover it.
- Provide shipwright with a local container storage volume with all images needed before a build
- This is an idea I have been thinking about: an init container that pulls everything locally before the actual build takes place.
- Builds won't need to pull images as they will be all there.
- Capture the build output image and publish it.
- If there are deployments associated with the image why not trigger them?
I have gone a long way but I am still far from reaching the end of it. If any of you think that this is an entertaining idea, please reach