WEBVTT 00:00.050 --> 00:08.030 So helm is the package manager for Kubernetes, just how we use Pip or Anaconda to install packages 00:08.030 --> 00:16.370 in a Python app, or how we use Maven to install packages in a Java app, or how we use npm to manage 00:16.370 --> 00:18.320 packages in a JavaScript app. 00:19.400 --> 00:23.540 We use helm to manage packages in a Kubernetes cluster. 00:23.570 --> 00:32.300 Now, this is immensely useful because think about these powerful and ubiquitous software like Elasticsearch, 00:32.300 --> 00:40.940 MongoDB, MySQL, Redis softwares that are used in almost every enterprise, every tech company. 00:40.940 --> 00:45.890 And yet the deployment and installation of these software is really complex. 00:45.890 --> 00:52.520 There are so many configuration files that need to be accounted for, and all of these resources, they 00:52.520 --> 00:56.390 need to collaborate together in a very sophisticated way. 00:56.540 --> 01:03.710 Well, the nice thing about helm is that there are repositories online that already contain helm charts 01:03.710 --> 01:05.390 for all of these softwares. 01:05.390 --> 01:12.230 They already have all of the configuration files already set up and captured inside of this templates 01:12.230 --> 01:16.070 folder, so you don't have to set anything up yourself. 01:16.100 --> 01:24.380 All you got to do is pull the helm chart, deploy it, and update just some values in the values.yaml 01:24.380 --> 01:30.380 file, just enough to steer the deployment towards one that suits your purposes. 01:30.410 --> 01:37.100 Okay, the nice thing about helm charts is that all of the intricate details about the deployment, 01:37.100 --> 01:41.720 they're all captured and locked away inside of the templates folder. 01:41.720 --> 01:43.370 You don't need to worry about it. 01:43.370 --> 01:49.400 All you got to do is pull the helm chart, update a little bit of values, and suddenly you've deployed 01:49.400 --> 01:53.660 a very powerful software with minimal, minimal effort. 01:53.660 --> 01:56.120 We're going to deploy the helm chart for MongoDB. 01:56.150 --> 02:00.920 You might be thinking, Ryan, we kind of already installed MongoDB using a stateful set, and it wasn't 02:00.920 --> 02:01.520 that hard. 02:01.520 --> 02:08.600 While this helm chart contains many, many, many more features, it's much more stable, much more 02:08.600 --> 02:16.130 scalable, and much more easily manageable because we can control everything from one values.yaml file 02:16.130 --> 02:19.850 and all of the resources that we have. 02:19.850 --> 02:23.900 We can treat as a single deployable and manageable unit. 02:23.900 --> 02:31.670 So ideally, we want to leverage the MongoDB helm chart instead of setting up and managing all of these 02:31.670 --> 02:34.130 configuration files independently. 02:34.130 --> 02:41.510 Also, considering that our deployment is very minimal, whereas this helm chart deployment will be 02:41.510 --> 02:46.220 very feature rich, but all of the complexities are abstracted away. 02:46.250 --> 02:49.250 Okay, so very excited for that. 02:49.820 --> 02:58.390 And now the way it works is usually you have your helm charts in a repository, a very popular repository 02:58.390 --> 03:06.190 is Bitnami because it contains helm charts for Elasticsearch, MongoDB, Redis, MySQL and basically 03:06.190 --> 03:11.620 what you can do is add this repository to your local helm configuration. 03:11.740 --> 03:17.200 And basically what this allows you to do is be able to deploy all of the helm charts. 03:17.200 --> 03:19.810 That's pretty much it. 03:20.140 --> 03:27.460 Uh, we're mainly going to add this repo to our local helm configuration and deploy the MongoDB helm 03:27.460 --> 03:28.090 chart. 03:28.120 --> 03:33.970 We're not going to bother with the other ones because once you deploy one helm chart, it's pretty much 03:33.970 --> 03:39.880 the same thing you helm install, update the values file, the thing gets deployed. 03:39.910 --> 03:40.870 All right. 03:41.740 --> 03:43.150 Let me zoom in a little bit. 03:43.300 --> 03:46.420 So let me make sure I'm CD into the correct folder. 03:46.420 --> 03:47.170 Section 12. 03:47.170 --> 03:50.710 Remember the one that we set up in the last lesson. 03:50.740 --> 03:59.590 Now before I do anything there is one thing I want to take care of um, we've been switching in and 03:59.620 --> 04:07.000 out of using helm, and what I've noticed in my cluster is I had some resources being packaged by helm 04:07.000 --> 04:11.440 and some other resources that were kind of just loose and hanging around in my cluster. 04:11.500 --> 04:18.280 So before anything, I want to do one final cleanup to make sure that we're starting from a fresh start. 04:18.310 --> 04:18.880 Okay. 04:18.880 --> 04:22.810 So I'm going to delete every possible resource that we've deployed in this course. 04:22.810 --> 04:31.960 So configmap secret, just so that we start managing everything under one helm release instead of having 04:31.960 --> 04:33.730 loose resources in our cluster. 04:33.730 --> 04:39.880 So we'll delete the Configmap, the secret, the service deployment. 04:40.090 --> 04:42.370 I don't know, maybe there's an auto scaler in there somewhere. 04:42.400 --> 04:56.200 HPA Statefulset pv PVC pods delete everything first in the default namespace Not stateful. 04:56.230 --> 04:57.490 Stateful set. 04:59.950 --> 05:06.310 Okay, I don't think I had anything except what Kubernetes deploys for you automatically. 05:06.310 --> 05:08.950 And don't worry, those won't get deleted. 05:08.950 --> 05:09.550 They'll come back. 05:09.550 --> 05:12.730 So if you had anything other than this. 05:13.000 --> 05:17.050 Um, those will get deleted, but the default stuff won't. 05:17.080 --> 05:22.720 Let's redo this, but not for the default namespace for the great submission namespace. 05:23.980 --> 05:25.120 All right. 05:26.110 --> 05:28.690 A lot of stuff gets deleted. 05:30.370 --> 05:34.750 All right, let me press cancel. 05:34.780 --> 05:36.580 Press this again. 05:38.080 --> 05:38.830 Um. 05:39.850 --> 05:41.020 All right. 05:41.290 --> 05:42.190 Good enough. 05:42.190 --> 05:44.560 Now I'll uninstall the helm charts. 05:44.680 --> 05:47.140 Helm, uh. 05:47.140 --> 05:48.970 Or I'll uninstall the helm releases. 05:48.970 --> 05:49.450 Helm. 05:49.480 --> 05:50.650 Uninstall. 05:51.160 --> 05:57.220 Um, there's a great submission API release and the grade submission namespace. 06:00.340 --> 06:01.210 Really? 06:02.020 --> 06:03.520 Did I delete it? 06:04.570 --> 06:05.140 Uh. 06:05.290 --> 06:06.400 Helm list. 06:06.790 --> 06:07.450 A. 06:10.210 --> 06:10.840 Helm. 06:10.930 --> 06:16.540 Oh, I must have deleted all my helm stuff. 06:21.430 --> 06:21.820 Already? 06:21.820 --> 06:22.420 Okay. 06:22.450 --> 06:23.470 Interesting. 06:24.550 --> 06:27.790 Let me check to make sure there's nothing in the default namespace. 06:28.240 --> 06:28.780 Okay. 06:28.810 --> 06:31.750 Nothing in the default namespace for great submission API. 06:31.780 --> 06:33.430 There is no helm charts. 06:33.460 --> 06:34.030 Interesting. 06:34.030 --> 06:41.680 So if I say kubectl get pods n great submission, I've got nothing. 06:41.710 --> 06:42.310 Cool. 06:42.340 --> 06:43.570 Off to a clean start. 06:43.600 --> 06:46.060 Let me make sure there's nothing in the MongoDB namespace. 06:46.090 --> 06:48.130 Get pods n MongoDB. 06:48.490 --> 06:49.870 Nothing there as well. 06:49.870 --> 06:53.970 Let's say kubectl get all dash n And MongoDB. 06:54.750 --> 06:56.160 Okay, beautiful. 06:56.190 --> 06:57.840 Off to a fresh start. 06:58.710 --> 07:06.690 Um, the first thing I want to do is I want to stress that if we can manage, uh, a lot of resources 07:06.690 --> 07:13.860 using helm instead of having standalone resources deployed separately, we would much rather use the 07:13.860 --> 07:15.240 helm approach. 07:15.300 --> 07:15.660 All right. 07:15.690 --> 07:18.930 And now let's just deploy these helm charts in the namespace that they belong. 07:18.930 --> 07:26.760 So helm install or let me CD integrate submission portal first. 07:26.790 --> 07:27.840 Helm. 07:27.870 --> 07:31.410 We don't need to package them up. 07:32.820 --> 07:34.350 Uh, before the installation. 07:34.350 --> 07:36.360 We can just do that within the command. 07:36.390 --> 07:46.350 So, helm, install a great submission portal release from the helm chart that exists inside of the 07:46.350 --> 07:48.210 great Submission portal folder. 07:48.210 --> 07:54.270 So automatically it will package everything up and release the contents of that package, and we want 07:54.270 --> 07:58.290 the helm chart to be installed inside of the grade submission namespace. 07:58.620 --> 07:59.760 All right. 07:59.910 --> 08:02.550 So that's it for the grade submission portal. 08:02.550 --> 08:05.640 We do the same thing for the grade submission API. 08:05.910 --> 08:08.850 I'm going to say helm or CD out of this. 08:08.880 --> 08:11.040 See the Integrate Submission API. 08:11.070 --> 08:21.570 Clear that helm install the grade submission API release based on the helm chart that exists inside 08:21.570 --> 08:23.100 the current directory. 08:24.300 --> 08:25.770 The helm chart will be packaged. 08:25.770 --> 08:32.430 Its contents will be released within grade submission namespace. 08:33.300 --> 08:34.020 All right. 08:34.110 --> 08:38.880 Kubectl get pods dash n grade submission. 08:39.990 --> 08:42.630 Everything works beautifully. 08:42.750 --> 08:49.230 Two great submission API pods that are running but aren't ready because they're trying to connect to 08:49.260 --> 08:55.890 a MongoDB instance that doesn't exist, and a great submission portal pod that's running. 08:55.890 --> 08:58.200 Let's test out the great Submission Portal pod. 08:58.230 --> 09:00.120 Make sure everything works. 09:00.120 --> 09:02.640 There is me breaking the fourth wall. 09:03.180 --> 09:10.710 Um, we'll say local host, not 5001. 09:10.740 --> 09:13.200 We're using local host 80. 09:13.230 --> 09:15.240 Okay, wonderful. 09:15.270 --> 09:16.710 API is not working. 09:16.710 --> 09:24.330 But if you go ahead and say helm list dash A, you should have two helm releases, both inside the same 09:24.330 --> 09:25.200 namespace. 09:25.230 --> 09:26.250 Let's get to work. 09:26.250 --> 09:28.290 So this is where the real fun starts. 09:28.290 --> 09:34.320 And I prepared a checklist to guide this lesson just so that I don't get too excited and mess things 09:34.320 --> 09:34.920 up. 09:34.920 --> 09:38.250 So first reminder was to CD into MongoDB. 09:40.200 --> 09:41.970 CD into that folder. 09:42.000 --> 09:43.260 All right. 09:45.240 --> 09:53.590 The second thing I want to do is add the repository that contains all of these helm charts into my local 09:53.620 --> 09:54.970 helm configuration. 09:54.970 --> 09:58.450 So helm repo add. 09:59.170 --> 09:59.980 All right. 10:00.010 --> 10:05.110 Once you say helm repo, add the repo we want to add is Bitnami. 10:05.530 --> 10:13.960 And the repository that contains all of the charts created by the Bitnami team can be accessed at the 10:13.960 --> 10:15.250 following URL. 10:15.340 --> 10:17.500 You could have obtained this URL from the web. 10:17.500 --> 10:19.210 I just happened to memorize it. 10:19.240 --> 10:25.510 Okay, I already had this repository added for you. 10:25.510 --> 10:31.900 A different message should show, but because I already have a repositories set up, what I'm going 10:31.930 --> 10:35.410 to do is say helm repo update. 10:35.530 --> 10:41.800 What that's going to do is grab the latest from my chart repos and make sure that they make sure that 10:41.800 --> 10:43.000 they're up to date. 10:43.180 --> 10:51.500 Okay, so now I've added this repository full of helm charts into my local helm configuration, which 10:51.500 --> 10:54.680 means I now have access to these helm charts. 10:55.040 --> 10:59.690 Helm charts and am able to deploy them into my Kubernetes cluster. 10:59.780 --> 11:01.910 Which helm charts do I have access to? 11:01.940 --> 11:05.900 Specifically, let me say Helm search. 11:05.900 --> 11:11.750 Lets search the repository for all the charts that it gives us access to. 11:13.700 --> 11:15.320 Let me zoom out a little bit. 11:15.830 --> 11:16.730 All right. 11:16.730 --> 11:19.910 So already we see some pretty interesting ones. 11:19.910 --> 11:26.390 We see Redis RabbitMQ PyTorch, Prometheus PostgreSQL. 11:26.420 --> 11:27.950 That's pretty cool. 11:27.950 --> 11:30.200 Uh nginx ingress. 11:30.200 --> 11:32.660 We could have deployed that as a helm chart. 11:32.720 --> 11:39.050 Um, MySQL MongoDB the one we're going to be using in this video. 11:39.860 --> 11:44.540 Um, Kibana, a visualization tool for Elasticsearch. 11:44.570 --> 11:52.970 Whereas Elasticsearch o Grafana, a visualization tool for Prometheus Fluentd Elasticsearch. 11:53.000 --> 11:55.310 Pretty, pretty cool stuff. 11:55.400 --> 12:02.420 So by adding the Bitnami repo, we get access to all of these helm charts and are able to deploy them 12:02.420 --> 12:06.050 in our Kubernetes cluster as we see fit. 12:06.470 --> 12:10.310 Okay, now I want to show you something. 12:10.310 --> 12:18.440 If you write Bitnami charts and look them up on GitHub, this is where they update all of their helm 12:18.440 --> 12:19.190 charts. 12:19.190 --> 12:23.240 You can see that they this is a very active repository. 12:23.270 --> 12:29.850 You have some charts that were updated just an hour ago of me recording this video, some updated 16 12:29.850 --> 12:30.350 hours ago. 12:30.380 --> 12:33.560 I'm curious to when they last updated the MongoDB one. 12:34.010 --> 12:34.790 Okay. 12:34.790 --> 12:35.960 Uh, where is it? 12:35.990 --> 12:36.860 MongoDB. 12:37.370 --> 12:38.510 Yesterday. 12:38.540 --> 12:38.960 Pretty. 12:38.960 --> 12:39.830 Pretty cool stuff. 12:39.830 --> 12:41.690 Pretty active community. 12:42.140 --> 12:50.300 Um, what I'm going to do is search up all the helm chart versions specifically for MongoDB. 12:50.300 --> 12:57.350 So if you look up here, this is the latest chart version of each software, if you will. 12:58.070 --> 13:02.840 Uh, the latest one for MongoDB is 15 .6.3, which is the one we're going to be using in this video. 13:02.840 --> 13:05.780 So doesn't matter what your latest one is. 13:05.780 --> 13:07.760 For consistency, use the same version as me. 13:07.760 --> 13:19.400 But if I say um, helm search repo this time I'm going to refine my search to be specific to the MongoDB 13:19.430 --> 13:20.240 helm charts. 13:20.270 --> 13:20.870 Okay. 13:20.870 --> 13:31.550 And I want to view all of the versions for MongoDB, not just the latest one we see starting from 5.09. 13:31.670 --> 13:34.880 Um, oh, not MongoDB. 13:34.910 --> 13:38.810 Sharded MongoDB, that's the one we're going to use. 13:39.500 --> 13:44.000 Starts at 5.09, ends at 15.60 .13. 13:44.210 --> 13:46.520 Okay Cool. 13:47.030 --> 13:51.680 And now how are we going to deploy this helm chart. 13:51.680 --> 13:56.180 So you'll remember let me click on this. 13:57.710 --> 13:58.880 Where is it. 13:59.240 --> 14:00.740 It's so little hard to see. 14:00.770 --> 14:01.610 Oh there you go. 14:01.610 --> 14:02.480 So MongoDB. 14:02.480 --> 14:08.360 So this is very similar to the helm charts that we created for our applications. 14:08.360 --> 14:15.080 You've got a templates folder that abstracts away all of the configuration files that are needed to 14:15.110 --> 14:19.280 set everything up that are needed to deploy MongoDB. 14:19.610 --> 14:28.520 And you've got a values.yaml file whose values get injected into the templates. 14:28.550 --> 14:29.300 Okay. 14:29.510 --> 14:32.780 Now most of these values we're not going to touch. 14:32.810 --> 14:35.720 Most of these default values are fine. 14:36.320 --> 14:38.960 Um, they're very, very well commented. 14:38.990 --> 14:46.330 I actually took the liberty of reading all of these comments and seeing how each field is described 14:46.330 --> 14:52.060 in order to know exactly what I need to change for this lesson in order to set up a proper deployment. 14:52.060 --> 14:59.920 So usually when you're leveraging these helm packages, you want to take the time to read all the fields 14:59.920 --> 15:05.800 that you're able to modify according to whatever deployment that you want to accomplish. 15:05.830 --> 15:06.640 Okay. 15:07.270 --> 15:10.990 Um, most default values in here should be fine. 15:10.990 --> 15:20.950 Now, if for some reason you can't find the GitHub repo and read what the helm chart has to offer, 15:21.040 --> 15:26.260 what you can do is say helm show values. 15:26.350 --> 15:34.690 I want to refine my search to just the MongoDB helm chart, the latest one in this case, and now and 15:34.690 --> 15:44.110 whatever values it outputs for the following, I want to output it to a default values dot YAML file. 15:46.120 --> 15:51.670 Okay, so here I extract a default values.yaml file that shows me. 15:57.400 --> 16:03.070 All of the default values that are being used in this helm chart. 16:03.220 --> 16:10.600 And now what I'm going to do is create a values dot YAML file. 16:10.870 --> 16:13.750 This will contain all of the default values. 16:13.750 --> 16:18.850 This will contain all of the values that I want to override for my helm deployment. 16:18.850 --> 16:21.370 I can go ahead and delete all of this. 16:21.370 --> 16:22.690 I don't need it anymore. 16:22.690 --> 16:24.580 We're not going to be setting up ourselves. 16:24.580 --> 16:27.010 We're going to be leveraging a helm chart. 16:27.550 --> 16:32.590 And now, upon reading the default values, there are a few things I want to change. 16:32.620 --> 16:33.370 All right. 16:33.370 --> 16:40.360 So there was a field called use Statefulset I'm going to set that to true. 16:40.570 --> 16:47.000 Otherwise it's going to use a deployment to set up our MongoDB instance. 16:47.000 --> 16:54.530 We want to use a stateful set to make sure that each pod replica is has a unique name, has its own 16:54.530 --> 16:56.720 storage allocated to it. 16:56.750 --> 17:03.080 Okay, so the first value I'm going to override is use stateful set and set that to true. 17:03.860 --> 17:11.990 So whatever values we write here, they will override whatever default values are already present not 17:11.990 --> 17:13.520 affecting the other ones. 17:14.180 --> 17:18.320 Um, for authentication by default it's set to true. 17:18.320 --> 17:21.290 I'm going to override that to be false. 17:21.680 --> 17:24.830 Auth enabled false. 17:25.610 --> 17:27.860 Just to keep things simple at first. 17:27.860 --> 17:32.600 And another thing that I needed to change in this helm chart. 17:32.630 --> 17:35.360 If I say service followed by the following. 17:35.360 --> 17:37.610 So remember I already read all of this. 17:37.610 --> 17:40.040 So I know what to change and not to change. 17:40.040 --> 17:44.110 So service by default it's of type cluster IP. 17:44.110 --> 17:44.650 Perfect. 17:44.650 --> 17:53.140 So the MongoDB instance is going to be given a cluster IP service port name MongoDB ports MongoDB at 17:53.140 --> 17:54.640 port 27017. 17:54.640 --> 17:56.470 So I don't need to change that. 17:56.650 --> 17:58.450 Everything seems to be pretty good. 17:58.450 --> 18:06.580 I'm satisfied with what all of these values seem to accomplish upon being injected into their corresponding 18:06.580 --> 18:09.220 configuration files within the templates folder. 18:09.220 --> 18:13.570 I don't think there's anything else that I want to change for now. 18:13.660 --> 18:17.470 So what I can do is install this helm chart. 18:17.590 --> 18:23.200 I'm going to install the helm chart version. 18:25.060 --> 18:25.930 Where is it? 18:28.120 --> 18:33.310 Version 15.6 .13, which is going to have all of these default values. 18:33.310 --> 18:40.450 But I'm going to install it in a way where it considers the values that I'm overriding inside of my 18:40.500 --> 18:41.970 values.yaml file. 18:41.970 --> 18:47.160 So over here I'm going to say helm. 18:47.850 --> 18:52.770 Install the helm release is MongoDB. 18:52.800 --> 18:53.220 Okay. 18:53.250 --> 18:54.570 Nothing changes there. 18:54.570 --> 19:01.290 I'm installing a helm release based on the helm chart. 19:01.320 --> 19:09.360 Bitnami MongoDB version 15.60 .13. 19:10.020 --> 19:17.610 All right, so just like how we created helm releases based on our local helm charts within the Great 19:17.610 --> 19:20.370 Submission API folder or the Great Submission Portal folder. 19:20.400 --> 19:26.700 Now we're creating a helm release based on the helm chart within the Bitnami repository, the one that's 19:26.730 --> 19:29.430 version 15.60 .13. 19:30.510 --> 19:35.010 Then I'm going to say dash f for file this helm chart. 19:35.010 --> 19:42.060 I want it to be created while considering the values that I have inside of my values.yaml file. 19:42.060 --> 19:46.860 So it has all of these default values that it's going to use to set up the configuration. 19:46.860 --> 19:53.130 But it's also consider but it's also going to consider that I want to override the field use stateful 19:53.130 --> 19:54.120 set to be true. 19:54.150 --> 19:58.290 And I want to override authentication to be disabled. 19:58.380 --> 19:59.160 Okay. 19:59.190 --> 20:03.450 And finally I want to deploy this inside of the MongoDB namespace. 20:06.090 --> 20:08.070 Installation failed. 20:08.730 --> 20:11.130 Expected at most two arguments. 20:11.160 --> 20:14.490 Unexpected arguments Values.yaml. 20:24.720 --> 20:25.800 Interesting. 20:27.570 --> 20:32.340 Okay, I'm not sure what I did different between the first command and this one. 20:32.760 --> 20:36.960 So you can feel free to have a look yourself. 20:36.990 --> 20:38.850 Helm install MongoDB. 20:41.790 --> 20:44.340 Oh, I didn't separate these two. 20:44.670 --> 20:45.840 Okay, whatever. 20:47.370 --> 20:51.390 So now we have deployed MongoDB using helm. 20:51.420 --> 21:00.780 Can you look at the difference between what we had to do here and what we had to do here. 21:00.900 --> 21:03.750 We don't actually need this default values.yaml. 21:03.750 --> 21:05.250 I just left it there for reference. 21:05.250 --> 21:12.210 I'll be deleting it shortly, but pretty cool how we deployed MongoDB without setting up a single configuration 21:12.210 --> 21:13.560 file ourselves. 21:13.560 --> 21:20.640 We just overrode some values in order to steer the deployment according to something that we want. 21:20.670 --> 21:25.230 So we should have a MongoDB instances being managed by a stateful set. 21:25.260 --> 21:28.830 You can also modify how many instances you want to run. 21:28.830 --> 21:31.380 I'm sure there's a field there somewhere. 21:31.860 --> 21:33.090 I forgot where it was. 21:33.090 --> 21:36.210 But anyways, the default is just one instance. 21:37.020 --> 21:40.590 Uh, let's say kubectl get pods dash n MongoDB. 21:41.310 --> 21:45.900 We've got one MongoDB instance being managed by a stateful set. 21:45.930 --> 21:47.400 I'll address this error in a bit. 21:47.430 --> 21:53.160 If you're using a windows computer or a mac that doesn't use Apple Silicon, you shouldn't get this 21:53.160 --> 21:53.760 error. 21:53.760 --> 21:56.970 If you, unfortunately have a mac that uses Apple Silicon. 21:56.970 --> 21:59.640 So MacBook, M1, M2, or whatever. 21:59.700 --> 22:00.870 I'll address this in a bit. 22:00.870 --> 22:01.620 Just bear with me. 22:01.620 --> 22:06.150 So kubectl get statefulset dash n MongoDB. 22:07.650 --> 22:08.220 Beautiful. 22:08.220 --> 22:10.860 So we get this stateful set. 22:10.890 --> 22:14.670 We get this pod, uh, for free. 22:14.670 --> 22:19.230 All we had to do was change a couple of really, really minimal fields. 22:19.320 --> 22:29.340 Now what I want to teach you is that in Kubernetes, even if we're using helm, nothing ever just installs 22:29.370 --> 22:30.480 seamlessly. 22:30.510 --> 22:35.460 You're going to get bugs, you're going to get weird errors that are unexpected. 22:35.580 --> 22:37.430 The trick is not to panic. 22:37.460 --> 22:39.920 Describe the pod. 22:39.950 --> 22:41.960 See what that error is? 22:41.990 --> 22:43.520 Describe whatever resource. 22:43.550 --> 22:44.720 See what the error is. 22:44.750 --> 22:45.800 Go online. 22:45.830 --> 22:47.720 Other people struggled with it as well. 22:47.750 --> 22:53.300 Read the threads on Stack Overflow on the GitHub issues, and try to figure out what the problem is 22:53.330 --> 22:54.890 and determine a solution. 22:54.920 --> 22:57.110 Okay, so I'm going to do that for you right? 22:57.140 --> 23:01.850 I obviously already did this before the video started, but let's pretend that I'm doing it right now 23:01.850 --> 23:02.660 in front of you live. 23:02.660 --> 23:05.450 So kubectl describe pod. 23:05.480 --> 23:09.380 We're going to describe MongoDB zero in the namespace MongoDB. 23:11.990 --> 23:14.450 And we get an image. 23:15.650 --> 23:22.280 Pull back off pulling image bitnami MongoDB Debian r 12. 23:22.700 --> 23:28.400 And no matching manifest for Linux ARM 64. 23:28.610 --> 23:29.180 All right. 23:29.180 --> 23:40.520 So unfortunately the MongoDB helm charts being managed By, uh, bitnami their, their image, their 23:40.520 --> 23:44.870 MongoDB image that they themselves created. 23:45.410 --> 23:48.530 Um, it's not compatible with Arm64. 23:48.560 --> 23:49.040 Okay. 23:49.070 --> 23:55.250 So if you look inside of the default values.yaml file, let's look at image. 23:56.540 --> 24:00.710 This image right over here is no good. 24:00.740 --> 24:01.370 Okay. 24:01.370 --> 24:03.470 Let me take you to Docker Hub. 24:04.460 --> 24:11.720 So what I'm talking about all of these were compiled to work with the Linux Amd64 architecture. 24:11.750 --> 24:19.070 If you're using a MacBook, M1, M2, or whatever, you need these images to be compatible with ARM. 24:19.100 --> 24:31.550 So what we can do is we can override the image field such that we're not using this default image, 24:31.550 --> 24:40.910 but we force the Bitnami helm chart to use a MongoDB image that's actually compatible with both AMD 24:40.910 --> 24:42.200 and with ARM. 24:42.230 --> 24:46.760 Okay, now you might be wondering, and you're a genius to be able to figure it out like that. 24:46.790 --> 24:49.130 I wasn't initially sure what the problem is. 24:49.160 --> 24:55.430 I mean, the error message is pretty descriptive, but just like anybody else, I went through the process 24:55.430 --> 24:59.780 of troubleshooting and seeing if other people had the same problem. 24:59.780 --> 25:11.270 So I went on GitHub issues, I went on StackOverflow, and I found this comment right over here that, 25:11.930 --> 25:13.970 uh, validated my doubts. 25:13.970 --> 25:18.590 And their solution was to force the Bitnami Mongo helm chart. 25:18.590 --> 25:19.940 Force is a strong word. 25:19.940 --> 25:28.100 In this case, we're overriding the image field to use the official Mongo image that's actually compatible 25:28.100 --> 25:29.270 with both platforms. 25:29.300 --> 25:41.000 Okay, so if I go and I look up mongo We'll look up the image that that individual specifically outlined 25:41.120 --> 25:43.220 for just for the sake of it. 25:43.940 --> 25:48.230 So 6.04.4. 25:48.260 --> 25:53.690 Jamie, you can see that this image is compatible with amd64 arm64. 25:53.690 --> 25:58.940 So it should work with Mac and with windows on most machines. 25:58.970 --> 26:00.230 All right. 26:00.230 --> 26:04.430 So what I'll do is I'm going to copy these values over. 26:06.110 --> 26:07.190 All right. 26:08.360 --> 26:09.860 Registry IO. 26:09.860 --> 26:12.980 So we're so we're still going to be grabbing the image from Docker Hub. 26:12.980 --> 26:20.030 But in this case the repository is actually Mongo okay. 26:22.910 --> 26:25.070 Not Bitnami slash MongoDB. 26:25.070 --> 26:35.710 And the tag is 6.04 Jamie there are other Mongo versions that are also compatible with Amd64 and Arm64. 26:35.740 --> 26:37.480 Just going to use this one. 26:37.540 --> 26:38.290 Okay. 26:38.500 --> 26:40.780 Because it seems like it's right in front of us. 26:42.760 --> 26:49.660 And now another thing we want to do that was outlined is set the persistence such that the persistent 26:49.660 --> 26:52.300 volume gets mounted at slash data slash debe. 26:52.330 --> 26:56.290 You'll remember that we did that inside of the stateful set section. 26:56.560 --> 27:00.520 Now let's go ahead and look at what the default value is for that. 27:00.520 --> 27:02.500 So if I look up persistence. 27:05.170 --> 27:12.340 Um mount path uh it's bitnami slash MongoDB. 27:12.340 --> 27:16.870 But we're not using the Bitnami MongoDB software anymore. 27:16.900 --> 27:25.780 We're using the standard MongoDB application which you learned, which I showed you saves all of its 27:25.780 --> 27:29.890 data by default to the local directory slash data slash DB. 27:29.890 --> 27:34.030 So we need to You update this variable accordingly. 27:34.030 --> 27:40.990 That way when that value gets injected into what probably is going to be the stateful set resource, 27:41.020 --> 27:46.270 the persistent volume is mounted to the right local directory within the container. 27:46.270 --> 27:51.280 So what we need to do is under persistence followed by a mount path. 27:51.310 --> 27:53.860 Change this slash data slash debe. 27:56.470 --> 27:57.400 Okay. 28:03.820 --> 28:09.190 So now let's go ahead and helm uninstall what we have currently. 28:09.220 --> 28:10.870 I don't think we need this anymore. 28:12.070 --> 28:19.990 But all things considered it's pretty cool how we're able to install MongoDB so easily just by defining 28:19.990 --> 28:20.920 a few values. 28:20.920 --> 28:25.690 So helm uninstall I'm pretty sure I called the release MongoDB. 28:26.380 --> 28:31.450 I'm going to uninstall this release that exists inside of the MongoDB namespace. 28:33.550 --> 28:36.580 Now I'm going to reinstall it. 28:38.620 --> 28:42.040 Using this updated Values.yaml. 28:50.110 --> 28:51.250 All right. 28:52.630 --> 29:01.900 Now we'll say kubectl get pods dash n MongoDB pods being managed by the statefulset. 29:01.930 --> 29:03.670 At least now it's running. 29:03.670 --> 29:05.440 It's not ready yet. 29:05.470 --> 29:05.950 Beautiful. 29:05.950 --> 29:07.090 That's a good sign. 29:07.120 --> 29:16.750 So by forcing the helm chart to use this image that's compatible with both platforms, it was able to 29:16.780 --> 29:19.300 seamlessly get everything up and running. 29:23.590 --> 29:25.630 It's going to require some time. 29:25.930 --> 29:29.290 Um, be back in a few minutes. 29:29.290 --> 29:30.730 I'll fill up my cup of water. 29:36.340 --> 29:39.610 Okay, there we go. 29:40.420 --> 29:48.010 And now finally, kubectl get pods dash n gray submission. 29:48.760 --> 29:54.250 So we've got these great submission APIs that are so desperate to connect to an instance of MongoDB. 29:54.580 --> 30:00.460 But this time the MongoDB instance lives inside of a different namespace. 30:00.460 --> 30:02.950 How is the connection going to work? 30:03.310 --> 30:07.270 And so the question is how do you connect to a service that exists in a different namespace. 30:07.270 --> 30:12.880 Because when the service when when you add a cluster IP service in the same namespace, all the great 30:12.880 --> 30:22.000 submission API had to do is say, um, the service name followed by the port number, right? 30:23.200 --> 30:24.190 Port number. 30:24.190 --> 30:30.510 But when the service exists in a different namespace and you want a pod to communicate with that service, 30:30.510 --> 30:35.670 then what you need to specify is a service name followed by the service namespace. 30:35.670 --> 30:44.070 The namespace that that service is in, followed by the following static string service dot cluster, 30:44.100 --> 30:50.700 dot local and then followed by the port number, which in this case is 27017. 30:50.700 --> 30:58.200 So what I'm going to do is say kubectl get services dash n MongoDB. 30:59.700 --> 31:00.360 All right. 31:00.360 --> 31:02.940 The service name is MongoDB. 31:03.570 --> 31:07.530 The service namespace is MongoDB. 31:09.840 --> 31:16.800 And this is what we're going to use to connect to our cluster IP service. 31:16.800 --> 31:26.490 So if we go back to the values.yaml file for the grade submission API instead of localhost 27017, we 31:26.490 --> 31:28.020 say MongoDB. 31:28.200 --> 31:33.120 The service name followed by the namespace followed by this status string. 31:33.120 --> 31:40.230 That's going to allow us to connect to the service, followed by the port where the service is responding 31:40.260 --> 31:41.340 to requests. 31:41.370 --> 31:47.460 Ultimately, that's going to send everything over to MongoDB, which is going to be able to handle URIs 31:47.460 --> 31:53.460 of this scheme and create the connection that our great submission API is so desperate for. 31:53.490 --> 31:59.610 Now, you'll remember before that we usually we had credentials over here. 32:02.370 --> 32:09.000 Um, the thing is, in this case, our MongoDB isn't expecting any credentials, so we don't have to 32:09.030 --> 32:10.440 include it in the URI. 32:10.440 --> 32:11.790 And that should be enough. 32:12.810 --> 32:16.560 Um, I'm going to keep authentication disabled. 32:16.590 --> 32:17.640 Okay. 32:18.810 --> 32:22.650 Uh, just to keep the lesson focused on all the right things. 32:22.680 --> 32:25.620 Now I'm going to CD into the great submission API. 32:25.650 --> 32:27.510 Let's uninstall the helm release. 32:27.510 --> 32:32.220 So helm uninstall I have a helm release called Great Submission API. 32:32.250 --> 32:34.260 Yours might be named something different. 32:35.910 --> 32:36.540 Uh. 32:36.810 --> 32:37.350 Darn it. 32:37.890 --> 32:39.300 And great submission. 32:40.980 --> 32:41.970 Okay. 32:44.310 --> 32:47.190 Helm release should be uninstalled now. 32:49.170 --> 32:51.660 Now I'm going to reinstall it. 32:52.230 --> 32:55.170 Helm install. 32:55.200 --> 32:58.890 Great submission API. 33:00.720 --> 33:00.930 Uh. 33:01.380 --> 33:03.090 And great submission. 33:05.310 --> 33:07.080 Installation name. 33:07.110 --> 33:08.610 Oh, sorry. 33:08.610 --> 33:14.970 Install the helm release based on the following helm chart that exists inside of this folder. 33:17.550 --> 33:18.390 Beautiful. 33:18.630 --> 33:22.830 I'm going to give it a couple of minutes for all the connections to take place 33:28.230 --> 33:29.070 Okay. 33:30.900 --> 33:33.810 Hey, guys, my computer just shut down. 33:33.900 --> 33:35.970 Um, anyways, whatever. 33:35.970 --> 33:41.250 I had to restart my Docker engine, and I forgot where we were. 33:41.280 --> 33:45.180 I expect that by the time I edit this video, there's going to be a lot of video glitches that you would 33:45.210 --> 33:46.470 have realized by now. 33:46.470 --> 33:50.760 But anyways, kubectl get pods dash n great submission. 33:52.350 --> 33:54.750 All the great submission APIs are currently running. 33:54.750 --> 33:58.080 They're ready if yours for some reason don't work. 33:58.080 --> 34:01.800 Mine restarted quite a bit for whatever reason. 34:01.800 --> 34:04.620 Uh, probably due to a lack of resources. 34:04.620 --> 34:11.040 And if resourcing is the issue, what you can do is open up your Docker dashboard. 34:11.040 --> 34:14.220 If you're using windows, it should be on your bottom right toolbar. 34:14.220 --> 34:22.230 Once you open up your Docker dashboard, you can go to the settings uh menu. 34:22.260 --> 34:23.250 Go to resources. 34:23.250 --> 34:27.810 You can allocate more resources to your cluster. 34:28.020 --> 34:29.070 Okay. 34:29.940 --> 34:36.600 We've seen how we can leverage helm to install helm charts and deploy things very seamlessly. 34:36.600 --> 34:42.420 But I want to take things a step further and show you how we can install things using operators. 34:42.450 --> 34:42.720 Okay. 34:42.750 --> 34:49.020 So I don't want to spend too much time on this one helm package, which we're going to decommission 34:49.020 --> 34:50.340 in the next section. 34:50.340 --> 34:53.970 So I'll see you in the next section where we where we discuss operators. 34:53.970 --> 34:55.830 And I hope you enjoyed this one. 34:55.860 --> 34:56.670 All right. 34:56.700 --> 34:57.270 You know what? 34:57.300 --> 35:00.990 Before we wrap up, I wouldn't hurt to test what we've got so far. 35:00.990 --> 35:04.950 So localhost 80. 35:06.510 --> 35:11.010 Uh, we'll give Harry a score of 95 in potions. 35:13.050 --> 35:14.340 Everything works seamlessly. 35:14.340 --> 35:19.860 You got the great submission portal talking to the API, which is able to save grades to MongoDB. 35:20.070 --> 35:22.200 Okay, that's it for this section. 35:22.230 --> 35:23.310 See you in the next one.