Authoring Helm Charts

Transcript:

Let's take a brief look at how we might author some charts of our own. So I'll navigate to the charts subdirectory. I'll create a namespace. Now I've included a couple of things here. The first one is this, what I'm naming Helm create unmodified. There is a Helm create command, so I can do Helm create foo, and it will create a new chart with a bunch of default values and all of the necessary boilerplate for using Helm. I'll go ahead and delete this. Helm create unmodified is exactly that. I ran Helm create unmodified and it produced this chart. So if you wanted to explore the set of default configurations that it provides, it showcases a bunch of the different features of Helm, how you would use them, et cetera. You would then go in and take these templates and customize them to meet your needs. I've also included a super minimal Helm chart that doesn't include all of the boilerplate, but it's just enough to get started and showcase some of the different templating options that we have. I'm calling this Helm chart minimal. You can see here in the metadata chart.yaml, we've got the name, a description. There are two Helm chart types. There's application type. And so if your Helm chart is deploying an application, that is generally the one that you're going to want to use. The other one is a library type. And so that is if your chart is defining resource primitives that are then going to be consumed by other charts. So you can have a dependency hierarchy where one chart depends on another. And so there are library charts that are not meant to be installed in and of themselves, but are used by other charts to provide kind of foundational resource types. Let's look at the default values YAML file here. Here I'm specifying an environment as well as an array of config data. And then in my templates directory, I have two things. I have a helpers file. This is the same variable definition that I showed on the slide based on the environment in my values file defined an end short variable. So it's either going to be prod or non-prod. And then within my actual templates that are going to get rendered, I just have a config map. And this config map is going to be named based on my release name. It's going to include an app version. It's going to include the environment and put quotation marks on it. It's going to include that end short variable. And then it's going to loop over the set of values in my config data and decide based on those values, whether or not they should be included in this config map or not. Also in the notes.txt file that you include in your templates, this is going to get rendered out after you install or upgrade the chart. And so this is where you can provide that helpful information like the Postgres chart gave us information about the service or the password, et cetera. Kind of getting started information is what you would put here. Now I want to install it with the default values. And so to do that, I'm going to do helm upgrade install. Like I said, I use this even when it's the first time I'm installing something because it's valid in either case. I'm passing it the name of the release that I want to use. And then here I'm passing it a relative path to where the chart lives in the file system. So I haven't published this chart to any repo. So instead of pulling from a repo, I'm also able to reference a local chart within my file system. You can see that the release was installed in my O5 charge namespace. And we got that note from my notes.txt telling me which environment I deployed. You see it rendered out that env.short. Because my default values file was production, we deployed prod. Let's look at the config maps in my namespace to see what was actually deployed. Okay, we've got our config map data here. We can see that it included the app version, the environment, and the env.short. In this case, it was prod. And then also based on this loop here, since this enabled key was true, we got a conditional key with this string as the value. Conditional key, this will be included. Let's go ahead and deploy our chart again using our alternative values file here. Now, because it's the staging environment, we'll expect the env.short to be non-prod. We'll expect this conditional key not to show up because I have this enabled false, meaning that this conditional is going to skip over it. The way that you pass a specific set of values, again, it's the same command here, except now I'm passing a values file as well. You can see our notes was templated out properly and we can get our config map and look at the values. So now we no longer have any conditional key from our config data, and we only have these three keys because this enabled field was false. Awesome. I'll go ahead and clean up that namespace. And so that is a speed run of Helm and using Helm. One thing we didn't cover are Helm hooks. Helm hooks allow you to specify resources that should be deployed either before you install something or before you upgrade something or afterwards. Oftentimes there's some sequencing that is required when you're rolling out applications. Let's say you need to do a database migration that you might put as a Helm hook that is deployed before install or before upgrades, or there could be some cleanup actions that need to be deployed after. Those could also be a different hook. And so just wanted to call out that hooks exist, even though we didn't cover them here. But hopefully that gives you an idea of how you'll use Helm, which will be a very common occurrence as you install third-party tools into your clusters.