Supplying Custom Values Files to Helm Charts in Argo CD Applications

In this blog post, we will dive into a common challenge developers face when using Argo CD — an innovative Kubernetes application deployment and management tool. We'll explore how to supply custom values files to a Helm chart sourced from a Helm chart repository within an Argo CD application. This situation arises when you want to use a Helm chart that you don't maintain but need to override some default values with your own custom ones managed in a Git repository, following GitOps practices.

Before we dive into the solutions, we invite you to check out our free course on GitOps and Continuous Delivery. Developed by the founders of the Argo Project, this course offers hands-on experience in implementing these practices with Argo CD.

Check out our Youtube video for an in-depth look with demos of the solutions presented in this blog post.

Understanding the Challenge

The challenge we face is sourcing a Helm chart from a Helm chart repository and custom values from a Git repository simultaneously. We'll look at three common solutions to tackle this problem, each with pros and cons. Let's explore each approach in detail:

Solution 1: Helm Umbrella Chart

The first solution involves creating a Helm umbrella chart that includes the Helm chart from the repository as a dependency. The custom values are then maintained in the same Git repository as this umbrella chart. This approach allows you to source the Helm chart and values files from Git within an Argo CD Application.

It's important to note that any values you want to supply to a chart dependency must be under a top-level key in the values files with the same name as the Helm chart dependency. In our example chart YAML, we've got a dependency named hello-world; in the values files, it's got hello-world as the top-level key.

However, the downside with this approach is that if all three of my applications are tracking the same revision of my Git repository and then, therefore, the same revision of the Helm umbrella chart, when I update the dependency in the chart, YAML, it will affect all three applications.

Solution 2: App of Apps Pattern with Values in Application Manifest

The second solution is to place the custom values directly in the Application manifest instead of separate values files. This approach works well when adopting the App of Apps pattern for managing your Application manifests in Git. It allows you to pass the Helm values directly to the chart hosted in the Helm chart repository while keeping the values in Git. This provides GitOps for the entire application and allows each Application variation to have a different target revision of the Helm chart.

Solution 3: Multiple Sources for Applications (Beta Feature)

The final solution utilizes the Multiple Sources for Applications beta feature introduced in Argo CD version 2.6. This allows you to specify multiple sources for the Application manifest, including Helm chart repositories and Git repositories for values files. This approach combines the benefits of using the Helm chart repository and Git for custom values, enabling easier management of applications with distinct target revisions for different environments.

Conclusion

Choosing the right approach depends on your specific requirements and preferences. While the Helm umbrella chart solution might be the most elegant currently, the Multiple Sources for Applications feature shows promise for the future. It's vital to consider factors like application complexity, versioning, and ease of management when making your decision.

Thank you for reading our blog post! We invite you to check the Akuity YouTube channel for more Argo CD-related content and insights. Happy syncing!