Ansible Playbook Code - Question #1

[Trevor]

---
- name: Install and start Apache
  hosts: web
  become: true
  tasks:
    - name: Ensure the httpd package is installed
      ansible.builtin.package:
        name: httpd
        state: present
    - name: Start the httpd service if needed
      ansible.builtin.service:
        name: httpd
        state: started
        enabled: true

Question:  In the line

                         hosts:  web

                  the name "web" is intended to refer to an inventory group, and not 
                  an individual host.  How can I, by visual inspection, make this
                  determination?

Question:  The line that immediately folllows the name of the task, is the name
                  of the module that will be run.  Does the module name ALWAYS
                  immediately appear on the line following the name of the task?

Question:  Is is possible (or practical) for a task to be without a module name?

[shashi01]

@Trevor 

You can’t definitively tell if "web" is a group or host by visual inspection alone; you need to check the inventory

The module does not always have to be on the line after the - name: directive.

Yes, a task can exist without an action module if its purpose is to control the playbook's flow, such as importing another task file.

[bonnevil]

If you have a conflict between a host name and a group name in the inventory, you'll get a warning like the following when you run the job (at least with ansible-playbook), or when you check the syntax of the inventory with ansible-inventory:

[WARNING]: Found both group and host with same name: web

In my testing, the inventory host name seems to be the one that's used and the group is ignored, but I would not count on that behavior, and without a closer look I could be subtly wrong about how Ansible is interpreting host patterns in the inventory.

It's a good argument for using FQDNs for all inventory host names, I suppose, and ensuring inventory group names don't look like FQDNs.

If there's an underscore in the inventory name, it's not a valid DNS hostname unless we use the ansible_host variable to point that inventory name at a real hostname or IP address. (The RFCs/DNS do not allow underscore in host names.)  An inventory name which contains an underscore and doesn't set ansible_host could be a valid group name, however.

[Trevor]

bonnevil, very good lesson!!!

I really love the recommendation about using FQDNs for all inventory hostnames!!!

Thanks you very much for the lesson!!!!

[Trevor]

shashi01, thank you those responses!!!  There'll be no head scratching on what's being said here!!!!

[Travis]

@Trevor -

To expand on this more @shashi01 is 100% correct. What I tried to do when delivering a course especially to beginners in Ansible is stress the indentation levels and i would demonstrate that "placement" of the items at didn't quite matter. Obviously tasks go in order, however things like pre-tasks, post-tasks, and handlers are are the same indentation level as tasks. So I would demonstrate putting post tasks and handlers at the top, followed by tasks and pre-tasks at the bottom. Then show how the playbook processed.

When it comes to modules, you have another indentation level there, so again, order doesn't matter as long as you have the required components. Additionally, in terms of tasks using modules and actions. A task will always do something because a module has defaults set. So while you might not be directly specifying an action for a given task, the act of having a task with a module will result in something happening. 

In another post we discussed ansible_facts. The setup module collects facts. So there are a few ways this is leveraged.

---
- name: Playbook with no tasks but runs a task
  hosts: localhost
  gather_facts: true

So the above playbook will run a task and that is to gather facts.

Then we can have this next playbook ...

---
- name: Playbook with a single task
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Gather facts
      ansible.builtin.setup:

ansible.builtin.setup module – Gathers facts about remote hosts — Ansible Community Documentation

Also, just so you know, you can gather just a subset of facts too with the built-in setup module. So one thing we show people on optimizing playbooks is disabling fact gathering to speed things up if you aren't using facts, but maybe we do need facts, but not all of them, well, that can be done too!!