Ansible The Hard Way

Ansible The Hard Way

In this special blog, we are going to learn the basic of Ansible and the most complex part of it, Ansible is too easy to write If you will understand it thoroughly. I have written lots of playbooks for my project from scratch, so whatever I have discovered until now I will take this opportunity to share my knowledge with y’all.

Ansible an excellent Configuration management tool for the project whereas you can use it for Infrastructure provisioning too but not a good choice, Terraform will always win when provisioning comes into the picture.

The most important features of Ansible are,

  1. Agentless.
  2. It supports custom modules.
  3. Dynamic Inventory.
  4. Vast Built-in Modules.
  5. Python Syntax (Nice and Easy).

Let’s Understand Ansible in depth.


Ansible-Playbook directory structure.

Let’s understand each directory and its importance,

Default Ansible configuration.

When you will install ansible, It will create a few important ansible directories and files in /etc/ansible

  1. Inventory
  2. ansible.cfg
  3. roles


Inside Inventory you will see a hosts file. The most Important file where we generally pass the server IPs details. These IP’s can be categorized in the file based on the environment like,

So, suppose you want to run your playbook in a particular environment, just pass the name of the environment in ansible-playbook command.


It consists of ansible configuration which you can modify based on your requirements like,

  1. pssh/paramiko for connecting to the server.
  2. path of inventory.
  3. path of roles.
  4. host-key verification and many more.


Now if you want you can create those files and directories wherever you want and skip the one present in /etc/ansible directory.

Ansible has an excellent feature to detect the root folder based on below hierarchy,

  1. Suppose you have created project directory in /home/ubuntu/project. So, when you will run ansible command It will check the ansible.cfg file in that directory and will consider it as precedence. It will read all the ansible configurations from this file.
  2. If ansible.cfg is not found in the project directory then it will give precedence to the /etc/ansible/ directory


This directory consists of multiple role, which we write based on our configuration and requirements.

Role basically consists of,

  1. tasks (Where all configuration management logic will reside).
  2. vars ( We can define variables in this folder and can be used in tasks).
  3. templates ( We can put any configuration file in this directory for copying to the remote server, we can use jinja templates to configure these files based on some parameters or logic).
  4. files (Contain files that we want to copy to the remote server).
  5. handlers (Contain logic to restart the service, you can do the same in tasks too).
  6. metadata (Contain the details of your project and dependencies).


It consists of sensitive data which can be used as a variable in the playbook as a vars_files(e.g, auth.yaml in the above project directory).


To the point, assuming you have the prior knowledge of Ansible.

Writing vars,

Now suppose you want to pass the value of item1 in tasks, use the below method,

To pass all the values of askops,

Writing tasks, Converting value in json and using jmx querry on it,

Using regex based on conditional statement in tasks,

In the above code, ansible will replace the endpoint value with the new value, when the environment will be development.

Copying Multiple templates file to the remote server,

Changing multiple directory permissions,

Copying multiple files on the remote server,

Conditional Statements,

Tagging tasks,

Jinja templating in templates, with default value assigned if the length of the variable value will be zero.

Main YAML file to run the complete playbook (e.g “master-deploy.yaml/worker-deploy.yaml“).

Run playbook,

That’s it for now, feel free to comment and provide some valuable suggestions.

Developer: Nikhil raj
Price: Free

Leave a Reply