Each play within a playbook can run one or more tasks, and each task invokes an Ansible module. Does a "task" ALWAYS include some module to be invoked?
Yes, a TASK always has a module that it runs. The "TASK" keyword expects at a minumum the name of the module to run. Often it is best practice to have a name on the task for troubleshooting. At the "task" level, it is just an ordered list of ansible modules and the required options for those modules (if any).
Actually, a play can also run zero tasks; you don't have to have a tasks section! If you leave fact gathering on (the default if you don't set gather_facts: false) then the ansible.builtin.setup module always runs at the start of the play even if you have no tasks section. One reason you might not have a tasks section is if your play only consists of running roles. The roles probably have internal tasks, but your play might not have any top-level tasks to run individual modules.
It's best to start by thinking that a task is always going to run a module. (There's also something called an "action plugin", but set that aside for now, just think about modules.)
Yes, a TASK always has a module that it runs. The "TASK" keyword expects at a minumum the name of the module to run. Often it is best practice to have a name on the task for troubleshooting. At the "task" level, it is just an ordered list of ansible modules and the required options for those modules (if any).
I do love the way you began your response Mr. Travis Michette - YES, with
some explanation to follow. For my simple brain, once I see the binary response
(i.e. YES or NO), I can digest what's to follow very easy.
Thank you for coming to my rescue for the _____ time. I had to put a blank
there because I've lost count of the number of times
@Trevor -
Being a completist ... I wanted to provide this to you as well as it has the breakdown of playbook keywords.
https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html
I also attached a presentation I did as an overview when I was teaching the courses. This should help. As @bonnevil mentioned, a valid playbook doesn't even need any tasks. It generally won't do anything unless fact gathering is turned on in which case it runs the "setup" module to gather facts about inventory hosts.
Anoyther thing to keep in mind is again the entire reason for playbooks is to have a list of tasks and this gives the power of allowing multiple modules (tasks) to run. Ansible ad-hoc commands while powerful can only run a single task at a time which is why we develop playbooks. Also, keep in mind, with plays being able to run multiple tasks, playbooks can run multiple plays giving you a complete and complex solution.
Travis, you're just the gift that keeps on giving!
Thank you for the additional content!!!
This is a minimal play that does nothing at all, but is valid playbook syntax. If you set gather_facts: true or delete the gather_facts line, then you'll run a single task, "Gathering Facts", that will run the ansible.builtin.setup module before the play ends.
- name: Play does nothing
hosts: localhost
gather_facts: false
bonnevil,
If I'm understanding your response correctly, even with this bare bones
playbook, there's still a module associated with a task. Give me a nod,
or a shake of the head on that
@Trevor yes, ansible.builtin.setup module.
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.