Category Archives: Ansible

Ansible configuration file precedence

Installation of Ansible provides us a default /etc/ansible/ansible.cfg configuration file, in which we can make various settings like the default user with which playbook should run on the remote server and the privilege mode of that user.

Here is the default sections present in ansible.cfg file.

# grep ‘^[[]’ /etc/ansible/ansible.cfg

As we are dealing with multiple servers which need to be manage by Ansible and most of the time group of servers have different requirements than other hence need of having separate ansible.cfg files for these group of servers can arise easily. Having multiple ansible.cfg creates confusion that which one will get use, this is a genuine question here is the precedence ordering starting from top to bottom.

  • $ANSIBLE_CONFIG   Setting environment variable for the location of ansible configuration file.
  • Using ./ansible.cfg   from the current directory which is used to run the ansible playbook or adhoc command
  • ~/.ansible.cfg   file present in home directory of user which is use to run the ansible command.
  • /etc/ansible/ansible.cfg  default ansible.cfg file.

IMP : Ansible will only use the configuration settings from the file which is found in this sequence first, it will not look for the settings in the higher sequence files if the setting is not present in the file which is chosen for deployment.

Ex : If ./ansible.cfg file is choosen as $ANSIBLE_CONFIG is not defined then it will use all the settings present in ./ansible.cfg, if any setting/parameter is missing for this file, it will not search the setting in ansible.cfg file present in home directory or the default ansible.cfg file.

Useful hacks for Ansible to make troubleshooting easy

I have completed my Red Hat Ansible certification couple of months back but after that I didn’t get the chance to get my hands dirty on it. I planned to revisit my Ansible concepts again so that  I can start using it in my daily work.

Here is my first post on some Ansible tips and tricks.

Useful tips about yaml templates :

* As ansible is based on yaml playbooks and in yaml template  proper spacing matters a lot. While using yaml template in vim editor I face lot of difficulties to keep the proper spacing to make the yaml template work hence to avoid pressing space again and again here is the useful VIM trick so that double space is getting inserted by default while pressing tab.

autocmd FileType yaml setlocal ai ts=2 sw=2 et

Above line need to added in “$HOME/.vimrc” file and after that whenever tab is pressed it will automatically take 2 spaces.

* Couple of online methods are available to check the yaml SYNTAX. My search for the yaml SYNTAX check using CLI ends with following python command :

#  python -c ‘import yaml , sys ; print yaml.load(sys.stdin)’ < test1.yml
[{‘tasks’: [{‘name’: ‘first task’, ‘service’: ‘name=iptables enabled=true’}, {‘name’: ‘second task’, ‘service’: ‘name=sshd enabled=true’}], ‘hosts’: ‘all’, ‘name’: ‘a simple playbook’}]

Here test1.yaml is the yaml file for which SYNTAX need to be check. In my case I was not having any SYNTAX error hence it simply prints the yaml content in json format.

* Another way to check the SYNTAX is using ansible command. If any error is there it will give us the approx position of the SYNTAX error.

# ansible-playbook –syntax-check test1.yml

playbook: test1.yml

Troubleshooting Ansible playbooks :

In the previous section we have take care about the SYNTAX of Ansible playbook now steps regarding troubleshooting the logical of playbook.

* I always prefer to run the Ansible playbook in dry mode that means not making any actual change just checking what changes it’s going to make. Be careful some modules doesn’t respect the dry mode but still it’s a safer option as most of the modules do respect this mode.

# ansible-playbook –check test1.yml

PLAY [a simple playbook] ******************************************************

TASK: [first task] ************************************************************
ok: [localhost]

TASK: [second task] ***********************************************************
ok: [localhost]

PLAY RECAP ********************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0

* Another method is to run the playbook step by step instead of running the whole playbook in single shot. It will ask for confirmation before running each step. It will only the step on “y”

# ansible-playbook –step test1.yml

PLAY [a simple playbook] ******************************************************
Perform task: first task (y/n/c): y

Perform task: first task (y/n/c):  ********************************************
ok: [localhost]
Perform task: second task (y/n/c): y

Perform task: second task (y/n/c):  *******************************************
ok: [localhost]

PLAY RECAP ********************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0

* It also has the option to start a particular task from the list of tasks mentioned in playbook. Like I was having two tasks in my playbook, I have started second task from playbook skipping the first one. Of-course you can also use the tags to achieve the same.

# ansible-playbook –start-at-task=”second task” test1.yml

PLAY [a simple playbook] ******************************************************

TASK: [second task] ***********************************************************
ok: [localhost]

PLAY RECAP ********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0

* By default ansible only dumps the adhoc command or playbook  information on terminal, it’s not getting recorded in log file but that doesn’t mean we can’t. It provide us the flexibility of putting the information in log file so that it can be viewed at later.

# grep log_path /etc/ansible/ansible.cfg
#log_path = /var/log/ansible.log

By default log_path parameter is commented in ansible.cfg file, it can be set to the path of log file in which you want to dump the log information. Also, environment variable ANSIBLE_LOG_PATH can be set which will take precedence over the default location mentioned in ansible.cfg file.

* Here comes my favorite debug module which can be used inside the Ansible playbook to print the variable value. This feature is key to managing tasks that use variables
to communicate with each other (for example, using the output of a task as the input to the
following one).

In first example it’s printing the facts information.

– debug: msg=”The free memory for this system is {{ ansible_memfree_mb }}”

In second example, variable of variable is printed with more verbosity.

– debug: var=output1 verbosity=2