1 00:00:00,180 --> 00:00:06,060 In this lecture, we will discuss about imperative and declarative approaches in communities towards 2 00:00:06,060 --> 00:00:07,060 the end of this lecture. 3 00:00:07,350 --> 00:00:10,590 We will talk about some tips that you can use in the exam. 4 00:00:11,730 --> 00:00:17,520 So far, we have seen different ways of creating and managing objects in communities. 5 00:00:19,290 --> 00:00:24,930 We created objects directly by running commands, as well as using object configuration files. 6 00:00:25,680 --> 00:00:31,890 Now, in the infrastructure as code world, there are different approaches in managing the infrastructure 7 00:00:32,310 --> 00:00:36,840 and they are classified into imperative and declarative approaches. 8 00:00:39,600 --> 00:00:46,170 Let's understand this with an analogy, let's say you want to visit a friend's house located at St. 9 00:00:46,170 --> 00:00:53,910 B and the past you would hire a taxi and give Step-By-Step instructions to the driver on how to reach 10 00:00:53,910 --> 00:01:00,090 the destination, like take right to Street B, then take left to go to Street C, and then take another 11 00:01:00,090 --> 00:01:07,320 left and then right to go to Street D and stop at the house specifying what to do and how to do. 12 00:01:07,320 --> 00:01:10,560 More importantly is the imperative approach. 13 00:01:11,280 --> 00:01:18,480 On the other hand, today when you book a cab, say through Uber, you just specify the final destination, 14 00:01:18,510 --> 00:01:20,010 like drive to Tom's house. 15 00:01:20,550 --> 00:01:23,070 And this is the declarative approach. 16 00:01:23,070 --> 00:01:26,240 In this case, we are not giving Step-By-Step instructions. 17 00:01:26,250 --> 00:01:29,730 Instead, we're just specifying the final destination. 18 00:01:29,940 --> 00:01:32,370 We're declaring the final destination. 19 00:01:32,730 --> 00:01:39,510 And the system figures out the right path to reach the destination, specifying what to do, not how 20 00:01:39,510 --> 00:01:41,470 to do, is the declarative approach. 21 00:01:42,270 --> 00:01:48,000 So what's that got to do with what we are learning in the infrastructure as code world? 22 00:01:48,010 --> 00:01:54,750 An example of an imperative approach of provisioning infrastructure would be a set of instructions right 23 00:01:54,870 --> 00:02:01,260 step by step, such as provisioning a VM named a Web server, installing the Ingenix software on it, 24 00:02:01,590 --> 00:02:08,760 editing configuration file to use Port AT&T and setting the path to Web files, downloading source code 25 00:02:08,760 --> 00:02:13,170 of repositories from GIT and finally starting the engine server. 26 00:02:13,830 --> 00:02:19,710 So here we are saying what is required and also how to get things done. 27 00:02:20,340 --> 00:02:24,180 In the declarative approach we declare our requirements. 28 00:02:24,180 --> 00:02:29,790 For instance, all we say is that we need a VM by the name Web server with the Internet software on 29 00:02:29,790 --> 00:02:36,150 it with a port said to eighty eight and the path to the web files defined and where the source code 30 00:02:36,150 --> 00:02:38,100 of the application is is stored. 31 00:02:38,520 --> 00:02:45,300 And everything that's needed to be done to get this infrastructure in place is done by the system or 32 00:02:45,300 --> 00:02:45,920 the software. 33 00:02:46,440 --> 00:02:53,070 You don't have to provide step by step instructions, orchestration, tools like Ansible Puppet or chef 34 00:02:53,430 --> 00:02:55,740 or terraform fall into this category. 35 00:02:56,790 --> 00:03:02,350 And the imperative approach, what happens if the first time only half of the steps were executed? 36 00:03:02,790 --> 00:03:08,370 What happens if you provide the same set of instructions again to complete the remaining steps to handle 37 00:03:08,370 --> 00:03:09,500 such situations? 38 00:03:09,510 --> 00:03:15,930 There will be many additional steps involved, such as checks to see if something already exists and 39 00:03:15,930 --> 00:03:18,530 taking an action based on the results of that check. 40 00:03:19,050 --> 00:03:25,490 For instance, while provisioning EVM, what would happen if a m by the name Web server already exists? 41 00:03:26,130 --> 00:03:32,280 The same goes with creating a database or importing data should it fail or should it continue since 42 00:03:32,280 --> 00:03:33,510 the VM is already there? 43 00:03:34,110 --> 00:03:39,840 What if we decide to upgrade the version of software to say in the next one or one eight in the future, 44 00:03:40,380 --> 00:03:46,920 it should be as simple as updating the version of Engine X in the configuration file and the system 45 00:03:47,100 --> 00:03:48,690 should take care of the rest. 46 00:03:49,500 --> 00:03:56,040 Ideally, the system should be intelligent enough to know what has already been done and apply the necessary 47 00:03:56,040 --> 00:03:56,610 changes. 48 00:03:56,610 --> 00:04:00,170 Only that's the declarative way of doing things. 49 00:04:01,860 --> 00:04:08,010 In the corporate world, the imperative way of managing infrastructure is using commands like the cattle 50 00:04:08,010 --> 00:04:13,080 run command to create a pod that you've got to create a deployment command to create a deployment, 51 00:04:13,530 --> 00:04:17,400 the expose command to create a service to expose the deployment. 52 00:04:17,820 --> 00:04:23,910 And the added command may be used to edit an existing object for scaling a deployment or replicates 53 00:04:23,910 --> 00:04:24,090 it. 54 00:04:24,090 --> 00:04:28,670 Use the scale command and updating the image on a deployment. 55 00:04:28,680 --> 00:04:31,230 We use the whole set image command. 56 00:04:32,270 --> 00:04:38,660 We have also used object configuration files to manage objects such as creating an object, using the 57 00:04:38,670 --> 00:04:45,660 character to create that command with the option to specify the object configuration file and editing 58 00:04:45,660 --> 00:04:51,970 an object using the cube to replace command and deleting an object using the cubicle delete command. 59 00:04:52,590 --> 00:04:57,570 All of these are imperative approaches to managing objects and capabilities. 60 00:04:58,140 --> 00:05:04,950 We are saying exactly how to bring the infrastructure to our needs by creating, updating or deleting 61 00:05:04,950 --> 00:05:05,430 objects. 62 00:05:06,210 --> 00:05:13,020 The declarative approach would be to create a set of files that defines the expected state of the applications 63 00:05:13,020 --> 00:05:14,880 and services on a continuous cluster. 64 00:05:15,390 --> 00:05:23,220 And with a single API, command coordinators should be able to read the configuration files and decide 65 00:05:23,220 --> 00:05:28,350 by itself what needs to be done to bring the infrastructure to the expected state. 66 00:05:28,920 --> 00:05:35,490 So in the declarative approach, you will run the code to apply command for creating, updating or deleting 67 00:05:35,490 --> 00:05:36,120 an object. 68 00:05:36,690 --> 00:05:43,020 The API command will look at the existing configuration and figure out what changes need to be made 69 00:05:43,290 --> 00:05:44,010 to the system. 70 00:05:44,980 --> 00:05:49,790 So let's look at these in a bit more detail now within the imperative approach. 71 00:05:49,810 --> 00:05:50,980 There are two ways. 72 00:05:51,460 --> 00:05:58,120 The first is using imperative commands such as the run, create or expose commands to create new objects 73 00:05:58,480 --> 00:06:02,320 and the added scale and said commands to update existing objects. 74 00:06:02,800 --> 00:06:08,650 Now, these commands help in quickly creating or modifying objects as we don't have to deal with YAML 75 00:06:08,650 --> 00:06:12,400 files and these are helpful during the certification exams. 76 00:06:12,850 --> 00:06:18,490 However, they are limited in functionality and will require forming long and complex commands for advanced 77 00:06:18,490 --> 00:06:22,210 use cases such as creating a multi container pod or deployment. 78 00:06:22,870 --> 00:06:26,050 Secondly, these commands are run once and forgotten. 79 00:06:26,200 --> 00:06:30,070 They are only available in the history of the user who ran these commands. 80 00:06:30,430 --> 00:06:35,150 So it's hard for another person to figure out how these objects were created. 81 00:06:35,290 --> 00:06:37,040 So it is hard to keep track of. 82 00:06:37,480 --> 00:06:41,710 And so it's difficult to work with these commands in large or complex environments. 83 00:06:42,280 --> 00:06:47,350 And that's where managing objects with the object configuration files can help. 84 00:06:48,430 --> 00:06:55,360 Creating object definition files or configuration files or manifesto files, as it's also called, can 85 00:06:55,360 --> 00:07:01,910 help us write down exactly what we need the object to look like in a Yamal format and use the kicker 86 00:07:02,020 --> 00:07:04,220 to create command to create the object. 87 00:07:04,780 --> 00:07:11,050 We now have the YAML file with us always, and it can be saved in a code repository like it. 88 00:07:11,620 --> 00:07:17,770 We can put together a change review and approval process around these files so that a change made is 89 00:07:17,770 --> 00:07:23,620 reviewed and approved before it is applied to a production environment in the future. 90 00:07:23,620 --> 00:07:29,320 If it changes to be made, for instance, editing the image name to another version, there are different 91 00:07:29,320 --> 00:07:30,620 ways to go about it. 92 00:07:31,000 --> 00:07:36,210 One way is to use the cubicle to edit command and specify the object name. 93 00:07:36,850 --> 00:07:44,260 So when this command is run, it opens a Yamal definition file similar to the one you used to create 94 00:07:44,260 --> 00:07:44,860 the object. 95 00:07:45,130 --> 00:07:50,710 But with some additional fields, such as the status fields that you see here, which are used to store 96 00:07:50,710 --> 00:07:52,010 the status of the pod. 97 00:07:52,930 --> 00:07:56,890 This is not the file you used to create the object. 98 00:07:57,160 --> 00:08:01,780 This is a similar pod definition file within the coronets memory. 99 00:08:01,930 --> 00:08:09,010 You can make changes to this file and save and quit and those changes will be applied to the life object. 100 00:08:09,400 --> 00:08:15,880 However, note that there is a difference between the live object and the definition file that you have 101 00:08:15,880 --> 00:08:16,320 locally. 102 00:08:16,750 --> 00:08:21,490 The change you made using the to edit command is not really recorded anywhere. 103 00:08:21,880 --> 00:08:28,480 After the change is applied, you're only left with your local definition file, which in fact has the 104 00:08:28,480 --> 00:08:30,670 old image name in it. 105 00:08:31,800 --> 00:08:38,460 In the future, say, you or a team may decide to make a change to this object, unaware that a change 106 00:08:38,460 --> 00:08:44,670 was made using the edit command when the new change is applied, the previous change to the image is 107 00:08:44,670 --> 00:08:45,060 lost. 108 00:08:45,630 --> 00:08:47,970 So you can use the edit command. 109 00:08:48,270 --> 00:08:53,700 If you are making a change and you're sure that you're not going to rely on the object configuration 110 00:08:53,700 --> 00:08:54,600 file in the future. 111 00:08:55,320 --> 00:09:01,650 But a better approach to that is to first edit the local version of the object configuration file with 112 00:09:01,650 --> 00:09:09,120 the required changes, and that is by updating the image name here and then running the cubicle to replace 113 00:09:09,120 --> 00:09:11,220 command to update the object. 114 00:09:12,330 --> 00:09:19,140 This way going forward, the changes made are recorded and can be tracked as part of the change review 115 00:09:19,140 --> 00:09:19,680 process. 116 00:09:20,580 --> 00:09:26,670 So at times you may want to completely delete and recreate objects in such cases, you may run the same 117 00:09:26,670 --> 00:09:30,540 command but with the force option like this. 118 00:09:31,840 --> 00:09:39,190 Now, this is still the imperative approach because you're still instructed is how to create or update 119 00:09:39,190 --> 00:09:44,650 these objects first, you're only to create command, to create the object, and then you run the replace 120 00:09:44,650 --> 00:09:48,020 command to replace the object or delete command or delete the object. 121 00:09:48,670 --> 00:09:50,800 And what if you run the create command? 122 00:09:50,800 --> 00:09:56,740 If the object already exists now, then it would fail with an error that says the part already exists. 123 00:09:57,280 --> 00:10:02,170 When you update an object, you should always make sure that the object exists first before running 124 00:10:02,170 --> 00:10:03,090 the replace command. 125 00:10:03,610 --> 00:10:07,650 If an object does not exist, the replace command failed with an error message. 126 00:10:08,470 --> 00:10:15,520 So the imperative approach is very taxing for you as an administrator, as you must always be aware 127 00:10:15,790 --> 00:10:22,120 of the current configurations and perform checks to make sure that things are in place before making 128 00:10:22,120 --> 00:10:22,680 a change. 129 00:10:24,180 --> 00:10:29,880 The declarative approach is where you used the same object configuration files that that we've been 130 00:10:29,880 --> 00:10:36,510 working on, but instead of the creator, every place commands, we used to apply command to manage 131 00:10:36,510 --> 00:10:36,990 objects. 132 00:10:37,560 --> 00:10:44,010 The cubicle apply command is intelligent enough to create an object if it doesn't already exist. 133 00:10:44,400 --> 00:10:50,850 If there are multiple object configuration files, as you would usually, then you may specify a directory 134 00:10:50,880 --> 00:10:52,860 as the path instead of a single file. 135 00:10:53,130 --> 00:10:56,340 That way all the objects are created at once. 136 00:10:56,910 --> 00:11:03,980 Now, when changes are to be made, we simply update the object configuration file and run the apply 137 00:11:03,990 --> 00:11:04,650 command again. 138 00:11:04,800 --> 00:11:11,640 And this time it knows that the object exists and so it only updates the object with the new changes. 139 00:11:12,210 --> 00:11:18,840 So it never really throws an error that says the object already exists or the updates cannot be applied 140 00:11:19,260 --> 00:11:22,990 and will always figure out and the right approach to updating the object. 141 00:11:23,490 --> 00:11:29,610 So going forward, any changes made on the application, whether they're updating images or fields of 142 00:11:29,610 --> 00:11:36,240 existing configuration files or adding new configuration files altogether for new objects, all they 143 00:11:36,240 --> 00:11:42,510 do is simply update our local directory with the changes and then apply command, take care of the rest. 144 00:11:43,320 --> 00:11:50,980 So we will discuss more about how the command works exactly in the backend in the next lecture. 145 00:11:51,690 --> 00:11:56,200 For now, let me give you some tips as part of the exam. 146 00:11:56,700 --> 00:12:02,970 So from an exam perspective, you could use the imperative approach to save time as much as possible. 147 00:12:04,110 --> 00:12:09,300 For example, if the question is to just create a path or a deployment with a given image, then one 148 00:12:09,300 --> 00:12:12,040 of these imperative commands can help you achieve that quickly. 149 00:12:12,300 --> 00:12:14,790 So it's important to practice the imperative commands. 150 00:12:15,180 --> 00:12:21,600 If you need to edit a property of an existing object, then using the edit command, um, maybe the 151 00:12:21,600 --> 00:12:22,350 quickest way. 152 00:12:22,860 --> 00:12:23,170 Right. 153 00:12:23,640 --> 00:12:29,730 If you have a complex requirement for, say, for example, that requires multiple container's environment 154 00:12:29,730 --> 00:12:36,150 variables, commands in containers, etc., then using an object configuration file to create object 155 00:12:36,150 --> 00:12:36,900 would be preferred. 156 00:12:37,440 --> 00:12:37,890 This way. 157 00:12:37,890 --> 00:12:43,770 If you see that you made a mistake, you can easily update the file and apply it again. 158 00:12:43,980 --> 00:12:49,270 And using the high command in that case would be a better option. 159 00:12:49,290 --> 00:12:55,470 So for more details on the different approaches to managing a cluster, get yourself familiarized with 160 00:12:55,470 --> 00:13:01,980 the community's documentation pages and in the upcoming lab exercises, try to use imperative approach 161 00:13:01,980 --> 00:13:03,000 in solving questions. 162 00:13:03,300 --> 00:13:05,670 Well, I will see you in the next lecture.