Day-15 | Ansible Zero to Hero | #ansible #devops

Hello everyone, my name is Abhishek and welcome back to my channel. So today, we are at day 15 of our complete DevOps course. So, in the previous class, that is day 14, we talked about the theory of configuration management. Uh, what is configuration management? Why Ansible has become a key player? We tried to compare it with Puppet and like, we talked about various other things as well, uh, regarding Ansible. So, it was completely a theoretical discussion, and today's topic, we'll try to cover the practical knowledge of Ansible. Perfect. So, let's start from the basics, right from the basics. Uh, so what I've done is, I just created an EC2 instance. Uh, like, it's your choice. If you have a Linux machine already, you can proceed with it. But if you are a first-timer, let's say you're learning Ansible for the very first time, I would definitely recommend you to start with, uh, like, you know, a Linux machine, not Windows or Mac. Uh, the reason for that is, you know, things will be much easier when you try, when you start doing on Linux. But, uh, it's fine. Uh, I mean, if you don't have a Linux machine and if you can't create, for some reasons, a Linux machine on an EC2 instance, then yeah, you can also try with your Mac or Windows.

Okay, so what is the first thing that you need to do? So, the very first thing that you need to do is to install Ansible, right? Definitely, to try any tool, you need to start with the installation of the tool. So, let me show you how to install Ansible in the very first case. So, there are a lot of documentations with which talks about installation of Ansible, right? Uh, like, you know, you can go to the official Ansible docs as well. So, if you see here, this is the official Ansible docs. You can also install Ansible from here. But what I would recommend you is, depending upon your, uh, distribution that you have installed, like, for example, if you see here, uh, this is a Ubuntu machine that I created from AWS. Like, this is an EC2 instance that I launched. So, similarly, uh, like, you might have launched a CentOS one or any other thing. So, it comes with a default package manager, right? So, for example, in terms of Ubuntu, I get apt. So, what you can typically do is, start with `sudo apt update`. Okay. `sudo` is because for running any apt commands, you would need, uh, root privileges. So, that's why you have to, uh, prefix it with `sudo`. So, `sudo apt update`. Okay. As you do that, your all the packages will be updated. So, this is definitely, this is something that you have to definitely do for the first time as you install your EC2 instance. So, once you do it, okay, so I have already done it. So, it took a slightly less time, but, uh, in your case, it might take a little more time. Don't worry about it. Once you do it, uh, you can simply do this: `sudo apt install ansible`. Okay. So, this will install Ansible for you. In my case, like I told you, it is already installed and it is set to the newest version. So, apt did not do anything. But, uh, in your case, once you run this command, it would install Ansible for you. Okay. Isn't it so simple? Like, you can go to the official Ansible documentation and try things as well. But, like I told you, sometimes it becomes tricky because this documentation is a very generic one. So, how does it do it? Basically, it installs Python for you, then it installs pip for you, and using pip, it installs Ansible. So, the reason for that is, basically, they wanted to keep the documentation as generic as possible, irrespective of Windows, Linux, Mac, or everything, because you are doing it through Python, uh, the installation would work. But the easiest way is, uh, to use your package manager, because all your package managers have Ansible as your packages. So, even if you're on Mac, you can simply do a `brew install ansible`. If you are on Windows, you can do `chocolatey install ansible`. So, uh, definitely go with your own package manager, so that it is added by default to the path as well. Whereas, if you are doing using this Python pip, sometimes you also have to add it to your path, okay, if your Python is configured in a different location.

Okay, so we are done with the first things that is to install Ansible. Verify it using this command: `ansible --version`. So, as I do `ansible --version`, you can clearly see that it mentions that Ansible is properly installed. Okay. Okay, makes sense. So, what is the next thing that you have to do? The next thing is using Ansible. Once you've, I mean, you want to start playing with Ansible, right? So, to start playing with Ansible, you would need one more server. Yeah, I mean, in the minimum, you'll need two servers. That is, uh, this server has Ansible, and to practically explain, okay, you need one more server. So, that you know, you can configure the other server using this Ansible server, right? So, that's the reason why I have created two servers. Okay. So, this is the Ansible server that we have currently logged in, and this is the target server. Okay. Let me increase the font. So, this is the target server. So, what I'll do is, using this Ansible server, I'll configure the target server. Okay. So, if you see, both of them are Ubuntu. So, that's the reason I named it as Target Ubuntu machine. But irrespective of it, you can create anything. Okay. It doesn't matter. Like I mentioned in the previous class as well, all that Ansible requires is a passwordless authentication. So, if Ansible can authenticate without any password to these machines, so Ansible can do anything. Okay. It can configure anything on that server.

Okay, so I have two servers now. Firstly, I'll show you how to set up passwordless authentication, right? Because, as I told you, the prerequisite is Ansible should be able to communicate to this server without any password. So, for that, let's see how to do that. Okay. So, uh, go to this instance. I mean, just click on this instance. You will get, uh, the private IP address, like you see here. So, this is the private IP address. Always talk to the, always talk to the private IP address, because, you know, both of them are in the same VPC, right? And both, both of the instances are in EC2, I mean, or on AWS. So, use the private IP address. It will be very easy. So, copy this private IP address and let me show you, uh, if I do SSH to it. Okay. So, let me SSH to the private IP address. It will ask for the password, because, uh, I haven't configured any passwordless authentication yet, because I want to show it to you from the scratch. Okay. So, if you follow any documentations, sometimes people will confuse you, because, uh, like, you know, there are multiple ways to configure passwordless authentication. But the easiest way, okay. So, some documentations might talk about `ssh-copy-id`. Okay. So, `ssh-copy-id` is one way of doing it. Just enter `ssh-copy-id` and provide the IP address of the target server, and everything will be set. Yes, `ssh-copy-id` is the easiest one. But what happens is, sometimes the `ssh-copy-id` does not have enough permissions to do it for you. So, that's why I will show you a very easy way. Okay. And if you have any questions to this way, always, uh, like, you know, like I always mention, you put your questions in the comment section. I'll definitely answer. But I'll explain you in a very straightforward way. So, I'm pretty sure you shouldn't get any questions.

So, on the Ubuntu user, what you will do is, simply type `ssh-keygen`. Okay. What `ssh-keygen` will do for you is, it will generate a key for you, right? That's why it's called `ssh-keygen`. What is the key? It will generate a public-private IP. Okay. So, that means it will create a public key and it will create a private key. So, is it asking? It is asking, "Is this location fine? `/home/ubuntu/.ssh/id_rsa`". Yeah, it's okay for me. Uh, it says that you already have something. Can I overwrite? No problem. Okay. In your case, you might not have it already. Okay. Then enter. So, what happens is, once you do this, there is a set of files that is your public key, private key, known_hosts key, known_hosts file, that is stored in this specific location. So, this directory gets created, and there are a bunch of files that are stored in this directory. Okay. So, `/home/ubuntu/.ssh`. So, how are these things created? Basically, these things are created using the command called `ssh-keygen`. Okay. So, you can enter `ssh-keygen` on your machine, and after that, you get `id_rsa` and `id_rsa.pub`. So, this is your private key, and this is your public key. So, the private key is used to log into this machine, and the private key is something that you can, that you should never share with anybody. So, what is that you need to share? If somebody says that, "Okay, let's communicate with each other," always go with the public key.

So, what we will try to do is, like I told you, we will try to talk to this target server, okay, from this Ansible server in a passwordless way. Okay. So, we don't want to authenticate using the password. So, for that reason, what I'll do is, I'll take this public key. `cat public key`. Uh, sorry, I'm not in that directory. So, uh, what I can do is `cat` followed by this location, followed by `id_rsa.pub`. Okay. So, this is my public key. Let me copy this public key. Okay. And once I copy this public key, what I will do is, again, log in to your second machine, okay, that is your target server. So, take a new tab, okay, and I'm already logged in here. Let me also increase the font for this one. Okay. I hope the font size is good. So, this is the, uh, other, other server or the target server. If you see the IP address, `172.31.62.228`. Okay. Now, what I will do is, just do the `ssh-keys` in here as well. Okay. Once you do the `ssh-keys` in here as well, okay, it will again create the same set of files. So, if you do `ls .ssh`, you will see here that you have `authorized_keys`, `private key`, and `public key`. Okay. Makes sense. So, now, what we'll do is, just open the `authorized_keys`. In the `authorized_keys`, what you need to do is, the one that you copied here, right? So, you open the `id_rsa.pub`, copied the content, and then paste the content here. Okay. So, just paste the content from here to here, and just save this file.

Now, let me see what happens. Okay. I'll execute the SSH command one more time. Okay. `ssh` followed by the IP address here. Okay. This is the IP address. Let me do SSH to the target server. Enter. Awesome. What happened? I was able to authenticate without any password, right? If you see here clearly, I did not give any password. I just said `ssh`. Up arrow. I just did `ssh` the IP address of the target server, and as I do `ssh`, I am able to connect to the target server without any password. So, this is the prerequisite for your Ansible, right? So, prerequisite for Ansible is, you need to have a password, passwordless authentication. And how did I set up the passwordless authentication? In simple terms, like if I have to explain it in one single line, what I did is, I just copied the public IP address of the Ansible server to the `authorized_keys` of the target servers. Let's say you will have one more server. Okay. If you have one more server, what you will do? Let's say we have a CentOS server. Okay. So, again, you will follow the same steps. Like, uh, now you already have the public key. So, you don't have to do `ssh-keygen`. What you will do is, you'll just copy the public key and you will create the CentOS server. Open the CentOS server, that means SSH to the CentOS server in a new terminal, and open the `authorized_keys`, and paste your public key in the `authorized_keys` of your CentOS server. Then Ansible will be able to communicate, or the Ansible host will be able to communicate to that target server in a passwordless authentication way. Awesome. I hope that things are very clear till now. Okay. What did we do? We first step, we installed Ansible. And second step, we set up the passwordless authentication with Ansible. Now, we are half done. Okay. So, these are the two things that are important. And once you do these two things, we are almost 50% done, because rest of all things are pretty easy. I'll show you. We can write Ansible Playbooks in no time. Don't worry about it.

So, again, Ansible. Perfect. Ansible is installed now. Before writing Ansible Playbooks, okay, what is an Ansible Playbook? So, Ansible Playbook is nothing but, let's take an example of shell. Okay. In shell scripting, you will write a file, okay, and what do you call that file? You call that file as a shell script file, right? If you are writing in Python, you call them as Python files. So, similarly, in Ansible, instead of calling them as Ansible files, we usually call them as Playbooks. That's it. Okay. So, whenever somebody is asking, "Have you written any Ansible Playbooks?" that means, "Have you written any Ansible files?" But is it mandatory to always write Ansible Playbooks? Okay. So, like, for example, if you're talking about shell, sometimes you might only have to run some basic shell commands. Like, for example, if I have to list some files, I can simply do `ls -l` as well, right? I can simply do `ls -l` and it listed the files here. For that, do I always have to write this shell script saying that, "Okay, `script.sh`" and in the `script.sh`, I'll say `#!/bin/bash` and `ls -l`, and then run this file? Is it required? No. So, you can also run the shell commands. Similarly, with Python, you don't have to write Python scripts all the time and execute the Python scripts, right? You can simply say `python3` and here you can write some commands, and your commands can get executed. Ansible will also support something similar. Okay. So, my main intention to explain all of these things is, you don't have to write Playbooks all the times. Okay. You can also run Ansible commands from the CLI. Okay. So, it depends on the tasks that you are doing, because the reason why I'm explaining is, I have seen people writing Playbooks even for simple tasks.

So, look, for example, okay, this is my Ansible server. Sorry, this is my Ansible server, and this is my target server. Let's say the task is to just create some files on this target server. Okay. So, using Ansible, your requirement that you got from your team is that, "Okay, please use Ansible and create some files in 100 target servers." But in our case, right now, we just have one target server. I'll also show you with more target servers, don't worry about it. So, we just have one target server. Okay. Uh, the task is just, "Create some files on the target server." This is a very simple task, right? So, for this simple task, I don't, I don't want to write a Playbook. What is the other way? So, you can, like I told you, you can simply run some Ansible commands as well. It's not always you have to do Playbooks. So, in Ansible terminology, it is called as Ansible Ad Hoc Commands. Okay. So, let me show you before writing Playbooks, how to run Ansible Ad Hoc Commands. So, to run Ansible Ad Hoc Commands, what you can do is, okay, `ansible` followed by the inventory file location. Like, if you followed my yesterday's class, I explained what is an inventory file. Inventory file is nothing but, it's a file which stores your IP addresses of the target servers. Like, for example, I created an inventory file here. Let me open this file and show you. Okay. `cat inventory`. What did I do? I just added the IP address of my target server. Like, this is my target server, and I just added the IP address of the target server in the inventory file. Okay. So, this inventory file can be anywhere. Okay. By default, Ansible stores the inventory file in `/etc/ansible/hosts`. This is the default file. But, you know, it's not always convenient to use it from here. So, whenever you write your Playbooks or whenever you run your ad hoc commands, you will add her commands, uh, you can store the inventory file in the same location as well. So, that's the reason why I stored the inventory file here. If I have 10 servers, what I need to do is, I can simply, uh, open the inventory file and append the IP address of 10 servers. Perfect.

So, `ansible -i inventory_file_location_or_name` followed by the IP address. Okay. What is the IP address of your target server? If you have one target server, you can provide one target server. If you have 100 target servers, you can group them in the inventory file and you can provide the name of the group. I'll also show that, don't worry. Okay. So, because I just have one target server, I can simply say this one. Or there is also another thing that Ansible supports is, just say `all`. Okay. So, by saying `all`, it means everything in the inventory file, all the servers in the inventory file. Okay. So, `ansible -i inventory all -m module_name`. Now, you might get a question that, "Okay, Abhishek, how do you know what is the module?" I'll show you that as well, don't worry. `-a arguments`. Just create a file. Okay. `touch test` or `touch devops_class`. Just run this simple command. Okay. I'll explain you the order of this simple command. What I am doing in this simple command? What is a module in Ansible? What is this `-a` which stands for arguments? Okay. Don't worry about it. But before that, just run this simple command and see what happens. Okay. So, what happened is, Ansible will give you that, okay, it changed something, and this yellow line means that everything is good. So, if you have any errors, you will get some red color lines which indicates that there are some errors. Now, let's go to the target server and see if the file is created. `ls -l`. Okay. If you see here, `devops_class` and when is it created? Right now. Okay. So, I just created the file. So, what did I do? I used the Ansible. Thank you. So, I used the Ansible ad hoc command. So, is it very simple, right? It is very, very simple. And why will you write a Playbook? You will write a Playbook only when you want to execute a set of these commands. Okay. So, here, there is only one command that I wanted to execute on the target server, right? Or there is only one task that I wanted to perform on the target server. So, for performing this one or two tasks, you can always go with the Ansible ad hoc commands. Similarly, with shell as well, right? If you want to perform one or two shell commands, you can directly execute that one or two commands. For example, if I want to just say, uh, `ls -l` and find the size of each file. Okay. So, what I would do? I would simply do this, right? `ls -l` and if there are 10 folders, I would see the, like, you know, size of these 10 folders using `du -sh`. I don't have to create a shell script for this. Similarly, if you want to execute one or two Ansible commands or one or two tasks using your Ansible on your target servers, always go for ad hoc commands. The reason why I'm stressing this is, many interviewers ask these questions: "What is the difference between Ansible Ad Hoc Commands versus Ansible Playbook?" Okay. So, the difference is that Ansible Ad Hoc command for one or two. Does Ansible Playbook is for multiple commands. Perfect.

I hope the things are very clear till now. Okay. What did we do? We installed Ansible. Then we configured the passwordless authentication with Ansible. And we also executed Ansible Ad Hoc commands to create some files or, you know, to execute some tasks on the target server. This is amazing, right? So, we did already three different things on Ansible in no time. Now, the question here is, okay, I know many people are getting this question here that, "Okay, how do you know what is this module called `shell` and how do you know what are the arguments to pass?" Don't worry about it. Nobody knows everything, because there are thousands of modules in Ansible. So, you can simply open your browser and search for Ansible modules. Okay. This is something that everybody does. Okay. Don't worry about it. Click on "All Modules" because day in, day out, Ansible keeps updating the modules because every day there is so much contribution that is happening to Ansible. Then, so like, you know, people keep adding commands to Ansible, people keep updating the commands to Ansible. So, always go to the documentation. And, like, you know, you want to just create a file. So, I know that using shell, you can create. So, you know, this is a shell module. "Execute shell commands on the targets." So, what I did is, I just looked into the documentation and I understood from the documentation, "Oh, okay, so Ansible supports something called as shell commands, and using the shell command, I can create some files." That is what I did. And Ansible also provides you examples. Like, you know, here in this case, Ansible told you that, "Okay, if you want to write a Playbook, this is the YAML syntax that you want to follow." But what we did, we just did one single command. So, that's the reason why I did it through and you will add her commands. So, `-m` stands for modules, and `-a` stands for what is the command that you wanted to execute, right? For example, let me change this and show you. You can execute any shell commands. Uh, let me see what is the number of processors on the target server. So, what I did, I just said `nproc`, and it said that, okay, the target server has only one CPU. Let me see `df`. Okay. So, `df` is to identify what is the disk, right? Disk usage and, you know, everything about your disk. So, I got the output using `df`. Perfect. So, this is how you can modify the ad hoc command arguments, and you can also do much thing, many other things. Like, you know, you know, you can copy files from this server to the other server using the ad hoc command. Like, uh, if you want to see that, just come here in the Ansible module section, just search for `copy`. Okay. So, see what are the different copy things that Ansible is providing. So, it said that, okay, so there is an argument called `copy`, there is a module called `copy`. Okay. So, I understood from here. What I'll do is, I can replace this module from `shell` to `copy`, and I need to understand what are the arguments. That's it. So, here you can directly jump to the example and see what are the arguments. So, for the `copy`, these are the different arguments that are passed. Okay. So, simply, what I can do is, in `-a`, I can replace these arguments. Like, I can say, simply `src:`, what is the location? I can provide the location of the file. After that, I can say `destination`. Right now, I'm just showing it to you how to do it. Okay. And then provide owner details if they are required, and all of those things. So, this is how you will learn Ansible Ad Hoc Commands. So, I showed you one command. You can try different things. Like, like you can try `copy`, you can try `scp`, you can try, uh, like, you know, deleting files on your target server. So, try all of them by your own.

Now, let us see what happens when you have multiple servers. Right now, I just showed you with one server. What I did is, I added that to the inventory file, and I showed you using executing this way, right? So, for example, I said `all`. What if there are two different servers? Okay. And one set of servers is your team's, and one set of server is other teams. Or let's understand this way: one set of servers are DB servers, okay, database-related servers, and the other set of servers are web servers. Okay. So, there is a use case that runs certain number of Playbooks only on the DB servers and run certain number of Playbooks only on the web servers. Okay. So, if that is a requirement, what you can simply do is that, in your inventory file, okay, open the inventory file, and in the inventory file, you can do grouping of your servers. Okay. So, here you can simply mention as `[db_servers]`. This is just for an example. And here you can mention as `[web_servers]`. So, the brackets are very important. Okay. You have to definitely use the brackets. Let's say I have web servers with an IP address `172.31.62.100`. Okay. So, now, if I have to execute the Ansible commands only on the web servers, what I can do is, instead of `all`, I can simply say `web_servers`. So, what will happen is, Ansible will go to the inventory file, it will look into the inventory file, it will see what are the list of web servers, okay, and it will execute the Ansible commands on the list of web servers. If there is one web server, it will execute on one web server. If there are 100 web servers, it will execute on 100 web servers. That means the group of machines that are under the name called `web_servers`. So, this is another interview question for you. So, the question is that, "How do you group the servers in Ansible?" or "How can you execute certain number of tasks only on certain number of virtual machines using Ansible?" So, for that, the answer is that, in Ansible, everything is configured in the inventory file. All the server names and server details are configured in the inventory file. You can do grouping of your servers in the inventory file and tell Ansible that, "Okay, execute this Playbook or run this Ansible command only on certain number of servers," or "execute only it on web servers," or "execute only it on DB servers." Right? Are things clear till now? Perfect.

Okay, so now let's see how to write an Ansible Playbook. Okay. So, the reason I told you is to write an Ansible Playbook is when you want to execute multiple tasks. So, let me take a scenario. Okay. So, the scenario here is, we want to install Nginx, okay, and what we want to do is, we want to start Nginx, okay. So, let's say this is the task. You want to install Nginx, and you also want to start Nginx. So, for this, what you need to do is, you want to write a Playbook. Perfect. So, let me call it as `first-playbook` and in which format is Ansible Playbooks written? They are written in the YAML format. Okay. So, that's why we will say `ansible-playbook.yaml`. Perfect. So, to start writing an Ansible Playbook, don't worry, I'll definitely keep it very, very easy for you guys. Okay. So, to to start writing an Ansible Playbook, just start with three hyphens. Okay. So, the three hyphens indicate that this is a YAML file. And after that, what we'll do is, you will start explaining about your Playbook. That is, what is the name of your Playbook? Okay. So, the name of the Playbook, let's say, is "to install and start Nginx". Okay. So, after that, what you will do is, you will provide the list of hosts where this Playbook has to run. Okay. So, to provide these details, like I told you, we usually group the servers in the inventory file. And if you want to execute in all of them, so just provide, uh, the server names as `all`. So, when you provide the server names as `all`, then it simply gets executed on all the servers in your inventory file. Okay. Once that that is done, so there are two cases: one is, do you want to execute this Playbook using the same user, or do you want to execute this Playbook using the root user? What do I mean by that? So, there are some times where you want to run this Playbook as the root user. That is because, let's say you want to install Nginx. So, if I go to the other server and show you, if I do something like, uh, `apt install nginx`, what will happen is, it will tell you that, "Okay, unable to acquire dpkg, sorry, dpkg logs." That is because you are not a root user. So, what you usually do is, you use `sudo`, right? So, use `sudo` and then you add the command. That is because you want to execute this command as a root user. Similarly, if you want to do something similar on Ansible, you have to use something called as `become: root`. Okay. So, what this `become: root` does is, it will execute your Ansible Playbooks as a root user. Perfect.

Once this is done, you will start writing the tasks. Okay. So, in YAML, the syntax might look difficult for you for the very first time, but once you start writing, it's not that difficult. Okay. So, what we did here, we started with three hyphens, which indicates that this is a YAML file. And then we use this hyphen to start the Playbook. That means, this hyphen indicates that, you know, it's a list. So, you are going to provide a list of Playbooks. You can write one Playbook in a file, or you want to, you can also write multiple Playbooks in a file. So, in my case, I can only write one Playbook in a file. So, that's why I said, "Okay, let me start this one Playbook." And if I have multiple Playbooks, what I need to do is, I can also do this. Okay. `- name: My second Playbook`. But don't worry about it. Now, we are writing only one Playbook here. So, we started with the name of the Playbook, then we told, in which files or on which servers this, uh, Playbook has to be executed. So, that is the `hosts`, which takes from the inventory file. So, I put here as `all`, so that all the servers in the inventory file get executed. Then I use the `become` command. So, what `become` does is, uh, it will allow you to execute it as a root user, or, you know, you can also use, uh, something called as `become_user` and you can provide any user that you want to use. Perfect.

So, now, inside the `tasks`, again, whenever you have a list of tasks, okay, whenever you have a list of something in, uh, YAML, what you need to do is, you have to start with a hyphen. Okay, which indicates that, okay, so there are a list of things that you wanted to do. So, my first task would be, again, provide the name of the task. Always describe your task using `name`. Okay. So, "Install Nginx". This would be my first task. And what is the command I would use? Okay. `apt`. So, either you can do this. Okay. `shell` and you can say `apt install nginx`. So, that is also quite possible. This is something that we learned, right? So, we use a shell command, we use the shell module, and I said `apt install nginx`. You can also do this. Or, Ansible by default provides a module for `apt`. So, you can also do this, like, you know, you can say `apt`, followed by `name:`. What is the name of the module that you want to use? So, I want to use, I mean, I want to install Nginx. So, provide the detail as `nginx`, and then you say `state: present`. That means, to install. So, this command is exactly equivalent to `shell` followed by `apt install nginx`. And it will also start the Nginx. So, uh, for that, we'll write a new task. But, okay, so `shell apt install nginx` and `apt name nginx state present` both are the same things. Now, you can ask me, "Okay, if both of them are same, why do I have to run this one?" To keep it more generic. Okay. So, whenever you want to run a certain number of tasks on Ubuntu, always go with the package manager, because sometimes when you are writing the shell commands, you might miss some things, whereas if you are using the apt, which is a package manager module that Ansible is providing, things will be much easier. And even into, even tomorrow, if the shell command is changed or something, you can always rely on this Ansible module that is provided by the Ansible. Perfect. `apt name: nginx state: present`. This is task number one. And how do I write the task number two? Again, match the syntax here. Okay. Match the indentation here, and in the indentation, use another hyphen and write your second task. What is my second task? The second task is to start Nginx. So, the first task that I have written is to install Nginx, and the second task that I have written is to start Nginx. And to start Nginx, again, what you can do, there are two options here. One is, you can say `shell` and you can say `systemctl start nginx`. Or, this is one possible way. Or, again, like I mentioned above, Ansible provides a module, okay, that is called as a `service` module. Okay. Using the `service` module, you can say, what is the name of the service? That is `nginx`. Followed by, what is the state? So, the state here is `started`. So, I want to have my service in `started` state. That's it. So, our Playbook is done. We wrote our first Playbook. Isn't it very simple?

So, to write our first Playbook, what did we do? We started with three hyphens, okay, the three hyphens indicate that this is a YAML file. And then we started to explain what this Playbook is, okay, and why did we use this hyphen here? The hyphen, the hyphen here is to indicate that there can be a list of Playbooks. Okay. And this is my first Playbook. Okay. So, in the first Playbook, what you are doing is, you are explaining "Install and Start Nginx". And what are the hosts against which this has to get executed? So, this has to get executed against the `all` the hosts in the inventory file. Then `become: root`. What does this `become: root` does? Is this `become: root` will switch the user to root, because we wanted to execute some package manager related commands. If you just want to, like, you know, execute everything through the Ubuntu user, let's say your Ubuntu user has permissions to do everything, then you don't have to use this line in your Playbook. Okay. Once you provide all of these details, then you go with your actual tasks. Okay. In the actual tasks, you explain, okay, what is the first task, and what is the second task. So, in the first task, I provided "Install Nginx". Okay. So, I wanted to install Nginx as the first one, and then I wanted to, uh, sorry, I did not save this file. Just give me a moment, so that I'll just rewrite all of these things. Okay. Yeah. So, these are the two tasks that are created, and this is the description of the task. Now, once we have all of these things, okay, once you have two tasks here, once you have, uh, written the name of your Playbook, and then you have explained everything about your Playbook, what you can do is, just save this file. Okay.

And now, what we'll do is, we will execute this Playbook. To execute this Playbook, previously we used the `ansible` command, right? So, `ansible` command is used to run some Ansible commands. Whereas, if you want to run Ansible Playbooks, the command that you want to use is `ansible-playbook`. Okay. So, the difference between `ansible` and `ansible-playbook` commands is that `ansible` is used to run Ansible Ad Hoc Commands, whereas `ansible-playbook` is used to run your Ansible Playbook files that we have just written. Perfect. As always, provide the location of your inventory file. If your inventory file is in the default location, then you don't have to provide these details. Like, you know, if you're using the `/etc/ansible/hosts` file as your inventory file, then don't worry, the details will be automatically picked up. But always make sure that, you know, provide the inventory file in the location itself, so that, you know, it will be more convenient rather than using the default one. After that, provide the name of your Playbook. Okay. The name of the Playbook is `first-playbook.yaml`. Now, let's see the magic and let's also try to understand what is happening. Okay. First of all, click enter. Then it said that the first task that is executed is "Gathering Facts". The second task that executed is "Install Nginx", and the third task is "Start Nginx". So, what has happened? Firstly, "Gather Facts". So, "Gather Facts" is nothing but, Ansible will try to get all the information of your target server. It will also see if it is able to authenticate without any password or not. Then it will get more details that are required on the target server. So, this is the step that gets executed irrespective of what Playbook that you are writing. "Gather Facts" is the first task that gets executed. After that, "Install Nginx". So, "Install Nginx" is the task that we wrote. And what happens after that? "Start Nginx". Okay. So, all the three tasks are passed. Let us see if Nginx is installed here or not. So, let's run the command `sudo systemctl status nginx`. Let us see what has happened. Perfect. It said that Nginx is running. Okay. So, we have done a great job till now. What I would like to ask is, everybody who are following this video, make sure that you practice these examples. One is the Ansible Ad Hoc command that I showed you, and also make sure you execute this same Playbook that I have written. Okay. It is very simple. One, follow the video, okay, and write the same Playbook in the same order. Okay. And if you have any questions till now, I would like everybody to put that in the comment section. Perfect.

So, we understood what is happening here. But for the viewers, I wanted to show this in detail. So, to read, understand what is happening within the Ansible, what Ansible is doing internally, just add the verbose. Okay. `-v` and execute the. You can add `2v`, `3v`. It only increases the verbosity within the Ansible. So, if you add three `v`s, that means Ansible prints whatever it is doing with the highest verbosity. So, what is verbosity? It basically means debug. Okay. So, you will get the debug logs here. So, previously, we understood what was happening, just like, you know, Ansible created a server and all. But if you use verbose, if you want to understand Ansible in more detailed way, what Ansible is doing on the target server, step by step, use the verbose option. And Ansible gives you everything. Like, you know, what, what it has started to do. Firstly, when you executed this `first-playbook.yaml`, it was searching for path on this Ubuntu Server. And then it, uh, used some configuration options. After that, it started with this "Install Nginx". Okay. Where it gathered the facts. The Playbook name is "Install Nginx". It gathered the facts. See, it is trying to establish, establish the SSH connection. Okay. So, it said that, okay, SSH connection was established successfully. Once it established the SSH connection, then it was looking for some Python related stuff. Okay. Because Ansible by default uses Python. Then it also found that, what is "Gather Facts" doing? It is doing all of these things: one is the SSH connection, one is the, uh, if your target server has, you know, all the dependencies that are required, Python dependencies that are required to execute. And once that is done, it will start with the. See, there is a lot of information. It will start with the "Install Nginx". And even in the "Install Nginx", for each and every task, what is it doing? How is it trying to establish the connection? And what has happened? See, uh, it also gave you the JSON file, which indicates what has the things that it has done. So, it has installed a package for you called Nginx, and it used `apt` to do that. We did it force? No, it just used the `apt`. It did not use any force. And then `dpkg` options, everything is present here. Okay. So, to learn Ansible in a better way, use the verbose option. And that is what I did when I started to learn Ansible in the very first things, because I also wanted to write my own Ansible modules. So, right now, I'm only explaining you to how to execute your Ansible Playbooks. But as I told you, you can always contribute to Ansible and write your own Ansible modules. So, to understand that, you need to understand what Ansible is doing internally. So, for that, use the verbosity option. Perfect.

So, what we have done? We have also executed our first Ansible Playbook. Now, what are the next things to learn in Ansible? Once you learn this, you need to understand that, okay, so I wrote my Ansible Playbook, and this is looking very simple. I learned Ansible completely. No. The reason here is, this is a very basic installation. Right? We just installed Nginx and we just started the Nginx service. But there are cases where you want to use your Ansible Playbooks to configure your Kubernetes cluster. Okay. This is a very classic example. Let me tell you what I wanted to, what usually people do in real-time organizations. Let's say `kubernetes.yaml`. Okay. The task here is, "Create three EC2 instances on AWS, okay, and configure one of those EC2 instances as master, and configure two other EC2 instances as worker." Okay. So, what is the task? "Create three EC2 instances on AWS, configure one EC2 instance as master, and configure two EC2 instances as worker." So, for that, what usually people, or what usually DevOps engineers, test is, for this, we use Terraform. Okay. And for the two other tasks, we use Ansible. So, this is, uh, done using Ansible, and this is also done using Ansible. So, people might ask, "Can't we do this using Ansible?" We can do that. Okay. So, we can always do, uh, the installation or, uh, stuff like creation using Ansible as well. But Terraform is a tool that is specifically designed for that purpose. Okay. You can create EC2 instances using Ansible as well. Uh, it's like, for example, if you want to purchase movie tickets, you can do it through BookMyShow as well, and you can do it through Paytm as well. But you would always go for the best option, right? So, the best option here in this case is Terraform. So, Terraform is an infrastructure management tool, or it's an Infrastructure as Code tool. So, that's why, uh, whenever you wanted to create anything with respect to infrastructure, go with Terraform. So, DevOps engineers usually create these EC2 instances using Terraform and perform these two actions using Ansible. Now, if these two actions cannot be written in one, one simple Playbook, right? For example, if you look at our `first-playbook.yaml`, this has only two tasks. But if you want to configure both your Kubernetes control plane as well as your Kubernetes data plane, or master as well as your worker nodes, your Playbook will become very huge. Okay. So, almost you will have some 50 to 60 tasks, and if you start writing this entire 50 to 60 tasks in one `playbook.yaml` file, it will be impossible to read. Okay. So, for that very own reason, what Ansible has done, and there will be a lot of variables, and there will be a lot of configuration files, you have to handle some errors, right? To avoid that, specific kind of problems, what Ansible has done is, it has come up with a concept called Ansible Roles. Okay. What is that? Ansible Roles. Now, what is Ansible Roles? So, Ansible Roles is nothing but, like, you know, in a very simple terminology, if I have to explain your Ansible Roles, Ansible Roles is an efficient way of writing Ansible Playbooks that will only improve your efficiency to write complex Playbooks. The best example that you can do, that you can give is, whenever some interviewer, interviewer is asking you this question, you can simply explain them that, "Okay, let's say I want to configure a Kubernetes using Ansible. So, it will have close to some 50 to 60 tasks, and you have a lot of variables, you have a lot of parameters, you have certificates, right? You have secrets that you have to configure while creating this Kubernetes cluster. So, for that very own reason, if you try to do it with roles, like you can segregate each and everything, and you can properly structure your Ansible Playbooks." So, that's why the concept of roles is introduced. So, if you want to start playing with roles, okay, what you can simply do is, you can

Use this command called ansible Galaxy, okay? And then you can say initialize. Okay, ansible Galaxy role init stands for initialize. And just start saying that, uh, I want to create a role for Kubernetes. So let me, uh, create a folder for this before that. Okay, so this is my second playbook, for example. My second playbook is to configure Kubernetes. So what I'll do is I'll do ansible hyphen Galaxy role init Kubernetes. Now let us see what happens as you execute this command. Okay, what happened is Ansible said that role Kubernetes was created successfully. What is that? Let me do LS. So if you see LS, if you do LS, you'll see that there is a folder called Kubernetes that is created. Let me open that folder and see what is inside that. Okay, LS Kubernetes. Okay, you will see a bunch of files that are created for you. This is the concept of roles. Okay, if you do LS hyphen LTR and see what is inside each and every folder. Okay, so whenever you execute this command, Ansible creates you a bunch of files and folders. Okay, and using these files and folders, you can structure your Ansible playbooks. Okay, so you have templates, you have files, you have readme where you can explain what this playbook is and what are the rules and responsibilities of this playbook. You can create tasks, like previously we used to write tasks in the playbook.yaml, right? Whereas here you will use the tasks. And then you have handlers, you have tests, vars, defaults, and meta. I'll explain you each and every of this thing, don't worry. But till now, what I wanted to explain you is that whenever you want to write some complicated playbooks, okay, what, what you would do is you will start using the Ansible Galaxy command to create roles. And what happens if you create roles is you can write structured and efficient Ansible playbooks. Okay, so to write this entire playbooks in this live session, uh, it will get slightly complicated. So that, that's the reason why I have put everything on my GitHub repository. Okay, so if you see here, this is my GitHub repository. I, I already know that most of you are following me on GitHub. And if you are not, then I have the link in the description. Don't worry, you can go and click on that GitHub and you will see a repository called ansible examples. So I forked this from ansible hyphen ansible examples, but I would recommend you to follow this repository, not the parent one, because my goal is to keep updating this ansible repository with more examples so that whenever I create a new example, you can watch for it. For example, today there is no Kubernetes example here. I don't have any Kubernetes example that is stored in this repository. So in future, I'll add that thing so that you can basically watch for it. So for example, here there are a bunch of playbooks, right? So let's say that I want to look for JBoss Standalone. Okay, I want to install a JBoss server and I want to configure the JBoss server. So what you will do is instead of writing everything inside the playbook.yaml, like, uh, this is the playbook.yaml file. So the YAML file that is present at the parent level or at the top of your folder is your parent playbook.yaml. That is the same as we wrote here. Okay, so if you remember, we wrote something called as first playbook.yaml, right? So this is the site.yaml. site.yaml is here. Parent playbook.yaml in this case. Okay, what did I provide? I just provided the name of the host and then I said that everything else you can find in the role. Okay, so previously what we used to write, we used to write, uh, what is the name of this playbook? What are the hosts? And then we used to write tasks here itself, right? Instead, what we do is whenever we are writing roles, we just segregate and we say that, okay, this is the host. And if you want to look at the tasks and other details, just find it in the roles folder. And what is the roles folder? JBoss Standalone. Okay, let us see what is there in the JBoss Standalone folder. Okay, go to the roles and inside roles, you have JBoss Standalone. Okay, if you go to JBoss Standalone, then we have all of these files and folders, right? So whenever you do by default, you get a bunch of things. If you don't require some of these things, for example, here, second playbook and inside this, I have Kubernetes CD, second playbook. Okay, and inside this, CD Kubernetes. So here you have a bunch of these things, right? So if you, let's say you don't want readme.yaml, let's say you don't want defaults, you can delete them. No worries. Okay, so here you have files and let's tasks and templates. So inside the tasks, we write everything that is related to this tasks.yaml. Okay, that is all the tasks. So previously we used to write everything on the parent playbook.yaml, but to segregate and to make things better, what you do is you create a role and inside the role, you write all of this tasks. Perfect. So this is a view, segregate and improve the efficiency. But what are the other files and folders here? Okay, I explained what is tasks, but what is this files? What is this folders? What is this templates? So let me explain you that as well, like for example, okay, so this is the entire structure, right? You have templates, you have files, you have tasks, you have handlers, tests, vars, defaults, and meta. Let's start with meta. So meta is basically used to write some metadata information inside this file. For example, let's say I have, I want to provide what are the details of this entire playbook. What is this entire playbook doing? So in such cases, you can provide the metadata information and also you can provide the licensing information. That is in the future, let's say you want to share this, uh, playbooks or share this entire playbook plus role, uh, to the community. Okay, Ansible Galaxy community. So in such cases, what you can do is you can write the entire information, like, you know, this playbook I have written for, uh, the open source purpose and I want to share it. And if anybody wants to use it for commercial purpose, it is not allowed. Okay, so such things you provide in the meta folder. After that, you have defaults. Okay, defaults is basically used to store some variable kind of things. Like for example, if you go to defaults today and open the main.yaml, so default file, default file for Kubernetes. Okay, you can store some variables and you can do the same thing with vars folder and also group vars folder. I'll explain you what is the difference between each of them in the interview questions, don't worry. And then there is test folder. So test is just like any other test that you write. Uh, even if you are writing, uh, shell scripts or even if you're writing Python scripts, you basically add some unit tests, right? So that is similar here. And then you have handlers. Handlers is basically for handling some kind of exception. Let's say while you are starting, uh, Nginx server in our previous example, we ran into some error. So using the handlers, what you can do is you can either send some mail notifications or, you know, you can say that whenever this Nginx server is failing to start, there is no purpose of installing Nginx itself. So delete the Nginx also. Okay, so this sort of things you can handle it. So handler is basically the situations that you want to handle. Then tasks, I don't, I don't have to explain it. I know that you all are familiar with tasks by now. And readme.md. So basically, you can explain, uh, our viewers or, you know, who are watching this repositories, you can tell them that what is the, uh, content of this, uh, uh, Ansible playbooks, what we stored in the Ansible playbooks and all. Then files, you can store some files like, uh, for example, you have some, uh, certificates or, you know, uh, you have some, uh, basic example is, let's say you have some index.html and you want to pass this index.html. Okay, so in such cases, you can use, uh, files as well, like, uh, for example, you want to pass the index.html onto the, uh, task. Okay, you want to copy the index.html from here to another machine. So using the, uh, files folder, you can store them and you can pass. So template is for basic templating, right? So Ansible uses the Jinja2 templating and if you want to use any anything related to this templates, you can store in the templates folder. Perfect. So this is about your Ansible structure and why Ansible roles are used. You can take a reference or take a look at these files and folders that I stored in my GitHub repository. Like I told you, there are a bunch of examples. Okay, so you can start looking at them. But before that, what you need to do is you have to be acquainted with Ansible ad-hoc commands. You have to start writing your first Ansible playbooks and then you, like, you know, I also showed you how to establish password authentication and all of these things. Get familiar with them as well. After that, go to this roles concept and implement Ansible roles. For that, you can pick any of the example that I have here. Best start with the JBoss Standalone. Okay, if you have any questions with this JBoss Standalone, uh, if you tried and if it doesn't work, you can let me know. But, uh, pretty sure this will work because these are all tested playbooks. Even myself, I have tested, uh, some of these playbooks, so they'll definitely work. Now, if you want to learn more about the Ansible interview questions, don't worry. I've already done a video on it. Uh, just to not stretch this video and to repeat the same content, I'll put the link in the description. I have put 18 most asked Ansible interview questions. Okay, 18 Ansible interview questions and their answers. So it covers all of these topics. It covers roles, it covers handlers, it covers, like, you know, uh, some, uh, complicated scenario based questions on Ansible. So watch that video so that you get a clear understanding of what are the interview questions that people can ask on Ansible. Apart from this, if you have any questions, if you want me to do, uh, more videos on Ansible, if you fail to understand some topics on Ansible, do let me know in the comment section and I'll definitely, uh, do a video for you guys. I hope you enjoyed this video. If you like the video, click on the like button. And if you have someone who wants to learn Ansible, please share with this, share this video with them. Thank you so much. I'll, I'll see in the next video. Take care everyone. Bye.