7:37 a.m.
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 image
management 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
out. I want to give this project a place where it can deliver value to
users. :-)
[1] https://github.com/ricardomaraschini/tagger
[2] https://youtu.be/HZZeFLooeUM