Helm

Transcript:

The next tool that I mentioned is Helm, which I've already covered quite a bit. We'll take a very quick look at what a Helm chart for one of our services might look like, the types of values that we might expose as the interface. So under the Helm subdirectory, you can see we have a chart directory. We've got our chart.yaml. Within the templates is where you define the resources that will be deployed. And so here I just have a single example if we were defining a Helm chart for our Golang API. So under here, you can see this deployment.yaml. Again, it's going to look very similar to what we saw before. The main difference being now we've got this Go templating that allows us to specify number of replicas in the values.replicas and a tag that we want to use for our container image as values.version. In our ingress route, we're able to substitute in an environment post fix. And then our secret and service, our static.yaml that have no modification between environments. If we now look at the values.yaml, I've got three values specified. I've got an environment post fix, a replicas, and a version. The values.yaml within your chart are going to be the default values for everything. So I've specified default version, one replica, and an empty string here such that the ingress route template collapses down and we get kubernetescourse.devopstructure.com. Then I've got these example values file that will show how you can pass these in when you're doing a kubectl install such that they get used as we render out those templates. Let's start by rendering out the different values files and seeing how that impacts our manifests. To do that, we can use the helm template command. So here I'm calling helm template, passing it the path to the helm chart and then piping that to YQ just so we get nice syntax highlighting. And this will render out the values based on those default values. Based on the defaults in our values.yaml. So we would expect the image tag to be default version, a single replica, and an empty string used in that ingress route. If we go to our deployment, you can see default version was indeed used. We have a single replica and our ingress route did not have any postfix on our subdomain. Great. If we then want to render out production, for example, we want to pass that helm template command to the dash dash values option, passing it the values file that we want to use. In this case, it's the values.production.yaml. So we're going to expect two replicas and production version to have been used. Scrolling down, we see that's exactly what happened. Two replicas and the production version was used. Now, if instead of helm template, we used a helm upgrade dash dash install, like we've been using for a lot of our third party helm charts, we would pass it that dash dash values option, pass it our values file, and these would get applied to the cluster as a helm release. Now, the other things that I mentioned about helm is like this is an additional artifact that you need to build and publish and version, et cetera. So we have a package command. So if I do a T package, that runs the helm package and passes it the path to our chart. Using the version that's in our chart.yaml, it will then create a tarball containing our helm chart. So here we see API Golang helm chart version 0.1.0. So it bundled up our helm chart into this package. We can then take that package and push it to a registry of our choosing. So if I do T push, it will do helm push, passing it the tarball that I just generated, passing an OCI registry where I have created a repository for this particular chart. So I had created this repository on Docker Hub. And as you can see, I just pushed this version a few seconds ago. Now others could connect to this repo and pull down that version to consume within their clusters. Hopefully that gives you an idea of how you could write helm charts for your own services and choose these specific configurations that you want to expose.