Hey everybody, I'm David Okun with IBM Cloud, and today we're gonna talk about Helm. Helm is a package manager for Kubernetes that makes it easy to take applications and services that are highly repeatable, or get used in a lot of different scenarios, and it makes it easier to deploy them to a typical Kubernetes cluster. To really understand and take that home, let's walk through a typical scenario of a couple of different applications and services as they're deployed in Kubernetes. So, let's say we're working with an e-commerce application that's signing up users for a certain shopping platform for the holidays, I'm sure you can think of a couple of examples there. And let's say that we've written a Node.js application that we're going to deploy to our Kubernetes cluster. Here we're going to say that that's marked here with one deployment but we have two replicas of this. This is because this is going to need to be highly available, so we have two replicas to handle all the different requests that are going to be coming in. And then, additionally, underneath this, we've got a MongoDB database. This is going to handle communications to, and from, each of our replicas just our main Node.js application that we have, and let's say that we've also written a service as a way to access our application, and let's say we've written that as a node port. Node port meaning that there's just a one-to-one ratio between IP's inside of, and outside of, our Kubernetes cluster. So, in order to deploy this kind of application stack, you need to define this, - or one way that you can define this with Kubernetes, is writing a couple of YAML files to describe what your deployments are going to look like, what your service is going to look like, etc. And this is a fairly parse down example, but let's go through some of the key elements of this here. With our deployment of our Node.js application, let's assume Mongo's there for you know persistence sake. With our deployments, we know that we're going to be writing an image of Node and
Mongo. So, for example, our YAML file here might look something like "node/mongo". And you might say version one, something like that. And, again, for the number of replicas that we have for this application, we know that we need 2 replicas here to, again, be able to handle that high availability. Now, for our service. Again, we decided that it was going to be a type of node port, so we're going to write that here. And, again, this is a one-to-one ratio between IP's outside of our service and inside of it to be able to route it to just one service here on our deployment because we have two replicas here to mitigate load whenever it comes to our deployment. And then, let's say for this particular example, this is going to be served up on Port 8080. So, we can write that purely inside our "Service.YAML" will file here. Now, this all works, and let's say that you wrote this application yourself, you wrote these YAML files yourself, you're really familiar with the configuration, so as long as you're still working on this it's fairly easy to be able to make changes to it and change things as requirements might change. So, let's say the holidays end and you want to go ahead and spin this down. You know exactly where to find the number of replicas that you need to change. But let's say you move on to a different job in your company, and somebody else is stuck managing this. They might not know, even in this simple example, where to go to change the number of replicas that you have with this particular application. So ,what if there was an easier way to manage the configuration for your whole application stack - and separate that logically from everything you have with your particular templated application. This is one place where Helm can really help you out. Think of Helm as combining two particular components for your whole application stack: a configuration, which is going to be defined by our values that YAML file up here, and a template - or what we call in Helm, a chart. Your chart is going to consist of all the files that you're going to be templating here. Now how do we actually template these files and inject variables into them? Well, you're going to take your configuration and you're going to instead use templating language to decide where those values are going to be put inside your templates, or your chart, here. So, let's say we want the number of replicas to be determined by our configuration up here instead of hard-coding that into our particular "Deployment.YAML" file. The way we could change that is we could say replicas are, instead, going to be managed by "Values.deployment.replicas", (I'll shorten it but you understand you just write after that). So, that way this is going to say, "OK, we're going to refer to the Values.deployment.replicas node," and sure enough, that's much easier to find in our configuration. So, we can simply write "2" here. Now, this means that, depending on what you want hard-coded in your template, you can decide whether to keep that hard-coded here, or you can make another change here, and simply refer to the same thing, instead you would say "image", and then you could say something like "node/mongo1". So, you could do the same thing for your service as well. Let's say you want to go from using a node port to a load balancer, as given to you by Kubernetes in the future. So, that you could instead change this, and you could say "Values.service.type", and you can change this to say "Values.service.port". This means that for a developer on this project, or for somebody who's working infrastructure, and making sure that this is deployed fresh, you can simply have them change your configuration here. So, for example here we're just gonna write "Node Port", and for this we'll just choose 8080. Now, how does this actually work, and how does this get all of this combined into your Kubernetes cluster? Well, the command that you're gonna write when you install the Helm CLI on your machine, if you want to combine this into one chart, you would simply write "helm install" ... ... something like "MyApp", if you're referring to the right folder that you have as the CLI tells you to do. And what Helm will do, is it will actually take the templating chart that you have, look for particular parts where you've defined variables in your configuration, and it will go to that configuration file, use the YAML to find the Nodes that you need, and inject those parameters inside your templating file. Once it's got everything comprised, Helm will send this over to a component that needs to be installed on your Kubernetes cluster called "Tiller". Think of Tiller as basically just the server-side component of Helm, it's going to take the commands you've sent with the Helm client, and turn that into something that your Kubernetes cluster will understand, so that it will say, "OK, take the service, map that there, take the deployment, map that there, and take this database, and map it there." Now, this becomes extra useful when you want to do things like upgrade to a new configuration and rollback. Let's say you're past the holidays and you say, "OK, we can spin this down to where we only need one replica now of this particular deployment." So, rather than taking down the application whole-meal, and then going ahead and redeploying it with the new configuration, you could simply instead type "helm upgrade MyApp". So, you could just replace "install" with "upgrade", and that's how you can use that same syntax. That way, what you would do is, Helm would, again, template everything out, make sure that it works the way you want it to, and get that configuration sent over to Kubernetes so it can manage uptime as being the most important characteristic of your particular stack. Let's say you made a mistake when you were upgrading it, and something that you just changed it to doesn't work. The way to roll that back - you guessed it - is the "Rollback" command. What Helm will also give you is it actually keeps a version history for you of different configurations that you've sent over the wire with Helm, so that you can rollback to the last known working configuration whenever you want to. Lastly, when you're working with these you've talked about, hey, maybe you moved on to a different
team - but maybe other teams need this exact same kind of configuration as well. Well, you can make use of Repos as well and you can actually deploy your charts
into that Repo by typing "helm package" and then using "helm repo index" to send that up to a repository, so anyone in your company can make use of the same chart as well. So, what we've discussed is basically taking a typical scenario, going through it in a fairly understandable way by hard coding your YAML, but, by parameterizing it with Helm, you just make it a little bit easier to manage these packages, and upgrade them when you need to, and make it easier for everyone else on your team to understand it as well. It's currently in the incubation phase of the Cloud-Native Computing Foundation and it's ready for open source, and ready for you to use today. Thank you. If you have questions please drop us a line below. If you want to see more videos like this in the future, please "like" and subscribe, and don't forget, you can always get started on the cloud at no cost by signing up for a free IBM Cloud account.
