Getting understand about the directory structure that needed to setup is really important as it helps to ease of things that we can work upon on Ansible. However, different people might follow bit of differ in the structure what we would follow here, but its about each once preference. End of the day, Structure is about to help us getting thing done in Ansible easy.
Project Root Directory:
This is the top level hierarchy where everything in your ansible work should go upon. It can have any name.
Inventory File:
This file should be listed each of the server nodes that the Ansible should work on. Note that prior ssh KEY being copy is mandatory.
- [web_hosts] whatever inside this square brackets is a just alias that represent group of hosts. And that group of hosts will be invoke by the “Prod.yml” file and once it does, it send the instruction that are listed in this same yaml file. These instruction should be kind of basics, such as system updates, hostname change, etc..
- hostnames are just yet another aliases and they don’t require any DNS entries nor hostname configured inside OS level. But they come handy when we want to call them later rather mentioning their respective IP addresses.
Prod.yml:
This is what holding the entire work-flow that suppose to be executed by Ansible. It calls aliases listed in “Inventory FIle” [ – hosts: node_master ] and by doing so we have the option to select order in which the hosts that needed to configured. Then it’s best practice to call the individual Roles here with their respective directory aliases so then each specific roles’ set of instruction will be call upon within their sub-directories rather than listed inside this main Prod.yaml file. But, as I already explained above, yet you can call some basic instruction task here under the [ KEY “pre_tasks” ]. When I say basic tasks, its like general things like update system via `yum update`Â or change hostname and etc..
Roles Directory:
This is where you can have Role specific sub-directories and the idea is that each of them then represent it’s own instruction set. For example, think about you want to install apahe and mysql via ansible. Then, you can have one directory, lets say “apache_role”, whose having what needed to be done on apache and on the other hand other sub-directory, called “mysql_role”, will have mysql own specific instruction. As we already covered in “Prod.yml” , we can call these sub-directories by their directory alias when needed.
Tasks Directories:
Inside each Role Directory you can have another set of sub-directories each calling task specific instruction. In very basic Task hold a single YAML file which calls every single instruction that needed to be executed on this role, for example, install apache, configuration changes, service restarts, etc..
Default Directory:
This is where role specific environment variable are listed within a YAML file.
Template Directory:
This is what holds the sample configuration files and they suppose to be in “Jinja” format which actually holds configuration data in a variable manner so then when these configuration files are instructed to being copied, those variable are then get replaced by its own parameter that are found in the Default Directory YAML file.
OK, Now you should have a clear idea on defining your Ansible structure, else you should try to go through couple of times on each points what I explained above until yourself familiar the concept. In my next post, I will be taking real-world scenario on where we could apply Ansible automation.
“I hope this has been informative for you”