WEBVTT 00:00.840 --> 00:02.670 -: Wow, I'm actually kind of surprised 00:02.670 --> 00:04.800 everything worked correctly the second time through, 00:04.800 --> 00:06.240 at least the build did. 00:06.240 --> 00:08.550 Remember, if you see any error message here, 00:08.550 --> 00:09.990 try flipping over to the QA, 00:09.990 --> 00:12.570 try comparing your code to mine on GitHub, 00:12.570 --> 00:14.280 because it's so incredibly likely 00:14.280 --> 00:16.080 that it's just a tiny typo. 00:16.080 --> 00:18.630 So at this point, it looks like the build successfully ran. 00:18.630 --> 00:21.060 All that really means is that we built our images, 00:21.060 --> 00:22.260 pushed them off to Docker Hub, 00:22.260 --> 00:24.960 and then ran some commands against kubectl 00:24.960 --> 00:28.230 on our production Kubernetes instance over here. 00:28.230 --> 00:29.850 Now, before we try to actually test out 00:29.850 --> 00:32.850 our site inside of Kubernetes or anything like that, 00:32.850 --> 00:35.100 I wanna very quickly open up Docker Hub. 00:35.100 --> 00:36.900 I wanna look at some of the different repos 00:36.900 --> 00:38.070 that we have inside of here. 00:38.070 --> 00:39.680 How about say, multi-server. 00:39.680 --> 00:42.930 If I look at multi-server and I look at my tags, 00:42.930 --> 00:44.940 I'll see that both the latest tag 00:44.940 --> 00:47.010 and this new long tag right there 00:47.010 --> 00:48.960 were updated just two minutes ago. 00:48.960 --> 00:49.793 So that definitely means 00:49.793 --> 00:52.470 that I now have a permanent backup of my code, 00:52.470 --> 00:54.390 as it was at this commit right here, 00:54.390 --> 00:56.340 or the image I should say. 00:56.340 --> 00:58.800 And I also have a completely up to date tag 00:58.800 --> 01:01.740 of latest that new engineers can pull down in the future 01:01.740 --> 01:03.420 and know without a doubt that yeah, 01:03.420 --> 01:05.880 they're running the latest version of this image. 01:05.880 --> 01:07.050 So that's definitely cool. 01:07.050 --> 01:08.040 And the next thing I wanna do 01:08.040 --> 01:10.413 is go back over to my Kubernetes dashboard. 01:11.670 --> 01:14.103 So once over here, I'm gonna refresh the page, 01:17.190 --> 01:20.100 and then I'll take a look at the workloads tab. 01:20.100 --> 01:22.650 So now over here, oh, this is pretty awesome. 01:22.650 --> 01:24.535 I see that I've got my client deployment, 01:24.535 --> 01:26.670 PostgreSQL, Redis, server, worker, 01:26.670 --> 01:28.500 all those deployments have been created. 01:28.500 --> 01:30.240 You can click into one of these deployments 01:30.240 --> 01:33.360 and you'll see all of the different pods that it manages, 01:33.360 --> 01:35.890 along with a couple of graphs detailing the 01:37.590 --> 01:39.360 runtime information about this deployment. 01:39.360 --> 01:41.370 So here's the managed pods right here. 01:41.370 --> 01:43.020 Little information about each one that's running, 01:43.020 --> 01:44.730 and of course we can click into each of those 01:44.730 --> 01:47.880 and see information about that individual pod as well. 01:47.880 --> 01:49.530 Now, if I go over to services 01:49.530 --> 01:51.840 I'm gonna see a lot of information over here as well. 01:51.840 --> 01:54.300 So there's our set of cluster IPs. 01:54.300 --> 01:55.980 There's say the client cluster IP, 01:55.980 --> 01:58.350 all the others for all the other different 01:58.350 --> 02:01.170 sets of pods we have inside of our application. 02:01.170 --> 02:02.220 Now, very interestingly, 02:02.220 --> 02:04.470 you'll see that we have an Ingress service right here 02:04.470 --> 02:09.150 and it has an endpoint of like */ and */api. 02:09.150 --> 02:10.920 These two endpoints that you see right here 02:10.920 --> 02:12.180 are essentially routes 02:12.180 --> 02:13.740 and those are the different routes that we had set up 02:13.740 --> 02:18.480 inside of our K8 Ingress service .yaml file. 02:18.480 --> 02:20.700 So remember inside of here, we set up the two paths. 02:20.700 --> 02:24.630 We have path of / and path of /api. 02:24.630 --> 02:26.430 So that's what these two endpoints right here 02:26.430 --> 02:27.810 are talking about. 02:27.810 --> 02:29.490 We still have the old load balancer. 02:29.490 --> 02:30.960 I shouldn't say old, it was just created, 02:30.960 --> 02:32.460 but it's the load balancer that we were talking about 02:32.460 --> 02:33.480 in the last section. 02:33.480 --> 02:35.760 So remember, the Ingress right here is really just 02:35.760 --> 02:37.290 a config file. 02:37.290 --> 02:39.180 This config file is being shipped off 02:39.180 --> 02:40.620 to the Ingress controller. 02:40.620 --> 02:43.980 The Ingress controller is both making changes to NGINX 02:43.980 --> 02:46.353 and hosting NGINX simultaneously. 02:47.430 --> 02:50.010 Now, some other quick things I wanna take a look at. 02:50.010 --> 02:51.840 If we look at configuration, 02:51.840 --> 02:53.280 we're gonna have some config maps, 02:53.280 --> 02:55.350 which we haven't quite spoken about too much, 02:55.350 --> 02:58.500 but we do also see inside of here the PG password secret 02:58.500 --> 02:59.760 that we had previously created. 02:59.760 --> 03:03.930 We also see a service account that belongs to NGINX Ingress. 03:03.930 --> 03:06.180 This service account right here was created by Tiller 03:06.180 --> 03:07.740 when it went through all that setup 03:07.740 --> 03:10.047 of NGINX Ingress for us. 03:10.047 --> 03:11.160 And the last thing I wanna show you 03:11.160 --> 03:12.840 is storage tab over here. 03:12.840 --> 03:13.740 So you'll see that we have 03:13.740 --> 03:16.110 a persistent volume claim created. 03:16.110 --> 03:18.506 This is the database persistent volume claim 03:18.506 --> 03:20.490 that we had created to make sure that we had 03:20.490 --> 03:23.580 some permanent storage allocated to PostgreSQL. 03:23.580 --> 03:25.350 So we can click into this. 03:25.350 --> 03:27.990 I don't know if it's gonna show us the actual, 03:27.990 --> 03:28.823 well, ah, here we go. 03:28.823 --> 03:30.340 So here's the volume right here. 03:31.350 --> 03:32.400 So we can click on this volume 03:32.400 --> 03:34.440 and this is a volume that was created 03:34.440 --> 03:36.420 by that persistent volume claim. 03:36.420 --> 03:38.610 Now, if you want to, I'm pretty sure we could actually go up 03:38.610 --> 03:40.530 to our navigation menu up here 03:40.530 --> 03:45.530 and take a look at the storage or, is it data store? 03:45.570 --> 03:48.240 No, I forget exactly where it sits on here. 03:48.240 --> 03:49.380 Okay, maybe we'll come back to that. 03:49.380 --> 03:50.910 But I thought it would've been really nice 03:50.910 --> 03:52.980 to look at the persistent disc dashboard 03:52.980 --> 03:55.140 and see if that one was actually created over there, 03:55.140 --> 03:56.790 but I don't actually see anything on here 03:56.790 --> 03:59.700 related to the persistent data. 03:59.700 --> 04:01.560 Okay, so anyways, last thing we'll do, 04:01.560 --> 04:02.910 we'll go back over to services 04:02.910 --> 04:04.110 and we're going to try visiting 04:04.110 --> 04:06.360 our IP address right here again. 04:06.360 --> 04:08.850 Now, if everything worked correctly, when we click on this 04:08.850 --> 04:12.660 we should see our React project appear on the screen. 04:12.660 --> 04:13.920 I don't know what to expect here. 04:13.920 --> 04:16.260 I don't know if it's gonna work, but whatever happens, 04:16.260 --> 04:17.820 we'll just deal with it accordingly. 04:17.820 --> 04:19.380 Okay, so I'm gonna go to that address. 04:19.380 --> 04:22.410 I see the privacy error here, which is totally fine. 04:22.410 --> 04:23.760 Remember, this is something that we saw 04:23.760 --> 04:25.290 in our local environment as well. 04:25.290 --> 04:26.790 We are gonna fix this up very quickly. 04:26.790 --> 04:28.650 So this is a very temporary thing. 04:28.650 --> 04:31.083 So I'll go to advanced and then proceed. 04:32.010 --> 04:34.350 Yeah, oh my gosh, I can barely believe it. 04:34.350 --> 04:37.680 It actually worked, or at least it, I think it worked. 04:37.680 --> 04:39.660 You know, let's actually try entering a number here. 04:39.660 --> 04:43.290 I'll put in four and submit it, and then I'll refresh. 04:43.290 --> 04:44.580 Oh my, I can't believe it. 04:44.580 --> 04:46.200 It actually worked. 04:46.200 --> 04:47.033 Yes! 04:47.033 --> 04:48.033 Oh, I'm so happy. 04:49.170 --> 04:50.730 All right, my friends, there you are. 04:50.730 --> 04:51.630 There you have it, 04:51.630 --> 04:55.350 a Kubernetes cluster running in production. 04:55.350 --> 04:57.030 Now we're not quite done. 04:57.030 --> 04:58.110 We have deployed this. 04:58.110 --> 04:59.550 You know, we're just about there 04:59.550 --> 05:01.830 but we still got this HTTPS error. 05:01.830 --> 05:04.020 So clearly we need to do a little bit work there. 05:04.020 --> 05:06.180 I also want to very quickly walk through the process 05:06.180 --> 05:08.130 of making a change to our source code 05:08.130 --> 05:10.230 and then redeploying all these changes 05:10.230 --> 05:13.020 and making sure that we can see the updates up here live 05:13.020 --> 05:14.370 at this address as well. 05:14.370 --> 05:15.840 So let's take a pause right now 05:15.840 --> 05:17.580 and tackle a couple extra steps 05:17.580 --> 05:18.870 in the next couple of videos. 05:18.870 --> 05:20.520 So I'll see you in just a minute.