I'm curious about the best practices when working with open-source tools like Prometheus, Grafana, or Ingress-NGINX in a production environment. Do you think it's better to keep the entire Helm chart source code in your Git repository, or would it be sufficient to just maintain a `Chart.yaml` file that references public repositories alongside your `values.yaml`? I understand the advantages of having an 'immutable' setup by keeping everything locally, but updating all of it can turn into a hassle. How do you strike a balance between security, reliability, and ease of maintenance? I've encountered issues before where repositories went offline, but I also find it tedious to download everything and host it. By the way, I'm currently using ArgoCD for deployment. Thanks for your insights!
5 Answers
We vend everything into our repo and it's been beneficial. The scenario you mentioned about repo downtime is why. When your production deployment fails at 2 a.m. due to an upstream Helm repo being down, having everything vendored is a lifesaver. With ArgoCD, you can still point to Helm chart repositories but pin specific versions. A good approach is to have your `Chart.yaml` reference upstream repos, while also committing the `charts/` directory from `helm dependency build`. This gives you reliability and keeps documentation in place. Plus, you can automate updates with tools like Renovate or Dependabot to monitor your `Chart.yaml`.
I lean towards pulling charts on the fly. If you're worried about public repositories disappearing, consider setting up your own mirror or proxy like Nexus. This way, you can mitigate the risk of losing access to necessary resources, and it adds security benefits since you can implement scanning and organizational rules on it.
With ArgoCD, you can render Helm charts into static manifests during sync time. This means even if the chart isn't available, you can continue with the pre-templated source for a while. I think that provides a good compromise between reliability and not going full vendoring.
That makes sense! Ideally, this should be centralized across your organization. I can see how it might feel overwhelming if every team has to manage it on their own.
Using submodules might be a solution. It helps keep everything manageable.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures