Welcome back everybody.
Once you use helm, you can never really go back.
It's, uh.
It's a tool that really simplifies the deployment process.
So if I look at the great submission API or even the great submission portal, in this case, each one
is composed of many configuration files, and having to manage each artifact one by one individually
can get really tedious, really cumbersome, having to deploy each one individually in our cluster.
Um, if I ever want to remove the Great Submission API microservice, uh, keeping track of what all
of its associated artifacts are and deleting those individually, that can get really tedious.
And so what helm allows us to do is combine every closely related artifact into a single unit called
a helm package.
And when I'm ready to deploy, I can simply Release the contents of that helm package, and it will
deploy all of the associated artifacts.
And if I ever want to remove the microservice, for whatever reason, I can simply uninstall my helm
release and it will automatically pull away all of these closely related artifacts and remove them for
me.
So if I look at a diagram, ultimately what it does is it combines all closely related artifacts deployment
service ingress Configmap secrets into a single unit called a helm package.
When I'm ready, I can release the contents of that package and all of the artifacts will get deployed,
the deployment, the service, etc. when I want to remove my microservice, for whatever reason, I
can simply uninstall the helm release, and it will pull away all of the associated artifacts and remove
them for me.
So instead of managing all of these artifacts individually, I can simply manage a single unit called
a helm package, hence the name Helm Package Manager.
Now another really cool thing that helm offers us it.
It allows us to configure all of our objects within a single values.yaml file.
It centralizes the place where all of our values will be.
To give you an example, if I look at the grade submission API deployment, the grade submission, API
service, etc. um, this name field, it repeats itself a lot.
Okay, now if I decide one day to change the microservice name from grade submission API to I don't
know, Great submission back end.
I would need to make that update in many, many different places and this can be really tedious and
error prone.
But with helm, what we do is we convert all our objects into templates, into bare bone skeletons.
And these templates, they all get their values from a centralized values.yaml file.
So if the deployment and the service in this case, if they both get their microservice name from the
same values.yaml file, then I only need to update the microservice name in a single place and that
update will be reflected everywhere else.
So not only does helm simplify the deployment of our artifacts through a single helm package, it also
provides a centralized The place where we can configure all of our Kubernetes objects.
Okay, that's enough theory.
Let's go ahead and implement this.
I am going to copy and paste section ten.
Call this section 11.
All right.
And so I want to start by deleting everything that we deployed in section ten aside from MongoDB.
So kubectl delete.
Now if we had packaged if we had combined everything into a helm package then we could have simply uninstalled
that one helm release.
And it would have removed all of the Kubernetes objects for us.
But in this case, we have to keep track of all of them.
Deployment secret service.
There was an ingress in there as well, and you can already see how tedious this can get, especially
when things become more complex.
Delete everything from the great submission namespace.
And oh, I ended up deleting the MongoDB secret by accident.
So you can already see that when we're having to manage loosely deployed artifacts as opposed to managing
single Kubernetes packages, things can get messy and you can make a lot of mistakes.
In this case, I have to go back and reapply what I had for MongoDB.
So kubectl apply f MongoDB.
All right.
So enough talk.
Let's go ahead and combine everything into helm packages.
So inside of great submission API I'm going to create a templates folder where all of my templates will
go.
And a values file.
Whose Values we're going to inject into every template, as well as a chart dot YAML file, which contains
the metadata that describes what the chart is about.
So I'll say chart API version use version two.
The API version field should be v2 for helm charts that require at least helm three.
Okay, name of the helm chart create submission API.
And we're going to start with version 1.0.0.
Description.
Uh, this is I don't know what to say.
Um, a helm.
Sorry, guys.
It's 3:50 a.m. right now.
I don't know why I'm recording this late, but my brain isn't working the way that it normally does.
A helm chart for deploying the grade submission API.
A back end service We're managing grade data.
All right, um, what do I want to do now?
Oh, now I want to set up all the values that are going to be injected inside of my templates.
So first I like to start with general service details.
So the micro service name grade submission API, the namespace where all my microservice related artifacts
will be deployed, grade submission, and the number of instances of grade submission API instances
that are going to be running.
We'll say two.
Okay, so I like to start with the general service details, because these are values that are most
likely to change between environments or deployments.
And the name field for instance, is something that repeats a lot.
And so instead of changing it Millions of times.
What we can do is strip all of these templates from the name field and have them all reference the microservice
name in our values file.
That way, if I ever want to change the microservice name, I only have to do it in one place and it
reflects everywhere else.
So let's start by removing any instance where the name is being hardcoded, and we're going to reference
the microservice name inside of the values file.
Let me make sure I've spelled everything correctly.
I don't trust myself sometimes, especially not at 4 a.m..
All right.
And instead of saying great submission, I'm going to retrieve the microservice dot namespace from the
values file.
Okay.
Here I'm going to say values dot microservice replicas.
This is the number of instances of my app that I want to have running.
So this is a value that changes a lot depending on how much traffic you expect your app is going to
get.
Instead of drilling into the deployment artifact itself, you can just do it from the centralized place
that has all of our values in a clean format.
Okay.
Um, we'll replace this as well with the dynamic value from our values file.
We can make that change here as well.
Here too.
So here we're injecting the value followed by a static config.
And here as well
Going over to the secret.
We can apply this change here as well.
Here we say dot namespace going over to the config map.
Dot namespace.
Now how can we make sure that all of these values are actually being injected where we need them to?
Well first of all let's see the out of section ten.
By the way, is this big enough?
I would say this is too big.
It makes it hard for me to work with it anyway.
So we'll see the out of section ten CD into section 11.
Clear the output helm template.
No, sorry, I shouldn't be reporting this late.
We see the into the great submission API, the root directory where we have our helm chart set up.
Okay.
Make sure you have the exact same layout as me.
A folder with all the templates in it and at the same level, a chart, YAML and a values.yaml.
If you want to get similar results, then say helm template dot.
If you don't get any errors, then you did everything correctly.
You were able to inject values from your values.yaml file into the templates.
Beautiful.
All right, now let's keep going.
The next thing I want to specify is container specific configurations.
Container specific configurations.
So the image is a value that is likely to change a lot.
We changed images three times throughout this course for the Great Submission API.
We're already at stateless v3.
Okay.
So that's something we want to have in our values file and be able to change it seamlessly here.
Um, the port is something that can be subject to change as we switch from one environment to another.
Um.
The liveness.
So the liveness delay, you'll remember it gives the application time to start up before the liveness
probe attempts to probe a liveness endpoint.
Okay.
And what we set the delay to really depends on how fast our application starts up.
As we update our app.
The startup time might be slower, might be faster.
So we need a convenient place that we can update our liveness delay in.
I think we had it to 15 seconds.
We'll leave it at that.
And um, I guess one thing we can also update are the resources, things that are always subject to
update.
Because again, as you update the app, the amount of memory and CPU that's required might might change
as well.
Let me copy what we have.
128 maybe bytes.
128 Millicores.
I think I'll leave it at that.
Okay.
So we've defined our container specific configurations.
Let's make the updates where we need them.
Or let's inject the values where we need them I should say.
So here instead of hard coding the value let's get it from the values file.
Values dot workload dot image.
All right.
values.workload.org.
So that should replace a lot of them.
Okay.
So if we do ever change the port where the app is serving requests instead of making that change millions
of times we can just do it in the values file.
Okay.
So that's been changed I'm pretty sure the service.
As well.
Oh, I forgot to update the name and namespace over here.
Um, okay, just give me a second.
Let me do it.
Oh, oops.
He's doing that here.
Microservice name, microservice name.
Microservice namespace.
Service has been fully updated.
We don't need to visit that anymore.
The deployment, I believe, is fully updated.
Uh, no it's not.
Values.
Dot workload.
Dot.
I think it was liveness delay.
I don't trust myself.
Let me copy and paste it.
Especially not at this hour.
All right.
Wait a minute.
What is this still doing here?
I remember I had a delay on the readiness probe just for demo purposes.
But ultimately, an initial delay for the readiness probe isn't necessary, because if the application
hasn't started up yet, and if the probe tries to reach the readiness endpoint, it can't.
It will determine that the app isn't ready to serve traffic and block any traffic from reaching the
app, which is exactly what we want it to do.
So, um, having a delay isn't necessary.
Sorry guys.
Should have removed it after I demoed it, but I forgot it doesn't matter anyways, um, the last thing
we want to inject is the memory and CPU.
So workload, dot resources.
Dot memory.
Workload.
Dot resources.
Memory.
Workload.
Dot resources.
Dot CPU
All right.
Now, probing period isn't something I anticipate will change a lot.
A probing period of five seconds is pretty standard, pretty reasonable.
We can leave that the way it is.
I don't think I want to change anything else here.
All right.
Secrets looking good for now.
Configmap looking good for now.
Let's do a quick helm template.
Make sure everything is good.
I have a parse error function.
Workload not defined.
Great submission API deployment.yaml.
Oh, what am I doing
Okay.
Everything is good so far.
All the values are being injected as they should.
Let me remove this comment.
Keep everything clean.
Okay.
The next thing I want to place in the values file are the environment variables.
Just stop doing that.
Uh.
MongoDB host.
Set that to MongoDB.
MongoDB port.
Set that to 27017.
So if I go to great submission API config.
So connection details are things that change pretty often, the MongoDB host refers to the cluster IP
service of the MongoDB app, and a cluster IP service name is something that is very prone to change,
so it follows that we don't hard code it.
Here we reference it from the values file.
A convenient place where we can very easily update it later.
So values dot env dot mongodb host.
And here we say values dot env dot mongodb port.
All right.
And that should be that for the config map.
Now for the secret.
Let me put a comment.
Environment variables.
Now for the secrets I'm going to have a section called secrets for a Sensitive Data.
All right MongoDB user I believe the field was called.
Let's just grab everything from here so that we don't mess it up.
It's the following MongoDB password is the following.
So credentials is something that changes very often as well.
It's actually a very common security practice to change database credentials.
So so we don't want to hard code them inside the secret template.
We want to reference it from the values file and inject it accordingly.
So here we'll say.
Uh dot values dot uh secrets dot MongoDB user
Same thing down here.
Values.
Dot secrets dot MongoDB.
Password.
Okay.
Actually, one more thing I want to do.
You know what?
Let's just wrap it up right here.
We'll say helm template dot get.
So container port.
Everything is good.
I would say.
Service port.
Everything is good.
Fig map.
We're good here as well.
All right.
I think we're ready to package or combine everything into a helm package.
How do we do that?
Making sure that we're at the grade submission API directory.
We're going to say helm package package everything up over here.
Into a helm package.
Note notice the helm package is named what we had in our helm chart metadata followed by the version.
Okay, so if I ever update something in this helm chart like a patch or something, and it becomes version
10.0.1, I can say helm package again.
And now we have another helm package whose contents we can release in our Kubernetes cluster.
Now the contents of both of these packages is identical because I didn't actually make any changes.
So let me delete this, put this back to version 1.0.0.
And now I can release the contents of this helm package by saying helm install.
I'm going to call the helm release that will control all of our Kubernetes objects.
Create submission API and the helm release will be based on the contents that exist inside of the helm
package.
Create submission API 1.0.0.
All right, fingers crossed everything works.
Uh, it's so annoying.
I knew this would happen.
Um, so you see here how I specifically placed the MongoDB port in double quotes.
Now, for some reason, in the config map, it still interprets it as the number 27017.
So what I want to do is reinforce more quotes by saying quotes right over here.
So what this does is it surrounds our value right over here with double quotes, because for some reason
it was injected as a number.
All right.
So now I need to uninstall the helm release helm uninstall, uninstall the Great submission API release
and then have to repackage.
So oh I made a small update right.
So I'm going to call this now version 10.0.1 Helm package.
All right.
What am I doing.
Followed by a dot.
Okay.
Delete this one right over here.
Helm install.
We're going to release the contents of our great submission API package named Great Submission API version
10.0.1.
Beautiful.
By installing a helm release.
You'll notice if you say kubectl get pods dash n great submission.
Our pods were deployed for us kubectl get configmap dash and great submission.
Our configmap was deployed as well.
Kubectl get secrets dash n create submission.
Our secrets was created as well.
Beautiful.
All of them being managed by the helm release.
Now, if I decide I want to remove my great submission API instead of individually removing each, uh,
artifact and potentially removing other artifacts by mistake, you remember how tedious this can get.
All I can do is just say helm uninstall.
Um.
The great submission API, helm release.
And by uninstalling this release, it will automatically remove all of its associated artifacts.
Okay, so if I say kubectl get pods n submission, they're all terminating.
If I say kubectl get deployments n great submission, that should be gone as well.
No resources found.
If I say kubectl get.
Um, I don't know.
Secrets.
Our great submission API secret was also removed, so that's good.
But let me go ahead and reinstall everything.
So we release the contents of our great submission API 10.0.1 package into our Kubernetes cluster kubectl
get pods, dash and great submission.
Make sure the Great submission API is working properly.
It's not ready yet.
Has it yet connected to the MongoDB instance?
Let's give it some time.
Did I remove the delay on the readiness probe?
I did.
Beautiful.
Now all right so we've got the great submission app running.
Um.
All right.
And now this video has actually gone on long enough.
So what I'm going to do is start doing things a lot faster.
Okay.
So let me create a values.yaml file.
So you'll find that once you create one helm chart, it's a very repetitive process.
Okay.
So Values.yaml chart dot YAML.
Uh put every template in a templates folder.
Grab all of this.
Put it over here
So I'm just going to snap my fingers.
And so by snapping my fingers, I just created all of these values behind the scenes and fast forwarded.
So feel free to pause and copy them down.
Okay, same thing for the chart.
Feel free to pause.
Copy it down.
I'll scroll here for the remainder of the description.
Description is really that important.
All right.
And now let's just go ahead and replace everything.
Hey guys it's Rand from the future currently editing this video.
Um, in the next two minutes, I make some silly mistakes copying over the port number as well as the
great service host environment variable.
Um, I end up realizing my mistake in like 2 to 3 minutes and fixing them.
So just wanted to let you know so that as you're copying them now to be wary that I did make a mistake,
and I do end up correcting it later.
All right, back to the video.
Okay.
The reason we're rushing through this is because, um, well, this video has gone on long enough,
and it's a very similar process to what we had earlier.
All we're doing is we're injecting values from a values file.
Okay.
Dot namespace values dot env.
I think I called it great service host deployment.
Let's go ahead and take care of that real quick.
Values that microservice name values dot microservice dot namespace we can use well oops here as well.
Values dot a microservice.
Name values.
Dot workload.
Dot port.
Values.
Dot workload.
Dot image okay.
Values.
Dot workload.
Dot port here as well.
Um dot liveness delay.
It's pretty much all the same fields that we had before.
So I like when things get repetitive just because, uh, it gives a sense of familiarity, um, makes
things a lot less intimidating.
So this was a values dot workload, dot resources, dot memory here values, dot workload, dot resources
dot CPU And here values that workload.
That resources memory.
Values that workload.
Support deployments, the big beasts.
Everything else should be pretty easy.
Values dot Micro-service dot name values dot microservice dot namespace.
So again remember we're doing all of this because you see fields that repeat a lot.
And instead of having to update them millions of times, all of them are referring to a single centralized
value that we only got to change once.
So values dot workload dot port.
Okay.
Values.
Oops.
Is um, let me just copy this over.
Values.
Microservice name used microservice namespace.
We'll copy this over as well.
Values.
Dot.
Microservice dot.
Short.
All right I think we're ready, guys.
All right.
Let's see the other great submission API.
See the integrate submission portal.
Again make sure that you've got this layout.
All right.
Otherwise your home template command is not going to work.
Um.
Okay.
Everything is looking good so far
Great service host isn't resolving to anything but.
Um.
Values.
Uh.
Silly me.
There we go.
All right.
Helm package will package all of these files up.
Successfully packaged chart.
Beautiful.
So we've deployed our great submission API release.
Now let's install the great submission portal release.
We will release the contents of our great submission portal package.
Service create submission portal is invalid port.
Court.
Invalid value zero.
Uh.
Sorry, guys.
Um, I'm gonna have to uninstall the release.
I'm gonna have to repackage everything up.
All right.
It was just re.
You know what?
Let me delete this just so I don't confuse you.
Repackage this and reinstall.
So we'll now we'll release the contents of this updated package and we'll call the helm release create
submission portal.
Wonderful So now we've got a helm release that's managing all the great submission portal artifacts.
So I say kubectl get deployments and great submission.
Wonderful.
We've got a great submission portal, a great submission API.
Unless I messed something up and I didn't put in the right service values or the right service ports,
whatever it is now.
4:22 a.m..
Very possible.
Everything should work fine though, however.
All right.
Wonderful.
Give Harry a score of 55 in potions.
Fingers crossed everything still works.
Beautiful.
I'm going to keep what we've got so far, because we're going to scale it up to the next section, and
I'll see you then.