WEBVTT 00:07.030 --> 00:10.450 Hello and welcome to this lecture in this lecture. 00:10.540 --> 00:17.500 We will try and understand micro services architecture using a simple Web application. 00:18.280 --> 00:26.350 We will then try and deploy this Web application on multiple different Coburn as platforms such as Google 00:26.350 --> 00:27.670 Cloud Platform. 00:28.300 --> 00:34.600 I'm going to use a simple application developed by Docker to demonstrate the various features available 00:34.660 --> 00:37.420 in running an application stack on Docker. 00:38.400 --> 00:45.420 So let's first get familiarized with the application, because we will be working with the same application 00:45.540 --> 00:48.270 in different sections to the rest of this course. 00:49.800 --> 00:57.600 This is a sample voting application which provides an interface for a user to vote and another interface 00:57.810 --> 00:58.860 to show the results. 00:59.640 --> 01:05.610 The application consists of various components, such as the voting app, which is a Web application 01:05.610 --> 01:13.020 developed in Python to provide the user with an interface to choose between two options a cat and a 01:13.020 --> 01:13.440 dog. 01:14.850 --> 01:21.530 When you make a selection, the vote is stored in red is for those of you who are new to red is red. 01:21.720 --> 01:24.480 In this case, serves as a database in memory. 01:25.170 --> 01:29.930 This vote is then processed by the worker, which is an application written in dot net. 01:30.360 --> 01:36.690 The worker application takes the new vote and updates the persistent database, which is at Postgrads 01:36.720 --> 01:37.950 Escuela in our case. 01:38.640 --> 01:43.830 The Post Chris Escudo simply has a table with the number of votes for each category. 01:44.160 --> 01:45.300 Cats and dogs. 01:45.840 --> 01:50.910 In this case, it increments the number of votes for cats as our vote was for cats. 01:51.420 --> 01:56.940 Finally, the result of the vote is displayed in a web interface, which is another Web application 01:57.270 --> 01:58.730 developed in No G.S.. 01:59.340 --> 02:05.970 This resulting application reads the count of votes from the Post's Chris Siecle database and displays 02:05.970 --> 02:06.990 it to the user. 02:07.990 --> 02:14.230 So that is the architecture and dataflow of this simple voting application stack. 02:15.270 --> 02:22.170 As you can see, this sample application is filled with a combination of different services, different 02:22.170 --> 02:27.830 development tools and multiple different development platforms such as Python. 02:28.020 --> 02:30.060 No G.S., dot net, et cetera. 02:31.050 --> 02:38.040 This sample application will be used to showcase how easy it is to set up an entire application stack 02:38.130 --> 02:41.250 consisting of diverse competence in Dakar. 02:42.910 --> 02:51.040 Let us see how we can put together this application stack on a single docker engine using docker run 02:51.040 --> 02:51.610 commands. 02:52.150 --> 02:59.170 Let us assume that all images of applications are already built and are available on Docker repository. 02:59.830 --> 03:01.690 Let us start with the data layer. 03:02.380 --> 03:07.750 First, we are on the Docker Run command to start an instance of red is by running the docker run. 03:07.870 --> 03:08.620 Red is command. 03:09.520 --> 03:15.490 We will add the dash D parameter to run this container in the background and we will also named the 03:15.490 --> 03:17.110 container red this. 03:18.150 --> 03:20.450 Now, naming the containers is important. 03:21.410 --> 03:22.460 Why is that important? 03:22.880 --> 03:23.750 Hold that thought. 03:23.900 --> 03:25.280 We will come to that in a bit. 03:26.250 --> 03:32.340 Next, we will deploy the Postgrads sequel database by running the Docker Run Postscripts Command. 03:33.460 --> 03:39.850 This time, too, we will add the Dashty option to run this in the background and name this container 03:40.120 --> 03:41.650 DBE for database. 03:42.670 --> 03:48.810 Next, we will start with the application services, we will deploy a front, an app for voting interface 03:48.820 --> 03:51.490 by running an instance of wanting app image. 03:52.210 --> 03:57.580 Run the Docker Run command and name the instance vote since this is a Web server. 03:57.640 --> 04:00.620 It has a Web UI instance running on Port 80. 04:01.090 --> 04:06.580 We will publish that port to five thousand on the host system so we can access it from a browser. 04:07.210 --> 04:12.220 Next, we will deploy the results web application that shows the results the user. 04:13.060 --> 04:19.470 For this, we deploy a container using the results dash app image and published Port 80 to Port five 04:19.470 --> 04:21.100 thousand one on the host. 04:21.760 --> 04:25.930 This way we can access the Web UI of the resulting app on a browser. 04:26.590 --> 04:31.240 Finally, we deploy the worker by running an instance of the worker image. 04:33.180 --> 04:33.420 OK. 04:34.170 --> 04:39.180 Now, this is all good and we can see that all the instances are running on the host. 04:39.930 --> 04:41.640 But there is some problem. 04:42.150 --> 04:43.740 It just does not seem to work. 04:44.370 --> 04:50.400 The problem is that we have successfully run all the different containers, but we haven't actually 04:50.460 --> 04:51.600 linked them together. 04:52.290 --> 04:57.810 As in, we haven't told the voting web application to use this particular red, this instance. 04:58.440 --> 05:01.050 There could be multiple red is instances running. 05:01.740 --> 05:08.160 We haven't told the worker and the resulting app to use this particular PostgreSQL database that we 05:08.160 --> 05:08.520 ran. 05:09.450 --> 05:10.470 So how do we do that? 05:11.480 --> 05:13.240 That is where we use links. 05:13.850 --> 05:19.460 Link is a command line option, which can be used to link two containers together. 05:20.270 --> 05:25.730 For example, the voting app Web Service is dependent on the ready service. 05:26.540 --> 05:32.750 When the Web server starts, as you can see in this piece of code on the Web server, it looks for a 05:32.750 --> 05:34.880 ready service running on host. 05:36.260 --> 05:39.990 But the voting app container cannot resolve a host by the name. 05:40.150 --> 05:40.600 Read this. 05:41.240 --> 05:47.570 To make the voting app aware of the ready service, we add a link option while running the voting app 05:47.570 --> 05:49.610 container to link it to the red. 05:49.610 --> 05:50.390 This container. 05:51.020 --> 05:57.410 Adding a dash dash link option to the DOCA run command and specifying the name of the red is container, 05:57.530 --> 06:03.560 which is which in this case it's red, is followed by a colon and the name of the host that the voting 06:03.560 --> 06:04.760 app is looking for. 06:05.090 --> 06:07.100 Which is also read this in this case. 06:08.150 --> 06:13.370 Remember that this is why we named the container when we ran it the first time. 06:13.400 --> 06:16.550 So we could use its name while creating a link. 06:17.990 --> 06:24.530 What this is, in fact, doing is it creates an entry into the ATC host file on the voting app container, 06:24.710 --> 06:29.630 adding an entry with the host named where the internal IP of the red, this container. 06:30.780 --> 06:36.930 Similarly, we add a link for the result app to communicate with the database by adding a link option 06:36.960 --> 06:40.140 to refer the database by the name D.B.. 06:41.160 --> 06:46.950 As you can see in this source code of the application, it makes an attempt to connect to a postscripts 06:46.950 --> 06:49.560 database on host DBI. 06:50.370 --> 06:56.430 Finally, the worker application requires access to both the Radice as well as the Postgres database. 06:56.880 --> 06:59.910 So we add two links to the worker application. 07:00.240 --> 07:04.890 One link to link theoretics and the other link to link Postgres database. 07:06.980 --> 07:14.320 Note that using links this way is deprecated and the support may be removed in our future in Dacher. 07:15.230 --> 07:22.460 This is because, as we will see in some time, advanced and newer concepts in Docker Swarm and networking 07:22.460 --> 07:26.990 supports better ways of achieving what we just did here with links. 07:27.890 --> 07:29.740 But I wanted to mention that anyway. 07:29.820 --> 07:32.960 So you learned the concept from the very basics.