Ansible Architecture | How does Ansible Work?

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. Plus, I love your feedback on what you want to see in the course. So we just now saw how we can create our anible master and the target nodes and how we can ping each of these target nodes using our anible master inventory file. But in real time you may not be working with only two or three servers. You'll be dealing with different services and a huge number of instances at once. So for that we won't sit and type each command and wait for it to happen. We have to improvise isn't it? So if you see here we have instances which belong to web server deployment and a few other for the database. The configurations will be different for both but we need to automate them in such a way that all the tasks that are targeted to be performed in web servers should be a part of the list and the same goes with the DB servers as well. So what I'm trying to explain is let's suppose we have target A and target D and they both have to perform or they both need similar application or services to be installed on them and they have to perform a specific operation like web server deployment we can actually make them a part of the list all web servers and also CNF can be a part of the DB servers and let's see how we actually do it. This is how the DevOps inventory might look like if you are using Excel sheets to keep track of the instances. So if you see here we have target one, target two, target three, target four, target five with web servers and other two as part of the DV server with different connection type. So I'm using password and the other iss keys. And the benefit of using an inventory file is that you can keep all of the targets under one roof under one file and execute them as per your need. So our table starts with the serial number. Next we have the host name. We have the friendly names that we give to our servers from target one, target two to target 5. Each name is a label that helps us quickly identify which server we are working with. Next we have the IP address. So which are serving as the unique identifier for each of the servers in the digital world much like a home address. So these are the IP address for each of the host. Now we have the username. So the username column shows who we log in as. So here EC2 user a common default for EC2 instances available on AWS. Now we have the connection type. So the connection type tells us how anible will connect to its servers. while SSH is our go-to for secure communications. You'll notice that some server are accessed via password as well. Finally, we have the service. So service actually describes what each server is doing. Some are running web services, others handle the database part. So we have web servers three and database servers as two. So target three and target four are DB servers. Target one, target two and target five are web servers. So if you see we have our inventory file here inside which we have categorized the targets with the definition within the square brackets. So if you have used INI files before you might be aware of the syntax which we use to write the config files. So we have web servers within which we have uh target a.hello.com targetd.hello.com and DB servers we have target C.hello.com and target F.hello.com. These are the host names and we have common as well where I have mentioned all of them so that if there is any operation that I want to perform on all the servers then I can use the common. Now how do we run this commands that we have here? So for one of the operations that we have we would want to actually ping to a particular host uh to see if it actually is reachable or not. So if I want to perform any operation or ping to targets at web server. So I can just write a anible command that is anible space web service which is basically the tag name that I have or the group name that I have here hyphen m which is basically a module name and then the command that I want to execute that is py i which is for the inventory and what is the inventory name that is inventory.txt. I'll pass it. So within that inventory it'll try to search for the web servers group and it will perform a ping operation on all the hosts that belong to that particular group called web servers. So what are the web server group that we have? So within this web server group we have target A and target D where it'll perform a ping on these two servers. The same goes for the DB servers. We have anible space DB servers M ping- I inventory.txt. So it'll do that and when I want to perform it for all the servers I have a group called common. So within which I can actually run the command ansible space common m ping is the command hyphen i inventory.txt. So instead of ping I can also run different commands. So after hyphen m I can write a command that I want to execute and that also there's a list of commands that you can execute. So we can check that as well. So we will be actually checking that as well. So don't worry about it. So hyphen m space ping hyphen i inventory.txt. Inventory.txt is your inventory file which has the list of host names that we want to perform operations on. So those are basically our target servers. And as I already told you, so if I want to perform any tasks that are common for both then I can keep a separate tag called common or now if I have we have kept a different name here and add the servers to the list as we have done in the common and I can execute the same using the command. Now let's see the overview of Ansible structure. So we'll begin with Ansible playbook, the fundamental blueprint of our automation tasks. So playbooks are written in YAML making them easily understandable and executed by us the users who are orchestrating the automation. At the heart of Ansible's operation is the inventory. This is where we list all the nodes or host that we manage. It's an essential component because it informs Ansible about the targets of our tasks. It can be static, dynamic and even include variables for more complex operations. If you see we have one more component that is called modules. So modules are like the specialized tools in our toolbox and Ansible comes equipped with an intensive collection of these allowing us to perform a wide array of tasks from the simple to the complex. Here we have the flexibility to utilize core modules that come with Ansible or develop custom modules that fit our unique requirements. So we can as well develop custom modules. The next component that we see here are plugins. So plugins augment anible score capabilities enabling us to customize our automation process. They can modify playbook behavior, filter data, dynamically load variables and more. The APIs that you see here, these actually act as the gateways for integration, allowing Ansible to embed within or connect with other services and platforms, facilitating seamless workflows. Now, let's look at how these elements come together in our automation workflow. We the users actually engage with the Ansible playbooks to initiate automation jobs. The inventory is consulted to pinpoint the targets for these tasks. The modules actually carry out the specific tasks we define from configuration management to application deployment. So plugins here support these actions in various ways from logging outputs to handling backend requests. But through APIs, Ansible interacts with external systems enabling us to manage services like cloud databases and platforms within our automation routines. On the other side of the architecture, Anible extends its reach to cloud platforms. So automating the setup and management of cloud resources is made straightforward with anel's cloud modules. We have host so we manage servers whether on premise or in the cloud directly through anible's powerful modules. When it comes to networks our network devices are configured and managed by anible ensuring the network state is aligned with our playbooks. So finally with application and services. So anible oversees the deployment and operations of applications and services fulfilling the full spectrum of our automation needs. So when we talk about anible automation architecture, this actually brings together the many components of our IT infrastructure or environment under a single automated and manageable framework. And if you understand this, you will have all the capabilities that you need in your day-to-day operations. Moving on to a much more controlled view of Ansible. So at the heart of the automation landscape is the control node. So this is the most important part. So this is a system where Ansible is installed and from where all our automation commands are executed. On this control node, we host our playbooks which are the scripts that define the tasks we want to automate across our infrastructure. Now the control node can't operate in isolation. So it needs to know where and what to manage. This is where our inventory comes into play. So our inventory is a carefully organized list of managed nodes. So these nodes are the remote systems or hosts that Ansible will manage. So we create and maintain this inventory on the control node and it's crafted to reflect the structure and nature of our environment describing where each system fits in our operation. So the interaction between the control node and the manage node is what anible is what makes anible such a powerful tool. So we send instruction in the form of playbooks from our control node and anible actually translates this instructions into action across our manage nodes. Whether it's managing a single server or scaling to hundreds our inventory ensures that anible knows each systems role and how to communicate with them effectively. And the beauty of Ansible lies in its simplicity and agentless nature. So there is no need to install agents on our manage nodes. Instead, Ansible uses SSH for Linux or Unix and Windows RM or Win RM for Windows nodes to execute the task defined in our playbooks. In our setup, manage nodes 1 and two that you see here. In our setup, manage nodes 1, 2, and three that you see here. Those are the node one, node 2, node 3. Each represent a server or host in our infrastructure that Ansible manages. So these could be any type of servers or or cloud instances that supports SSH or VINRM allowing us to automate a wide variety of tasks from software installations to complex deployment workflows. So this structure basically simplifies how we handle our infrastructure. It actually helps us to deploy changes, enforce configurations and ensure our systems are in the desired state all from a central location that is called the central node or the control node. This model not only enhances efficiency but also drives consistency and reliability in our operations.