WEBVTT

00:00.200 --> 00:01.670
Welcome back everybody.

00:01.700 --> 00:05.270
Once you use helm, you can never really go back.

00:05.630 --> 00:06.530
It's, uh.

00:06.530 --> 00:10.700
It's a tool that really simplifies the deployment process.

00:10.730 --> 00:16.820
So if I look at the great submission API or even the great submission portal, in this case, each one

00:16.820 --> 00:24.980
is composed of many configuration files, and having to manage each artifact one by one individually

00:24.980 --> 00:31.640
can get really tedious, really cumbersome, having to deploy each one individually in our cluster.

00:31.940 --> 00:37.910
Um, if I ever want to remove the Great Submission API microservice, uh, keeping track of what all

00:37.940 --> 00:43.850
of its associated artifacts are and deleting those individually, that can get really tedious.

00:44.690 --> 00:54.770
And so what helm allows us to do is combine every closely related artifact into a single unit called

00:54.770 --> 00:56.210
a helm package.

00:56.210 --> 01:04.200
And when I'm ready to deploy, I can simply Release the contents of that helm package, and it will

01:04.200 --> 01:07.620
deploy all of the associated artifacts.

01:07.770 --> 01:14.700
And if I ever want to remove the microservice, for whatever reason, I can simply uninstall my helm

01:14.700 --> 01:22.320
release and it will automatically pull away all of these closely related artifacts and remove them for

01:22.320 --> 01:22.800
me.

01:22.800 --> 01:33.180
So if I look at a diagram, ultimately what it does is it combines all closely related artifacts deployment

01:33.180 --> 01:40.470
service ingress Configmap secrets into a single unit called a helm package.

01:40.500 --> 01:48.990
When I'm ready, I can release the contents of that package and all of the artifacts will get deployed,

01:48.990 --> 01:57.630
the deployment, the service, etc. when I want to remove my microservice, for whatever reason, I

01:57.630 --> 02:05.610
can simply uninstall the helm release, and it will pull away all of the associated artifacts and remove

02:05.610 --> 02:06.630
them for me.

02:06.630 --> 02:15.060
So instead of managing all of these artifacts individually, I can simply manage a single unit called

02:15.060 --> 02:19.800
a helm package, hence the name Helm Package Manager.

02:19.830 --> 02:23.370
Now another really cool thing that helm offers us it.

02:23.400 --> 02:31.260
It allows us to configure all of our objects within a single values.yaml file.

02:31.260 --> 02:36.240
It centralizes the place where all of our values will be.

02:36.330 --> 02:42.990
To give you an example, if I look at the grade submission API deployment, the grade submission, API

02:43.020 --> 02:50.040
service, etc. um, this name field, it repeats itself a lot.

02:50.070 --> 02:58.950
Okay, now if I decide one day to change the microservice name from grade submission API to I don't

02:58.980 --> 03:01.000
know, Great submission back end.

03:01.090 --> 03:08.800
I would need to make that update in many, many different places and this can be really tedious and

03:08.830 --> 03:09.970
error prone.

03:10.180 --> 03:20.890
But with helm, what we do is we convert all our objects into templates, into bare bone skeletons.

03:20.890 --> 03:28.630
And these templates, they all get their values from a centralized values.yaml file.

03:28.630 --> 03:38.020
So if the deployment and the service in this case, if they both get their microservice name from the

03:38.020 --> 03:45.880
same values.yaml file, then I only need to update the microservice name in a single place and that

03:45.880 --> 03:48.430
update will be reflected everywhere else.

03:48.460 --> 03:56.170
So not only does helm simplify the deployment of our artifacts through a single helm package, it also

03:56.170 --> 04:03.350
provides a centralized The place where we can configure all of our Kubernetes objects.

04:03.530 --> 04:05.720
Okay, that's enough theory.

04:05.720 --> 04:07.760
Let's go ahead and implement this.

04:08.690 --> 04:12.770
I am going to copy and paste section ten.

04:13.790 --> 04:16.010
Call this section 11.

04:17.930 --> 04:18.920
All right.

04:19.010 --> 04:26.120
And so I want to start by deleting everything that we deployed in section ten aside from MongoDB.

04:27.050 --> 04:29.300
So kubectl delete.

04:29.390 --> 04:37.250
Now if we had packaged if we had combined everything into a helm package then we could have simply uninstalled

04:37.250 --> 04:38.810
that one helm release.

04:38.810 --> 04:42.860
And it would have removed all of the Kubernetes objects for us.

04:42.860 --> 04:46.520
But in this case, we have to keep track of all of them.

04:46.550 --> 04:50.270
Deployment secret service.

04:50.300 --> 04:57.440
There was an ingress in there as well, and you can already see how tedious this can get, especially

04:57.440 --> 04:59.480
when things become more complex.

04:59.690 --> 05:02.870
Delete everything from the great submission namespace.

05:02.870 --> 05:07.820
And oh, I ended up deleting the MongoDB secret by accident.

05:07.820 --> 05:16.850
So you can already see that when we're having to manage loosely deployed artifacts as opposed to managing

05:16.850 --> 05:22.820
single Kubernetes packages, things can get messy and you can make a lot of mistakes.

05:22.820 --> 05:27.740
In this case, I have to go back and reapply what I had for MongoDB.

05:27.740 --> 05:30.470
So kubectl apply f MongoDB.

05:32.450 --> 05:33.530
All right.

05:34.100 --> 05:35.450
So enough talk.

05:35.450 --> 05:39.950
Let's go ahead and combine everything into helm packages.

05:39.950 --> 05:48.350
So inside of great submission API I'm going to create a templates folder where all of my templates will

05:48.350 --> 05:49.100
go.

05:51.170 --> 05:53.600
And a values file.

05:56.330 --> 06:05.220
Whose Values we're going to inject into every template, as well as a chart dot YAML file, which contains

06:05.220 --> 06:08.910
the metadata that describes what the chart is about.

06:09.060 --> 06:14.010
So I'll say chart API version use version two.

06:14.280 --> 06:18.870
The API version field should be v2 for helm charts that require at least helm three.

06:18.900 --> 06:22.290
Okay, name of the helm chart create submission API.

06:22.290 --> 06:25.410
And we're going to start with version 1.0.0.

06:25.560 --> 06:26.850
Description.

06:27.900 --> 06:31.740
Uh, this is I don't know what to say.

06:33.300 --> 06:36.630
Um, a helm.

06:38.100 --> 06:38.850
Sorry, guys.

06:38.850 --> 06:40.710
It's 3:50 a.m. right now.

06:40.710 --> 06:46.890
I don't know why I'm recording this late, but my brain isn't working the way that it normally does.

06:47.040 --> 06:52.500
A helm chart for deploying the grade submission API.

06:53.070 --> 07:00.180
A back end service We're managing grade data.

07:00.630 --> 07:04.680
All right, um, what do I want to do now?

07:04.800 --> 07:11.790
Oh, now I want to set up all the values that are going to be injected inside of my templates.

07:11.790 --> 07:15.930
So first I like to start with general service details.

07:15.930 --> 07:24.990
So the micro service name grade submission API, the namespace where all my microservice related artifacts

07:24.990 --> 07:32.250
will be deployed, grade submission, and the number of instances of grade submission API instances

07:32.250 --> 07:33.540
that are going to be running.

07:33.570 --> 07:34.860
We'll say two.

07:35.490 --> 07:44.340
Okay, so I like to start with the general service details, because these are values that are most

07:44.340 --> 07:48.540
likely to change between environments or deployments.

07:48.540 --> 07:53.490
And the name field for instance, is something that repeats a lot.

07:53.490 --> 07:57.640
And so instead of changing it Millions of times.

07:57.640 --> 08:07.870
What we can do is strip all of these templates from the name field and have them all reference the microservice

08:08.050 --> 08:09.580
name in our values file.

08:09.610 --> 08:15.160
That way, if I ever want to change the microservice name, I only have to do it in one place and it

08:15.160 --> 08:16.810
reflects everywhere else.

08:16.840 --> 08:24.340
So let's start by removing any instance where the name is being hardcoded, and we're going to reference

08:24.340 --> 08:29.500
the microservice name inside of the values file.

08:29.530 --> 08:31.570
Let me make sure I've spelled everything correctly.

08:31.570 --> 08:35.560
I don't trust myself sometimes, especially not at 4 a.m..

08:37.300 --> 08:38.080
All right.

08:38.080 --> 08:45.910
And instead of saying great submission, I'm going to retrieve the microservice dot namespace from the

08:45.910 --> 08:47.230
values file.

08:47.980 --> 08:48.850
Okay.

08:50.170 --> 08:57.230
Here I'm going to say values dot microservice replicas.

08:57.260 --> 09:03.110
This is the number of instances of my app that I want to have running.

09:03.470 --> 09:10.790
So this is a value that changes a lot depending on how much traffic you expect your app is going to

09:10.790 --> 09:11.480
get.

09:11.510 --> 09:18.230
Instead of drilling into the deployment artifact itself, you can just do it from the centralized place

09:18.230 --> 09:21.380
that has all of our values in a clean format.

09:21.560 --> 09:22.370
Okay.

09:23.150 --> 09:35.840
Um, we'll replace this as well with the dynamic value from our values file.

09:35.840 --> 09:38.330
We can make that change here as well.

09:41.420 --> 09:41.990
Here too.

09:42.020 --> 09:46.520
So here we're injecting the value followed by a static config.

09:52.520 --> 09:53.840
And here as well

09:56.840 --> 09:58.910
Going over to the secret.

09:58.940 --> 10:01.280
We can apply this change here as well.

10:01.370 --> 10:07.340
Here we say dot namespace going over to the config map.

10:09.530 --> 10:11.330
Dot namespace.

10:11.660 --> 10:19.400
Now how can we make sure that all of these values are actually being injected where we need them to?

10:20.180 --> 10:22.370
Well first of all let's see the out of section ten.

10:22.400 --> 10:23.900
By the way, is this big enough?

10:25.310 --> 10:26.990
I would say this is too big.

10:27.320 --> 10:29.390
It makes it hard for me to work with it anyway.

10:29.390 --> 10:34.040
So we'll see the out of section ten CD into section 11.

10:34.340 --> 10:37.550
Clear the output helm template.

10:37.580 --> 10:41.630
No, sorry, I shouldn't be reporting this late.

10:41.630 --> 10:49.310
We see the into the great submission API, the root directory where we have our helm chart set up.

10:49.340 --> 10:49.730
Okay.

10:49.760 --> 10:52.730
Make sure you have the exact same layout as me.

10:52.760 --> 10:58.800
A folder with all the templates in it and at the same level, a chart, YAML and a values.yaml.

10:58.800 --> 11:03.960
If you want to get similar results, then say helm template dot.

11:03.990 --> 11:07.050
If you don't get any errors, then you did everything correctly.

11:07.080 --> 11:16.950
You were able to inject values from your values.yaml file into the templates.

11:17.670 --> 11:18.690
Beautiful.

11:19.650 --> 11:21.600
All right, now let's keep going.

11:21.630 --> 11:27.180
The next thing I want to specify is container specific configurations.

11:27.180 --> 11:30.630
Container specific configurations.

11:30.690 --> 11:34.530
So the image is a value that is likely to change a lot.

11:34.560 --> 11:39.570
We changed images three times throughout this course for the Great Submission API.

11:39.600 --> 11:41.880
We're already at stateless v3.

11:42.600 --> 11:43.170
Okay.

11:43.170 --> 11:48.390
So that's something we want to have in our values file and be able to change it seamlessly here.

11:49.080 --> 11:56.890
Um, the port is something that can be subject to change as we switch from one environment to another.

11:57.160 --> 11:58.090
Um.

11:58.420 --> 12:00.010
The liveness.

12:02.200 --> 12:08.440
So the liveness delay, you'll remember it gives the application time to start up before the liveness

12:08.440 --> 12:11.950
probe attempts to probe a liveness endpoint.

12:11.980 --> 12:12.730
Okay.

12:12.850 --> 12:20.230
And what we set the delay to really depends on how fast our application starts up.

12:20.230 --> 12:22.000
As we update our app.

12:22.000 --> 12:24.940
The startup time might be slower, might be faster.

12:24.940 --> 12:31.120
So we need a convenient place that we can update our liveness delay in.

12:31.120 --> 12:33.460
I think we had it to 15 seconds.

12:33.460 --> 12:34.960
We'll leave it at that.

12:35.500 --> 12:45.880
And um, I guess one thing we can also update are the resources, things that are always subject to

12:45.880 --> 12:46.180
update.

12:46.180 --> 12:52.480
Because again, as you update the app, the amount of memory and CPU that's required might might change

12:52.480 --> 12:53.140
as well.

12:53.170 --> 12:55.330
Let me copy what we have.

13:00.160 --> 13:02.170
128 maybe bytes.

13:02.200 --> 13:04.120
128 Millicores.

13:04.960 --> 13:06.670
I think I'll leave it at that.

13:06.700 --> 13:07.330
Okay.

13:07.330 --> 13:10.030
So we've defined our container specific configurations.

13:10.030 --> 13:12.970
Let's make the updates where we need them.

13:13.090 --> 13:16.000
Or let's inject the values where we need them I should say.

13:16.570 --> 13:21.490
So here instead of hard coding the value let's get it from the values file.

13:21.520 --> 13:28.810
Values dot workload dot image.

13:31.180 --> 13:31.930
All right.

13:31.960 --> 13:33.910
values.workload.org.

13:33.910 --> 13:35.680
So that should replace a lot of them.

13:35.710 --> 13:35.920
Okay.

13:35.950 --> 13:43.990
So if we do ever change the port where the app is serving requests instead of making that change millions

13:43.990 --> 13:47.200
of times we can just do it in the values file.

13:47.230 --> 13:48.010
Okay.

13:49.240 --> 13:54.680
So that's been changed I'm pretty sure the service.

13:56.990 --> 13:57.890
As well.

13:59.270 --> 14:04.070
Oh, I forgot to update the name and namespace over here.

14:04.550 --> 14:07.430
Um, okay, just give me a second.

14:10.580 --> 14:11.180
Let me do it.

14:11.210 --> 14:11.990
Oh, oops.

14:11.990 --> 14:13.970
He's doing that here.

14:13.970 --> 14:16.520
Microservice name, microservice name.

14:16.520 --> 14:19.280
Microservice namespace.

14:19.490 --> 14:21.200
Service has been fully updated.

14:21.230 --> 14:23.450
We don't need to visit that anymore.

14:24.140 --> 14:27.740
The deployment, I believe, is fully updated.

14:30.470 --> 14:32.180
Uh, no it's not.

14:32.630 --> 14:33.890
Values.

14:33.920 --> 14:35.090
Dot workload.

14:35.120 --> 14:35.840
Dot.

14:36.050 --> 14:38.270
I think it was liveness delay.

14:39.020 --> 14:39.950
I don't trust myself.

14:39.950 --> 14:41.060
Let me copy and paste it.

14:41.090 --> 14:42.920
Especially not at this hour.

14:43.880 --> 14:45.110
All right.

14:46.280 --> 14:47.060
Wait a minute.

14:47.060 --> 14:48.890
What is this still doing here?

14:49.880 --> 14:55.370
I remember I had a delay on the readiness probe just for demo purposes.

14:55.760 --> 15:01.640
But ultimately, an initial delay for the readiness probe isn't necessary, because if the application

15:01.640 --> 15:06.770
hasn't started up yet, and if the probe tries to reach the readiness endpoint, it can't.

15:06.800 --> 15:11.630
It will determine that the app isn't ready to serve traffic and block any traffic from reaching the

15:11.630 --> 15:13.550
app, which is exactly what we want it to do.

15:13.550 --> 15:17.720
So, um, having a delay isn't necessary.

15:17.720 --> 15:18.770
Sorry guys.

15:18.770 --> 15:27.440
Should have removed it after I demoed it, but I forgot it doesn't matter anyways, um, the last thing

15:27.470 --> 15:32.960
we want to inject is the memory and CPU.

15:32.960 --> 15:34.640
So workload, dot resources.

15:34.640 --> 15:35.570
Dot memory.

15:37.640 --> 15:39.290
Workload.

15:39.320 --> 15:41.000
Dot resources.

15:41.060 --> 15:42.170
Memory.

15:43.790 --> 15:44.360
Workload.

15:44.360 --> 15:45.320
Dot resources.

15:45.320 --> 15:46.430
Dot CPU

15:55.530 --> 15:56.370
All right.

15:57.030 --> 16:04.170
Now, probing period isn't something I anticipate will change a lot.

16:04.200 --> 16:08.850
A probing period of five seconds is pretty standard, pretty reasonable.

16:08.880 --> 16:11.130
We can leave that the way it is.

16:11.310 --> 16:14.790
I don't think I want to change anything else here.

16:17.160 --> 16:17.760
All right.

16:17.790 --> 16:21.180
Secrets looking good for now.

16:21.180 --> 16:23.070
Configmap looking good for now.

16:23.070 --> 16:24.750
Let's do a quick helm template.

16:24.780 --> 16:26.040
Make sure everything is good.

16:29.100 --> 16:30.930
I have a parse error function.

16:30.930 --> 16:34.080
Workload not defined.

16:34.080 --> 16:37.200
Great submission API deployment.yaml.

16:40.350 --> 16:41.820
Oh, what am I doing

16:51.220 --> 16:52.000
Okay.

16:55.180 --> 16:55.480
Okay.

16:55.600 --> 16:57.880
Everything is good so far.

17:01.150 --> 17:03.910
All the values are being injected as they should.

17:03.940 --> 17:05.710
Let me remove this comment.

17:06.910 --> 17:08.470
Keep everything clean.

17:11.230 --> 17:12.100
Okay.

17:12.850 --> 17:19.870
The next thing I want to place in the values file are the environment variables.

17:22.330 --> 17:23.860
Just stop doing that.

17:23.890 --> 17:24.220
Uh.

17:26.620 --> 17:28.690
MongoDB host.

17:29.710 --> 17:31.120
Set that to MongoDB.

17:33.670 --> 17:36.490
MongoDB port.

17:37.600 --> 17:42.550
Set that to 27017.

17:43.060 --> 17:46.270
So if I go to great submission API config.

17:47.380 --> 17:54.130
So connection details are things that change pretty often, the MongoDB host refers to the cluster IP

17:54.130 --> 18:01.480
service of the MongoDB app, and a cluster IP service name is something that is very prone to change,

18:01.480 --> 18:03.580
so it follows that we don't hard code it.

18:03.580 --> 18:06.340
Here we reference it from the values file.

18:06.370 --> 18:09.580
A convenient place where we can very easily update it later.

18:09.580 --> 18:15.100
So values dot env dot mongodb host.

18:15.820 --> 18:22.900
And here we say values dot env dot mongodb port.

18:25.240 --> 18:26.410
All right.

18:28.450 --> 18:32.020
And that should be that for the config map.

18:32.050 --> 18:33.760
Now for the secret.

18:35.260 --> 18:36.550
Let me put a comment.

18:37.030 --> 18:39.910
Environment variables.

18:40.930 --> 18:48.190
Now for the secrets I'm going to have a section called secrets for a Sensitive Data.

18:49.450 --> 18:54.770
All right MongoDB user I believe the field was called.

18:55.340 --> 19:00.020
Let's just grab everything from here so that we don't mess it up.

19:05.300 --> 19:11.420
It's the following MongoDB password is the following.

19:13.490 --> 19:19.250
So credentials is something that changes very often as well.

19:19.250 --> 19:23.480
It's actually a very common security practice to change database credentials.

19:23.480 --> 19:27.770
So so we don't want to hard code them inside the secret template.

19:27.770 --> 19:32.390
We want to reference it from the values file and inject it accordingly.

19:32.390 --> 19:34.760
So here we'll say.

19:38.000 --> 19:46.100
Uh dot values dot uh secrets dot MongoDB user

19:53.250 --> 19:55.350
Same thing down here.

19:59.790 --> 20:00.210
Values.

20:00.210 --> 20:02.520
Dot secrets dot MongoDB.

20:02.550 --> 20:03.570
Password.

20:04.680 --> 20:05.400
Okay.

20:06.000 --> 20:08.130
Actually, one more thing I want to do.

20:08.880 --> 20:09.780
You know what?

20:09.840 --> 20:11.910
Let's just wrap it up right here.

20:12.570 --> 20:18.900
We'll say helm template dot get.

20:20.280 --> 20:22.980
So container port.

20:24.000 --> 20:25.440
Everything is good.

20:25.470 --> 20:26.550
I would say.

20:30.720 --> 20:31.980
Service port.

20:31.980 --> 20:33.450
Everything is good.

20:35.340 --> 20:36.060
Fig map.

20:36.060 --> 20:37.560
We're good here as well.

20:39.600 --> 20:40.950
All right.

20:40.950 --> 20:48.180
I think we're ready to package or combine everything into a helm package.

20:48.210 --> 20:49.590
How do we do that?

20:49.770 --> 20:52.620
Making sure that we're at the grade submission API directory.

20:52.650 --> 20:57.270
We're going to say helm package package everything up over here.

20:59.790 --> 21:01.140
Into a helm package.

21:01.170 --> 21:09.810
Note notice the helm package is named what we had in our helm chart metadata followed by the version.

21:10.020 --> 21:17.100
Okay, so if I ever update something in this helm chart like a patch or something, and it becomes version

21:17.100 --> 21:21.450
10.0.1, I can say helm package again.

21:23.040 --> 21:28.380
And now we have another helm package whose contents we can release in our Kubernetes cluster.

21:28.410 --> 21:33.450
Now the contents of both of these packages is identical because I didn't actually make any changes.

21:33.450 --> 21:40.350
So let me delete this, put this back to version 1.0.0.

21:40.350 --> 21:45.390
And now I can release the contents of this helm package by saying helm install.

21:45.420 --> 21:51.580
I'm going to call the helm release that will control all of our Kubernetes objects.

21:51.610 --> 21:59.980
Create submission API and the helm release will be based on the contents that exist inside of the helm

21:59.980 --> 22:00.520
package.

22:00.520 --> 22:04.360
Create submission API 1.0.0.

22:04.570 --> 22:07.450
All right, fingers crossed everything works.

22:09.820 --> 22:11.530
Uh, it's so annoying.

22:12.130 --> 22:13.570
I knew this would happen.

22:14.200 --> 22:22.570
Um, so you see here how I specifically placed the MongoDB port in double quotes.

22:23.020 --> 22:31.000
Now, for some reason, in the config map, it still interprets it as the number 27017.

22:31.090 --> 22:38.500
So what I want to do is reinforce more quotes by saying quotes right over here.

22:38.500 --> 22:46.300
So what this does is it surrounds our value right over here with double quotes, because for some reason

22:46.300 --> 22:48.820
it was injected as a number.

22:49.660 --> 22:50.650
All right.

22:51.790 --> 23:00.940
So now I need to uninstall the helm release helm uninstall, uninstall the Great submission API release

23:02.830 --> 23:06.850
and then have to repackage.

23:06.880 --> 23:10.210
So oh I made a small update right.

23:10.270 --> 23:17.200
So I'm going to call this now version 10.0.1 Helm package.

23:17.740 --> 23:18.100
All right.

23:18.550 --> 23:19.300
What am I doing.

23:19.330 --> 23:21.310
Followed by a dot.

23:22.660 --> 23:23.260
Okay.

23:23.290 --> 23:25.330
Delete this one right over here.

23:27.880 --> 23:29.920
Helm install.

23:30.310 --> 23:40.270
We're going to release the contents of our great submission API package named Great Submission API version

23:40.270 --> 23:42.010
10.0.1.

23:44.500 --> 23:45.490
Beautiful.

23:45.700 --> 23:48.410
By installing a helm release.

23:48.440 --> 23:53.480
You'll notice if you say kubectl get pods dash n great submission.

23:55.130 --> 24:02.210
Our pods were deployed for us kubectl get configmap dash and great submission.

24:04.220 --> 24:07.190
Our configmap was deployed as well.

24:07.580 --> 24:12.620
Kubectl get secrets dash n create submission.

24:14.180 --> 24:16.880
Our secrets was created as well.

24:16.910 --> 24:17.840
Beautiful.

24:17.840 --> 24:21.440
All of them being managed by the helm release.

24:21.470 --> 24:31.790
Now, if I decide I want to remove my great submission API instead of individually removing each, uh,

24:31.790 --> 24:39.350
artifact and potentially removing other artifacts by mistake, you remember how tedious this can get.

24:39.380 --> 24:43.190
All I can do is just say helm uninstall.

24:44.780 --> 24:45.170
Um.

24:45.170 --> 24:47.850
The great submission API, helm release.

24:50.430 --> 24:56.220
And by uninstalling this release, it will automatically remove all of its associated artifacts.

24:56.250 --> 25:02.880
Okay, so if I say kubectl get pods n submission, they're all terminating.

25:02.880 --> 25:10.410
If I say kubectl get deployments n great submission, that should be gone as well.

25:14.190 --> 25:15.750
No resources found.

25:15.750 --> 25:17.940
If I say kubectl get.

25:17.970 --> 25:20.970
Um, I don't know.

25:20.970 --> 25:22.050
Secrets.

25:23.820 --> 25:27.600
Our great submission API secret was also removed, so that's good.

25:27.630 --> 25:31.680
But let me go ahead and reinstall everything.

25:33.870 --> 25:44.670
So we release the contents of our great submission API 10.0.1 package into our Kubernetes cluster kubectl

25:44.670 --> 25:46.770
get pods, dash and great submission.

25:46.770 --> 25:50.040
Make sure the Great submission API is working properly.

25:50.070 --> 25:51.570
It's not ready yet.

25:51.600 --> 25:54.000
Has it yet connected to the MongoDB instance?

25:54.000 --> 25:55.320
Let's give it some time.

25:55.350 --> 25:59.580
Did I remove the delay on the readiness probe?

26:00.720 --> 26:01.740
I did.

26:01.830 --> 26:02.790
Beautiful.

26:05.100 --> 26:10.260
Now all right so we've got the great submission app running.

26:11.640 --> 26:12.240
Um.

26:12.270 --> 26:12.990
All right.

26:12.990 --> 26:15.540
And now this video has actually gone on long enough.

26:15.540 --> 26:18.540
So what I'm going to do is start doing things a lot faster.

26:18.570 --> 26:18.780
Okay.

26:18.810 --> 26:21.270
So let me create a values.yaml file.

26:21.270 --> 26:26.820
So you'll find that once you create one helm chart, it's a very repetitive process.

26:26.850 --> 26:27.570
Okay.

26:27.570 --> 26:32.220
So Values.yaml chart dot YAML.

26:33.720 --> 26:36.990
Uh put every template in a templates folder.

26:39.300 --> 26:41.040
Grab all of this.

26:41.070 --> 26:42.570
Put it over here

26:45.580 --> 26:47.650
So I'm just going to snap my fingers.

26:47.650 --> 26:55.120
And so by snapping my fingers, I just created all of these values behind the scenes and fast forwarded.

26:55.120 --> 26:59.290
So feel free to pause and copy them down.

27:00.070 --> 27:03.520
Okay, same thing for the chart.

27:03.520 --> 27:05.080
Feel free to pause.

27:05.140 --> 27:06.670
Copy it down.

27:07.360 --> 27:10.090
I'll scroll here for the remainder of the description.

27:10.090 --> 27:12.310
Description is really that important.

27:13.720 --> 27:14.650
All right.

27:16.330 --> 27:19.420
And now let's just go ahead and replace everything.

27:19.450 --> 27:22.900
Hey guys it's Rand from the future currently editing this video.

27:23.350 --> 27:31.330
Um, in the next two minutes, I make some silly mistakes copying over the port number as well as the

27:31.330 --> 27:34.060
great service host environment variable.

27:34.720 --> 27:39.370
Um, I end up realizing my mistake in like 2 to 3 minutes and fixing them.

27:39.370 --> 27:46.040
So just wanted to let you know so that as you're copying them now to be wary that I did make a mistake,

27:46.040 --> 27:48.050
and I do end up correcting it later.

27:48.080 --> 27:49.880
All right, back to the video.

27:51.260 --> 27:52.070
Okay.

27:52.100 --> 27:59.870
The reason we're rushing through this is because, um, well, this video has gone on long enough,

27:59.870 --> 28:03.320
and it's a very similar process to what we had earlier.

28:03.350 --> 28:07.310
All we're doing is we're injecting values from a values file.

28:07.340 --> 28:08.030
Okay.

28:08.330 --> 28:12.980
Dot namespace values dot env.

28:13.010 --> 28:17.780
I think I called it great service host deployment.

28:17.810 --> 28:20.990
Let's go ahead and take care of that real quick.

28:23.150 --> 28:40.250
Values that microservice name values dot microservice dot namespace we can use well oops here as well.

28:43.460 --> 28:44.690
Values dot a microservice.

28:44.990 --> 28:46.490
Name values.

28:47.000 --> 28:49.430
Dot workload.

28:49.460 --> 28:51.410
Dot port.

28:53.540 --> 28:54.140
Values.

28:54.140 --> 28:55.190
Dot workload.

28:55.220 --> 28:59.000
Dot image okay.

29:00.710 --> 29:01.910
Values.

29:01.910 --> 29:03.290
Dot workload.

29:03.290 --> 29:05.030
Dot port here as well.

29:06.500 --> 29:12.440
Um dot liveness delay.

29:13.490 --> 29:16.190
It's pretty much all the same fields that we had before.

29:16.340 --> 29:26.720
So I like when things get repetitive just because, uh, it gives a sense of familiarity, um, makes

29:26.720 --> 29:28.130
things a lot less intimidating.

29:28.130 --> 29:40.970
So this was a values dot workload, dot resources, dot memory here values, dot workload, dot resources

29:41.000 --> 29:45.990
dot CPU And here values that workload.

29:46.020 --> 29:48.390
That resources memory.

29:50.820 --> 29:51.870
Values that workload.

29:51.930 --> 29:55.470
Support deployments, the big beasts.

29:55.470 --> 29:57.450
Everything else should be pretty easy.

29:58.500 --> 30:07.860
Values dot Micro-service dot name values dot microservice dot namespace.

30:11.010 --> 30:16.680
So again remember we're doing all of this because you see fields that repeat a lot.

30:16.680 --> 30:23.310
And instead of having to update them millions of times, all of them are referring to a single centralized

30:23.310 --> 30:25.770
value that we only got to change once.

30:25.890 --> 30:33.210
So values dot workload dot port.

30:35.520 --> 30:36.420
Okay.

30:38.640 --> 30:39.600
Values.

30:39.630 --> 30:39.930
Oops.

30:39.930 --> 30:42.930
Is um, let me just copy this over.

30:44.460 --> 30:45.240
Values.

30:45.480 --> 30:50.970
Microservice name used microservice namespace.

30:52.470 --> 30:54.720
We'll copy this over as well.

30:55.860 --> 30:56.340
Values.

30:56.340 --> 30:56.580
Dot.

30:56.580 --> 30:57.930
Microservice dot.

30:57.930 --> 30:58.920
Short.

31:06.810 --> 31:10.980
All right I think we're ready, guys.

31:15.660 --> 31:16.500
All right.

31:16.710 --> 31:18.780
Let's see the other great submission API.

31:19.320 --> 31:21.360
See the integrate submission portal.

31:21.390 --> 31:23.820
Again make sure that you've got this layout.

31:23.850 --> 31:24.480
All right.

31:24.510 --> 31:28.230
Otherwise your home template command is not going to work.

31:28.320 --> 31:29.430
Um.

31:36.060 --> 31:36.900
Okay.

31:37.170 --> 31:39.060
Everything is looking good so far

31:42.400 --> 31:46.900
Great service host isn't resolving to anything but.

31:50.920 --> 31:51.760
Um.

31:54.010 --> 31:55.330
Values.

31:55.390 --> 31:55.780
Uh.

31:55.810 --> 31:56.920
Silly me.

32:03.490 --> 32:04.330
There we go.

32:05.170 --> 32:06.160
All right.

32:06.250 --> 32:10.810
Helm package will package all of these files up.

32:11.980 --> 32:13.990
Successfully packaged chart.

32:13.990 --> 32:15.130
Beautiful.

32:15.130 --> 32:19.090
So we've deployed our great submission API release.

32:19.120 --> 32:24.970
Now let's install the great submission portal release.

32:26.950 --> 32:32.170
We will release the contents of our great submission portal package.

32:38.080 --> 32:42.010
Service create submission portal is invalid port.

32:42.010 --> 32:42.050
Court.

32:42.050 --> 32:44.600
Invalid value zero.

32:48.500 --> 32:48.860
Uh.

32:51.020 --> 32:52.730
Sorry, guys.

32:55.880 --> 33:02.600
Um, I'm gonna have to uninstall the release.

33:04.940 --> 33:07.490
I'm gonna have to repackage everything up.

33:08.840 --> 33:09.830
All right.

33:13.370 --> 33:14.270
It was just re.

33:14.300 --> 33:14.810
You know what?

33:14.810 --> 33:17.540
Let me delete this just so I don't confuse you.

33:18.680 --> 33:23.810
Repackage this and reinstall.

33:24.380 --> 33:30.080
So we'll now we'll release the contents of this updated package and we'll call the helm release create

33:30.080 --> 33:31.400
submission portal.

33:39.470 --> 33:47.390
Wonderful So now we've got a helm release that's managing all the great submission portal artifacts.

33:48.320 --> 33:52.490
So I say kubectl get deployments and great submission.

33:55.070 --> 33:55.880
Wonderful.

33:55.910 --> 33:58.700
We've got a great submission portal, a great submission API.

33:58.730 --> 34:06.170
Unless I messed something up and I didn't put in the right service values or the right service ports,

34:06.200 --> 34:08.300
whatever it is now.

34:08.300 --> 34:09.620
4:22 a.m..

34:09.650 --> 34:10.910
Very possible.

34:11.300 --> 34:13.850
Everything should work fine though, however.

34:14.810 --> 34:15.920
All right.

34:25.820 --> 34:26.600
Wonderful.

34:27.320 --> 34:30.860
Give Harry a score of 55 in potions.

34:31.130 --> 34:33.830
Fingers crossed everything still works.

34:33.830 --> 34:34.940
Beautiful.

34:34.970 --> 34:40.370
I'm going to keep what we've got so far, because we're going to scale it up to the next section, and

34:40.370 --> 34:41.360
I'll see you then.