Trying to run docker via gitlab-runners has been a sore point for a couple years, mainly around running multiple pods performing docker build.
Recently I learned, though gitlab recommends docker-dind, that there are much better alternatives out there with buildkit possibly being the best one.
Everything I deploy in all the environments I manage is 100% gitops via argocd.
This pretty much requires a helm chart for each app deployed.
Additionally, kargo is implemented to watch for helm charts, and used to deploy first to a testing cluster, then promoted up through stages, e.g. dev → test → prod.
All this means that if there isn’t a helm chart, I have to create and manage one, or else find a different product.
I searched for community supported charts and found a couple, but didn’t find myself feeling super confident in them.
How nice it would be if docker managed and maintained an official helm chart. Maybe now is the right time to make that happen. … or better yet, maybe a buildkitd-operator?
From the answer it sounds like you think i don’t know how to point to a manifest folder via an applicationset or application resource, or to create a git repo folder with my own helm chart files and the manifest you speak of, and so you provided a link to an introduction on argocd. Though i wouldn’t claim total mastery over argocd, i am in pursuit of that, and have had two jobs where i setup their argocd based gitops infrastructure, and im now at a third job doing the same. I understand that if you believe there is no need for a helm chart that resources would be wasted setting one up. Its difficult to communicate what is needed to manage apps at an enterprise level, but i would hope to first at least communicate the need to deploy to a dev cluster, then promote that up to test, then up to prod. I can only point to the fact that helm charts exist, and that it is the most popular way to deploy in to kubernetes. Even though not everyone likes helm charts, it continues to remain the most popular. It completely amazes me anyone would chose to stick with raw manifest files. Just food for thought, at my last position the department abandoned total dedication to cockroachdb over to yugabyte because yugabyte had well made charts and cockroachdb was only starting to work on them as an after thought. I setup automation to watch for new releases of cockroachdb and built helm charts in response, and pushed to a local repo before switching to yugabyte.
Your answer to my other question will probably get me going in my homelab, making this lower priority.
How would you implement the promotion dev → test → prod in an enterprise environment with a manifest based repo? kargo can watch for new releases via a git repo, but then what? Its easy to use kargo to modify a git repo with a new helm version number, but what would it do with a raw manifest?
I was able to get my homelab working using an emptydir solution provided by the gitlab-runner implementation along with docker-dind.
I’d rather be using buildkit though, to instead work with a rootless pod, to eliminate the need to use emptydir, and to get the benefit of caching.
I’m just going to go ahead and close this for now as there doesn’t seem to be much interest in a helm chart and revisit occasionally hoping something appears. For sure adoption would increase if one were available.
I sent the speak of this CNCF video an email and asked if he might consider creating a helm chart and submit it as a starting point for an official helm chart:
BuildKit is a much better fit than docker-dind, especially in GitOps workflows. An official Helm chart or even a BuildKit operator would make integration with tools like ArgoCD and Kargo a lot smoother.
