If you have been looking for a tool to deploy your applications into a Kubernetes cluster, you have definitely stumbled upon Helm. Its the most com...
For further actions, you may consider blocking this person and/or reporting abuse
The Cyclops might be a good tool for managing the helm charts but here is my insights:
While it’s true that Helm uses values.yaml by default, and you can override values using a file or the --set flag, this is not necessarily a drawback. The --set flag is particularly useful for managing different environments without modifying the base chart.
Moreover, Helm provides ways to track deployed configurations. Commands like helm get values and helm history allow you to inspect the currently deployed values, reducing the risk of accidental overrides. Best practices, such as maintaining separate values.yaml files per environment, further mitigate this concern. Hence, this is not a fundamental limitation of Helm but rather a matter of managing configurations effectively.
Additionally, Helm provides validation mechanisms, such as helm lint, which can catch syntax errors and misconfigurations before deployment.
I completely agree that what the tool does and how you use it are equally important.
However, will all developers be proficient with Helm (to understand and use the commands you mentioned) and will onboarding them to Helm (on top of Kubernetes) have a positive ROI?
Helm should be a part of your deployment process but not the only tool you use.
That’s a great point! While not all developers may be proficient with Helm initially, providing proper onboarding and best practices can help teams use it effectively. The learning curve is a valid consideration, but the automation and consistency Helm brings to Kubernetes deployments often justify the investment.
Additionally, integrating Helm with other tools, such as GitOps workflows (e.g., ArgoCD or Flux), can further streamline deployments and reduce the need for direct Helm interactions. Helm works best as part of a well-designed deployment strategy rather than a standalone solution.
More of this please
🫡
Insightful post keep it up!
💪💪
You do know that there's an additional argument to help with your configuration issues?
--reuse-existing-valuesThe question here is, will you remember the flag every time you upgrade a chart? The point on the configuration persistence is not really "Is the config saved?" because it is in the release secret, but how transparent is it for developers, and how reliably can they change releases? In my opinion, developers should focus on what they are good at, which is coding and shipping products, and leave deployment to developers proficient in the topic.
Dope
😎
cool, but isn't that argocd with extra crd?
ArgoCD also has a CRD to manage deployments. The difference here is that you get a custom UI based on the helm chart for developers to use on top of their applications. With argocd you still need to configure all your apps through YAML
Love the YAML meme 😄
🔮 😂
Very cool
thanks! 🙌
Check out nelm, seems very promising to solve these and several other helm 2 limitations: github.com/werf/nelm
Thanks for highlighting this project! It has seen a lot of progress lately, with the big news coming soon :)