What is Helm?

What is Helm?


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 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 beginning 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 two
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 gonna 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 dot 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 spend 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 in its 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 dot YAML file. The way we could change that is we could
say replicas are instead gonna be managed by values dot deployment dot
replicas, I’ll shorten it but you understand you just write it out after that.
So that way this is gonna say okay we’re gonna refer to the Values dot Deployment
dot 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 what does it keep that hard-code
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 Mongo 1. 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 dot
Service dot Type, and you can change this to say Values dot Service dot 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
server-side component of Helm, it’s gonna 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 okay 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 okay 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 go ahead
and you know redeploying it with the new configuration you could simply instead type Helm Upgrade MyApp. So you could say replace Upgrade with Install
or replace Installed 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’re 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.

3 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *