WEBVTT 00:00.180 --> 00:04.240 So we just saw how the voting application works on Tucker. 00:05.040 --> 00:07.990 Let's now see how to deploy it on corporate notice. 00:08.880 --> 00:16.050 So it's important to have a clear idea of what we are trying to achieve and plan accordingly. 00:16.500 --> 00:18.270 Before we get started. 00:18.300 --> 00:20.880 So we already know how the application works. 00:21.420 --> 00:24.510 And it's a good idea to write down what we plan to do. 00:25.080 --> 00:28.290 So our goal is to deploy these containers. 00:28.320 --> 00:35.310 These applications as containers on our coronets cluster and then enable connectivity between the containers 00:35.340 --> 00:43.980 so that the applications can access each other and the databases and then enable external access for 00:43.980 --> 00:50.550 the external facing applications, which are the voting and the result app so that the users can access 00:50.640 --> 00:51.480 the Web browser. 00:52.260 --> 00:52.530 Right. 00:52.830 --> 00:55.230 So how do we go about this? 00:55.950 --> 01:00.930 Now we know that we cannot deploy containers directly on coronets. 01:01.410 --> 01:07.480 We learned that the smallest object that we can create on a Cabernets cluster is a pod. 01:07.860 --> 01:14.520 So we must first deploy these applications as a pod on our cabernets cluster. 01:15.150 --> 01:21.870 Or we could deploy them as replica sets or deployments, as we have seen through throughout this course. 01:21.920 --> 01:28.170 But first, for the sake of simplicity, we will stick to pods in this lecture. 01:28.410 --> 01:28.560 Right. 01:29.070 --> 01:32.820 And later we will see how to easily convert that to a deployment. 01:33.480 --> 01:39.780 So once the parts are deployed, the next step is to enable connectivity between the surfaces. 01:40.530 --> 01:44.910 So it's important to know what the connectivity requirements are. 01:45.270 --> 01:51.180 So we must be very clear about what application requires access to what services. 01:51.780 --> 01:57.540 We know that the red this database is accessed by the voting app and the worker app. 01:57.810 --> 01:59.970 The wadding app saves the world to the red. 01:59.970 --> 02:04.200 Its database and the worker app reads the world from the red database. 02:04.920 --> 02:11.490 We know that the PostgreSQL Whewell database is accessed by the worker app to update it with the total 02:11.490 --> 02:12.350 count of roads. 02:12.840 --> 02:20.340 And it's also accessed by the result app to read the total count of votes to be displayed in the resulting 02:20.820 --> 02:22.200 Web page in the browser. 02:22.890 --> 02:31.110 So we know that the voting app is accessed by the external users, the voters, and the result app is 02:31.170 --> 02:34.890 also accessed by the external users to view the results. 02:35.460 --> 02:41.670 So most of the components are being accessed by another component except for the worker app. 02:42.180 --> 02:45.960 Note that the worker app is not being accessed by anyone. 02:46.830 --> 02:53.700 You can see arrows going into all of these components, but there are no arrows going into worker, 02:54.090 --> 02:59.250 which means none of the other components or external users are accessing the worker app. 02:59.700 --> 03:06.360 The worker app simply reads the count of votes from the Reds database and then updates the total count 03:06.540 --> 03:09.870 of votes on the Progress CUAL database. 03:10.290 --> 03:16.140 So none of the other components nor the external users ever access the worker app. 03:16.870 --> 03:23.850 Now, while the voting app has a Python Web server that listens on Port A-T and the result app also 03:23.850 --> 03:31.800 has a no jass based server that listens on Port 80 and they read this database has a service that listens 03:31.830 --> 03:33.570 on Port six three seven nine. 03:33.930 --> 03:38.430 And the PostgreSQL database has a service that listens on Port five, four, three, two. 03:39.200 --> 03:44.610 The worker app has no service because it's just a worker and it's not accessed by any other service 03:44.700 --> 03:45.750 or external users. 03:45.780 --> 03:47.130 So keep that in mind. 03:48.030 --> 03:51.270 So how do you make one component accessible by another? 03:51.330 --> 03:56.640 Say, for example, how do you make the greatest database accessible by the voting app? 03:57.360 --> 04:01.800 Should the voting app use the IP address of the reddest part, perhaps? 04:02.370 --> 04:04.290 No, because that can change. 04:04.380 --> 04:07.020 The IP of the port can change if the port restarts. 04:07.860 --> 04:12.690 And you may also run into issues when you try to scale your applications in the future. 04:13.650 --> 04:16.350 The right way to do it is to use a service. 04:16.930 --> 04:23.220 Now we learned that a service can be used to expose an application to other applications or users for 04:23.220 --> 04:24.300 external access. 04:24.900 --> 04:31.440 So we will create a service for the reddest pod so that it can be accessed by the voting app and the 04:31.440 --> 04:32.220 worker app. 04:32.630 --> 04:38.010 And we will call it a red this service, and it will be accessible anywhere within the cluster. 04:38.100 --> 04:40.390 By the name of the service Radice. 04:41.190 --> 04:43.200 So why is that name important? 04:43.770 --> 04:52.500 The source code within the voting app and the worker app are hard coded to point to a Redis database 04:52.860 --> 04:55.650 running on a host by the name Radice. 04:56.400 --> 04:59.130 So it's important to name your service. 04:59.580 --> 05:02.720 This so that these applications can connect to the red database. 05:03.250 --> 05:09.190 And this is not a best practice to hardcore stuff like this within the source code of an application. 05:09.730 --> 05:12.620 Instead, you should be using environment variables or something. 05:12.670 --> 05:19.240 But for the sake of simplicity, we will just follow this application as it is developed. 05:19.510 --> 05:25.470 Right now, these services are not to be accessed outside the cluster. 05:25.510 --> 05:29.040 So they should just be of type cluster IP. 05:29.680 --> 05:37.840 So we will follow the same approach of creating a service for the PostgreSQL pod so that the PostgreSQL 05:37.840 --> 05:40.480 DBE can be accessed by the worker. 05:40.660 --> 05:41.660 And the result app. 05:42.340 --> 05:45.520 So what should we name the PostgreSQL service? 05:46.120 --> 05:52.030 If you look at the source code of the result app and the work app, you will see that they are looking 05:52.030 --> 05:54.750 for a database at the address DBI. 05:55.270 --> 06:00.900 So the service that we create for PostgreSQL should be named DBI. 06:01.480 --> 06:07.810 Also note that while connecting to the database, the worker and the result apps passing a username 06:07.900 --> 06:13.270 and password to connect to the database, both of which are set to progress. 06:13.390 --> 06:21.580 So when we deploy the postgrads d.b pod, we must make sure that we set the these credentials for it 06:21.670 --> 06:25.090 as the initial set of credentials to while creating the database. 06:26.110 --> 06:30.310 Now the next task is to enable external access. 06:30.610 --> 06:35.770 So for this, we saw that we could use a service with a type set to node port. 06:36.280 --> 06:38.950 So we create services for voting app. 06:39.280 --> 06:40.270 And the result app. 06:40.390 --> 06:43.840 And set there Type two node port. 06:44.560 --> 06:48.280 Now we could decide on what port we are going to make them available on. 06:48.380 --> 06:52.340 And it would be a high port with a port no greater than 30000. 06:53.290 --> 06:55.930 So we'll do that when we create the service. 06:56.020 --> 06:59.170 So we are done and we have the high level steps ready. 06:59.740 --> 07:03.430 So to summarize, we will be deploying five port in total. 07:03.670 --> 07:05.230 And we have four services. 07:06.160 --> 07:09.850 One for red is another for postgrads, both of which are internal services. 07:10.120 --> 07:11.740 So they are of type cluster IP. 07:11.740 --> 07:14.770 And we then have external facing services for Wooding app. 07:14.800 --> 07:15.640 And the result app. 07:16.120 --> 07:18.500 However, we have no service for the worker pod. 07:18.940 --> 07:21.130 And this is because it is not running any service. 07:21.160 --> 07:24.880 That must be accessed by another application or external users. 07:25.270 --> 07:29.110 So it is just a worker process that reads from one database and updates, Senator. 07:29.650 --> 07:31.540 So it's not going to require a service. 07:31.570 --> 07:37.090 Now I say that again, as that's a common question that I get when we talk about services. 07:37.780 --> 07:40.000 Why does this work or not require a service? 07:40.160 --> 07:40.330 Right. 07:40.390 --> 07:48.250 So a service is only required if the application has some kind of process or database service or Web 07:48.250 --> 07:50.840 service that needs to be exposed. 07:50.860 --> 07:52.450 That needs to be accessed by others. 07:52.930 --> 07:55.540 In this case, that's that's not true for the worker app. 07:56.320 --> 08:02.590 Now, before we we get started with the deployment note that we will be using the following Docker images 08:02.590 --> 08:03.670 for these applications. 08:04.180 --> 08:11.440 So these images are built from a four of the original developed at the Docker samples repository. 08:12.400 --> 08:16.630 The image names are called cloud slash example. 08:16.630 --> 08:20.350 Wooding app underscore vote with a tag of me one. 08:20.850 --> 08:24.470 And then again, worker B one result won. 08:25.060 --> 08:31.900 And for the databases we will use the official redis and post crepuscule releases that are available. 08:32.650 --> 08:32.850 Right. 08:32.890 --> 08:34.270 So that's it for now. 08:34.990 --> 08:37.750 And we will see this in action in the upcoming demo.