Ansible Debug

Ansible Debug

Ansible offers a debug module that allows us to fix mistakes during execution instead of altering your playbook and re-running it to check whether your change worked. It enables us to check or set the estimation of factors, update module contentions, and re-run with the latest factors and conventions. The debugger lets you settle the reason for the disappointment and proceed with playbook execution.

Empowering the debugger

The debugger isn't empowered, as a matter of course. It would be best if you empowered or enable it first on the off chance that you need to summon the debugger during playbook execution.

We can use one of these three strategies to empower the debugger:

  • with the debugger keyword
  • in design or a climate variable, or
  • as a technique

Empowering the debugger with the debugger keyword

New in variant 2.5.

You can use the debugger keyword to empower (or impair) the debugger for a particular play, job, square, or task. This alternative is particularly valuable when creating or broadening playbooks, plays, and jobs. You can empower the debugger on new or refreshed undertakings. If they fizzle, you can fix the blunders effectively. The debugger keyword acknowledges five qualities:

ValuesResult
alwaysContinuously summon the debugger, paying little heed to the result.  
neverNever summon the debugger, paying little heed to the result.  
on_failedPossibly conjure the debugger if an assignment fizzles.  
on_unreachablePossibly conjure the debugger if a host is inaccessible.  
on_skippedPossibly summon the debugger if the errand is skipped.

When you utilize the debugger catchphrase, the worth you determine abrogates any worldwide design to empower or cripple the debugger at different levels, for example, in a job and an assignment, Ansible distinctions the most granular definition. This definition applies to all squares and assignments inside, except if they determine an alternate worth. At the block level, the definition supersedes the definition at the assume or role level and applies to all tasks inside that block, except if they indicate an alternate worth. The assignment level definition consistently applies to the errand; it nullifies the definitions at the block, play, or role level.

Instances of utilizing the debugger keyword

Case of setting the debugger keyword on a task:

 - name: Execute an order
 ansible.builtin.command: "false"
 debugger: on_failed 

Case of setting the debugger keyword on a play:

 - name: My play
 hosts: all
 debugger: on_skipped
 assignments:
 - name: Execute an order
 ansible.builtin.command: "valid"
  when: False 

Case of setting the debugger keyword at different levels:

 - name: Play
 hosts: all
 debugger: never
 assignments:
 - name: Execute an order
 ansible.builtin.command: "false"
 debugger: on_failed 

In this model, the debugger is never at the play level and on_failed at the assignment level. On the off chance that the assignment falls flat, Ansible conjures the debugger because the definition on the errand supersedes its parent play definition.

Empowering the debugger as a strategy

On the off chance that you are running inheritance playbooks or jobs, you may see the debugger empowered as a system. You can do this at the play level, in Ansible .cfg, or with the climate variable ANSIBLE_STRATEGY=debug. For instance:

 - hosts: test
 system: troubleshoot
 tasks:
 ... 

Or then again in ansible.cfg:

 [defaults]
 system = troubleshoot 

Settling blunders in the debugger

After Ansible conjures the debugger, you can utilize the seven debug orders to determine the blunder that Ansible experienced. Think about this model playbook, which characterizes the var1 variable yet uses the unclear wrong_var variable in an assignment unintentionally.

 - hosts: test
 debugger: on_failed
 gather_facts: no
 vars:
 var1: value1
 assignments:
 - name: Use an off-base variable
 ansible.builtin.ping: data={{ wrong_var }} 

Accessible debug commands

You can use these seven commands at the debug level:

CommandShortcutAction
printpPrint data about the undertaking.  
tasks.args[Key] = valueNo shortcutUpdate module contentions  
task_vars[Key] = valueNo shortcutUpdate task factors (you should update_task next)  
update_taskuReproduce a task with refreshed assignment factors  
redorRun the undertaking once more  
continuecKeep executing, beginning with the following undertaking  
quitqStop the debugger

Update args command

task.args[*key*] = *value* refreshes a module contention. This example playbook has an invalid bundle name:

 - hosts: test
 technique: troubleshoot
 gather_facts: yes
 vars:
 pkg_name: not_exist
 assignments:
 - name: Install a bundle
 ansible.builtin.apt: name={{ pkg_name }} 

Update task command

New in version 2.8.

u or update_task reproduces the undertaking from the first errand information structure and formats with refreshed assignment factors. See the section Update vars order for a case of utilization.

Redo order

r or redo runs the undertaking once more.

Continue order

c or continue with keeps executing, beginning with the following undertaking.

Quit order

q or quit stops the debugger. The playbook execution is prematurely ended.

How the debugger communicates with the free strategy

With the default linear strategy empowered, Ansible ends execution when the debugger is dynamic and runs the fixed task following the redo order. With the free methodology empowered, Ansible doesn't hang tight for all hosts and may line last assignments on one host before an errand fizzles on another host. With the free system, Ansible doesn't line or execute any assignments while the debugger is dynamic. Notwithstanding, all lined undertakings stay in the line and run when you leave the debugger. Other lined assignments may execute before your rescheduled task if you use redo to reschedule a task from the debugger.