WEBVTT 00:00.020 --> 00:00.830 Welcome back everybody. 00:00.830 --> 00:04.010 Let's discuss another very cool benefit that Kubernetes provides. 00:04.010 --> 00:06.110 And that is configuration management. 00:06.110 --> 00:15.140 The ability to separate application specific configuration from environment related deployment details 00:15.170 --> 00:15.470 okay. 00:15.500 --> 00:22.370 So if you take a look at what we've got so far, we're mixing parameters and settings that are specific 00:22.370 --> 00:30.380 to the application with deployment details that describe how the app should be deployed in its environment. 00:30.380 --> 00:35.270 We're doing that in the Great submission API deployment and the great Submission portal deployment. 00:35.270 --> 00:37.850 We're doing that in the stateful set as well. 00:37.850 --> 00:45.920 Here we have uh, parameters and settings that are specific to configuring the MongoDB app itself. 00:45.920 --> 00:52.520 And we're entangling that with environment related deployment details. 00:52.520 --> 00:59.000 So how persistent volume claims will be bound to each container, how persistent persistent volumes 00:59.000 --> 00:59.810 will be mounted. 00:59.810 --> 01:02.050 The amount of replicas we're going to have. 01:02.620 --> 01:08.140 So these are things that belong in a deployment manifest. 01:08.530 --> 01:11.080 Uh, application specific configuration. 01:11.080 --> 01:12.370 Do not. 01:12.430 --> 01:13.600 Why? 01:13.630 --> 01:22.300 Here are some, uh, obvious examples, uh, updating database credentials, changing them every now 01:22.300 --> 01:24.970 and then is a very common practice. 01:25.000 --> 01:25.690 Okay. 01:25.690 --> 01:35.380 You don't want to reconfigure the entire stateful set re-update the entire stateful set every time we 01:35.380 --> 01:37.630 change the username and password. 01:37.630 --> 01:38.860 That's one. 01:38.950 --> 01:45.430 Number two is let's just say the great submission API ends up relying on a lot more environment variables, 01:45.430 --> 01:47.290 maybe eight, 10 or 12. 01:47.320 --> 01:52.630 Are you going to flood the deployment with all of these environment variables? 01:53.050 --> 01:57.550 Um, if you do that, things just become really, really hard to maintain. 01:57.550 --> 02:05.890 You never want to entangle Application specific configuration with environment related deployment details. 02:05.890 --> 02:13.090 You want to have a clear separation of concerns, and that's where configmap and secrets are very useful. 02:13.780 --> 02:22.840 We can store Non-confidential configuration data in Configmaps, and we can store and base64 encode 02:22.840 --> 02:27.280 sensitive configuration data inside of secrets. 02:27.280 --> 02:33.880 And then we can reference the Configmaps and secrets in our deployment manifest, leaving our deployment 02:33.880 --> 02:40.150 completely devoid of configuration data and only containing deployment details. 02:40.150 --> 02:48.610 So expanding on that, a Configmap only contains Non-confidential configuration data using usually in 02:48.640 --> 02:55.180 plain text, and then the deployment now just contains deployment details, and it can reference the 02:55.180 --> 02:57.430 values that it needs from the config map. 02:57.430 --> 02:58.990 Same thing over here. 02:59.130 --> 03:04.800 The deployment just contains the deployment details and it can reference whatever sensitive information 03:04.800 --> 03:09.120 the secret has to set up authentication or even to authenticate. 03:09.240 --> 03:10.140 All right. 03:10.140 --> 03:15.750 So now what I can do is copy and paste section seven. 03:16.140 --> 03:19.200 Call it section eight. 03:21.540 --> 03:23.070 2222. 03:23.520 --> 03:24.090 Oh. 03:24.120 --> 03:25.680 Before you start please do this. 03:25.680 --> 03:34.650 Delete every deployment stateful set PVC delete everything from the great submission namespace. 03:34.800 --> 03:39.960 Trust me, if you don't, you're going to get really weird results throughout this lesson because we're 03:39.960 --> 03:43.650 basically rewiring everything and we don't want to have any loose ends. 03:43.680 --> 03:50.190 Okay, so make sure to delete every single object that we have so far in the great submission namespace. 03:50.340 --> 03:51.960 You can leave the services. 03:51.960 --> 03:53.100 They're harmless. 03:53.220 --> 03:56.610 And before we do anything we're going to add a few more files. 03:56.610 --> 03:59.210 And things are already starting Actually guys, give me one second. 03:59.210 --> 04:00.080 I'll be back. 04:00.110 --> 04:02.540 There's a lot of construction noise in the background. 04:03.830 --> 04:05.300 All right, all right, I'm back. 04:05.330 --> 04:11.210 I forgot what I was talking about, but anyways, I'll go ahead and split everything up into folders. 04:11.210 --> 04:13.160 Create submission API. 04:15.170 --> 04:17.120 Uh, one folder. 04:17.150 --> 04:18.320 Great submission portal. 04:18.320 --> 04:21.260 That's going to contain all the great submission portal objects. 04:21.650 --> 04:23.720 One folder called MongoDB. 04:25.970 --> 04:31.940 We move those here, move, move those here. 04:31.970 --> 04:35.330 Move and move those here. 04:36.050 --> 04:36.500 All right. 04:36.500 --> 04:46.340 So the deployment's got, um, these parameters and settings and this username and password, we want 04:46.370 --> 04:51.680 to put these in a config map, put these in a secret and reference them accordingly. 04:51.710 --> 04:57.800 Let's create a new file called Great Submission API Config.yaml. 04:59.440 --> 05:02.020 Um, call this config map. 05:02.410 --> 05:04.630 Don't forget to. 05:04.660 --> 05:07.870 Well, obviously you won't get the config map and name. 05:07.900 --> 05:10.750 One thing you shouldn't forget is the namespace. 05:10.780 --> 05:11.530 Okay? 05:11.560 --> 05:17.320 If you don't put the config map in the same namespace as your deployment, your deployment is not going 05:17.320 --> 05:18.490 to be able to find it. 05:18.520 --> 05:19.360 All right. 05:19.360 --> 05:24.100 So grade submission, it must be in the same namespace as the deployment. 05:24.100 --> 05:31.900 So that the deployment can is able to reference it and load in all of its values in real time and give 05:31.900 --> 05:33.910 its values to the application. 05:37.420 --> 05:42.340 So here we can just say MongoDB host equals MongoDB. 05:42.370 --> 05:49.660 So yeah, we can just specify our environment variables as key value pairs okay. 05:50.290 --> 05:51.130 Sorry guys. 05:53.380 --> 05:57.940 And remove any white space Okay. 05:58.360 --> 06:05.620 And now inside of our deployment, instead of referencing our environment variables like that, I can 06:05.620 --> 06:13.240 just say environment from we're going to get all of our environment variables from a config map. 06:14.260 --> 06:17.080 So I'm going to say config map ref. 06:19.150 --> 06:26.590 We're going to reference the config map named great submission API config in order in order for the 06:26.590 --> 06:27.310 deployment. 06:27.310 --> 06:33.280 To successfully reference this config map, they need to be in the same namespace. 06:34.780 --> 06:37.690 And now we need to put these in a secret. 06:38.650 --> 06:44.950 So great submission API secret dot YAML. 06:46.360 --> 06:48.310 We'll say secret. 06:48.340 --> 06:51.970 We'll call this secret great submission API secret. 06:52.000 --> 06:58.860 Make sure it's in the same namespace as our He meant all right. 06:58.860 --> 07:08.070 And now the fields that we're going to put our MongoDB user in MongoDB password inside of our secret 07:08.100 --> 07:13.500 and later reference from our deployment, so we can specify them as simple key value pairs. 07:13.530 --> 07:15.720 MongoDB user. 07:16.380 --> 07:23.730 And you can't actually store things in plain text under the secrets as data object. 07:23.760 --> 07:24.930 I'll get to that in a second. 07:24.960 --> 07:26.850 They need to be base64 encoded. 07:26.880 --> 07:27.840 Why? 07:27.960 --> 07:30.120 I'll explain in just one second. 07:30.360 --> 07:32.460 Let's just put these here for now. 07:33.570 --> 07:34.530 All right. 07:36.600 --> 07:43.860 So any value, any sensitive value that we place under the data object Kubernetes is going to assume 07:43.860 --> 07:45.930 it's base64 encoded. 07:45.960 --> 07:46.920 Don't believe me? 07:46.950 --> 07:48.570 Hover over data object. 07:48.570 --> 07:52.890 The serialized form of the secret data is a base64 encoded string. 07:52.890 --> 07:58.050 If you want it to store your sensitive data in plain text, then you would put things under string data. 07:58.050 --> 08:00.300 But I don't see why you would do that. 08:00.330 --> 08:02.850 And so yeah, we can't simply write these in plain text. 08:02.880 --> 08:04.170 They need to be base64 encoded. 08:04.200 --> 08:05.520 Let's do that right now. 08:05.550 --> 08:07.380 We can do that straight from the command line. 08:07.380 --> 08:10.980 Notice I'm already keyed into section eight. 08:11.010 --> 08:12.600 Make sure to do that as well. 08:12.630 --> 08:23.100 I'm going to say echo dash n and this plain text value I want to convert into base64. 08:26.700 --> 08:28.920 This password value. 08:31.080 --> 08:33.450 In a base64 encoded as well. 08:35.940 --> 08:36.870 Okay. 08:37.470 --> 08:45.870 So Kubernetes is going to assume this is base64 encoded and interprets. 08:46.830 --> 08:50.610 It's going to get back the value password 123. 08:50.640 --> 08:51.030 Okay. 08:51.060 --> 08:57.680 So you need to make sure that your password is base64 encoded because that's what Kubernetes is expecting 08:57.680 --> 09:04.490 it to be, because it's going to decode it back into its plaintext value when giving it back to our 09:04.490 --> 09:05.840 container that needs it. 09:05.870 --> 09:06.170 All right. 09:06.200 --> 09:10.580 We haven't referenced the secret yet, but why do we base64 encode? 09:11.120 --> 09:17.330 Well, if we have a password with many with many special characters that can't be written in plain text 09:17.330 --> 09:18.530 in a YAML file. 09:18.560 --> 09:32.300 Base64 converts that really complex password into a set of 64 safe Ascii characters A to Z 0 to 9, 09:32.300 --> 09:35.840 ensuring that we can use whatever password we want. 09:35.870 --> 09:39.950 Because look, some special characters you simply can't write in plain text. 09:39.980 --> 09:44.750 They need to be base64 encoded and passwords tend to have these characters. 09:44.750 --> 09:51.380 So that's why in a secret, Kubernetes assumes everything you write is going to be base64 encoded, 09:51.380 --> 09:59.500 and it's going to decode it upon it being injected within whatever container you want to give that data 09:59.500 --> 09:59.890 to. 09:59.920 --> 10:07.750 So here we reference all the environment variables in the secret that's named Great Submission API secret. 10:07.990 --> 10:09.280 And that's it guys. 10:10.090 --> 10:14.620 Um, I'm not going to deploy anything yet, but nothing changed. 10:14.620 --> 10:15.280 All right. 10:15.280 --> 10:18.310 Before we had environment variables specified over here. 10:18.340 --> 10:23.890 Now we're referencing these environment variables from a config map, which stores the variables in 10:23.890 --> 10:29.230 plain text and from a secret which stores the base64 encoded version. 10:29.230 --> 10:32.650 So this is assumed to be password 123. 10:32.650 --> 10:35.740 And this is interpreted as admin. 10:35.830 --> 10:36.850 All right. 10:37.420 --> 10:42.580 Same thing for the great submission portal here I just need a config map, because I don't think the 10:42.580 --> 10:49.600 great submission portal has any sensitive data or relies on any sensitive data. 10:49.630 --> 10:53.860 Config map call it great submission portal config. 10:53.860 --> 10:57.270 Not API config in the namespace create submission. 10:57.270 --> 11:03.570 Remember, it must be in the same namespace in order for the deployment to find it, and the values 11:03.570 --> 11:05.490 it's going to have are the following. 11:05.520 --> 11:12.600 We can just copy and paste that over here, and we can write our environment variables as key value 11:12.600 --> 11:13.770 pairs. 11:14.070 --> 11:14.640 Config. 11:14.640 --> 11:15.810 We can just use plain text. 11:15.840 --> 11:16.770 Simple as that. 11:16.770 --> 11:21.180 Again make sure you've got no trailing white space no special characters. 11:21.210 --> 11:23.970 Otherwise you'll end up getting these really weird errors. 11:24.000 --> 11:24.810 Okay. 11:24.840 --> 11:26.790 And environment variables. 11:26.820 --> 11:28.530 We're going to get them from 11:30.330 --> 11:31.770 a 11:33.720 --> 11:41.910 config map that we reference using its name grade submission portal config. 11:42.360 --> 11:43.230 Right. 11:43.230 --> 11:48.480 And we don't have to specify any application specific configuration within the deployment. 11:48.480 --> 11:52.530 We just reference whatever environment variables are inside of this config map. 11:52.530 --> 11:54.300 There could be one, there could be 20. 11:54.350 --> 11:54.950 Doesn't matter. 11:54.950 --> 12:01.100 We just reference it and inject these environment variables into the application that needs it. 12:01.130 --> 12:09.200 Now our deployments are devoid of parameters and settings specific to the app, and only contain the 12:09.200 --> 12:15.170 necessary deployment details that it needs to know how to run, how to deploy our application in its 12:15.170 --> 12:16.400 environment. 12:16.640 --> 12:18.890 Now we do the same thing for MongoDB. 12:18.920 --> 12:24.800 This one only needs a secret MongoDB secret YAML. 12:24.890 --> 12:27.350 I'll say secret over here. 12:27.380 --> 12:32.450 Call it MongoDB secret and namespace. 12:32.450 --> 12:34.460 Great submission. 12:35.240 --> 12:39.800 And once again, everything here is expected to be base64 encoded. 12:39.800 --> 12:48.890 We already did the base64 encoding over here, so I can copy over the values, but the keys themselves 12:48.890 --> 12:57.530 will be different because the Mongo app itself expects a certain um environment variable a certain set 12:57.530 --> 13:01.190 of environment variables for uh to in order for it to set up security. 13:01.220 --> 13:03.410 Namely these ones. 13:04.520 --> 13:05.120 All right. 13:05.120 --> 13:07.850 So mongo init db root username. 13:10.580 --> 13:13.760 Which uh should map to the value admin. 13:13.760 --> 13:22.550 But we're going to put in the base64 encoded version because that's what is expected inside of the data 13:22.580 --> 13:24.230 object of a secret. 13:25.550 --> 13:29.900 And the Mongo db root password we store. 13:29.900 --> 13:33.920 The base64 encoded is going to map to password one two, three. 13:33.950 --> 13:36.380 But we're not going to write password 123. 13:36.410 --> 13:42.950 We're going to write the base64 encoded version because Kubernetes will interpret it and convert it 13:42.950 --> 13:47.930 back into plain text when we give it to whatever app is referencing it. 13:47.930 --> 13:48.710 Okay. 13:48.710 --> 13:55.750 So in this case, our MongoDB app is going to get password one, two, three. 13:55.780 --> 14:02.140 It's going to be base64 decoded at the container runtime back into its plaintext value. 14:02.170 --> 14:07.750 Now we reference the secret, not the environment variables. 14:07.750 --> 14:16.450 So we'll get the environment variables from uh, secret that we reference using its name MongoDB secret. 14:16.870 --> 14:18.100 All right. 14:18.130 --> 14:18.970 And that's it. 14:19.000 --> 14:20.530 Nothing changed guys. 14:20.530 --> 14:25.360 All we did was we separated configuration from deployment. 14:25.600 --> 14:31.480 And now whenever I need to update my usernames or passwords or whatever, I don't need to drill in my 14:31.480 --> 14:33.160 entire deployment manifest. 14:33.160 --> 14:37.060 I can just update it within its config file. 14:37.090 --> 14:37.690 Okay. 14:37.720 --> 14:38.230 All right. 14:38.260 --> 14:39.760 Again I want to emphasize this. 14:39.760 --> 14:44.290 Make sure that you've deleted all your deployment stateful PVCs whatever. 14:44.320 --> 14:46.540 Do it now if you haven't done so already. 14:46.570 --> 14:50.560 Not just your stateful sets, all the associated PVCs as well. 14:51.160 --> 14:54.150 Once you see that everything has been deleted. 14:54.210 --> 14:57.540 Then go ahead and CD into section eight. 14:57.930 --> 14:59.730 Um, sorry guys. 14:59.730 --> 15:04.830 Before moving on, I really want to make sure I don't have any loose ends because this lesson is a bit 15:04.860 --> 15:05.340 tedious. 15:05.340 --> 15:08.400 So the secret has been defined properly. 15:08.400 --> 15:15.030 It's got all the variables that it needs to inject into the MongoDB app. 15:15.030 --> 15:17.520 We're referencing the MongoDB secret. 15:17.520 --> 15:20.220 Let's make sure the name is consistent. 15:20.220 --> 15:22.020 It is there in the same namespace. 15:22.020 --> 15:22.320 All right. 15:22.320 --> 15:23.820 This one is fine. 15:24.660 --> 15:27.480 This one is fine as well. 15:29.880 --> 15:31.050 Okay. 15:33.000 --> 15:38.430 Well this one API config API secret same namespace. 15:38.430 --> 15:43.590 All the right values being referenced over here. 15:43.620 --> 15:46.950 Okay, no sense in worrying if we get bugs. 15:46.950 --> 15:52.500 We just describe our pod's, output the logs and try to debug. 15:53.760 --> 15:58.020 So we apply everything in the MongoDB folder first and foremost. 15:58.560 --> 15:59.700 All right. 16:00.120 --> 16:02.700 Kubectl get pods dash n. 16:02.700 --> 16:04.050 Great submission. 16:06.660 --> 16:07.080 Okay. 16:07.110 --> 16:09.690 The MongoDB pod has been started up. 16:10.470 --> 16:15.420 I'm going to say kubectl apply dash f everything in the grade submission API folder. 16:18.180 --> 16:25.770 So now I expect my grade submission API to have received the host and port that it needs to connect 16:25.770 --> 16:32.850 to the MongoDB service, and once connected that it receives the correct username and password, which 16:32.850 --> 16:39.330 will be base64 decoded back to admin and password 123 that it needs to authenticate against the MongoDB 16:39.360 --> 16:40.560 statefulset. 16:40.740 --> 16:45.060 Let's make sure container is still creating. 16:45.060 --> 16:46.860 Wow, that was a cliffhanger. 16:47.130 --> 16:49.470 Not a cliffhanger, but anticlimactic. 16:49.500 --> 16:51.800 Kubectl get pods dash n great submission. 16:51.800 --> 16:52.640 Let's try it again. 16:52.640 --> 16:53.060 Come on. 16:53.060 --> 16:53.630 Container. 16:53.630 --> 16:54.560 Create. 16:56.810 --> 16:57.650 Beautiful. 16:57.650 --> 16:59.060 It's running now. 16:59.060 --> 17:04.760 It's trying to connect to the MongoDB database kubectl logs dash f. 17:05.510 --> 17:08.720 Make sure it's able to authenticate. 17:08.750 --> 17:10.880 We want to view the logs for this pod. 17:10.880 --> 17:16.610 That's in the great submission namespace a tried connecting. 17:16.610 --> 17:19.220 It didn't, but then it finally did. 17:19.220 --> 17:24.980 So now I expect the readiness endpoint to have sent back positive responses to the readiness probe, 17:24.980 --> 17:27.980 which means our app should be ready. 17:28.010 --> 17:28.670 All right. 17:28.700 --> 17:31.220 There was an application restart for this one. 17:31.250 --> 17:32.300 Weird. 17:33.020 --> 17:39.620 Uh, the liveness probe must have sent back a negative response at some point, triggering an application 17:39.620 --> 17:40.280 restart. 17:40.280 --> 17:42.890 Anyway, now we apply the great submission portal. 17:43.880 --> 17:49.790 So the reason I did this order is because the MongoDB is kind of like standalone. 17:49.790 --> 17:55.570 The great submission API relies on connecting to MongoDB, and the Great Submission portal relies on 17:55.570 --> 17:57.700 connecting to the Great Submission API. 17:58.630 --> 18:01.960 Great submission portal usually always works from the first try. 18:01.990 --> 18:05.470 That one doesn't have any complexities to it. 18:07.360 --> 18:09.160 And great submission. 18:13.600 --> 18:16.270 Okay, it's not ready yet. 18:16.270 --> 18:24.400 I guess it hasn't fully connected to the great submission API, because I have a readiness endpoint 18:24.400 --> 18:29.080 in there that sends back a negative response or a status 500. 18:29.110 --> 18:31.690 If the portal can't connect to the API. 18:31.720 --> 18:33.430 Wonder why it can't? 18:35.740 --> 18:38.560 I can, I just spoke too soon. 18:38.650 --> 18:41.410 Okay, so it's really important that you delete it. 18:41.410 --> 18:42.520 Everything. 18:42.520 --> 18:48.460 First, all the deployment, stateful sets and PVCs and started from scratch. 18:48.490 --> 18:49.540 All right. 18:49.570 --> 18:51.660 To make sure everything works. 18:51.930 --> 18:55.470 Um, let's just go to localhost 32,000. 18:55.500 --> 19:01.110 If we get a smooth user experience, then everything has been connected to each other seamlessly, which 19:01.110 --> 19:02.610 means nothing changed. 19:02.610 --> 19:07.380 All we did was separate the configuration data, but everything still works smoothly. 19:07.380 --> 19:13.560 I did delete all the PVCs and whatnot, so their corresponding PV should have been deleted as well. 19:13.560 --> 19:16.380 So we should see no data if I go to grades. 19:17.220 --> 19:20.040 So if I go ahead and submit some new grades. 19:22.590 --> 19:23.850 It's so slow. 19:23.880 --> 19:26.760 My computer is really sluggish right now. 19:27.060 --> 19:31.260 Harry Potter give him a 43 and potions. 19:33.360 --> 19:37.470 Fingers crossed guys, that was a very tedious video to produce. 19:37.470 --> 19:39.600 Let's end on a good note. 19:40.620 --> 19:41.640 All right. 19:41.670 --> 19:42.870 Beautiful. 19:42.990 --> 19:53.040 So that's all for separating configuration data from your deployment manifests, we place sensitive 19:53.040 --> 20:00.600 configuration data inside of secrets, ensuring that their base64 encoded upon them being injected into 20:00.600 --> 20:02.280 whatever app relies on them. 20:02.280 --> 20:09.420 They will be base64 decoded back into their plain text value during container runtime, and we place 20:09.420 --> 20:16.500 non-confidential configuration data in config maps in plain text, and we just reference the config 20:16.500 --> 20:22.920 map using a config map ref ref and all of its environment variables will be loaded in to the app that 20:22.920 --> 20:27.180 needs them within the same container at container runtime. 20:27.210 --> 20:33.660 All right, that's it for, uh, configuration management with Kubernetes. 20:33.690 --> 20:40.530 Hope you can see how just uh, loosely coupled it makes everything and how awesome it is to be relying 20:40.530 --> 20:44.130 on a platform like Kubernetes that provides so many benefits. 20:44.130 --> 20:48.330 The next one is really exciting, where we discuss horizontal scaling. 20:48.330 --> 20:49.500 I'll see you then.