So helm is the package manager for Kubernetes, just how we use Pip or Anaconda to install packages
in a Python app, or how we use Maven to install packages in a Java app, or how we use npm to manage
packages in a JavaScript app.
We use helm to manage packages in a Kubernetes cluster.
Now, this is immensely useful because think about these powerful and ubiquitous software like Elasticsearch,
MongoDB, MySQL, Redis softwares that are used in almost every enterprise, every tech company.
And yet the deployment and installation of these software is really complex.
There are so many configuration files that need to be accounted for, and all of these resources, they
need to collaborate together in a very sophisticated way.
Well, the nice thing about helm is that there are repositories online that already contain helm charts
for all of these softwares.
They already have all of the configuration files already set up and captured inside of this templates
folder, so you don't have to set anything up yourself.
All you got to do is pull the helm chart, deploy it, and update just some values in the values.yaml
file, just enough to steer the deployment towards one that suits your purposes.
Okay, the nice thing about helm charts is that all of the intricate details about the deployment,
they're all captured and locked away inside of the templates folder.
You don't need to worry about it.
All you got to do is pull the helm chart, update a little bit of values, and suddenly you've deployed
a very powerful software with minimal, minimal effort.
We're going to deploy the helm chart for MongoDB.
You might be thinking, Ryan, we kind of already installed MongoDB using a stateful set, and it wasn't
that hard.
While this helm chart contains many, many, many more features, it's much more stable, much more
scalable, and much more easily manageable because we can control everything from one values.yaml file
and all of the resources that we have.
We can treat as a single deployable and manageable unit.
So ideally, we want to leverage the MongoDB helm chart instead of setting up and managing all of these
configuration files independently.
Also, considering that our deployment is very minimal, whereas this helm chart deployment will be
very feature rich, but all of the complexities are abstracted away.
Okay, so very excited for that.
And now the way it works is usually you have your helm charts in a repository, a very popular repository
is Bitnami because it contains helm charts for Elasticsearch, MongoDB, Redis, MySQL and basically
what you can do is add this repository to your local helm configuration.
And basically what this allows you to do is be able to deploy all of the helm charts.
That's pretty much it.
Uh, we're mainly going to add this repo to our local helm configuration and deploy the MongoDB helm
chart.
We're not going to bother with the other ones because once you deploy one helm chart, it's pretty much
the same thing you helm install, update the values file, the thing gets deployed.
All right.
Let me zoom in a little bit.
So let me make sure I'm CD into the correct folder.
Section 12.
Remember the one that we set up in the last lesson.
Now before I do anything there is one thing I want to take care of um, we've been switching in and
out of using helm, and what I've noticed in my cluster is I had some resources being packaged by helm
and some other resources that were kind of just loose and hanging around in my cluster.
So before anything, I want to do one final cleanup to make sure that we're starting from a fresh start.
Okay.
So I'm going to delete every possible resource that we've deployed in this course.
So configmap secret, just so that we start managing everything under one helm release instead of having
loose resources in our cluster.
So we'll delete the Configmap, the secret, the service deployment.
I don't know, maybe there's an auto scaler in there somewhere.
HPA Statefulset pv PVC pods delete everything first in the default namespace Not stateful.
Stateful set.
Okay, I don't think I had anything except what Kubernetes deploys for you automatically.
And don't worry, those won't get deleted.
They'll come back.
So if you had anything other than this.
Um, those will get deleted, but the default stuff won't.
Let's redo this, but not for the default namespace for the great submission namespace.
All right.
A lot of stuff gets deleted.
All right, let me press cancel.
Press this again.
Um.
All right.
Good enough.
Now I'll uninstall the helm charts.
Helm, uh.
Or I'll uninstall the helm releases.
Helm.
Uninstall.
Um, there's a great submission API release and the grade submission namespace.
Really?
Did I delete it?
Uh.
Helm list.
A.
Helm.
Oh, I must have deleted all my helm stuff.
Already?
Okay.
Interesting.
Let me check to make sure there's nothing in the default namespace.
Okay.
Nothing in the default namespace for great submission API.
There is no helm charts.
Interesting.
So if I say kubectl get pods n great submission, I've got nothing.
Cool.
Off to a clean start.
Let me make sure there's nothing in the MongoDB namespace.
Get pods n MongoDB.
Nothing there as well.
Let's say kubectl get all dash n And MongoDB.
Okay, beautiful.
Off to a fresh start.
Um, the first thing I want to do is I want to stress that if we can manage, uh, a lot of resources
using helm instead of having standalone resources deployed separately, we would much rather use the
helm approach.
All right.
And now let's just deploy these helm charts in the namespace that they belong.
So helm install or let me CD integrate submission portal first.
Helm.
We don't need to package them up.
Uh, before the installation.
We can just do that within the command.
So, helm, install a great submission portal release from the helm chart that exists inside of the
great Submission portal folder.
So automatically it will package everything up and release the contents of that package, and we want
the helm chart to be installed inside of the grade submission namespace.
All right.
So that's it for the grade submission portal.
We do the same thing for the grade submission API.
I'm going to say helm or CD out of this.
See the Integrate Submission API.
Clear that helm install the grade submission API release based on the helm chart that exists inside
the current directory.
The helm chart will be packaged.
Its contents will be released within grade submission namespace.
All right.
Kubectl get pods dash n grade submission.
Everything works beautifully.
Two great submission API pods that are running but aren't ready because they're trying to connect to
a MongoDB instance that doesn't exist, and a great submission portal pod that's running.
Let's test out the great Submission Portal pod.
Make sure everything works.
There is me breaking the fourth wall.
Um, we'll say local host, not 5001.
We're using local host 80.
Okay, wonderful.
API is not working.
But if you go ahead and say helm list dash A, you should have two helm releases, both inside the same
namespace.
Let's get to work.
So this is where the real fun starts.
And I prepared a checklist to guide this lesson just so that I don't get too excited and mess things
up.
So first reminder was to CD into MongoDB.
CD into that folder.
All right.
The second thing I want to do is add the repository that contains all of these helm charts into my local
helm configuration.
So helm repo add.
All right.
Once you say helm repo, add the repo we want to add is Bitnami.
And the repository that contains all of the charts created by the Bitnami team can be accessed at the
following URL.
You could have obtained this URL from the web.
I just happened to memorize it.
Okay, I already had this repository added for you.
A different message should show, but because I already have a repositories set up, what I'm going
to do is say helm repo update.
What that's going to do is grab the latest from my chart repos and make sure that they make sure that
they're up to date.
Okay, so now I've added this repository full of helm charts into my local helm configuration, which
means I now have access to these helm charts.
Helm charts and am able to deploy them into my Kubernetes cluster.
Which helm charts do I have access to?
Specifically, let me say Helm search.
Lets search the repository for all the charts that it gives us access to.
Let me zoom out a little bit.
All right.
So already we see some pretty interesting ones.
We see Redis RabbitMQ PyTorch, Prometheus PostgreSQL.
That's pretty cool.
Uh nginx ingress.
We could have deployed that as a helm chart.
Um, MySQL MongoDB the one we're going to be using in this video.
Um, Kibana, a visualization tool for Elasticsearch.
Whereas Elasticsearch o Grafana, a visualization tool for Prometheus Fluentd Elasticsearch.
Pretty, pretty cool stuff.
So by adding the Bitnami repo, we get access to all of these helm charts and are able to deploy them
in our Kubernetes cluster as we see fit.
Okay, now I want to show you something.
If you write Bitnami charts and look them up on GitHub, this is where they update all of their helm
charts.
You can see that they this is a very active repository.
You have some charts that were updated just an hour ago of me recording this video, some updated 16
hours ago.
I'm curious to when they last updated the MongoDB one.
Okay.
Uh, where is it?
MongoDB.
Yesterday.
Pretty.
Pretty cool stuff.
Pretty active community.
Um, what I'm going to do is search up all the helm chart versions specifically for MongoDB.
So if you look up here, this is the latest chart version of each software, if you will.
Uh, the latest one for MongoDB is 15 .6.3, which is the one we're going to be using in this video.
So doesn't matter what your latest one is.
For consistency, use the same version as me.
But if I say um, helm search repo this time I'm going to refine my search to be specific to the MongoDB
helm charts.
Okay.
And I want to view all of the versions for MongoDB, not just the latest one we see starting from 5.09.
Um, oh, not MongoDB.
Sharded MongoDB, that's the one we're going to use.
Starts at 5.09, ends at 15.60 .13.
Okay Cool.
And now how are we going to deploy this helm chart.
So you'll remember let me click on this.
Where is it.
It's so little hard to see.
Oh there you go.
So MongoDB.
So this is very similar to the helm charts that we created for our applications.
You've got a templates folder that abstracts away all of the configuration files that are needed to
set everything up that are needed to deploy MongoDB.
And you've got a values.yaml file whose values get injected into the templates.
Okay.
Now most of these values we're not going to touch.
Most of these default values are fine.
Um, they're very, very well commented.
I actually took the liberty of reading all of these comments and seeing how each field is described
in order to know exactly what I need to change for this lesson in order to set up a proper deployment.
So usually when you're leveraging these helm packages, you want to take the time to read all the fields
that you're able to modify according to whatever deployment that you want to accomplish.
Okay.
Um, most default values in here should be fine.
Now, if for some reason you can't find the GitHub repo and read what the helm chart has to offer,
what you can do is say helm show values.
I want to refine my search to just the MongoDB helm chart, the latest one in this case, and now and
whatever values it outputs for the following, I want to output it to a default values dot YAML file.
Okay, so here I extract a default values.yaml file that shows me.
All of the default values that are being used in this helm chart.
And now what I'm going to do is create a values dot YAML file.
This will contain all of the default values.
This will contain all of the values that I want to override for my helm deployment.
I can go ahead and delete all of this.
I don't need it anymore.
We're not going to be setting up ourselves.
We're going to be leveraging a helm chart.
And now, upon reading the default values, there are a few things I want to change.
All right.
So there was a field called use Statefulset I'm going to set that to true.
Otherwise it's going to use a deployment to set up our MongoDB instance.
We want to use a stateful set to make sure that each pod replica is has a unique name, has its own
storage allocated to it.
Okay, so the first value I'm going to override is use stateful set and set that to true.
So whatever values we write here, they will override whatever default values are already present not
affecting the other ones.
Um, for authentication by default it's set to true.
I'm going to override that to be false.
Auth enabled false.
Just to keep things simple at first.
And another thing that I needed to change in this helm chart.
If I say service followed by the following.
So remember I already read all of this.
So I know what to change and not to change.
So service by default it's of type cluster IP.
Perfect.
So the MongoDB instance is going to be given a cluster IP service port name MongoDB ports MongoDB at
port 27017.
So I don't need to change that.
Everything seems to be pretty good.
I'm satisfied with what all of these values seem to accomplish upon being injected into their corresponding
configuration files within the templates folder.
I don't think there's anything else that I want to change for now.
So what I can do is install this helm chart.
I'm going to install the helm chart version.
Where is it?
Version 15.6 .13, which is going to have all of these default values.
But I'm going to install it in a way where it considers the values that I'm overriding inside of my
values.yaml file.
So over here I'm going to say helm.
Install the helm release is MongoDB.
Okay.
Nothing changes there.
I'm installing a helm release based on the helm chart.
Bitnami MongoDB version 15.60 .13.
All right, so just like how we created helm releases based on our local helm charts within the Great
Submission API folder or the Great Submission Portal folder.
Now we're creating a helm release based on the helm chart within the Bitnami repository, the one that's
version 15.60 .13.
Then I'm going to say dash f for file this helm chart.
I want it to be created while considering the values that I have inside of my values.yaml file.
So it has all of these default values that it's going to use to set up the configuration.
But it's also consider but it's also going to consider that I want to override the field use stateful
set to be true.
And I want to override authentication to be disabled.
Okay.
And finally I want to deploy this inside of the MongoDB namespace.
Installation failed.
Expected at most two arguments.
Unexpected arguments Values.yaml.
Interesting.
Okay, I'm not sure what I did different between the first command and this one.
So you can feel free to have a look yourself.
Helm install MongoDB.
Oh, I didn't separate these two.
Okay, whatever.
So now we have deployed MongoDB using helm.
Can you look at the difference between what we had to do here and what we had to do here.
We don't actually need this default values.yaml.
I just left it there for reference.
I'll be deleting it shortly, but pretty cool how we deployed MongoDB without setting up a single configuration
file ourselves.
We just overrode some values in order to steer the deployment according to something that we want.
So we should have a MongoDB instances being managed by a stateful set.
You can also modify how many instances you want to run.
I'm sure there's a field there somewhere.
I forgot where it was.
But anyways, the default is just one instance.
Uh, let's say kubectl get pods dash n MongoDB.
We've got one MongoDB instance being managed by a stateful set.
I'll address this error in a bit.
If you're using a windows computer or a mac that doesn't use Apple Silicon, you shouldn't get this
error.
If you, unfortunately have a mac that uses Apple Silicon.
So MacBook, M1, M2, or whatever.
I'll address this in a bit.
Just bear with me.
So kubectl get statefulset dash n MongoDB.
Beautiful.
So we get this stateful set.
We get this pod, uh, for free.
All we had to do was change a couple of really, really minimal fields.
Now what I want to teach you is that in Kubernetes, even if we're using helm, nothing ever just installs
seamlessly.
You're going to get bugs, you're going to get weird errors that are unexpected.
The trick is not to panic.
Describe the pod.
See what that error is?
Describe whatever resource.
See what the error is.
Go online.
Other people struggled with it as well.
Read the threads on Stack Overflow on the GitHub issues, and try to figure out what the problem is
and determine a solution.
Okay, so I'm going to do that for you right?
I obviously already did this before the video started, but let's pretend that I'm doing it right now
in front of you live.
So kubectl describe pod.
We're going to describe MongoDB zero in the namespace MongoDB.
And we get an image.
Pull back off pulling image bitnami MongoDB Debian r 12.
And no matching manifest for Linux ARM 64.
All right.
So unfortunately the MongoDB helm charts being managed By, uh, bitnami their, their image, their
MongoDB image that they themselves created.
Um, it's not compatible with Arm64.
Okay.
So if you look inside of the default values.yaml file, let's look at image.
This image right over here is no good.
Okay.
Let me take you to Docker Hub.
So what I'm talking about all of these were compiled to work with the Linux Amd64 architecture.
If you're using a MacBook, M1, M2, or whatever, you need these images to be compatible with ARM.
So what we can do is we can override the image field such that we're not using this default image,
but we force the Bitnami helm chart to use a MongoDB image that's actually compatible with both AMD
and with ARM.
Okay, now you might be wondering, and you're a genius to be able to figure it out like that.
I wasn't initially sure what the problem is.
I mean, the error message is pretty descriptive, but just like anybody else, I went through the process
of troubleshooting and seeing if other people had the same problem.
So I went on GitHub issues, I went on StackOverflow, and I found this comment right over here that,
uh, validated my doubts.
And their solution was to force the Bitnami Mongo helm chart.
Force is a strong word.
In this case, we're overriding the image field to use the official Mongo image that's actually compatible
with both platforms.
Okay, so if I go and I look up mongo We'll look up the image that that individual specifically outlined
for just for the sake of it.
So 6.04.4.
Jamie, you can see that this image is compatible with amd64 arm64.
So it should work with Mac and with windows on most machines.
All right.
So what I'll do is I'm going to copy these values over.
All right.
Registry IO.
So we're so we're still going to be grabbing the image from Docker Hub.
But in this case the repository is actually Mongo okay.
Not Bitnami slash MongoDB.
And the tag is 6.04 Jamie there are other Mongo versions that are also compatible with Amd64 and Arm64.
Just going to use this one.
Okay.
Because it seems like it's right in front of us.
And now another thing we want to do that was outlined is set the persistence such that the persistent
volume gets mounted at slash data slash debe.
You'll remember that we did that inside of the stateful set section.
Now let's go ahead and look at what the default value is for that.
So if I look up persistence.
Um mount path uh it's bitnami slash MongoDB.
But we're not using the Bitnami MongoDB software anymore.
We're using the standard MongoDB application which you learned, which I showed you saves all of its
data by default to the local directory slash data slash DB.
So we need to You update this variable accordingly.
That way when that value gets injected into what probably is going to be the stateful set resource,
the persistent volume is mounted to the right local directory within the container.
So what we need to do is under persistence followed by a mount path.
Change this slash data slash debe.
Okay.
So now let's go ahead and helm uninstall what we have currently.
I don't think we need this anymore.
But all things considered it's pretty cool how we're able to install MongoDB so easily just by defining
a few values.
So helm uninstall I'm pretty sure I called the release MongoDB.
I'm going to uninstall this release that exists inside of the MongoDB namespace.
Now I'm going to reinstall it.
Using this updated Values.yaml.
All right.
Now we'll say kubectl get pods dash n MongoDB pods being managed by the statefulset.
At least now it's running.
It's not ready yet.
Beautiful.
That's a good sign.
So by forcing the helm chart to use this image that's compatible with both platforms, it was able to
seamlessly get everything up and running.
It's going to require some time.
Um, be back in a few minutes.
I'll fill up my cup of water.
Okay, there we go.
And now finally, kubectl get pods dash n gray submission.
So we've got these great submission APIs that are so desperate to connect to an instance of MongoDB.
But this time the MongoDB instance lives inside of a different namespace.
How is the connection going to work?
And so the question is how do you connect to a service that exists in a different namespace.
Because when the service when when you add a cluster IP service in the same namespace, all the great
submission API had to do is say, um, the service name followed by the port number, right?
Port number.
But when the service exists in a different namespace and you want a pod to communicate with that service,
then what you need to specify is a service name followed by the service namespace.
The namespace that that service is in, followed by the following static string service dot cluster,
dot local and then followed by the port number, which in this case is 27017.
So what I'm going to do is say kubectl get services dash n MongoDB.
All right.
The service name is MongoDB.
The service namespace is MongoDB.
And this is what we're going to use to connect to our cluster IP service.
So if we go back to the values.yaml file for the grade submission API instead of localhost 27017, we
say MongoDB.
The service name followed by the namespace followed by this status string.
That's going to allow us to connect to the service, followed by the port where the service is responding
to requests.
Ultimately, that's going to send everything over to MongoDB, which is going to be able to handle URIs
of this scheme and create the connection that our great submission API is so desperate for.
Now, you'll remember before that we usually we had credentials over here.
Um, the thing is, in this case, our MongoDB isn't expecting any credentials, so we don't have to
include it in the URI.
And that should be enough.
Um, I'm going to keep authentication disabled.
Okay.
Uh, just to keep the lesson focused on all the right things.
Now I'm going to CD into the great submission API.
Let's uninstall the helm release.
So helm uninstall I have a helm release called Great Submission API.
Yours might be named something different.
Uh.
Darn it.
And great submission.
Okay.
Helm release should be uninstalled now.
Now I'm going to reinstall it.
Helm install.
Great submission API.
Uh.
And great submission.
Installation name.
Oh, sorry.
Install the helm release based on the following helm chart that exists inside of this folder.
Beautiful.
I'm going to give it a couple of minutes for all the connections to take place
Okay.
Hey, guys, my computer just shut down.
Um, anyways, whatever.
I had to restart my Docker engine, and I forgot where we were.
I expect that by the time I edit this video, there's going to be a lot of video glitches that you would
have realized by now.
But anyways, kubectl get pods dash n great submission.
All the great submission APIs are currently running.
They're ready if yours for some reason don't work.
Mine restarted quite a bit for whatever reason.
Uh, probably due to a lack of resources.
And if resourcing is the issue, what you can do is open up your Docker dashboard.
If you're using windows, it should be on your bottom right toolbar.
Once you open up your Docker dashboard, you can go to the settings uh menu.
Go to resources.
You can allocate more resources to your cluster.
Okay.
We've seen how we can leverage helm to install helm charts and deploy things very seamlessly.
But I want to take things a step further and show you how we can install things using operators.
Okay.
So I don't want to spend too much time on this one helm package, which we're going to decommission
in the next section.
So I'll see you in the next section where we where we discuss operators.
And I hope you enjoyed this one.
All right.
You know what?
Before we wrap up, I wouldn't hurt to test what we've got so far.
So localhost 80.
Uh, we'll give Harry a score of 95 in potions.
Everything works seamlessly.
You got the great submission portal talking to the API, which is able to save grades to MongoDB.
Okay, that's it for this section.
See you in the next one.