hello everyone my name is abishek and welcome back to my Channel today is episode 4 of anible Zero to Hero series we have already completed three episodes in this series in the first episode we learned about introduction to anible and getting started with anible in the second episode we learned about anible ad hoc commands we learned things like passwordless authentication how to use inventory file in anible and some example anible ad hoc commands in episode 3 we learned how to write our very first anible Playbook by learning the basics of yaml anible Playbook structure what are anible plays modules and tasks in this video we will learn anible roles so there are two episodes dedicated ated for anible roles this is part one or day four where we will learn about the basics of anible roles where we will understand what exactly are anible roles why should you use anible roles we will learn about the folder structure of anible roles by creating a sample role we will also compare roles with playbooks because in day three we learned how to write an anible Playbook and using the anable Playbook we learned how to install Apachi and deploy a web application onto it so we will compare and see how anible roles are different from playbooks then we will create a sample role what we will do is what we have learned in day three we will take the same Playbook and we will Implement that using anible roles so this video is going to be very informative and this will be part one for the second episode where we will Deep dive into the anable roles further and we will understand about shared roles how to share the roles across organizations within your organization we will learn how to write complicated roles and all so please don't miss this video try to watch it till the end let's do a very quick recap of what we have have learned in day three so in day three we learned that anible Playbook is basically a yaml file and within the yaml file a devops engineer can put collection of plays so A playbook is basically collection or combination of plays so this can be play one and this can be play two where where in each play there are Fields like host where host says on which Post in the inventory file should this anible play execute then there are Fields like variables vs then there is remote user which explains using which user should this play execute on the map manage nodes then we have tasks so tasks are basically a collection of things that should be executed on the target servers or the manage nodes and within each task you provide a module so this is what we have learned about the anible Playbook structure in day three and we have also learned that once a devops engineer writes this anible Playbook it can be a single play or collection of plays this play or Playbook is fed as input to the control node where anible is installed so once the devops engineer writes this yaml file this yaml file is submitted to the control node using the command anible Playbook minus I the inventory file and then name of the anable Playbook right once this Playbook is fed as an input to the control node where anible is installed so what anible does is it reads this place and it will understand okay I need to execute these task as part of play one and again set of task as part of play two where I need to execute this action because a anible control node can have multiple manage nodes you might or might not want to run a anible play on all the manage notes so using this field so anible will process multiple plays in The Playbook when it process the first play it will read the host and it will understand okay I need to execute this set of tasks on this particular host if the host is all then it executes on all the manage nodes if the host is grouped to a particular group in the inventory file it understands okay I only need to execute on set of manage nodes using which user do I need to execute using the remote user that is mentioned so this input is taken by the anible in the control node so anable connects to this manage nodes whichever are required and it installs the modules that you provide in the task and then module is executed using python that is installed on the manage nodes so this is the workflow that we have learned and if you go to the GitHub repository and look for the day three folder we have a sample Playbook so this is the sample Playbook and this just has one play as I've mentioned in the theory part so this one play says host as all where this particular task there are two tasks in this play which has to be executed on all the hosts in the inventory file become true basically means that the remote user is root and this is Task one this is Task two anible reads this task looks into the module so these are the modules in the task and anible installs these modules on the target machine and executes them using python so this is the entire workflow that we have learned during day three now let's move to the topic for today that is roles so to explain roles in anable let me put you you some questions so in the previous example that we have seen there are only two task in the answerable Playbook because we were writing our very first answerable Playbook so we have chosen a very simple answerable Playbook that has only two tasks but imagine a scenario where you have an anible Playbook that has 50 number of tasks or an anible Playbook with 60 number of tasks not just the number of tasks but imagine a scenario where within your anible playbook you have post then you have multiple number of variables so let's say the case where you have 20 variables and then you have tasks where within the task section you might want to put some 40 50 tasks then you have something called handlers I'll explain what is handlers don't worry then you have the meta information of the anable Playbook so what happens in this case is not just that the size of your anible playbook goes high but this anible Playbook that you are writing will also lose things like readability right whoever is reading this anable Playbook imagine you open a Playbook yaml file right main. yaml file or you know your first Playbook do yaml file or whatever is the name of the Playbook you open a file and imagine you see 2,000 lines the moment you see this Playbook yaml file with 2,000 lines that is a red flag and will lose interest in reading the file but instead imagine the case where you can split this Playbook okay you can clearly see here there are multiple sections there is a section for variables there is a section for tasks there is a section for handlers there is a section for metadata what if you split the sections and each section you put in a different folder and within the folder you have individual yaml files you know at the first site you might feel it complicated you might think abishek I can write this entire playbook in one yaml file instead why should I create a folder for vs then why should I create a folder for tasks why should I create a folder for handlers why should I create a folder for meta in instead I can write only one yaml file but you know when you see a yaml file which is as simple as this everything looks good great but when you see the same yaml file with 2,000 lines immediately you will say that anible is complicated and I don't want to write the code in anible you know so that brings to the concept called as readability and modularity not just for anible for any programming language it can be python it can be go it can be even languages like terraform readability and modularity is very very important and to address that readability and modularity anible brings a concept called as roles where in simple language without any complication if you want to understand what is a role role is nothing but take a anible Playbook and if you split the different sections in the anible Playbook into different folders and place them under one umbrella called as role then that becomes Your anible Role so you don't have to learn anything additional in terms of anible role all that you need to do is if you know how to write a anible Playbook yaml file you can just take the individual parts and put them under each and every folder now you might say but abishek do I need to create this folders each and every time is it not complicated don't worry what anible does is let me pull my terminal so anible can create that entire folder structure for you by just running one command and the command is an Galaxy so we are learning a new command at this point of time till now we learned two anible commands one is the anible command itself when you want to execute ad hoc commands next we learned anible Playbook command when you want to execute the anible playbooks now I am explaining a new command which is called as anible Galaxy and this command is going to play a very very crucial role because this command will simplify creating managing deleting and listing of the anible roles now let me quickly show you how to create a role using anible Galaxy it's very very simple all that you need to do is anible Galaxy followed by role followed by in it right anible galaxy role in it and provide the name of the role that you want to create let's say the name of the role that I want to create is test so it said role test was created successfully let's see what did it do if you are wondering what are these files I'm not doing anything new I'm just taking the files from the day3 folder I mean I'm using the same files because I said in the introduction I will convert whatever you have learned in day three into the roles concept okay I'll explain roles even further then we will see how to convert the roles sorry the Playbook into the roles and we will also learn the execution part for now I have taken the same files okay the first Playbook folder first Playbook DOL and index.html we are using the same files but we have created a role called as test and like I have explained in the theory part within this role there will be this folders let's see if we have the folders or not if we just do test CD test and if I do LS or let me do LS hyphen LTR see we have the folders like vs tasks meta handlers additionally we have three folders one is files one is templates and the other is defaults don't worry I will also cover what are those things but before that it is very very important to understand why are we using roles and when should we go for roles if you're writing such simple anible playbooks you don't even have to worry about roles you can write them you can use them but when you are writing complicated anible playbooks abishek you keep telling complicated anible playbooks what exactly are they can you give some examples for sure let's take example of installing and configuring kubernetes you know not every organization go for managed kubernetes services such as e or AKs you know in your organization you might have a requirement to install kubernetes on the control nodes and the worker nodes terraform can create the infrastructure terraform is used to create the infrastructure right it's a ISC tool where you might spin up the ec2 instances VPC configuration but when you want to install the packages on the ec2 instances or the farget instances that is where anible comes into picture and this can be a complicated role because to install kubernetes you have your control nodes then you have your worker noes and on the control nodes you need to install and configure different workloads API server etcd then you have to set up uh container runtime container Network right and again on the worker nodes you might want to set up the cubet you might want to set up how worker nodes are joining with the uh control nodes so overall this Playbook like I've explained my easily go up to 50 60 tasks right so imagine you joined an organization and the seniors in the organization have given you a Playbook doyl file which has kubernetes installation and configuration you will see a file like this and immediately you will say it's very difficult to understand instead the same example kubernetes or another example let's say installation and configuration of databases like orle again there will be so many steps to install a version of orle configure that version of orle or any database so such things by using roles you can make your playbook more readable more modular and in future in future using the anible Galaxy you know anible provides something called as anible Galaxy the one that we saw here is the command line utility for the same right so using this anable galaxy you can create roles and you can upload that roles into this anible galaxy or to your GitHub and you can share the roles within your organization so the other advantage that roles brings here along with the routability and modularity this can be also shared across your or organization because roles can be uploaded to you know you can assume anable Galaxy as a Marketplace just like Docker has Docker Hub right Amazon has a Marketplace Docker has you know Marketplace like dockerhub or a registry similarly anible Galaxy also has something like this where you can just go to this roles and you can search for any role let's say you task is to set up kubernetes so just come here and search for the role you have different users a role to install kubernetes on Linux kubernetes on Linux so you'll have hundreds of such examples in your organization also you can use this or you can use GitHub also for sharing your roles so that you don't have to write the roles again and again if you're doing freelancing work or if you are open to cons consuming the roles which are public then your opportunities are endless imagine this is just like dockerhub a best example for you right so the other advantage that roles bring is readability modularity and also sharing across team's organization and across everyone outside your organization if you want don't worry we have in next video that is in day five we are going to explore anable Galaxy more you know you can see the topic where I will show you how to push your roles to anable Galaxy how to read the roles from the anible Galaxy on your local machine just like when we learned Docker we learned how to push the docker images how to pull the docker images how to list the docker images on your local machine similarly we will do everything with anible roles so right now I hope it is easy to understand when should you go for anible roles and why should you go for it very simple answer is readability modularity and sharing across different teams we also have this notes you know let's say after the class if you want to revise go to the day4 folder and look for the roles. MD file where I have explained why should someone go for anible roles by explaining the advantages now abishek what are the different folders in the anible role like you have explained that within an anible role there is vs okay I can understand what exactly is vs folder I believe within this V folder I can place some variables exactly right you know if you go here and there is a folder called vs if you go to that folder you can see a file called main. yaml you can change the name as well you can add new variable new multiple files also into the vs folder but you can start placing your variables here any number of variables if you have one variable two variable what kind of variables anything you can place them in the vs folder okay then you have explained there is Task folder again I can understand I can simply copy the task that are here right I can just copy the task that are here onto the again whm task there is a file called main. yaml I can simply copy paste them here okay great so the task thing is also clear then you said meta I can understand meta is about the metadata which is quite simple where again in the met. yaml file I can just write abishek is the author of this file abishek is the owner of it if you have any questions approach abishek or this is version one of the anible role you can add such metadata information now what about the other folders there are folders like handlers right then there is a folder called defaults then you have files and templates abishek what about these four folders let's learn about them first let's start with simple files so files is nothing but you know if you go back to the day three thing here you know I'm writing this entire code and I have a file which I'm copying to the Apachi default directory right w www HTML where I have placed that file index.html I am placing that along with the Playbook imagine the same case where you have multiple HTML files quite possible right when you want to build a very good static website you might have multiple HTML files you might have CSS files right now the problem is that when you have so many things in the same folder where your playbook do yaml is person who is looking at this Playbook might again feel confused you might have some yaml files also so what you can do is simply put them into the folder called files right so if you just go to this folder called files and add any number of files that you have here and in the Playbook right in this task that you writing instead of referencing directly you can just say files hyen index.html right this is the only change that you can do that's it perfect now let me close this okay abishek what about the other things why you have templates you know templates and files are almost similar the only difference is that when you have Dynamic files what if you have files where you want to keep some values in the file Dynamic best example is provided in here you know here I have a file called test. J2 J2 because you know anible follows the ginger templating standard where this is the content of my file where I'm saying my name is if you are creating an E2 instance and if you want to run this thing my name is anible host host name that is instead of writing your ec2 instance host name directly because it will keep changing what you can simply do is you can create a file called test. J2 or you know you can pass any kind of variables into the template files which makes the template files Dynamic you can put the files directly in the static uh approach into the files folder but when you want Dynamic files where the entries of the file can be modified in the anable Playbook then you should be going for templates right then next we have is defaults defaults are also variables but the difference between vs and defaults is that you know defaults as the name suggest are the default values that means if you are not providing any value to the variables that you have created then you can say by default take the value that is available in the default SL main. yaml then comes the final thing that is handlers now what about the case of handlers so handlers is basically anible tasks which you want to execute upon a particular action for example you can see here in this anible Playbook we have defined two handlers right one is restart mcast and restart Apachi ignore this one know let's say I want to write a Handler called restart Apachi so what I can do is execute this task Handler is also like a task where execute this particular thing only when a particular task is requesting for so in the task here we are basically placing a file like you know we are deploying a file and whenever a file is deployed or whenever a application is deployed you always want to restart your web server or the application server right such things can be placed in handlers because you might want to call this handlers multiple times in your anible Playbook or you might want to call these handlers occasionally only when it is required such things you can place as handlers handlers are task but only executed upon a particular action and someone notifies that the handlers have to be executed so here what we are doing we are writing a task where we are copying a file onto a particular location where Apache is reading that file and then in the task we are notifying we are saying that the Handler called restart Apachi has to be executed right this is the significance of handlers again I'm saying you don't have to worry if you are not completely understanding these things because this is your first day with anible roles so going ahead we will be doing examples with anible roles we have 10 more days to go where we will be using each and every folder that is mentioned here and we will use with examples so now abishek can we convert The Playbook that we have written in the last class so this was the Playbook right now let's convert this into the anible roles and try to execute it as role very simple all that you need to do is let's say someone is giving you a anible Playbook like this okay they have given you anable Playbook like this let's remove this RM hyphen RF test so this is given to you by your colleague and they have asked you to convert this anable Playbook into role so what you will simply do is first you will will use the anible Galaxy command rooll in it let's call this role as let's say httpd okay so this is created we can see if you just do lsen LTR httpd all the folders are created now let's go to the anible Playbook yaml or the first Playbook yaml and what I'm going to do I will simply copy these things here right because I just have task here I don't have vs I don't have handlers I don't have any other things I just have tasks so let me copy this and what I'm going to do I'm going to remove this okay just save this file for now I'm going to go to to the httpd role task main. yaml and I'm going to place them here okay whenever you have such Extra Spaces and you want to indent it you can just use control+ V Escape control+ V and you can remove all of them by by clicking on d d for delete okay now let me save this file okay abishek here what you have done is you removed the task from the first Playbook do yaml and as you explained in the theory part you put them in the HTTP folder inside the task but how will this first Playbook do yaml understand the tasks are present there or how will the first Playbook doyl understand what is the role that I have to use simply just go to the first Playbook doyl and just say roles because a Playbook can use or a play can use multiple roles here just write [Music] HTTP and abishek I also have a file called index.html okay no worries just copy the index.html and put that in HTT tpd okay and within the httpd files or we can directly move them right you don't even have to copy because I want to move it completely within the files I can just put it now if I again do LS I just have first Playbook yaml I have my inventory file and I have a role called httpd and within the role I'm not sure if I have di command okay that's okay so within the role called [Music] httpd I have a files folder where within the files folder I have placed my index.html then I have task folder where in the task main. yaml I have written the complete task now I have to for sure go to the SRC of it and I have to update the location of my index.html so roles does not do any magic for you it will only structure modularize and help in sharing your anible code everything you have to do it by your own So within the SRC folder I'll just say files SL index.html because it's available in the files folder perfect so now let's see if we can run it and if this anible role will execute successfully or not so for that I'm am going to do anible Playbook minus I inventory. ini first Playbook do yaml every time you run anible play the first thing that runs is gathering facts because it has to gather the facts it has to see if the target machine is reachable if the passwordless authentication is fine if it can install the module on it and execute the module all that things takes place in The Gather fact then install Apachi worked fine then copy files from owner and permissions executed but you can see the change tasks are zero okay all the three tasks are executed but changed are zero why because anable is item poent in nature I explained this In First Class where if something is already available the thing that you are trying to do if it is already available on the target machine or the manage nodes anible will not execute that again if you're taking shell script or python for an example what happens with shell script if you're telling shell script to create a directory even though the directory is present okay for example if I do mkd ABC okay now ABC folder is available if I again do mkd ABC shell script will fail or the shell command will fail this nature is not called as itm poent whereas if you do the same thing with anel create a folder once and create the folder again anible will not create the folder because it says the folder is already available I don't have to create it this nature is called as item poent which is very important characteristic of anible that's why here you can see that the number of tasks are executed three but nothing is changed on the target machine so now let's connect to one of the ec2 instance and let's delete that HTM file let's see if an is going to create it or not that way we can confirm our roles are working right previously the configuration was already there so it did not create anything so let's take manage node one and uh connect let's use the E to instance connect I'll take the pseudo uh user and uh I'll try to delete it the V ww HTML so let's just do sudo Su hyen I'm with the root user let's do V Let's do www let's do HTML and here we have the index.html now let's remove this okay and let's rerun this command Now using roles let's see if the same thing is working or not I I have to see one task in the change status okay it is running you can clearly see it took some time in the execution of this particular thing and it said changed as one let's see I have deleted it and if I do it and I have the index.html file so this is how the anible roles are going to work where you will just take the Playbook and you will restructure modularize it so that you can reuse that Playbook that is called as anible role going ahead in the next classes you are going to understand more advantages of roles how roles can change the game of anible how you can share it across the organizations how you can reuse that piece of code how you can make complicated answerable playbooks as simple as possible thank you so much for watching today's video I hope you found it useful stay tuned for the next one take care bye-bye