WEBVTT 00:05.730 --> 00:07.380 Hello and welcome to this lecture. 00:07.470 --> 00:11.820 In this lecture, we will discuss about the cabinet, a service cluster IP. 00:13.060 --> 00:19.800 A full stack web application typically has different kinds of parts hosting different parts of an application. 00:20.460 --> 00:24.220 You may have a number of parts running a front end Web server. 00:24.630 --> 00:30.870 Another set of parts running a back in server, a set of parts running a key value store like Redis 00:31.470 --> 00:32.790 and another set of parts. 00:32.860 --> 00:36.130 Maybe running a persistent database like my S cual. 00:37.260 --> 00:43.170 The Web front end server needs to communicate to the backend servers and the back end servers need to 00:43.170 --> 00:46.750 communicate to the database as well as the ready services, etc.. 00:47.580 --> 00:55.500 So what is the right way to establish connectivity between these services or tiers of my application? 00:56.280 --> 01:00.870 The parts all have an IP address assigned to them, as we can see on the screen. 01:01.560 --> 01:04.950 But these eyepiece, as we know, are not static. 01:05.250 --> 01:10.080 These parts can go down anytime and new parts are created all the time. 01:10.440 --> 01:16.350 And so you cannot rely on these IP addresses for internal communication between the application. 01:16.950 --> 01:22.150 Also, what if the first front end part at ten to 40 4.0? 01:22.230 --> 01:25.560 Three need to connect to a back and service. 01:26.220 --> 01:29.820 Which of the three would it go to and who makes that decision? 01:30.440 --> 01:38.520 A Cuban at a service can help us group the part together and provide a single interface to access the 01:38.520 --> 01:39.710 parts in a group. 01:40.730 --> 01:47.900 For example, a service created for the back end part will help group all the back and parts together 01:47.990 --> 01:52.730 and provide a single interface for other parts to access to service. 01:53.660 --> 01:58.340 The requests are forwarded to one of the parts under the service randomly. 01:59.090 --> 02:05.540 Similarly, create additional services for Redis and allow the backend parts to access the ready systems 02:05.540 --> 02:06.500 through the service. 02:07.130 --> 02:14.300 This enables us to easily and effectively deploy a micro services based application on Coburn that is 02:14.300 --> 02:14.960 cluster. 02:15.710 --> 02:23.030 Each layer can now scale or move as required without impacting communication between the various services. 02:23.780 --> 02:30.650 Each service gets an IP name assigned to it inside the cluster, and that is the name that should be 02:30.650 --> 02:33.920 used by other paths to access the service. 02:34.580 --> 02:40.250 This type of service is known as cluster IP to create such a service. 02:40.310 --> 02:46.610 As always, use a definition file in the service definition file first used to default template which 02:46.610 --> 02:49.760 has API abortion kind metadata on spec. 02:50.360 --> 02:51.850 The API version is V. 02:51.850 --> 02:56.210 One kind is service and we will give a name to our service. 02:56.300 --> 03:01.710 We will call it back and under specification we have type and ports. 03:01.880 --> 03:03.740 The type is cluster IP. 03:04.130 --> 03:07.210 In fact, cluster IP is the default type. 03:07.220 --> 03:15.220 So even if you didn't specify it, it will automatically assume the type to be cluster IP under-report. 03:15.320 --> 03:17.480 We have a target port and port. 03:18.500 --> 03:26.030 The target port is the port where the back end is exposed, which in this case is 80 and the port is 03:26.030 --> 03:33.320 where the service is exposed, which is 80 as well, to link the service to a set of ports, we use 03:33.360 --> 03:33.950 selector. 03:34.790 --> 03:41.140 We will refer to the port definition file and copy the labels from it and remove it under selector. 03:42.020 --> 03:42.950 And that should be it. 03:43.520 --> 03:50.300 We can now create the service using the cube control, create command and then check its status using 03:50.300 --> 03:52.700 the cube control gets services command. 03:53.540 --> 03:59.780 The service can be accessed by other parts using the cluster IP or the service name.