Using Helm Values Files with Argo CD

hello in this video I will explain how to supply custom values files to a Helm chart sourced from a help chart repository in an Argo CD application so the challenge here is that you might be using a Helm chart that you don't maintain that you have to Source from a Helm chat repository for example a bit Nami Helm chart but you have values files that describe the values you want to override from the defaults and you manage those values files in git for example because you want to follow git Ops practices the challenge is that you are sourcing the helm chart from a Helm chart repository and the values files from a git repository and before I jump into this video I want to mention our free course in the description Down Below on git Ops and continuous delivery where you can get hands-on experience implementing these practices with Argo CD and a course created by the founders of the Argo project there are essentially three common solutions to accomplish this the first is creating a Helm umbrella chart that includes the chart from the helm chart repository as a dependency and you maintain this Helm chart in git alongside the values files or you can put the values directly into the application manifest instead of in a separate values file and use the app of apps pattern which if you're not familiar please check out our previous video on the app of apps pattern where I explain it in under eight minutes you use the app of apps pattern to maintain those application manifests in git just like you would the values files or you can take advantage of the multiple sources for applications feature in Argo CD to Source the helm chart from the helm chart repository and the values from git I'm going to demonstrate each one of these Solutions talk a little bit about the pros and cons and where I would choose to use one versus the other this video is presented by Acuity the Enterprise Argo company created by the founders of the Argo project so let's start off by taking a closer look at the problem that we're going to cover today so I have here an example of an Argo CD application Manifest this example is sourcing a Helm chart that I don't maintain from a Helm chart repository hosted on GitHub we're pulling in the hello world chart from this chart repository and the target revision of zero one zero the problem is that in my repository here I've got values files that I want to pass to that Helm chart as a part of this application but because I'm sourcing this Helm chart from a Helm chart Repository I can't simply add a reference to these values files in the source of my application so the first solution of this problem is to use a Helm umbrella chart now a Helm umbrella chart if you're not already familiar is one that takes in other charts as dependencies of it so in this example here I've got a chart that I maintain in my git Repository and then as a part of this chart I have a dependency now this hello world dependency comes from a Helm chart repository it doesn't come from something that I maintain but the advantage here is that I can Source this Helm chart from git in an Argo CD application and specify values files that I maintain in the same repository as this umbrella chart so for example if we go to the umbrella chart folder here you'll see that I've got three custom values files for Dev we're setting the replica count to one we're supplying that value to the dependent chart the important thing to note here is that any values I want to supply to a chart dependency I have to put under a top level key in my values files that has the same name as the helm chart dependency so in our chart.yaml here we've got dependencies name hello world and in my values files I've got hello world as the top level key and then I'm putting the values that I want to pass to that chart dependency under that top level hello world key the great part about this is that I can reuse this same umbrella chart for each variation of the chart that I want to deploy so I'm going to be able to reuse this umbrella chart for Dev stage and prod and in some cases you can even Supply multiple charts as a dependency under one umbrella chart but it's important to note that you have to trade off the complexity of maintaining multiple charts in one Argo CD application which means they all have the same same sync and Reconciliation life cycle versus maintaining multiple applications and multiple Helm charts Helm umbrella charts so let's take a look at what this looks like in Argo CD so I've got my three variations of the hello world chart being deployed using the helm umbrella chart that I have in my git Repository so if we look at the hello world prod application we've got three replicas based on what I've set in the values prod yaml so if we take a look at the application manifest for the hello world prod application you can see that I'm sourcing from the git Repository and path that contains the helm umbrella chart I showed earlier and then I'm specifying the values prod value file to pass to that Helm umbrella chart and so this is how I can maintain my values files in git while passing them to a Helm chart that I don't maintain that's hosted in a Helm chart Repository so through this it's going to pick up the this Helm umbrella chart which has the hello world dependency and then in that same folder it's got the values prod which tells it to use three replicas and then an Argo CD here we're pointing directly to that values file and to that umbrella chart in git and then we can see that the values are getting properly passed to the dependent chart because our hello world deployment has three replicas 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 my Helm umbrella chart when I update the dependency in the chart.yaml it will affect all three applications so if I were to update my chart dependency to a new version say 0 2 0 in Argo CD if I sync my applications and we can see that I've used an invalid chart version and it's now broken all three of my applications all three that are sourcing from that umbrella chart are affected by this now one solution to get around this is to maintain an umbrella chart for each variation of my application this requires maintaining additional boilerplate yaml for every variation I have to have a Helm umbrella chart for every variation of my application then so that leads me to our next solution which is maintaining the helm values in the application manifest instead of in separate yaml files in git this works really well when you're using something like the app of apps pattern to maintain your application manifest in git now if you're not already familiar with the app of apps pattern please go check out our previous video where I explain the app of apps pattern in under 8 minutes with an end-to-end demo so to demonstrate this I've got three application manifests stored in git already and if we go look at our prod.yaml application manifest you can see that it's very similar to the one that I showed in the initial problem statement where I'm sourcing the hello world chart from this Helm chart Repository the difference here is that I'm specifying the helm values directly in the application manifest meaning that I don't have to maintain a Helm umbrella chart just to be able to pass these Helm values to a chart hosted in a help chart repository and be able to maintain those values in git you kind of get the the best of both as now you're maintaining your application manifest and your values in git so you have get Ops for the whole application and you get the advantage that each variation of your application can have a different Target revision of the Helm chart from the helm chart Repository so let's see what that looks like in Argo CD so here I've already deployed my app of apps which has sourced this application manifest from my git repository along with the the ones for stage and Dev as well and then if I go to it you can see that my prod application has three replicas which means it has properly used the values that I've specified in the application manifest and if we look at the app details here we can see that we're using the helm chart from the helm chart repository and it's got the helm value stored directly in the application manifest now this solution's great except for when you have a large amount of values say for example you're taking all of the default values for a Helm chart and storing them in your values files or in your application manifest some organizations like to do this so that they've got certainty over what the values are even as they change the chart version but this is not ideal because then you end up with a really large application manifest that is difficult to navigate especially because prior to Argo CD version 2.8 which gets released in August of 2023 the values have to be specified as a plain text box which means that you don't get the syntax highlighting for the yaml that you're supplying for the values which can make it difficult to tell if you've got a basic syntax error or if you know the indentation's wrong or if something has been copied and pasted incorrectly into the values and it also makes it difficult if you like to do local development of uh what's being what's happening when you change the values it becomes much more difficult to run something like Helm template locally and being able to pass those values to it instead you have to copy it out of the application manifest or use something like yq to parse them out and then pass it to helm template this can also make it difficult to use something like an application set to generate the application manifest because each one can be different in a way that can't be sourced easily using an application set generator where if you have the values files in git you can easily interpret what the name of that values files is if it aligns with the applications name and therefore you could use the generator to template which values files to use but it's much more difficult to template the whole values block into the application manifest and that leads us into the final solution today which is multiple sources for applications now this is a feature that was introduced in version 2.6 of Argo CD and as of version 2.7 and 2.8 is still considered beta which means that the UI and CLI still generally behave as if there's only one source for the application and there may be backwards incompatible changes introduced in the future so proceed with caution when using this functionality for now but there are organizations using this in production to get around this problem so in this example I've got my values files stored in git here and then I've also got the application manifest stored along beside that to facilitate the app of apps pattern that we're using now these values files look just like a normal one that you would Supply to a Helm chart you don't need to have a top level key that specifies the dependent health chart to send it to because we're not using a Helm umbrella chart in this scenario these are just standard values files that you would pass to the helm chart if you were using it directly so for example our values prod file has the replica account of three now let's take a look at what an application manifest looks like for this so using our hello world prod application as an example you can see that the sources block now has a little bit more going on compared to our other examples so the first part here should look pretty familiar we're sourcing the hello world Helm chart from this Helm chart Repository but we're specifying the helm values file that it should use from another source so below the Helm chart Source we have a repo URL that points to my GitHub repository and then we give it an identifier a reference called values in this case and then if we look at the values files block here we're sourcing from the values reference which is this GitHub repository from this path we're sourcing the values files which this is the same values prod yaml file I showed you a moment ago so this multiple sources for an application gets combined together when rendering the Manifest so it's going to supply the values files from my GitHub repository to the helm chart that it's sourcing from a Helm chart Repository so let's see what this looks like in Argo CD if we take a look at our hello world prod application we can see that it's correctly pulling in the helm values because we're running three pods here but if we look at the application details the only repo URL we see here is the one for the helm chart repository the First Source in the multiple sources block now this is part of the detriment of using the beta feature is that the UI is going to behave as if there's only one source specified for the application so we can see that the the sync status here doesn't display properly and that it's unclear what commit revision we're on but if we take a look at the app details and the Manifest we can still see the multiple sources here specified in the Manifest at least so if you do end up using the multiple sources functionality before the UI receives all of the updates to properly present that it's using multiple sources you can at least tell from the Manifest tab here where it's sourcing the helm chart from and where it's getting the values from and what the relation between the two of them are this solution in my opinion is the best one in the long run because it removes the additional boilerplate required when using the helm umbrella chart solution and it's still very compatible with application sets and generated applications because you don't have to specify all of the values files in the application manifest itself if I was going to implement this myself today I would personally stick with the umbrella chart solution for now because I find it's the most elegant of the three assuming that when you update a dependency Helm chart version you're okay with that affecting all of your environments at once or you've got manual syncs for the applications so the only show is out of sync until you choose to sync that new Helm chart version into that environment thank you for watching this video if you're interested more I go CD related content please check out the Acuity YouTube channel

Channel: Akuity

Views: 9,198

Keywords:

Id: MlAWr8bVr0I

Length: 17min 27sec (1047 seconds)

Published: Mon Jul 17 2023