What is a Ansible Playbook | Lets understand the playbook

Hey everyone, before we dive into today's Anible session, I have something exciting to share. I am launching a complete mastering anible for beginners course very soon and there's a link in the description to join my waiting list and uh you will get early access, exclusive discounts and be notified the moment it goes live. And are you ready to write your first playbook? So let's get right into it. Okay, so let's dive into the well of writing anible playbooks. So think of playbooks as the script of a play where each act and scene is carefully planned to deliver a seamless performance. In the world of Ansible, these playbooks are like our automation blueprints written in the human readable format of YAML. We know this, isn't it? And if you want to write good playbooks and be anible playbook hero, you must be clear of these four components. The first one we have here, we have the playbooks. So this isn't just a script. It's a collection of plays that outline the sequence of automation tasks anible will perform from start to finish. The playbook is basically the master plan to achieve our overall automation objectives. So as you can see here, playbooks are a list of plays that define the order in which anible performs operations from top to bottom to execute the overall operations we want. Remember it will perform the operations from top to bottom. So the place that we define within the playbook will be executed from top to down fashion. So within the playbook we break down the actions into plays. So each play is targeted at a certain group of servers in our inventory. It's here that we define what roles each group will perform and in what order. Next we have the tasks. So these are the individual actions or steps that Ansible will carry out. So each task calls upon Ansible modules to do the heavy lifting whether it's installing software, writing files or starting services. Think of tasks like uh oh wait, why would you think of tasks as something you already know what a task is? So it's the same thing we know in engineering. A task is a single unit of work. So these are individual actions or steps that anible will carry out and each task calls upon anible modules to do the heavy lifting or to do the heavy operations or the operations themselves whether it could be installing softwares or writing files or starting services. So at the heart of each of the tasks are modules. So modules are really important when it comes to Ansible. So these are the tools in Ansible's toolkit. the commands or the scripts that execute on our managed nodes. Here you have to understand that modules are powerful and versatile and they come bundled up in collections with a fully qualified name or fully qualified collection name FQCN ensuring we know exactly which tool we are using for the job. Don't get confused with FQDN which is fully qualified domain name that is different. FQCN is fully qualified collection name. So the fully qualified collection name is closely related to modules because anible modules are often packaged and distributed as a part of anible collections. So I won't confuse you here but just remember this point as collections are a way to package and distribute pieces of anible content including playbooks, roles, modules, plugins and documentation. But modules are small unit of code or small units of code that ansible executes on target host to perform specific tasks. They are like the building block of anible automation. So I hope you got the point and you have to remember these points very clearly. The playbook, the play itself, then we have the task and then the modules. Let's take an example playbook here. Here our playbook is ensuring that our servers are in sync timewise by managing the NTP service. So let's break it down. Right in front of us is the playbook.yamel, a straightforward TML file that becomes a playbook when executed by Ansible. So notice the name ensure NTP network time protocol is installed and running. So it describes our goal a single playbook that applies to all hosts in our inventory. That is why we have mentioned host col. Naming the playbook is very important for the playbook as it tells users what it exactly does. Here you should pay attention to become equal to yes or become yes directive. It's easy to miss but very important. So this line escalates our privileges to ensure we have the necessary permissions to manage packages and services on the target host like sudo. And if you see we have mentioned host equal to all which means all hosts in the inventory. We are not saying any particular group any particular meta group. We are just saying all. Now look at the task section here. The first task install NTP package uses the apt module signifying we are working with the DBN or Ubuntu based systems. The state present that you see here ensures that if NTP isn't there, it will be after this play. So it'll try to install the NTP package. Moving on to the next task or the second task. The name that we have here is ensure NTP is running. So we leverage the service module here. It's not just about starting the NTB server or the service. The stated equal to true or the stated equal to started is a declaration of intent. Remember that the state colon started is a declaration of intent. It means that the service should always be running and if it's not anible will correct that. So if it means that if the service is not running, it'll make sure it is running by executing the operation to make it running. Last but not the least, the most important the module names. So apt and service are the modules. So when these are modules, the name and state are parameters which are a part of the module which help us perform operations based on that particular module. So if you see we have apt which has two parameters name and state. So name is NTP state is present. So when it comes to service we have two parameters. First one is name that is NTP. The state is started. Now let's write our playbook which might look a bit different than what we have here as this is just an example. But wait before that let's see how do we run it and how does it look. So we can execute this playbook ntp playbook.yamel yaml using the command anible playbook space the playbook name that is ntp_playbook.yamel YAML and when it comes to the output on the right hand side of the slide we have the output after running the playbook. So this text based output gives us a real time playbyplay of what anible is doing. So first it gathers the facts about the target nodes a sort of getting to know you step for anible. Then it proceeds with the task where it installs the NTP package and ensures that the NTP service is up and running on each server. And at the end you have the final summary. So this is the final summary. The final recap summary neatly displayed the outcome as okay indicates the number of successful tasks. Changed tells us how many tasks have changed. And importantly unreachable and failed are both exactly at zero. So that's what we wanted, isn't it? So keep your eye in the summary and on server one. Here you can see we have okay equal to one changed equal to two which means in these three tasks that you see here we have one okay for server one for the first task that we have and two changed on the second and third one. So if you see changed server one changed server one in these two tasks we have changed and the first operation that we performed on tasks on the server one is okay. So that is why you have one okay and two changed. But when you see the second server you have one okay two okay and one changed. So that is why it has shown okay equal to two changed equal to one and nowhere we can see there is a problem like unreachable or failed. So failed and unreachable are zero. So always refer to this as a state of the task when you talk about the operation being performed on the server and reading the output is really important when you're working with playbooks because that is the source of information that you get when you execute the playbook. You don't have other information. Yes, you have logs and other things but this will give you an overall view of what happened when you exactly executed the playbook.