Helm Demo: Deploy Node.js & MongoDB
Key Points
- Helm is a Kubernetes package manager that simplifies the deployment of repeatable applications and services across clusters.
- A typical e‑commerce example includes a Node.js app with two high‑availability replicas, a MongoDB backend, and a NodePort service exposing the app on port 8080.
- Without Helm, deploying such a stack requires manually writing multiple YAML manifests for deployments, services, container images, replica counts, and ports.
- Helm packages these manifests into a reusable chart, allowing you to define and deploy the entire application stack with a single command.
Sections
- Helm Overview with E‑commerce Example - David Okun introduces Helm as a Kubernetes package manager and demonstrates its use by deploying a replicated Node.js e‑commerce application with a MongoDB backend and a NodePort service.
- Helm Simplifies Application Configuration Management - The speaker explains how Helm separates a values.yaml configuration file from chart templates, enabling easy, centralized adjustments—such as changing replica counts—without hard‑coding them into individual Kubernetes manifests.
- Helm Templating and Upgrade Process - Helm renders chart templates with values from a YAML file, forwards the rendered manifests to the server‑side component Tiller for deployment on Kubernetes, and provides simple commands such as “helm upgrade” to modify configurations and enable rollbacks.
Full Transcript
# Helm Demo: Deploy Node.js & MongoDB **Source:** [https://www.youtube.com/watch?v=fy8SHvNZGeE](https://www.youtube.com/watch?v=fy8SHvNZGeE) **Duration:** 00:09:06 ## Summary - Helm is a Kubernetes package manager that simplifies the deployment of repeatable applications and services across clusters. - A typical e‑commerce example includes a Node.js app with two high‑availability replicas, a MongoDB backend, and a NodePort service exposing the app on port 8080. - Without Helm, deploying such a stack requires manually writing multiple YAML manifests for deployments, services, container images, replica counts, and ports. - Helm packages these manifests into a reusable chart, allowing you to define and deploy the entire application stack with a single command. ## Sections - [00:00:00](https://www.youtube.com/watch?v=fy8SHvNZGeE&t=0s) **Helm Overview with E‑commerce Example** - David Okun introduces Helm as a Kubernetes package manager and demonstrates its use by deploying a replicated Node.js e‑commerce application with a MongoDB backend and a NodePort service. - [00:03:06](https://www.youtube.com/watch?v=fy8SHvNZGeE&t=186s) **Helm Simplifies Application Configuration Management** - The speaker explains how Helm separates a values.yaml configuration file from chart templates, enabling easy, centralized adjustments—such as changing replica counts—without hard‑coding them into individual Kubernetes manifests. - [00:06:10](https://www.youtube.com/watch?v=fy8SHvNZGeE&t=370s) **Helm Templating and Upgrade Process** - Helm renders chart templates with values from a YAML file, forwards the rendered manifests to the server‑side component Tiller for deployment on Kubernetes, and provides simple commands such as “helm upgrade” to modify configurations and enable rollbacks. ## Full Transcript
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.