Consuming 3rd Party Helm Charts

Tramscript:

Now, the first thing that I want to do is navigate to my Helm folder. And then within this folder, there's a Postgres folder and a charts folder. Let's start with the Postgres one. This one will be consuming a third-party Helm chart. So I'll create a namespace just to isolate things. Then the first thing that I need to do is add the repo. Now, before we do anything else, let's confirm that you have Helm installed. This should be installed by dev box. Here, I'm using version 3.15.0. This is Helm version 3, which runs only as a client-side tool. Many years ago, there was a previous version of Helm that had a component you installed into your cluster called tiller. I think that's old enough now that any chart relying on that should be deprecated. So we're not going to cover it in detail. But just know that moving forward, you should be using at least Helm version 3, and it only operates on the client side. The first thing that I'm going to do is issue the Helm repo add command. And this adds the repo to my set of Helm repositories. In this case, I'm referring to a public repo hosted by Bitnami, which is a company that develops many Helm charts, and referencing their repository here. As you can see, I had already added this. You should add it to your Helm configuration. The next thing that I want to do is issue the Helm search repo command on the Bitnami repo and the PostgreSQL chart, specifically asking for the different versions that are available. So as you can see, this chart has been upgraded many times, as well as the application. So this is the version of PostgreSQL that it's going to install, and this is the chart version associated with that. So as you can see, there's many versions available. We're going to actually install one of these newer versions, but not the newest version so that we can show the process of an upgrade. I mentioned that there's both Helm repositories and OCI repositories. I just want to showcase there's a slightly different approach you use when interacting with OCI repositories. When you're looking at the documentation for a particular Helm chart, it should tell you whether or not it's a Helm repo or an OCI repo. Some tools actually offer both. In this case, I can log into an OCI repository by issuing the Helm registry login. And here, Docker Hub is actually an OCI registry. You'll use your Docker Hub username and password to log in. Great, so my login succeeded. And then we can't actually use that Helm search command against an OCI repository. There is a CLI that was installed via dev box called ORAS, or O-R-A-S. I'm not sure how to pronounce it. And you can use this to interact with these OCI repos directly. Here, I'm asking for the set of tags within the Docker Hub Bitnami charts registry for the PostgreSQL chart. This should be the same set of tags available via the Helm repo, because Bitnami hosts both as their own Helm repository, as well as an OCI repo on Docker Hub. Now, if you want to view a local copy of the Helm chart, if it's hosted on GitHub or something, you could go find the repository and look at it directly there. But you also can pull the chart. So I can issue a Helm pull command, referencing the repo and the chart in a particular version. And you'll see within my PostgreSQL directory, I now have this tarball, which contains the contents of that chart. I can unzip that by issuing a tar-xcf, and then the name of my tarball. And this will produce a directory called Postgres, which has the contents of the chart. So if I look at the chart.yaml, here is the metadata associated with this chart. You can see the version. You can see the name of the chart. You can see who is maintaining the chart, additional keywords for discovery purposes, the application version. So this is the application. This is the Postgres version included in the chart, et cetera. We also can then look within this templates subdirectory. And we see that if we deploy this, it's going to deploy some combination of a bunch of role-based access control things. It's going to deploy a stateful set, a service, some monitoring capabilities, a network policy, a configuration. Each of these is going to have all sorts of templating built in. This Helm chart also has the ability to deploy a backup cron job to help you back up your database. And so by pulling it, you can explore locally and also look at the values.yaml file. So this is going to contain all of the available configuration options that we can modify for our specific purposes. So we could pass in things like what we want the password and username and default database to be. We could store those in an existing secret so that we don't have to pass them directly in via the chart. They could be stored as a secret within our cluster and just reference those. If we wanted to override the image that was being used, instead of using the default image, let's say we had our own version or we're hosting it in our own container registry, we could do so here. And so there's all sorts of values that you may want to override. Hopefully, the chart authors have provided a good set of defaults. But you should always review the available configurations and see if any of them need to be set to meet the needs of your deployment. There's also this values schema file. This is not a required file, but it can be very useful to help enforce a schema on the values of the chart. Otherwise, people can specify anything they want in the values file. And let's say they had a typo. Without any validation, that typo might go unnoticed and just not impact the deployment. Whereas if you include a schema, Helm is able to enforce that schema. In addition to the values.yaml file in the chart itself or the value schema file, you can also issue the Helm show values command. And that will also specify the available values without necessarily needing to pull the chart. OK. That's a lot of preamble. But let's go ahead and install this Helm chart. In this case, we're going to issue the Helm install command, passing it the name of our chart, passing it a version. And here I have two versions specified in my task file. I'm starting out with version 15.4.1. And then I'm going to upgrade in the next step to 15.4.2 just to show you how that upgrade process works. I'm telling it to create the namespace if it doesn't exist. And then I'm passing it a values file. If I go to the values.yaml, I'm giving it a common annotation that I want to apply to all resources. And this is going to be substituted in via those templates to apply this annotation to all the resources that the chart is deploying. It has some helpful information here that is being printed out after the deployment was successful. It's telling us how I can access this on DNS within the cluster. So this is the name of the service. This is the namespace and then service cluster local. So we can see it created this cluster IP service behind the scenes. We can see that it stored our password in a secret here. And because I didn't specify a password, I believe it generates one automatically, a random one. Let's go ahead and do kget pods. And as you can see, we have a single replica from that stateful set that's up and running. I'll do kget all in my current namespace. And you can see we've got our stateful set. We've got a single pod. And we've got a service as well as a headless service. Now, let's see if this common annotation got subbed in and applied to my resources. So if I do kget stateful set-o yaml, pipe that to YQ. And here is my annotation that I provided via that values.yaml file that was injected into the stateful set itself. As you can see, it was also injected into my service. So I just wanted to showcase how setting a value and passing it via that values.yaml file gets applied into the various templates. Otherwise, this was a completely default installation. It's using my kubectl credentials and using the namespace that I configured as default, which in this case was my 05--postgresql namespace. So what if I wanted to upgrade this? I can issue a helm upgrade command. Whenever I do a helm upgrade command, I generally also include this dash dash install. And that's because this allows you to use the same command, whether it's the first time you're installing it or if you're upgrading. If you didn't include this dash dash install flag and the helm release did not exist yet, it would fail. And so I just use this one command to always install or upgrade. Here, everything is the same as before. My only difference is that I'm passing in a new version. So before we had 15.4.1. Now I'm passing in 15.4.2. And if I look at the pods, we see a new one has come up just 36 seconds ago. So that upgrade appears to have been successful. It's also useful to know that Helm stores its history of the releases within secrets in the cluster. So if I do kget secrets now in this namespace, I can see I have two releases. I have this initial install, and then I have this upgrade. And so this is how, as a client-side only tool, it's able to store some history such that we can do things like rollback. So let's say the new version we upgraded to didn't perform as expected and we needed to roll back to the previous version. We could do Helm rollback postgres. And this is the name of the release. So if I do Helm list, we can see this is my release that I have in the cluster. And so I'm doing Helm rollback release. It's gonna take my current version and go back to the previous one. And you can see it's now referencing the original version, 15.4.1, that I had deployed into the cluster. Now I use this command already, but if you do Helm list and specify namespace, this is gonna show all the releases within that namespace. I can also ask Helm to provide me with this specific set of values that were provided for that deployment. It's gonna provide me with the specific set of user-supplied values. The rest are gonna use the defaults, but these are the ones that I provided via my values.yaml file at runtime. So this is a very useful command if you need to figure out the configuration that was deployed. Hopefully those are all stored within your Git repository and are up to date, but this can be a way to validate that the deployed version matches your expectation. And then you also can run the Helm get manifest command. And this is going to look at the deployed release and give you the set of rendered out manifests. So taking all the templated values and rendering out the actual deployed versions that you want to have in the cluster. And this is a great way to see all of the manifests that that Helm chart is deploying in their rendered form. Now, finally, let's say you are no longer using whatever tool you had installed with Helm. There is an uninstall command. Let's just Helm uninstall, and then you pass it the name of the release. Here, the release is uninstalled. And if I do okay, I get all in my current namespace. Those two services, the stateful set and the corresponding pod were all cleaned up. Awesome. So that covers kind of the types of interactions that you'll have with a third-party Helm chart, how to access the repo, how to install the repo, how to look at the different configuration values that are available, and then how to interact with the releases on the cluster side once you've deployed things.