WEBVTT 00:00.900 --> 00:02.160 -: All right, my friends. 00:02.160 --> 00:05.220 Looks like Travis CI has successfully ran all of my tests 00:05.220 --> 00:08.490 and made changes to my production at Kubernetes instance. 00:08.490 --> 00:10.920 I'm now gonna flip over to my Kubernetes dashboard. 00:10.920 --> 00:11.910 Now as a quick reminder 00:11.910 --> 00:13.620 I've waited a couple of minutes here 00:13.620 --> 00:15.300 or at least long enough where I feel like 00:15.300 --> 00:17.525 yeah everything has probably been updated successfully. 00:17.525 --> 00:19.560 We can very easily check to make sure 00:19.560 --> 00:21.090 that everything was done correctly 00:21.090 --> 00:24.450 by running a couple of commands inside of our cloud console. 00:24.450 --> 00:25.620 So the first thing we can do 00:25.620 --> 00:28.860 is try to get get our certificate object 00:28.860 --> 00:29.730 that we had created. 00:29.730 --> 00:33.930 And when I say get, I mean run the kubectl get command. 00:33.930 --> 00:35.460 So inside my cloud console 00:35.460 --> 00:38.850 I'll do a kubectl, get certificates 00:38.850 --> 00:40.920 and this will print out all the different objects 00:40.920 --> 00:43.713 of type certificate that exist inside of our cluster. 00:44.700 --> 00:45.630 So I see right there 00:45.630 --> 00:48.630 there is the certificate object they had created. 00:48.630 --> 00:50.193 It was created two minutes ago. 00:51.060 --> 00:53.640 Now to really make sure that this thing works successfully 00:53.640 --> 00:58.110 I can then do a kubectl describe certificates 00:58.110 --> 00:59.970 and this will print out some information 00:59.970 --> 01:01.980 about the certificate object, 01:01.980 --> 01:03.840 in particular It's going to have a little bit 01:03.840 --> 01:05.820 of log information that describes 01:05.820 --> 01:07.830 this back and forth project with 01:07.830 --> 01:10.533 excuse me, back and forth process with Lets Encrypt. 01:11.700 --> 01:15.690 All right, so I'll do kubectl describe certificates 01:15.690 --> 01:18.420 and I'll see a bunch of information print out here. 01:18.420 --> 01:19.560 Now I want you to know 01:19.560 --> 01:22.470 you might see something in here around like message 01:22.470 --> 01:25.470 and it might say like validation failed. 01:25.470 --> 01:29.760 You also might see status false and type validate failed. 01:29.760 --> 01:32.820 So if you see these like validation failed messages, 01:32.820 --> 01:34.317 don't panic just yet. 01:34.317 --> 01:37.560 You can essentially ignore these last couple 01:37.560 --> 01:38.910 of keys inside of here. 01:38.910 --> 01:41.040 What's really important is the list 01:41.040 --> 01:44.370 of events that gets printed up at the very bottom. 01:44.370 --> 01:48.330 So notice how for my events, I see issues or some messages 01:48.330 --> 01:52.037 of created new ACME order attempting validation. 01:52.037 --> 01:54.060 I then see that the domain 01:54.060 --> 01:58.830 of www.k eights multi was verified successfully. 01:58.830 --> 02:01.953 And I see the same thing for Keightsmulti.com as well. 02:03.216 --> 02:04.710 I then had the certificate issued 02:04.710 --> 02:08.400 we obtained the certificate and then issued successfully. 02:08.400 --> 02:10.080 So the next thing I can do to make sure 02:10.080 --> 02:12.720 that this all worked correctly, is check out the secret 02:12.720 --> 02:13.553 that we had said, 02:13.553 --> 02:14.460 that the certificate should be 02:14.460 --> 02:16.410 stored inside of. 02:16.410 --> 02:18.510 Inside my certificate.emo file. 02:18.510 --> 02:22.290 Remember, we provided a secret name of keightsmulti.com 02:22.290 --> 02:24.810 or at least that's what it was for me. 02:24.810 --> 02:26.863 So I should now be able to look 02:26.863 --> 02:27.930 at a list of all of my different secrets 02:27.930 --> 02:30.960 and verify that there is a secret with this name. 02:30.960 --> 02:32.280 I won't necessarily be able to look 02:32.280 --> 02:33.581 at the contents of the secret. 02:33.581 --> 02:35.910 Maybe, might not want to, 02:35.910 --> 02:39.240 but I can at least verify that yes, the secret was created 02:39.240 --> 02:42.153 and probably contains the TLS certificate. 02:43.080 --> 02:47.040 So to do so, back inside of my cloud shell over here, 02:47.040 --> 02:48.033 I'll do a clear. 02:49.110 --> 02:54.063 And then kubectl get secrets. 02:55.650 --> 02:59.520 And right here I see keightsmulti.com. 02:59.520 --> 03:01.260 All right, I see data two 03:01.260 --> 03:02.820 which probably represents the public 03:02.820 --> 03:05.940 and private keys that make up the certificate. 03:05.940 --> 03:07.230 So that's pretty much it. 03:07.230 --> 03:09.870 It looks like we have successfully set up the process 03:09.870 --> 03:14.070 of reaching out to, there it is, Let's Encrypt. 03:14.070 --> 03:16.890 And we've successfully gotten this response back 03:16.890 --> 03:19.110 from them that told us to set up a route. 03:19.110 --> 03:20.730 They pinged our cluster. 03:20.730 --> 03:22.980 That request was automatically responded 03:22.980 --> 03:25.320 to through the cert-manager tool. 03:25.320 --> 03:27.930 And in response we got a certificate that's going to be good 03:27.930 --> 03:30.030 for some amount of time. 03:30.030 --> 03:32.790 So now in theory, when that certificate is about to expire 03:32.790 --> 03:34.890 cert-manager should wake back up 03:34.890 --> 03:37.590 and attempt to go through this process all over again. 03:39.420 --> 03:40.921 All right, so now the very last thing we have to 03:40.921 --> 03:44.659 do is make sure that our NGINX ingress is aware 03:44.659 --> 03:46.890 that we have ATLS certificate 03:46.890 --> 03:49.290 and start using it for serving up traffic. 03:49.290 --> 03:50.730 So let's take a quick pause 03:50.730 --> 03:53.823 and we'll get around to that in the next section.