1 00:00:05,050 --> 00:00:06,730 Hello and welcome to this lecture. 2 00:00:06,730 --> 00:00:12,310 My name is mugshot man I'm Beth and we are learning coordinators for beginners in this lecture. 3 00:00:12,310 --> 00:00:20,720 We will talk about creating a pod using a demo based configuration file in the previous lecture. 4 00:00:20,730 --> 00:00:27,450 We learn about e-mail files in general now we will learn how to develop e-mail files specifically for 5 00:00:27,450 --> 00:00:27,810 Cuba. 6 00:00:27,810 --> 00:00:35,760 Net is Cuban it is uses Jamil files as inputs for the creation of objects such as parts report cards 7 00:00:35,760 --> 00:00:41,460 deployment services etc. All of these follow a similar structure. 8 00:00:41,490 --> 00:00:46,660 Cuban errors definition file always contains four top level fields. 9 00:00:46,660 --> 00:00:51,010 The API version kind metadata and spec. 10 00:00:51,400 --> 00:00:55,680 These are the top level or root level properties. 11 00:00:55,690 --> 00:01:01,550 These are also required fields so you must have them in your configuration file. 12 00:01:01,630 --> 00:01:03,590 Let us look at each one of them. 13 00:01:03,730 --> 00:01:06,340 The first one is the API abortion. 14 00:01:06,340 --> 00:01:09,090 This is the version of the cobra that is API. 15 00:01:09,080 --> 00:01:14,170 We are using to create the object depending on what we are trying to create. 16 00:01:14,170 --> 00:01:20,330 We must use the right API version for now since we are working on parts. 17 00:01:20,380 --> 00:01:23,430 We will set the EPA version as we 1. 18 00:01:23,500 --> 00:01:33,100 Few other possible values for this field are apps for Slash p. 1 beta Extensions Plus 1 beta etc.. 19 00:01:33,310 --> 00:01:40,990 We will see what these are for later in this course next is the kind the kind refers to the type of 20 00:01:41,020 --> 00:01:44,880 object we are trying to create which in this case happens to be a part. 21 00:01:45,550 --> 00:01:49,330 So we will set it as part of some other possible values here. 22 00:01:49,330 --> 00:01:56,050 Could be replica set or deployment or service which is what you see in the kind field in the table on 23 00:01:56,050 --> 00:02:06,700 the right the next is metadata the metadata is data about the object like its name labels etc.. 24 00:02:07,570 --> 00:02:15,430 As you can see unlike the first two where you have specified a string value this is in the form of a 25 00:02:15,430 --> 00:02:16,150 dictionary. 26 00:02:17,430 --> 00:02:25,050 So everything under metadata is intended to the right a little bit and so names and labels are children 27 00:02:25,170 --> 00:02:33,420 of metadata the number of spaces before the two properties name and labels doesn't matter but they should 28 00:02:33,420 --> 00:02:36,060 be the same as they are siblings. 29 00:02:36,060 --> 00:02:44,160 In this case labels has more spaces on the left than name and so it is now a child of the name property 30 00:02:44,250 --> 00:02:52,260 instead of a sibling which is incorrect also the two properties must have more spaces than its parent 31 00:02:52,560 --> 00:02:56,990 which is metadata so that it's intended to the right a little bit. 32 00:02:57,150 --> 00:03:03,630 In this case all three of them have the same number of spaces before them and so they are all siblings 33 00:03:03,660 --> 00:03:04,670 which is not correct. 34 00:03:06,140 --> 00:03:10,930 Under metadata the name is a string value so you can name your part. 35 00:03:11,060 --> 00:03:20,230 My app part and the labels is a dictionary so labels is a dictionary within the metadata dictionary. 36 00:03:21,290 --> 00:03:24,970 And it can have any key and value pairs as you wish. 37 00:03:24,980 --> 00:03:30,520 For now I have added a label app with the value my app. 38 00:03:30,590 --> 00:03:36,620 Similarly you could add other labels as you see fit which will help you identify these objects at a 39 00:03:36,620 --> 00:03:38,300 later point in time. 40 00:03:38,510 --> 00:03:44,480 Say for example there are hundreds of parts running a front end application and hundreds of parts running 41 00:03:44,510 --> 00:03:47,310 a back end application or a database. 42 00:03:47,720 --> 00:03:52,780 It will be difficult for you to group these parts once they are deployed. 43 00:03:52,820 --> 00:03:59,300 If you label them now as front end backend or database you will be able to filter the parts based on 44 00:03:59,300 --> 00:04:02,470 this label at a later point in time. 45 00:04:02,550 --> 00:04:09,680 It's important to note that under metadata you can only specify name or labels or anything else that 46 00:04:09,680 --> 00:04:13,040 Coburn is expects to be under metadata. 47 00:04:13,040 --> 00:04:17,010 You cannot add any other property as you wish under this. 48 00:04:17,300 --> 00:04:23,370 However under the labels you can have any kind of key or value pairs as you see fit. 49 00:04:23,630 --> 00:04:28,290 So it's important to understand what each of these parameters expect. 50 00:04:29,000 --> 00:04:34,550 So far we have only mentioned the type and name of the object we need to create which happens to be 51 00:04:34,580 --> 00:04:36,250 a pod with a name. 52 00:04:36,260 --> 00:04:43,190 My app pod but we haven't really specified the container or image we need in the pod. 53 00:04:43,280 --> 00:04:50,990 The last section in the configuration file is the specification section which is written as spec depending 54 00:04:50,990 --> 00:04:53,300 on the object we are going to create. 55 00:04:53,300 --> 00:04:59,540 This is where we would provide additional information to carbonate as pertaining to that object. 56 00:04:59,540 --> 00:05:04,670 This is going to be different for different objects so it's important to understand or refer to the 57 00:05:04,670 --> 00:05:12,550 documentation section to get the right format for each since we are only creating a pod with a single 58 00:05:12,550 --> 00:05:13,870 container in it. 59 00:05:13,870 --> 00:05:24,510 It is easy spec is a dictionary so add a property under it called containers containers is a list or 60 00:05:24,510 --> 00:05:25,410 an array. 61 00:05:25,410 --> 00:05:31,410 The reason this property is a list is because the parts can have multiple containers within them. 62 00:05:31,440 --> 00:05:38,070 As we learned in the lecture earlier in this case though we will only add a single item in the list 63 00:05:38,370 --> 00:05:42,430 since we plan to have only a single container in the pod. 64 00:05:42,450 --> 00:05:48,810 The dash right before the name indicates that this is the first item in the list. 65 00:05:48,810 --> 00:05:50,930 The item in the list is a dictionary. 66 00:05:50,940 --> 00:05:58,280 So add a name and image property the value for image is in giant X which is the name of the Docker image 67 00:05:58,410 --> 00:06:06,660 in the docker repository once the file is created from the command cube TTL create that f followed by 68 00:06:06,660 --> 00:06:14,270 the file name which is part definition Don Hammel and Cuban artists creates the pod so to summarize 69 00:06:14,360 --> 00:06:23,480 remember the four top level properties API version kind metadata and spec then start by adding values 70 00:06:23,480 --> 00:06:29,750 to those depending on the object you are going to create once we create the part. 71 00:06:29,760 --> 00:06:32,580 How do you see it use the cube. 72 00:06:32,640 --> 00:06:33,300 Get parts. 73 00:06:33,300 --> 00:06:35,830 Command to see a list of parts available. 74 00:06:35,850 --> 00:06:40,740 In this case it's just one to see detailed information about the part. 75 00:06:40,740 --> 00:06:44,400 Run the cube CDL describe port command. 76 00:06:44,400 --> 00:06:48,220 This will tell you information about the part when it was created. 77 00:06:48,240 --> 00:06:49,890 What labels are assigned to it. 78 00:06:50,130 --> 00:06:56,330 What docker containers are a part of it and the events associated with that part. 79 00:06:56,360 --> 00:06:57,640 That's it for this lecture. 80 00:06:57,650 --> 00:07:01,250 We will now head over to a demo and I will see you in the next lecture.