vendir VS kbld

i never found myself struggling with submodules, but at times i found myself just slightly annoyed (especially when having to remove/replace submodules), especially when they are used for simpler use cases.

i actually ended up creating https://carvel.dev/vendir/ for some of the overlapping use cases. aside from not being git specific (for source content or destination), its entirely transparent to consumers of the repo as they do not need to know how some subset of content is being managed. (i am of course a fan of committing vendored content into repos and ignore small price of increasing repo size).

👉The aim of this post is to document this to make things even easier with a tool called CARVEL vendir

Pipe your manifest through https://github.com/vmware-tanzu/carvel-kbld before deploying. It will resolve the image tags to digests.

you can also use a tool such as kbld which is capable of taking yaml that has a floating tag or specifier, building your image, pushing it to a registry, and then emitting the same yaml but with the floating tag locked down into a SHA.

We use https://github.com/vmware-tanzu/carvel-kbld do workaround this issue. You can just pass your deployment.yaml to kbld and it will rewrite all image tags to their corresponding resolved digests. You can than pipe the result to kubectl apply or your deployment tool of choice (we use Kapp from the same developers as kbld).

From purely a container standpoint, for my home Kubernetes cluster, I use ArgoCD for deployment and wrote a little plugin to pipe the final manifests (generated through helm, kustomize, static files, whatever) through kbld. kbld replaces the image tag with the digest sha, which means ArgoCD sees it as a change to the manifest, and with auto-sync turned on deploys the latest image automatically. I've had my Argo applications configured this way for over a year with basically no issues.

kbld - Build or reference container images in Kubernetes configuration in an immutable way