Tasks, Modules, Roles in Ansible

Gourav Shah
A free video tutorial from Gourav Shah
Premium Instructor| 35k+ students| Devops Trainer and Author
4.1 instructor rating • 14 courses • 41,149 students

Learn more from the full course

Ultimate Ansible Bootcamp by School of Devops®

Unofficial Guide to EX407 Redhat Certified Specialist in Ansible Automation

07:32:45 of on-demand video • Updated July 2020

  • What is ansible, why its needed and how it works
  • How to configure ansible and setup static/dynamic inventories
  • Ad hoc server management, running jobs in parallel
  • Managing systems entities using ansible Modules
  • Writing Playbooks to define the state of infrastructure as a code
  • Creating modular, reusable code with Roles
  • Creating dynmic code with vars and templates
  • Using Ansible Galaxy
  • Encrypting sensitive data with Vault
  • Service Discovery and managing Multiple Environments
  • Application Deployment Strategies, Rolling Updates
English [Auto] Let's start learning about the part of the mission. Right. And simple. And our journey begins with a sort of a use case where we can actually talk about a use case of a trigger infrastructure with a load balancing application. Now ansible is a tool which allows you to write to infrastructure as a call. And what we're talking about here is describing the desired state of our infrastructure. So since it is our state let's begin with the end state in mind that's what we're going to begin with. And then we start breaking it breaking it down into components till we get those economic units that we can't independently manage with supposed tasks. So considering this as this is our infrastructure we're going to break it down into three different tiers. And when we do that we get this right. And we basically start talking about one or one application one layer at a time. And if you look at one day at a time let's say applications where if you zoom in it's basically one application configured multiple times multiple instances of the same application. So we'll do into that application and start talking about what do I need in order to automate and set up and configure this application. And that's the set of steps that we can it for example for the observer. We need to install a package maybe create a user start the service pull the configuration file and that's what makes you know our application configurations. And we want do it multiple times. Now these are the steps that we come up with. And once you come up with the steps you start identifying how do I manage that entity let's say and I want to include a user what module can I use that that's rate so that's where we start mapping it with the Antipas models. For example user has use a model for installing applications you have. We have multiple package modules actually based on the kind of platform that type of packages that are installed for configurations and the files which only have files are complex. And then we have four managing the SOS is taking applications you may have a service model. So we came up with the steps first then we started identifying or mapping it to them to build models. And once we do that that's when we start defining Okay lets say okay the user what should be the speed of that user what with what properties sure that exists. So we start writing those task definitions because we get to manage each of these entities each of this step is going to translate into a task in and symbol's convention. And we going to like for tasks and each of that task calls or more. And then we define the state of each of the entity lets say a user should be present. Templates should also be created a package should be installed and this should be running and then the rest of the properties with the word properties that should be present like what is the home directory password and these properties are then specific to those entities. A user has these many properties are template has a file so it may have a source that may help on missions and you know users and groups that it owns that package may have a Virgin service may have a name right. So want to identify these definitions. We start then translating into something that people understand and thats the Yamhill specification of those tasks and we start creating that task file. In this example its a task file call as mean it's YAML file with the search step by step configuration lets say the first task is to clearly use our second task is to create a package and it will look similar to this call where we have the name of the module to manage a particular entity for that step. Then the state and the properties that which it should exist and thats in turn is going to call MRU and then translate into the actual implementation of the script. That is what do. So we started with the steps convert it into the model converted into the tasks file and each of the task file and each of the task files will have a specific objective. Lets say installing the application starting so is adding a particular feature lets say SSL support or what you are hosting. So we create different task files with different object. Thats about the tasks now we will start writing the stars and we'll put them in some directory when we have multiple Uske rate and past's is where we write the CoreLogic step by step process of configuring our systems. And that goes in a particular directory let's call it tasks now task alone and on enough because sometimes we may want to copy some files related to particular application we may want to manage configuration related to particular application. We may want to write some tests related to that particular application and so on and so for the most I want to provide the full set of properties so tasks alone are not enough. You'd still need some supporting files along with that including the files templates of Vash and so on and so forth. Right. And all of these together are going to allow you to configure one single application. And that becomes our rule. So rule is nothing but a package which contains tasks along with the supporting files that it requires. And it can refer to. And that together it's going to configure your application and you can fill that role for every single application in your infrastructure. There is one to one mapping between the role and the application. For example if your application stack with Tomcat as an observer in the Mungo's it is obvious you can write a rule for prompt that rule for Mongul rule to actually deployed the application on top of Tom-Kat which can be an other feature because you can use that as a library of call you can use tomcat with a different application as well. And you can use in a different project husband so Sukkur to create a rule and keep it independent really independent of all the applications. And that's what a rule is for and rule is important because when you write ansible code it is you know it's in the form of these rules multiple rules and then you decide which rule applies to which no that comes next.