I'll come back.
Everybody, in the last lesson, you saw how we can combine many application resources and combine them
into a single deployable unit that can be very easily installed, uninstalled or upgraded.
Well, helm goes beyond that because online there are many, many, uh, repositories that contain helm
charts for Elasticsearch.
Uh, MongoDB, MySQL, Prometheus PostgreSQL.
Some of these applications being really, really hard to deploy.
They have so many Kubernetes resources, and manually deploying them one by one would be very tedious,
very error prone, and very hard to manage.
But they all have these helm charts that combine all of the resources into a single unit that can be
very easily installed on our cluster.
In this section, we're going to look at how we can install MongoDB using helm, as opposed to setting
up all of the resources ourselves.
Okay.
And the MongoDB installation using helm is actually going to be a lot more sophisticated and is going
to provide a lot more features that would otherwise require a lot of effort to set up ourselves.
So a little preview of what's to come.
We're still going to be using helm, uh, for the purposes of packaging up our grade submission API
and portal applications.
But, uh, what we need to do is start setting up for section 12.
Okay.
We need to upgrade the helm chart for the grade submission API.
So copy over everything we had in section 11 over to section 12.
And before we cut to the chase, let's play around with some helm commands.
Get you more familiar?
I think that's a bit too zoomed in.
What we can do to list all of the helm releases in our cluster is, say, Helm list dash a okay, and
I've got two helm charts, a great submission API and a great submission to helm releases, both deployed
in the default namespace based on the following chart.
Okay, now, although they've been deployed in the default namespace, their corresponding templates,
they've all been deployed in the great submission namespace.
So the contents of the helm package, they all get released inside of the great submission namespace.
If I say kubectl get pods n great submission there.
They're kubectl and get pod get deployment dash n great submission.
They're all in the great submission namespace.
So all although the helm releases are in the default namespace, all of the application resources that
it's managing get released and great submission.
However, it's good practice to keep everything great submission related enclosed in the great submission
namespace.
There is no reason to have these in the default namespace.
Okay, so what we can do is uninstall the current helm releases.
Helm uninstall creates a mission API version.
I think we can just say greater mission API.
Because this follows that.
Sorry about that guys.
The release name I called Great Submission API.
I remember now how uninstalled great submission portal.
All right.
And what we want to do.
I'm going to CD out of MongoDB CD into great submission API.
Um, just to stay on the side of caution, repackage everything.
Helm package dot.
And now what I want to do is deploy this helm release create submission API that is based on the Great
Submission API version one of our helm chart.
I'm going to deploy that in the namespace.
Great submission.
Nothing should really change because our resources will still get deployed in the same namespace as
before.
But now the helm chart is also in the same namespace, which is ideal.
Then I'll say helm install.
Oh no CD submission API.
Uh CD integrate.
Submission portal.
Helm.
Install.
Grade.
Submission portal.
Based on grade submission portal.
Helm.
Charts.
Okay.
this one right over here.
Hey, we've released the contents of our package.
I made the same mistake.
Remember, we want to deploy the helm chart.
We want to deploy the helm release.
inside of the namespace grid submission.
Okay, now if I say Helm list dash a, here we see a list of all the helm releases, all of them inside
of great submission.
All right.
Beautiful.
So that's another command that you learned.
You're going to learn another one called Helm Upgrade because now what I want to do is CD out of section
11.
And CD into section 12.
All right.
So in the great submission API up there is me.
If I show you the updated code, where is it?
Right over here.
I updated the Great Submission API application to only accept one environment variable the entire MongoDB
URI.
The container doesn't provide this application with this environment variable, then it's just going
to default to using some local host URI.
That doesn't work.
So accordingly we need to change some things around in our helm chart.
So this I packaged up into an image called stateless v4.
I believe this should be the final update of our grade submission API.
So the first thing we got to do is change from v3 to v4.
Okay.
We don't need a config map anymore.
That provides a MongoDB host and port because now the now the host, the port, the username and password,
they're all going to get combined into a single URI.
And that's going to exist inside of the secret.
So we can delete the config map.
Okay.
And now for the secret.
Instead of the data object which expects everything to be base64 encoded, we're going to say string
data.
All right.
And that's going to expect a MongoDB URI.
So everything here Kubernetes will expect to be in plain text.
And we're going to get a value from the values file called MongoDB URI, not base64 encoded plain text.
All right.
Going over here, uh, these are not needed anymore.
The only secret we're going to provide to the great submission API secret, or the only thing we're
going to provide the secret is the MongoDB URI.
And for now we'll just give a default URI.
Let's localhost 27017 okay.
It's not going to work because we're going to be setting up MongoDB officially in the next section.
But as long as we prepare for the next section, that's all I care about.
And now what I want to do is upgrade the grade submission API release based on this new helm chart.
So here's what I can do.
I'm going to make this version two because I didn't necessarily add a new feature.
I just had some things up.
So 1.0.2 is the new version of this helm chart.
And now what I want to do is upgrade the helm release.
So when I package up this new helm chart.
Chart dot YAML is missing.
Oh sorry about that.
Need to be inside of gray submission API.
Try this again.
All right.
Now we've got great submission API 1.0.2.
Uh, based on our updated helm chart.
I can release the contents of this helm package or sorry, I can upgrade the existing release.
So remember, the existing release is great submission API.
I can upgrade the great submission API helm release to be based on the upgraded helm chart version 1.0.2,
and we want to refer to the helm release that's inside of the grade submission namespace.
Okay.
Upgrade it now in the interest of helming around.
Hahaha, what we can do is actually delete the helm package.
I like having the helm package as an extra step.
So let's just say I added another patch to my templates.
Um, I can update.
I can update this to be version 1.0.3 and I can say Helm Upgrade Grade submission API.
I can update the grade submission API release based on the contents of the helm chart inside of the
Great Submission API folder.
So it's going to recognize templates.
It's going to recognize charts YAML, it's going to recognize Values.yaml.
It will implicitly package everything up into a helm package and create a great submission API release.
So we don't need to do that step ourselves.
It can automatically be done for us.
So all we're doing is we're saying look inside of the current directory, see this helm chart, create
a package.
Release the contents of that package under the Helm Release Grade Submission API.
And we want to upgrade the helm release inside of the grade submission namespace.
All right.
Same thing.
Just different ways of accomplishing the same results.
And so version 1.0.3 let's assume it doesn't work.
And we want to go back to a previous revision.
What I can do is roll back.
So I can say helm roll back.
The helm release is great submission API.
And I want to roll back to revision two.
So I can just say two.
Sorry about that.
Dash n great submission.
Remember the helm release is now in the great submission namespace.
Rollback was a success.
Happy helming.
Now I'm going to say helm list dash a.
Alrighty.
I'm going to put this back to 1.0.2.
Only because we didn't add another patch.
We stopped at this version.
Now the great Submission API, its pods shouldn't be ready because they're going to be trying to connect
to MongoDB using this URI.
They're not going to be.
They're not going to be able to.
Okay.
Beautiful.
That's all I wanted.
Create container config error.
That's a bit strange.
Uh kubectl
Describe.
Describe this pod.
Dash n grade submission.
Error config.
Map grade submission API config.
Not found.
Oh, something else I forgot to change.
So config map ref.
We don't need anymore.
We only need to reference a secret All right, you know what?
How about we use that as an excuse to go up to version three?
We'll say helm upgrade.
We'll upgrade the grade submission API release.
And remember, what's beautiful about helm is we don't need to manage these pods individually.
We can manage the entire unit at once.
Upgraded.
Install it, uninstall it as we see fit, upgrade everything based on the existing helm chart and the
current directory.
Dash n grade submission.
All right, we're on revision five.
So I was expecting the grade submission API readiness to not work.
I just wasn't expecting this error.
But that's only because I forgot to remove the config map reference that doesn't exist.
Kubectl get pods n grade submission.
Alright, beautiful.
The containers should be running with the grade submission.
APIs should be having a hard time trying to connect to MongoDB.
That's exactly what I want.
Cube CTL logs, dash, f dash and grade submission retrying.
That's okay.
Now what I want to do is I'm going to delete all the application resources for MongoDB because we're
going to be deploying redeploying MongoDB with many more additional features using helm in another video.
Okay.
So kubectl delete we'll delete the secret MongoDB secret dash n grade submission.
Um, there's another easy delete secret.
Sorry, guys.
Um, okay.
Delete service.
Again, another reason to use helm is instead of managing resources one by one, we have a very simple
MongoDB DB deployment.
But if we were to really inject many, many features into it, then we'd have many more resources and
managing them all manually would be a nightmare.
That's why helm was really a game changer in the Kubernetes world.
Okay, so just like how JavaScript has NPM, how Python has Hip or Anaconda, Kubernetes has its own
package manager helm, that we can very easily use to deploy really complex projects as singular, easily
manageable units.
Okay, so we'll delete the MongoDB service.
And we'll delete the MongoDB Statefulset that what it's called?
Just running ODB.
Okay, so MongoDB is officially gone.
Kubectl get pods dash n.
This is the exact setup we want to have before we move on to the next lesson or the next section, if
you will.
Hope you enjoyed this video.
Hope you had fun helming around with me and I'll see you in the next one.