@Trevor You asked for help while navigating the waters of Ansible!!!
1. A playbook begins with the three dashes (---), which is a YAML convention to signify the start of a new document. The playbook itself is essentially a list of "plays." Each play is a complete set of instructions, telling Ansible which hosts to target and what specific tasks to execute on them.
2. hosts: localhost is a simple but important command. It tells Ansible to run all the tasks that follow on your own machine, not on any remote server. The gather_facts: no line is a useful optimization. It tells Ansible to skip collecting system information, which can make your playbook run much faster if you don't need that data for your tasks.
3. tasks : Under the tasks: section, you wil find a list of all the actions Ansible will perform in the order you hve listed them. You are using the debug: module here in the tasks section , which is a great tool for printing messages to the screen. It is perfect for testing or seeing variable data as you build a playbook.
current structure of your playbook at this stage :
---
- hosts: localhost
gather_facts: no
tasks:
4. Since tasks: is a block which contains the ordered list of actions Ansible will try on the target host and you are using a trick with debug module i.e changed_when: true bcz normally, a debug task doesn't change anything, but this line forces Ansible to report it as "changed." This is the key to making the next part work.
5. notify: test_handler1 or notify: test_handler2 triggers a named handler if the task is marked as changed. Handlers only run at the end of a play unless called by a task.
current structure of your playbook at this stage :
---
- hosts: localhost
gather_facts: no
tasks:
- debug:
msg: "Some task"
changed_when: true
notify: test_handler1
- debug:
msg: "Some other task"
changed_when: true
notify: test_handler1
- debug:
msg: "Another task"
changed_when: true
notify: test_handler2
Notice ( in the above playbook ) how you have 3 sub taks as a list of ordered tasks nested under ( indentated ) the main tasks block.
6. Now you need to create those handlers . Handlers are special tasks that are only ever executed when a task explicitly notifies them.
You define them in a separate handlers: block, and each one needs a name: so you can refer to it. In your example, both handlers will print the same message, "Trevor needs help," when they are called.
Final structure of your playbook now :
---
- hosts: localhost
gather_facts: no
tasks:
- debug:
msg: "Some task"
changed_when: true
notify: test_handler1
- debug:
msg: "Some other task"
changed_when: true
notify: test_handler1
- debug:
msg: "Another task"
changed_when: true
notify: test_handler2
handlers:
- name: test_handler1
debug:
msg: Trevor needs help
- name: test_handler2
debug:
msg: Trevor needs help
Ansible executes tasks in a very specific, predictable order. Here's a breakdown of what happens in your playbook:
Task Execution
Ansible works through your tasks one by one, in the exact order you have listed them. In this case:
Task A runs. Because yo have set changed_when: true, Ansible marks it as "changed" and queues up a notification for test_handler1.
Task B runs. It also reports a change and, once again, queues up a notification for test_handler1.
Task C runs. It reports a change and queues a notification for test_handler2.
Now the Handler Execution:
After all the tasks in the play have been completed, Ansible moves on to running the handlers it was notified about.
Ansible runs test_handler1 first. It's crucial to understand that even though two separate tasks notified it, the handler will only run one single time. Handlers automatically deduplicate notifications within a single play, ensuring actions like a service restart only happen once.
Next, Ansible runs test_handler2.
It's also important to remember that handlers run in the order they are defined in the handlers: section of your playbook, not in the order they were notified.
.png "Commander"){kind=icon}
