WEBVTT 00:00.690 --> 00:01.894 -: There's one last environment variable 00:01.894 --> 00:04.560 that we have to set up the PG password. 00:04.560 --> 00:06.420 This environment variable is a password 00:06.420 --> 00:09.240 that's going to be used to get access to our database. 00:09.240 --> 00:11.520 Now, one thing I want to be really clear about right now, 00:11.520 --> 00:14.790 is that the password is tied to Postgres itself. 00:14.790 --> 00:16.410 This is not a password related 00:16.410 --> 00:18.900 to Docker or Kubernetes or anything like that. 00:18.900 --> 00:22.290 We are talking about just getting access to Postgres. 00:22.290 --> 00:23.123 We need to make sure 00:23.123 --> 00:24.630 that we add in this environment variable 00:24.630 --> 00:26.135 and pass it to the multi-server. 00:26.135 --> 00:28.126 But like I said in the last video, chances are 00:28.126 --> 00:30.630 that we do not want to write out our password 00:30.630 --> 00:34.320 in plain text and store inside of our config file. 00:34.320 --> 00:37.890 So rather than adding in our password as plain text 00:37.890 --> 00:40.320 or anything like that, we're going to use a new type 00:40.320 --> 00:41.970 of object inside of Kubernetes 00:41.970 --> 00:43.688 that we have not yet discussed. 00:43.688 --> 00:45.807 So the new type of object we're going to use 00:45.807 --> 00:48.480 is something called a secret. 00:48.480 --> 00:50.032 So it's a very similar type of object 00:50.032 --> 00:52.980 in the sense that we had previously created a pod, 00:52.980 --> 00:55.560 a deployment, a service, and so on. 00:55.560 --> 00:58.447 The purpose of a secret is to securely store one 00:58.447 --> 01:02.700 or more pieces of information inside of your cluster. 01:02.700 --> 01:04.680 So a good example of a use of a secret would be 01:04.680 --> 01:07.274 for a database password, an API key, 01:07.274 --> 01:11.370 or maybe an SSH key, or any similar type 01:11.370 --> 01:13.580 of secret piece of information that you do not 01:13.580 --> 01:16.260 want to have easily exposed to the outside world, 01:16.260 --> 01:17.730 but you do want to make available 01:17.730 --> 01:20.730 to run in containers inside of your application. 01:20.730 --> 01:23.181 And so our database password perfectly qualifies 01:23.181 --> 01:26.040 as something that we would want to store inside a secret. 01:26.040 --> 01:28.380 Now, the secret is only about information 01:28.380 --> 01:30.259 that you want to very much protect. 01:30.259 --> 01:34.743 So in our example of our environment variables here, 01:35.730 --> 01:38.010 storing the reddest host right here would've not 01:38.010 --> 01:40.440 been a very good use of a secret, 01:40.440 --> 01:42.308 because the reddest host is always going to be the name 01:42.308 --> 01:45.420 of our service, and the name of our service 01:45.420 --> 01:48.270 is very plainly legible and readable inside 01:48.270 --> 01:51.660 of our reddest clusterIP file right here. 01:51.660 --> 01:54.610 So not a good reason to try to store the reddest host 01:55.613 --> 01:56.880 for example, inside of a secret 01:56.880 --> 01:58.980 probably saying for the thing for the port. 01:58.980 --> 02:01.020 Now, maybe the PG user would be something 02:01.020 --> 02:02.520 to store inside of a secret. 02:02.520 --> 02:05.310 Maybe the PG database would be as well. 02:05.310 --> 02:06.780 But for our example here, 02:06.780 --> 02:10.230 we're just gonna worry about encoding our PG password 02:10.230 --> 02:11.930 and storing it inside of a secret. 02:12.810 --> 02:14.489 All right, so how do we create a secret? 02:14.489 --> 02:17.057 Well, a secret is an object very much 02:17.057 --> 02:18.966 like a pod, a deployment, a service. 02:18.966 --> 02:21.450 And so we have said a billion times 02:21.450 --> 02:23.610 throughout this course that we always create an object 02:23.610 --> 02:25.309 through the use of a config file. 02:25.309 --> 02:27.450 However, you and I are not going 02:27.450 --> 02:29.790 to use a config file to create a secret. 02:29.790 --> 02:33.120 Instead, we are going to run a imperative command 02:33.120 --> 02:35.310 that's going to create the secret for us. 02:35.310 --> 02:37.377 So why are we using an imperative command here 02:37.377 --> 02:39.122 as opposed to a config file? 02:39.122 --> 02:41.190 Well, when you create the secret, 02:41.190 --> 02:44.760 you have to provide the data that you want to encode. 02:44.760 --> 02:48.090 And so if we had to write out a config file that said, 02:48.090 --> 02:50.580 hey, here's our secret, like in plain text 02:50.580 --> 02:52.830 here's the PG password, then it would kind 02:52.830 --> 02:55.501 of defeat the purpose of having a secret anyways. 02:55.501 --> 02:58.920 So we're going to create our secret with a single command 02:58.920 --> 03:00.468 that's gonna be imperative in nature, 03:00.468 --> 03:02.400 and that means that we're going to have to run 03:02.400 --> 03:04.979 this command locally on our computer to create the secret. 03:04.979 --> 03:07.629 It also means that when we eventually take our application 03:07.629 --> 03:09.330 to a production environment, 03:09.330 --> 03:11.220 we're going to have to make sure that we create 03:11.220 --> 03:14.674 the secret manually in the production environment as well. 03:14.674 --> 03:17.160 Everything else that we've done with the config file, 03:17.160 --> 03:19.620 such as our deployments and our services, 03:19.620 --> 03:21.390 do not need to be manually created 03:21.390 --> 03:22.770 in a production environment. 03:22.770 --> 03:24.769 All we have to do is apply the config files 03:24.769 --> 03:26.670 that represent each of them. 03:26.670 --> 03:29.160 So again, our secret being imperative in nature, 03:29.160 --> 03:31.320 we're going to have to make sure that we manually create 03:31.320 --> 03:33.900 this thing in any environment that we eventually 03:33.900 --> 03:35.133 take our application to. 03:36.188 --> 03:37.830 So to create the secret, 03:37.830 --> 03:41.593 we're going to run a rather long kubeCTL command. 03:41.593 --> 03:43.080 I'm gonna zoom in on the thing 03:43.080 --> 03:45.450 and then we'll go over it step by step. 03:45.450 --> 03:48.180 So we're going to use kubeCTL Create. 03:48.180 --> 03:51.030 Create is a imperative command that we can use to create 03:51.030 --> 03:54.840 a new object without necessarily using a config file. 03:54.840 --> 03:57.127 You will see a lot of documentation and a lot 03:57.127 --> 04:00.246 of blog posts out there talking about kubeCTL Create. 04:00.246 --> 04:02.550 Remember, we have not been using this command 04:02.550 --> 04:04.110 throughout this course, because we've been taking 04:04.110 --> 04:06.900 the more imperative, or excuse me, more declarative approach 04:06.900 --> 04:09.150 of using those config files. 04:09.150 --> 04:10.680 We're then going to designate the type 04:10.680 --> 04:12.060 of object that we want to create. 04:12.060 --> 04:14.151 So of course we want to make a secret, 04:14.151 --> 04:17.008 and then we will designate the type of secret. 04:17.008 --> 04:19.740 Now, our type of secret is generic, 04:19.740 --> 04:22.980 which indicates that we are saving some arbitrary number 04:22.980 --> 04:25.020 of key value pairs together. 04:25.020 --> 04:28.011 There are two other types of secrets that you might create. 04:28.011 --> 04:31.080 The first one is a Docker registry. 04:31.080 --> 04:33.616 So you would put in Docker registry. 04:33.616 --> 04:36.860 The other type of secret you can make is TLS. 04:36.860 --> 04:39.872 And TLS is related to say, HTTPS setup. 04:39.872 --> 04:41.880 And we would use the TLS right here 04:41.880 --> 04:44.703 to store a set of TLS keys. 04:46.020 --> 04:47.160 Now, the vast majority of the time 04:47.160 --> 04:49.140 you are going to use the generic. 04:49.140 --> 04:51.810 We would use the Docker registry one anytime 04:51.810 --> 04:53.895 that we want to set up some type of authentication 04:53.895 --> 04:57.270 with a custom Docker registry that would, 04:57.270 --> 04:59.400 we would be storing our images in. 04:59.400 --> 05:01.350 Now, you and I are storing all of our images 05:01.350 --> 05:05.280 in Docker Hubs, so no custom authentication is required. 05:05.280 --> 05:08.490 So we do not need to make a secret of type Docker registry. 05:08.490 --> 05:10.611 And then as far as that TLS secret, we actually 05:10.611 --> 05:13.860 might be setting up some HTTPS stuff later. 05:13.860 --> 05:16.200 So we might end up using that other type of secret 05:16.200 --> 05:18.050 at some point in time, but we'll see. 05:19.350 --> 05:21.180 Okay, so after generic, we'll then put 05:21.180 --> 05:22.860 down a name for the secret. 05:22.860 --> 05:24.210 The secret name is very important. 05:24.210 --> 05:26.370 It's very similar to the name property. 05:26.370 --> 05:29.070 So we've added to all of our other objects. 05:29.070 --> 05:31.740 The name property is going to be how we refer back 05:31.740 --> 05:33.870 to the secret at some point in time in the future when 05:33.870 --> 05:36.330 we actually want to consume it and make use 05:36.330 --> 05:38.733 of this secret inside of a pod config. 05:40.290 --> 05:41.430 Then the last two arguments 05:41.430 --> 05:44.010 on here are going to be from literal. 05:44.010 --> 05:46.170 So when we use dash dash from literal, 05:46.170 --> 05:47.680 that means that we're going to write out 05:47.680 --> 05:50.880 the information to be stored inside the secret 05:50.880 --> 05:52.669 in this actual command, as opposed 05:52.669 --> 05:56.700 to trying to write the secret information into a file 05:56.700 --> 05:59.703 and then load up all that secret data from the file. 06:00.720 --> 06:02.550 So because we are using from literal, 06:02.550 --> 06:05.490 we're going to add on our information as a key value pair 06:05.490 --> 06:07.710 at the very end of the command. 06:07.710 --> 06:09.750 You and I want to encode some environment 06:09.750 --> 06:12.000 variable called PG password. 06:12.000 --> 06:13.440 So we'll probably end up doing something 06:13.440 --> 06:18.330 like PG password equals and then our actual password, 06:18.330 --> 06:19.350 whatever it might be. 06:19.350 --> 06:21.060 You know, for us, we'll probably keep it something simple, 06:21.060 --> 06:23.613 like password123 or whatever it might be. 06:24.690 --> 06:26.310 Okay, so that's the entire command. 06:26.310 --> 06:28.080 So let's flip over to our terminal. 06:28.080 --> 06:29.220 We're gonna write this thing out. 06:29.220 --> 06:31.380 And again, I want to remind you 06:31.380 --> 06:33.780 that we're gonna have to run this command locally 06:33.780 --> 06:36.270 in our machine and when we eventually 06:36.270 --> 06:38.238 move off to production, we're gonna have to run 06:38.238 --> 06:40.740 the same command again to create a secret 06:40.740 --> 06:42.953 on that new environment as well. 06:42.953 --> 06:44.523 So let's get to it. 06:45.900 --> 06:48.270 I'm gonna flip back over to my terminal. 06:48.270 --> 06:52.253 I'm going to run kubeCTL, create secret. 06:55.440 --> 06:59.100 We're going to make a type of secret called generic. 06:59.100 --> 07:02.280 The secret name will be PG password. 07:02.280 --> 07:04.110 Notice how we're doing this in lowercase here. 07:04.110 --> 07:06.480 So this is not the actual environment variable. 07:06.480 --> 07:07.740 It's not the actual secret, 07:07.740 --> 07:09.630 it's just the name of the secret. 07:09.630 --> 07:11.640 So we're going to eventually have to reference 07:11.640 --> 07:13.080 this thing in the future and say, 07:13.080 --> 07:14.580 hey, go pull some information 07:14.580 --> 07:16.833 outta the secret called PG password. 07:18.870 --> 07:21.873 We'll then do dash dash from literal. 07:23.940 --> 07:26.723 I'll zoom in here just to make sure it's nice and legible. 07:28.620 --> 07:29.453 There we go. 07:29.453 --> 07:31.950 So dash dash from literal, and then we're going to put 07:31.950 --> 07:35.250 down the actual key value pair that we want to encode. 07:35.250 --> 07:38.447 So I'll do PG password equals, I don't know 07:38.447 --> 07:41.010 one, two, three, four, five, ASDF, 07:41.010 --> 07:42.060 whatever you want it to be. 07:42.060 --> 07:43.210 It's totally up to you. 07:45.030 --> 07:47.520 All right, so that's the entire command. 07:47.520 --> 07:49.680 So I'm now going to run this, 07:49.680 --> 07:51.960 and we'll see that the secret was created. 07:51.960 --> 07:53.520 And now just to verify that, yep, 07:53.520 --> 07:54.750 it was successfully created. 07:54.750 --> 07:56.640 And to look at the secret, we'll put 07:56.640 --> 08:00.600 in kubeCTL get secrets, like so. 08:00.600 --> 08:01.433 And it's gonna tell us, 08:01.433 --> 08:04.680 all right, we've got a secret called PG password 08:04.680 --> 08:08.010 and there's one key value pair inside there. 08:08.010 --> 08:10.290 And the key value pair is the PG password 08:10.290 --> 08:12.120 that we put in right here. 08:12.120 --> 08:12.953 All right, so that's it. 08:12.953 --> 08:14.359 We've now created a secret that is going 08:14.359 --> 08:17.880 to store our Postgres database password. 08:17.880 --> 08:20.160 So now the last thing we have to do is wire 08:20.160 --> 08:24.300 up the secret to our server deployment. 08:24.300 --> 08:26.940 So we need to make sure that our server container knows 08:26.940 --> 08:29.370 about this secret and receives it as an environment 08:29.370 --> 08:31.290 variable, and then the other thing we have 08:31.290 --> 08:33.630 to do, that might be a little bit less obvious, 08:33.630 --> 08:36.750 is that we have now created a database password 08:36.750 --> 08:38.820 that is something different than the default 08:38.820 --> 08:41.190 Postgres password, which is by default, 08:41.190 --> 08:42.023 something like, I don't know, 08:42.023 --> 08:44.190 PG password or whatever it is. 08:44.190 --> 08:45.940 I forget it off the top of my head. 08:46.830 --> 08:48.881 So we need to make sure that we also update our 08:48.881 --> 08:52.140 Postgres deployment as well. 08:52.140 --> 08:55.380 We're going to update our Postgres container definition 08:55.380 --> 08:57.249 and tell it about the password 08:57.249 --> 09:00.960 that it should be using as its default check. 09:00.960 --> 09:03.870 So we want to override the images default password 09:03.870 --> 09:05.520 that it sets up when it creates a copy 09:05.520 --> 09:07.252 of database inside that container and say, 09:07.252 --> 09:08.870 hey, use this password instead. 09:08.870 --> 09:12.150 And so anytime that someone tries to connect to the database 09:12.150 --> 09:15.420 it's going to try to authenticate that connection 09:15.420 --> 09:17.562 with the password that we provide to it. 09:17.562 --> 09:20.460 So two places to wire up this secret. 09:20.460 --> 09:22.407 Let's take a pause right now and we'll take care 09:22.407 --> 09:24.843 of both these things in the next section.