DevOps - Ansible for the Absolute Beginners

1. Introduction 2: hello and welcome to this course on answerable fundamentals. My name is Mom, Schattman, Lambeth and I work as a solutions architect. I have been using answerable for automation in my solutions. And it is a great tool that is easy and can save you a lot of time. This is a hands on beginner's guide to answerable. When I started learning answerable first, all I could find what's the answerable documentation which we will look through. And I had to have access to a system with answerable installed on it to do and understand various concepts. Some of the concepts took a little bit time for me to get around. So I put together this cause for the absolute beginner. You really don't need to have access to a system with danceable or an environment set up to alone answerable. Well, it's always good to have, and I would strongly recommend to set up a real system to put your knowledge to action. But what I'm trying to say here is that this course provides coding exercises where you will be developing answerable playbooks right in your browser, and we will test to see if they're done right, so it's literally hands on and a great way to start learning answerable. So how exactly does this coursework? This course contains lectures on various topics, followed by some coding exercises where he will practice writing answerable playbooks. You will be developing Ansel playbooks for different use cases, which will give you a pretty good idea on how to start developing using, answerable, and get a lot of things done in a short amount of time and make your work more productive and collaborative. So what are we going to cover in this course? We will get started with understanding what answerable is and what it can do. This is for those who have no idea what answerable is and what it can do for us. So we will spend some time understanding that we will go through how to set up answerable in your environment. This is only if you wish to set up answerable. Now you can skip this and had straight into developing playbooks. And later on, when you're confident enough, come back and look at this again. Then we will get started with an introduction to Yam Oh, because yeah, Mo is the coding language for answerable all answerable play books are written in Yamma. If you already worked with the ammo, feel free to skip over that model. If not, get your hands dirty. With some exercises on Yemen, we will then head over to answerable, invent REFILES, playbooks and various concepts such as variables, condition, ALS, loops and rolls. Also, there are a lot of hands on coding exercises, so practice practice in practice. So why answerable in this section? We're going to discuss about what answer will ease and what it can do for you. If you already know what answer believes and you are here for some coding exercises, feel free to skip this lecture because in this section, we're going to discuss answerable at a very basic level to understand what it is and what it can do for you. So let's get started now. If you were a systems engineer or I T administrator or just anybody working in I t. You were probably involved in doing a lot of repetitive tasks in your environment, whether it be sizing and creating new hose or washing machines every day, applying configurations on them, patching hundreds of servers, migrations, deploying applications or even performing security and compliance audits. All of the's very repetitive task involves execution of hundreds of commands on hundreds of different servers while maintaining the right sequence of events with system reboots in between and what not smart people developed scripts to automate these tasks, but that requires coding skills and regular maintenance off the scripts and a lot of time to put this scripts together on the first place. That's where answerable comes into play. Answer is a powerful I T automation toe that you can quickly learn. It's simple enough for everyone in I t yet powerful enough to automate even the most complex deployments. Let's take a look at a simple use case. Imagine you have a number of hosts in your environment that you would like to restart in a particular order. Some of them are Web servers, and others are database servers. So you would like to power down the Web servers first, followed by the database servers than power up the database servers and then the Web servers. You could write unanswerable playbook to get this done in a matter of minutes and simply invoke the answerable playbook every time you wish to restart your application. Let's take a look at a complex example. In this case, we're setting up a complex infrastructure that spans across public and private cloud and hundreds of free EMS with danceable. You could Prohibition V EMS on public clouds like Amazon and probation. Private Cloud in private cloud set up like being were based infrastructure and move on to configuring applications on those systems and set up communications between them. There are a lot of built in modules available in answerable that supports these kind of operations. To begin with, the best place to start learning answerable is the Answer Bill documentation website. The answerable documentation pages are comprehensive and contains all information required to get started with danceable, and there are hundreds of examples off playbooks in these pages. Get familiar with the Answerable Documentation website at dark. Start answerable dot com. It contains information about setting up and installing, answerable various concepts, best practices, information about different modules and guides on advanced topics such as developing custom modules, custom strategies, etcetera, 2. Inventory: answerable can work with one or multiple systems in your infrastructure at the same time, in order to work with multiple servers, answerable needs to establish connectivity to those servers. This is done using Ssh for Lennox and Power Shalrie Moting for Windows. That's what makes answerable agent lists. Agent less means that you don't need to install any additional software on the target machine to be able to work with answerable a symbol. Ssh connectivity would surface answerable. Snead's. One of the major disadvantages off most other orchestration tools is that you are required to configure an agent on the target systems before you can invoke any kind of automation. Now, information about these target systems is stored in a file called In Wintry File. If you don't create a new in wintry file answerable uses three default Invent Refile, located at E. T. C. Answerable host. Let's take a look at a sample in mentally fire. The inventory file is an iron I like format. It's simply a number off servers listed one after the other. You can also group different silver's together by defining groups, enter the name of the group in square brackets and defined the list of servers part of that group in the lines below, you can have multiple groups defined in a single in men tree file. This is especially useful when you're performing different operations on different groups of servers. Let's say you have a set off observers where you wish to install a city PD services and Conficker Web server, and you have a separate set of servers, which are database servers where you like to install and configure database. In these cases, you can target different groups off servers at once, using the groups that you define in the inventory file. Let's take a deeper look into inventory files. For example, I have a list of servers named from 1 to 4. However, I would like to refer to these servers in answerable using an alias, because currently it's defined with their EFC UDN. But I necessarily mean not know the purpose of the silver Looking at the F Guardian. In such cases, we could use an alias to describe if the server is a Web server or a database server. I could do this by adding an alias for eat server at the beginning of the line and assigning the address off the server to answer will underscore Host Perimeter Answerable Underscore Host is an inventory perimeter used to specify the F Cody in or I p address off the server. There are other inventory parameters to some of the other key inventory. Perimeters are answerable, connection, answerable port and simple user and answerable. Ssh! Pass answerable connection is what defines how answerable connects to the target. Silver, as we discussed in the previous slide, is this a ssh connection to Aalen X over or a winner in connection to a windows over? This is how we define if the target host we wish to connect to hazelnuts or a Windows host . You could also said it to local host to indicate that we would like to work with local host and not connect to any remote hosts. If you don't have multiple servers to play around with, you could simply start with a local host in urine. Mentally file. Answerable Port defines which port to connect to by default. It is said to port 22 for SS age, but if you need to change, you can set it differently. Using answerable port perimeter answerable user defines the user used to make a remote connections by default. This is said to root for early next machines. If you need to change this, define it as shown here. Answerable. Ssh! Past defiance The ssh password for Lennox. Now you must be thinking, if storing passwords in plain text format is ideal, well, it's definitely not very idea, and answerable has a solution for it. Look for answers. Vault in the answerable documentation to see how you can securely store your passwords will basically answerable. Vault uses encryption where you will be encrypting your inventory files or any other files storing your passwords or any secure data using a pass race so you can basically encrypt your files using answerable world. And whenever you run your playbook, you input the pass phrase and answerable decrypt Stofile and reads the password from those files. So that's definitely a secure option. And look for more about that in the answerable documentation site. So go ahead to coding exercises and try to create some in mentally files. We will stick to what we learned so far and create invent REFILES in its basic format. There are different ways of trading in wintry files and different ways off defining variables like what we just saw defining variables if in the end inventory file. But that's not a best practice. There are other ways off defining variables, which we will look at in more detail in one of the upcoming lectures. So for now, let's stick to the basics. Let's take baby steps. So go ahead and create some sampling, wintry files and the coding exercises. 3. Playbooks: answerable playbooks. Our answer. Bols orchestration, language. It is in play books where we define what we want answerable to do. It is a set of instructions you provide answerable to work its magic. So, for example, it can be as simple as running a series of commands on different servers in a sequence and restarting those servers in a particular order. Or it could be as complex as deploying hundreds off VM in the public and private cloud infrastructure provisioning stories to be EMS, setting up their network and cluster configurations. Configuring applications on them, such as a Web server or database. Silver setting load balancing, setting up monitoring components, installing and configuring backup clients and updating configuration database with information about the new viens. Let's take a deeper look at how play books are written. Remember, all play books are written in Yamil format, which is why we spend some time earlier. Getting our hands dirty with yamma a playbook is a single Yamil file containing a set off place. It play defines a set off activities or task to be run on a single or a group of host at task. It's a single action to be performed on a host. Some examples off it ask, are executing a command or script on the hose, installing a package on the host or performing a shutdown or a restart operation on the host. Let's take a look at an actual playbook. Shown here is a symbol playbook that contains a single play named Play one. The goal of this play used to run a set of activities, one after the other on the local host. Remember that the host you want to run these actions is defined at the player level. In this case, we just want to test on the local host, which is why it is set to local host. This could be anything from your inventory file. So basically, at play is what defines what action you want to do on what host all the tasks listed under this particular play will be executed against those host. And those hose could be any number of hosts, or, in this case, it's just a local host. Next we run a set of commands, one after the other on the host. First we print the date, then we run a script on the silver, followed by installing the ace to TPD package, using the young model and finally starting the Web server using the service model. Now, if you don't understand what each of thes task does exactly and how it is defined, don't worry. We're going to take a better look at each of these in a few minutes. But for now, I just wanted to give you an idea on how a particular answerable playbook looks. Let's look at this sample playbook format and try to relate it to what we learned in the Amel section earlier have made a minor change and split the list of tasks into two separate place. The Amel file, which is our playbook, contains a list off to place. This is noted by the dash, so the dash indicates that it is an item in the list, so the playbook is a list off dictionaries. In Yanal's terms, each player is a dictionary and has a set of properties called name host and tasks. Remember, these are properties off a dictionary, and so the order doesn't really matter. So even if you swap the position off name and host, it's still a valid play. However, this is not the same for task. The task, as you can see, is a list as denoted by the dashes. Lists are ordered collection, so the position off entries matter If you stop the position of entries here, we are instructing answerable to start the Web service first before installing the hit City PD service, which is not a desired solution. So the yamma format is key. While developing playbooks, you must pay extra attention to the indentation and structure off this file. The host perimeter indicates which hosts you want to run these operations on. Remember, the host you want to perform this operations against is always set at a player level. Currently, this is to local host, which means that all these actions listed under the task is going to be performed on the local host. You could have any host or groups specified here, but you must ensure that the host or group is first defined in the inventory file recreated earlier. The host, defined in the inventory file, must match the host used in the playbook, and all connection information for the host is retrieved from the inventory file. Now there is no hard rule to use all the host defined in the inventory file. You could choose one or multiple or a group or multiple groups from the inventory file in the plate, but you really don't have to use all of them. Whatever host you have to find in the play, the play book should be defined in the inventory file. Otherwise, it's not going to run. Let's look at what a module is. The different actions run by task are called models. In this case, command script. Yum and service are all answerable modules. There are hundreds of other modules available out of the box. Information about these modules is available in answerable documentation website, or you could simply run the command answerable hashtag dash L on your answerable system To get familiar with the basic playbook structure in the upcoming exercises, you simply need to know the command module. Later on, in the next section, we will go through some other basic modules in more detail. If you look at the command module, you will see that you could simply specify the command you wish to run. In this case, date and answerable will execute that command on that particular silver. Finally, once you successfully build. The answer will play book. How do you run it? It's very simple. Execute the answerable playbook command and specify the name of the answerable playbook you just created. And that's it. If you do answerable playbook, dash help, you will get to know more about some additional perimeters available for this command. We will go through some of them in a later section, so go ahead and get your hands dirty. Developing some answerable playbooks encoding exercises. We're just going to get you familiar with basic playbooks and playbook structure. The whole idea is to get you familiar with how it plays defined and what it is and how tossed are defined and to understand the difference between them, we will focus on more realistic use cases in the upcoming lectures. But for now we will stick with real basics. So check out the upcoming Coding Exercises section and good luck 4. Modules: in this section, we're going to look at some additional answerable modules in a bit more detail. This is required so we can practice developing some more meaningful playbooks. Answerable modules are categorized into various groups based on their functionality. As I said earlier, there are hundreds off answerable models available so they're categorized into some of these system modules are actions to be performed at a system level, such as modifying the users and groups on the system, modifying I P tables and fireball configurations, working with logical volume groups, mounting operations or working with services, for example, starting stopping or restarting services in a system. Command modules are used to execute commands or scripts on a host. These could be simple commands using the command module or an interactive execution using expect by responding to problems. You could also run a script on the host using the script. Montiel file modules help with working with files. For example, using the A C L Modu to set and retrieve a C l information on files used the archive and UN archive modules to compress and unpack files use, find lining file and replace modules to modify the contents off an existing file data base models helps in working with databases such as Mongo, DB, Emma's, SQL, my SQL or Post Chris SQL To add or remove databases or modify database configurations, etcetera. The Cloud section has a vast collection off modules for various different cloud providers like Amazon. Sure, Docker, Gugu, Open, Stack and VM were being just a few of them. There are a number off models available for each of thes that allow you to perform various tasks such as creating and destroying instances, performing configuration changes in networking, insecurity and managing containers, data centers, clusters, worship, networking, re sand and a lot more. And then there are Windows modules that help use answerable in a Windows environment. Some of them are win copy to copy files. Win Command to execute a commander on Windows Machine, and there are a bunch of other models available to work with files on Windows Creating II s website. Install a software using Emma science dollar making changes to registry using rigid IT and manage services and users in Windows. These are just a few modules in few categories, there are lots more, and a comprehensive list can be found at dark. Start answerable dot com, along with detailed instructions on each of them. Let's look at a few of these models in detail to understand how you can use them and how to read the documentation page. We will start with command module. The command module is used to execute a command on a remote node. The perimeters of the command module, as listed in the documentation page, is shown here. Shown is a sample answerable playbook using the command module. As you can see To use the modu, you simply create a key value. Pair off the module name and the perimeter, which is the command in this case. In this case, we're instructing answerable to run the date command on the host, followed by executing the cat. TTC resolved or complement to list the contents of the file in case you needed to change directory. But before executing a command, for example, I will rewrite the second command in if different form now, by removing E. T. C from the cat command and setting change directory prime perimeter to TTC. This will ensure that answer will changes Directory to E. T. C. Before executing the command. This is how a perimeter and value is passed to the command module. The creates perimeter is used to perform a check before the command is run. For example, this command to create the folder will only run if the folder does not already exist. The remaining perimeters are self explanatory, so we will skip them. Except for this one right here called free form. This is worth looking at as you may see it in different modules. Free form indicates that this model takes a freeform command to run. So what does that mean? You will not be able to input a perimeter with the name freeform like how we just input a CHD IR or creates our command input such as cat TTC resolved at Khan for N. K. D. A. R forward slash folder is the freeform input. Not all models support input like this. For example, the copy model, which is used to copy files from a source to a destination on Lee, takes parametric ized input and not freeform input. So, as you can see here, copy requires a source file as SRC perimeter and destination as tst perimeter. Another model to look at is the script module. The script module executes a local script on one or more remote notes after transferring it to run a script on one or hundreds of servers, you really don't have to copy it over to all the servers. First, answerable takes care off, automatically copying the script to the remote node and then executing it on the remote systems. This is done through a very simple play that looks like this used the script module and specify the location of the script on the answerable controller machine and the arguments. Let's look at the service module. The service module is used to manage services on a system such as starting, stopping or restarting a service. The sample and civil playbook is used to start various services in a particular order. First, we start the database service using the service module. The service module, unlike the previous models, do not have a freeform input, which means you have to pass include in a key value pair format. We use the name perimeter to specify the name of the service we wish to start in this case , Post Chris SQL and the State perimeter indicates the operation. We would like to perform in this case started. Now, if you're wondering why it is started instead of start, hold on to your thoughts. We will come back to that in a bit. There are two ways writing this statement. You can either write it like this or write it in a dictionary or map format like this. They're one and the same. Remember in yeah, milestones Name and state our properties off a service. So if you look at the difference on the left, you have the parameters passed in ass name equals post, Chris SQL and state equals started. But on the right, you have the name in state defined in a more yeah mo format. And in the next line as a key value pair separated by semi colon. Both of these are one and the same. Let's add a few more tests to start a CDPD service and India next service. So back to our question on why the action is started and not start. If we were to instruct answerable to start the service, we would say start the service STT PD and not started the service a City PD. So then why is it started and not start. We're not instructing answerable to start the service. Instead, we're instructing answerable to ensure that the service STT PD is started. That essentially means if his CDPD service is not already started started. If a sensitivity service is already started, then don't do anything. This is called I'd impotency ask for the answerable. Documentation and operation is I'd impotent if the result of performing it once is exactly the same as the result of performing it repeatedly without intervening actions thus started , stopped and restarted. Actions instruct answerable to ensure the state of the service. Majority of the modules in answerable are right, impotent and answerable highly recommends this. The overall idea is that you should be able to run the same play book again. An answerable should report that everything is in an expected state. If something is not answerable, takes care of putting it into the expected state. Let's look at another module called the Line in file model. The line in fire module is used to find a line in the file and replace it or add it if it doesn't already exist. For example, were given a task to add a new Deanna server into the e t c resolved dot com file This simple, answerable playbook using the Lining file task adds the new names over information into the E. T. C. Resolved at con file. Remember, the line and file module is, I don't pretend. Let's compare this answerable playbook with a simple script that tries to achieve the same result. If this script is run multiple times, it adds a new entry into the file each time, which is not desired. If you're on the answerable playbook multiple times, it will ensure that there is only a single entry in the file. We will stop there with modules. We will be touching other additional modules in the remainder off the course while we discuss other concepts and look at more playbook examples. As I said earlier, there are hundreds of other models available. You really don't have to remember all these models, and they're perimeters. You can always have the answerable documentation page as a reference, or use the command line to list and browse through and available modules. In the upcoming coding exercises, we will be providing documentation about each model, so you should be good there, too. 5. Variables: this section, we're going to look at variables. So what are variables, Just like in any other scripting or programming language? Variables are used to store values that varies with different items. For example, let's say we are trying to perform the same operation off applying patches to hundreds off servers. We only need a single playbook for all 100 servers. However, it's the variables that store information about the different host names, user names or passwords that are used to connect to each of thes servers. We have already worked with variables earlier when we worked in the In Men Tree section. If you remember an inventory file that looks like this, the answerable host answerable connection answerable ssh pass! Are all examples off variables. We can define as many variables as required like this. We could also define variables inside playbook. This is a playbook we created earlier to add a DNS entry into ET see resolved out con file . To add a variable, we could simply add a virus keyword, followed by variables in a key value pair for mint, in this case, Deanna Silver, followed by the I P of the D. N. A server. We can always have variables defined in a separate file dedicated for variables. We will learn more about this later when we talk about includes and rolls. So we have now defined variables. But how do we use them if you look at our previous example where we defined a variable DNS server in the playbook, but we have not actually used it anywhere. What would be the right place to use that in this line here, where we defined the name server, we could replace the hard coded value with the value from the variable. To use a variable, simply enter the variable name enclosed in double braces or curly brackets. When we run, the playbook answerable will replace it with the value in the variable. Let's take another example. This is a longer playbook that is used to set multiple fireball configurations, which has a number off values hard coded in it. If someone else wanted to reuse this playbook, he would have to modify the playbook to change these values. If these values that can very are moved to the INM entry file and referred to in the playbook using double curly braces, we could get away with modifying the inventory files alone in the future. An even better way to do this would be to move the variables into a file in the name of the host. In this case wept. Ah, GMO. This is now a host variable file, and all values defined in this file are available for use by the playbook. This way it is even better organized. Remember this format we're using to use variables is called Tinge, a two template ing look it up when you get a chance. Finally, while using variables with ginger to template ing, remember to enclose it within coats if you're starting your assignment with the variable, however, if the variable is in between sentence, then this is not required. Let's play around with variables encoding exercises. 6. Conditionals: Hello and welcome to this lecture. In this lecture, we're going to look at condition ALS. Here we have a sample inventory file and a sample playbook. The inventory file contains two observers named as Web One and Web two and a database server named Ask DB Know that we also have a group defined with the name off all servers, and we have the Web and DB servers inside it. We have a playbook that attempts to start all services in the database and Web server, and if you notice we are running this play against the All Silver's group now, what would happen is answerable will try to run the single playbook across. All servers listed in the also VERS group, which would mean answerable, will try to start the database services first and then the festivity service. However, we do not have database service on the Web servers, and we do not have a City PD service in the database server. What we want to do is add a condition to each task, saying when we want the task to run, for example, we would like to run the my SQL task only if the host is database server. Similarly, we would like to start the history TPD service on Lee if the host is Web one or wept, too. Yes, we can have an or statement like this, or you can also have and statements in a similar way. Remember to use double equals operator for comparison. Also, remember, this is actually a bad example. If you really wanted to do something like this, the right way to do would be to group the servers into separate groups, called TB servers and Web servers, and run separate place for each group of servers. That way, it's a lot cleaner and more answerable like Let's look at another example in this playbook , I would like to check the status off a service and, based on the result, execute the next task. In this case, if the service is down, I would like to send an email to system. Add means reporting this issue. So so note the male model. That's a new model we haven't learned before, and it is used to send mails. Check the documentation page as it might require additional inputs. So we have two tasks. The 1st 1 for executing a command to check the status off a service, the 2nd 1 to send an email. If we were to run it now, it would simply check the status and send out an email, irrespective of whether the service is up or down. So we need to add a condition. As we just learned, we will add a rent condition to check the status of the service. But what do we check against? How do we get the result off the command run in the first task? That's where the register directive comes into. Play Register can be used to register or store the output off a model in this case, the output of the command run. In this case, the output of the command run will be stored in the variable command underscore output. Next, we use that variable to check if the result contains the word down. If it's true, we will send out an email. Remember, the output of the command is stored in a key STD out inside the variable command, underscore output, head over to the exercise of section and practice a little bit off using conditional 7. Loops: Hello and welcome to this lecture in this lecture, we're going to go through loops. Let's take a look at this example where we're creating an answerable playbook to install packages in a system using the young model. The young module helps you install or remove packages using the young package manager. In this case, we just have one package. But what if we have multiple? What if we have a lot of packages to install? Well, one way to do this would be to duplicate this lines as many times as required, but that's not very elegant. A better way to do this would be to have a single task loop over all the models. That's where we use with items with items is a looping director of which executes the same task multiple number of times each time it runs. It stores the value off the item in the item variable, so you can simply replace the hasty TPD value with the item variable inside the double braces like this, check out the answerable documentation page for loops. There are a number off additional options available for loops and really good examples available there. Check it out when you have time, head over to the exercises section and practice a little bit off using loops 8. Roles: in this section, we're going to look at answerable roles. If you have worked with any other programming languages or scripts, you probably know that you could write a large script or program in a single file. Or what is more preferred is to model arise it into packages, modules, classes and functions. That way, our code becomes more organized, reusable and easy to read and build upon and share with others. This is implemented in answerable with help off roles. Now, obviously we don't have any code, or at least what we have seen so far. There are no programs or classes or functions. What we do have our inventory files, variables and playbooks. Now, as you would have imagined by now, when we have too many things to automate our playbooks, inventory files variables are going to get bigger and more difficult to manage. So unlike what we have been doing so far, writing a single large playbook may not be ideal. In that case, that's where includes statements and rolls come into play. Let's take a look at include statements first with a really simple example. Here we have a large playbook doing multiple things at once, including provisioning v. EMS installing require dependencies, configuring Web server and setting up and starting applications. However, this playbook is approximately 1005 100 lines long and is really difficult to maintain. This playbook can only be used by someone who has the exact use case, which will be satisfied by this playbook in order to model. Arise it. We simply cut this large playbook into smaller files that address different use cases and then finally have a master playbook that includes thes smaller playbooks. The syntax for that is the include keyword, followed by the playbook name. Now our master playbook is just five lines long. We have four separate playbooks that are smaller, easier to maintain and that can be reused for different use cases. How about including tasks and variables? Here we have an answer. Will playbook with a list of variables and tasks that use those variables, we can move all tasks to a separate file and use the include statement to include task from that file. Similarly, we can move all variables to a separate file and include all variables from that file using the VARS file statement, note that here we don't use the ankle statement. It is called vars Underscore Files VARS and the school files is what we use for including variables defined in another file. Now, if you've been creating invent REFILES and defining variables in writing playbooks as we thought was fit for our needs, but is there a standard way to these? What does answerable recommend answerable rules? Define a structure for your project and defined standards on how files and folders are organized within your project. In this example, under my answerable project, I currently have an inventory file and a single large playbook to set up my Web server and to end now with roles were going to reorganize the playbook and variables. We create a new folder called Role, Within which we create another folder with the name of the role in this case, Web servers. The Web Silver rolls contains additional folders named filed templates, task handlers, VARS defaults and Metta. Each of these folder contains files associate it with those purposes. For example, the task folder contains Yeah mo file containing list of tasks and the Virus folder contains VAR files defined with variable declarations. Now we can move parts off our playbook to different folders. We moved variables into a file in the Virus folder and remove tasks into a file in the task folder. Now, in our master playbook, we could simply say, assigned the following rolls to the server, and the role is Web servers, which is the role we created under the Roles Folder. One of the advantages off using roles is that we do not have to worry about importing tasks and variables like we did in the previous slide. Answerable automatically imports all task from the task folder and all variables from the vast folder. The other folders are for storing supporting files or templates or handlers off defaults that we haven't covered in this course. Thes are out of scope for this fundamental course, and this will be included in an advanced course. 9. Advanced Topics and Conclusion: Hello and welcome to this lecture on advanced topics. In this section, we will go through some advanced concepts. There are no exercises for these as thes are more of concepts than code. Also, these are out of scope for this beginner's course and hopefully I will get to make an advanced course with quoting exercises for some of these topics. But it is important that you have a high level idea off the additional capabilities and support in answerable so that if you wish, you could refer to the answerable documentation page and get these done yourself. We're going to breeze through these topics, which includes preparing a Windows server to work with danceable. What answerable galaxy is, what our patterns, dynamic inventory and finally, how to develop a custom model. As we discussed in the first lecture, Answerable control machine can only be linens and not windows. However, Windows machines can be targets off, answerable and does be part off automation like how answerable connects to a Lennox machine . Using ssh answerable connects to a windows machine using wind or in but we know may not be enabled by default on a Windows machine. So there is some configuration required to set up winners on Windows Machine. Remember, you don't need to install anything on windows, so this is still agent less collaboration. Some of the requirements for setting up answerable to work with Windows is to have the pie win are a module installed on the answerable control machine. This can be done with the command pip. Install, piling or, um, and as by specifying the worsen, which is zero dark two door to Once this package is installed on the answerable control machine, we will need to set up. We know on the Windows Server now. There are different ways of doing this. An easy way to do this is to use the script provided by answerable called the Conficker, promoting for answerable script. This is a power shell script and you can download the script and run this on the Windows Server, which will set up winner on the Windows server, enabling answerable to connect remotely. There are different molds off authentication that you can set up like basic or certificate based or curb rose until, um, etcetera. You can find more information about this in the answerable documentation site. If you go to the Windows Support section, you will get detailed instructions on how to set this up. So if you look at here there, other different modes off authentication and if you scroll all the way down, there is a section called Windows System Prep, and here you have a link to the Power Shell script to be run on the windows. So don't load the script and run using the instructions provided here, and you should be all set. Answerable Galaxy is a free site for downloading, sharing and rating all kinds off community developed answerable roles. This is a great way to get a jump start on your automation projects. The website is galaxy dot answerable dot com, and as you can see, if you scroll browse through this website, you should be able to see a lot off roles available here. So remember we talked about roles earlier, so if you click on browse rolls, you will be able to see the different rules people have created and shared in answerable. And this is where you can share your roles and download. Other users can download your roles, so once you're once you create answerable project, you can simply download any existing rolls from answerable galaxy using answerable galaxy command line. And as we saw in the earlier section, it is as easy as assigning the downloaded rules to your host in your playbook. So check this out when you get time. It's really interesting site to browse. And once you start developing your own answerable roles, share it what with others and get feedback from others patterns. We have seen how to define what hosts were on tasks against. If you remember, this is done by specifying the name of the host in the host file. This could be a single host or a group of host, but there are additional options. You could use a pattern here. Let's see the different options available. You could specify multiple hosts at a time by entering the name of the host separated by a comma. As you can see here on the right host one comma host to calm upholstery. That's one option, or you could have selections of groups and hosts. So, for example, I'd like to run a set of commands against all servers partof Group One and also on Host one , which is not part of one or you could use patterns like a wild cards. In this case, Host star Will Iran the playbook against all the hosts that start with the name host? Or like in the last example? As you can see, you can run playbook on all the host that end with a dot company dot com Dennis suffix. There are additional options available for patterns. If you look at the answerable documentation page, you will be able to see some information here. There are some good examples that you can browse through, and this should be easy to figure out dynamic In Venturi, we have seen inventor information defined in inventory files like this, but it is not necessary to always define your inventory information in these files because this is a static file and you will have to change that Mannelly. If you were to integrate answerable with any other source off in wintry in your environment , then you will need to make this inventory dynamic. Answerable supports having dynamic inventory files typically unanswerable. You specify the include files using the dash I perimeter for dynamic inventory. Instead of specifying a file, you specify a script in this case, a Python Scripts As you can see here, there are two examples of command, and the 1st 1 is answerable playbook that I invent tree dot txt and then the playbook name . In this case, we're specifying a static inventory file named in men tree dot txt. In the second example, we're specifying inventory dot p Y, which is a Python script. The Python script is responsible for reaching out to whatever sources you have foreign entry and giving back answerable a list off groups host and their information. There are multiple scripts already available for dynamic inventory for solutions like cobbler AWS, Open stack, etcetera. So check it out. At the answerable documentation site, we learned about a few models through the course like command script lining files service, etcetera. These air basically python programs that perform specific actions. If you don't find a model that satisfies your requirement, you can develop your own module. You simply need to write a python program and place it in the models directory on your server. The program, though, has to be written in a particular format. You can get a template to start with at the danceable documentation page if you go to the answerable documentation website and going to the playbooks. Special topics and going to the Developer Information section and click on answerable Developer Guide. You have a section for developing modules. If you go into this section, you have different topics called building a simple module documenting your model, etcetera. Click on building a simple model and you have some sample python programs for writing for getting started with developing custom modules. Go through this and follow the instructions to develop your own custom modules. So to conclude, we discussed about various topics surrounding answerable. What answerable is and what it can do for us, how to set it up. Install it. We also went through an introduction to Yam Oh, we did some hands on practice on the ammo. We practiced some inventory files and playbooks and we worked with variables. Conditional is loops, etcetera, and we also looked at what roles are, how we can use them and what danceable Galaxies and how to search for roles unanswerable galaxy and use that in our project. You should now be in a position to start developing your own and simple playbooks and start testing them. Remember to refer to the answerable documentation side at all times for new modules and instructions on using them. This is a basic course, and hopefully I will get to develop an advanced course covering some advanced topics in the future. So thank you so much for your time and hope you had a good learning experience. Do let me know your feedback Or if you notice any issues with any of the exercises, please do write to me and I will try to get them fixed as soon as possible. Once again. Thank you very much for your time and for taking up the course and happy automating.