Tag Archives: hacks

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

Advertisements