Ansible Troubleshooting part 1

Overview

Ansible Troubleshooting part 1

In this article I show some ansible troubleshooting techniques. Sometimes it's hard to troubleshoot errors in Ansible. But there are some little handy thing nice things to make your live as ansible playbook writer easier.

Syntax Checking

Use syntax checkking if you want to verify quickly if the basisc syntax is ok within the playbook.

Here is the ansible command line example on how to perform Syntax check on ansible playbook.

1ansible-playbook –-syntax-check playbook.yml -i ansible_hosts

step

This is the simplest of the techniques to implement and follow. Just add --step to your ansible-playbook command, and for each task you run you will get a prompt that looks like this:

1PLAY [ping hosts] ******************************************************************
2Perform task: TASK: test (N)o/(y)es/(c)ontinue:

For each task, you can choose

  • to run the task (yes),
  • not run the task (no, the default),
  • or run the rest of the play (continue).
Continue

Note that continue will run until the end of the play, not the end of the entire run.

verbosity

Running the playbooks in verbosity mode can be the next step to get more details about what is happening in the tasks and variables. From the command line, you can add -v (or -vv, -vvv, -vvvv, -vvvvv).
The highest verbosity levels can sometimes be too much information, so it's better to increase gradually in multiple executions until you get what you need.
Level 4 can help when troubleshooting connectivity issues and level 5 is useful for WinRM problems.
In AWX or Tower, you can select the VERBOSITY level in the job template.

Verbosity mode

In verbosity mode, the values of certain variables (passwords, for example) will be displayed unless you use the no_log option in the task, so erase the outputs when you are done.

Ansible-troubleshooting
Example of verbosity logging

inline logging

1    - name: Display the value of the integer
2      debug:
3        msg: "string={{ integer }} / Data type={{ integer | type_debug }}"

Ansible-troubleshooting
Var and type debugging

As you can see the type is a string instead of a integer.

A little more advanced playbook to dump some of the most used variables:

 1- name: dump all
 2  hosts: all
 3  tasks:
 4    - name: Print some debug information
 5      vars:
 6        msg: |
 7          Module Variables ("vars"):
 8          --------------------------------
 9          {{ vars | to_nice_json }}
10          ================================
11
12          Environment Variables ("environment"):
13          --------------------------------
14          {{ environment | to_nice_json }}
15          ================================
16
17          Group Variables ("groups"):
18          --------------------------------
19          {{ groups | to_nice_json }}
20          ================================
21
22          Host Variables ("hostvars"):
23          --------------------------------
24          {{ hostvars | to_nice_json }}
25          ================================          
26      debug:
27        msg: "{{ msg.split('\n') }}"
28      tags: debug_info

dump vars and facts to a file

Sometimes its be usefull to inspect the values of the hostvars or the facts. Below playbook wil save the vars to a file. The task is delegated to the control host, to have the foles locally saved instead of the remote host.

 1---
 2- name: Dump vars and facts
 3  hosts: host1,host2
 4  tasks:
 5 
 6  - name: Dump vars
 7    copy:
 8      content: "{{ hostvars[inventory_hostname] | to_nice_yaml }}"
 9      dest: "/tmp/{{ inventory_hostname }}_vars.txt"
10    delegate_to: controlhost
11
12  - name: Dump facts
13    copy: 
14      content: "{{ ansible_facts | to_nice_yaml }}"
15      dest: "/tmp/{{ inventory_hostname }}_facts.txt"
16    delegate_to: controlhost

More to come

These are some basic troubleshooting skills. In a next article we spend some attention at some more advanced techniques.

comments powered by Disqus