docker
an official buildkit helm chart
Tell us about your request Implement an official helm chart which can be used to deploy buildkit.
A standard helm chart would make for easy deployment of a preferred setup, such as the one discussed in this video: https://www.youtube.com/watch?v=wTENRhYt3mw
Which service(s) is this request for? buildkitd
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? In 100% gitops environments which I manage, argocd is used to deploy helm charts and kargo is used to automatically modify the helm chart version as a means to promote through stages such as dev -> test -> prod.
When an application does not have a helm chart, the solution is to watch the git repo for releases with kargo, then run a script to pull the git repo and package it up as a helm chart, then push the helm chart to an onsite repo. After which the usual methods which are used for all our apps, deploy a new version of an app to a dev cluster automatically upon the release of a new helm chart works, and we follow standard procedure to promote the new helm chart up to test and later to prod. This is an uncomfortable solution and lacks the benefits of using a helm chart.
A preferred solution would be to simply do a helm install, and set some variables to get onprem certificates added automatically where they are needed, based on an officially supported chart.
Deploying a large manifest doesn't make for easy automation of deploying in a test cluster and later promotion.
Also, I manage hundreds of apps and to deploy a manifest and have to research how to get onprem certs added takes time. As someone deploying and managing the app, I'd rather the folks who know where the certs should go can just take care of that, and I can just enable the setting in a values.yaml file without having to deep dive the product. And what if something changes behind the scene, as long as the values.yaml stays the same, how the certs get set behind the scene can change without my having to stop everything and go deep dive the product again for what changed. This is just an example, there are other benefits to using a helm chart, and many reasons why it is the top method folks use to deploy into kubernetes. Mirroring the techniques to set metrics related settings etc makes for easily onboarding an app into the environment. There is a lot of standardization. With helm charts you could add a dependency on a 'common' library such as the one provided by bitnami, which already includes a lot of standardized settings that buildkit could take advantage of.
Are you currently working around the issue? Two solutions are in place at two locations where I'm involved:
- one continues to use docker-dind via kubernetes pods and loses the benefit of caching
- one uses vms with docker instead of kubernetes, because caching is required, and buildkit isn't seen as ready (no helm chart)
Additional context There would be an upsurge in adoption with an official helm chart.
