community.general/examples/playbooks/roletest2.yml

# in Ansible 1.2 and later, roles allow easy best-practices organization of content 
# and maximize shareability of ansible building blocks.
#
# suppose a playbook applied to a group of hosts includes two roles, foo and bar.
#
# what do roles do in this case?
#
# listing the roles as foo and bar will auto include the following:
#
#    tasks    from ./roles/foo/tasks/main.yml,    then ./roles/bar/tasks/main.yml
#    handlers from ./roles/foo/handlers/main.yml, then ./roles/bar/handlers/main.yml
#    vars     from ./roles/foo/vars/main.yml,     then ./roles/bar/vars/main.yml
#
# should any of these files not exist, that is ok, and they will simply not be loaded.
#
# should the task file in foo/tasks/main.yml want to include subtasks in other files, that
# is also permitted.
#
# templates and copy operations also get smarter about where to look for content when using
# roles.
# 
# as an example, a task in foo/tasks/main.yml could copy or template a file by
# referencing a "src=foo.j2" rather than having to explicitly path src=roles/foo/templates/foo.j2.

---

  - hosts: all
    roles:

    # a role can be listed flat like this: 
    #
    #   - common
    #   - webservers

    # but you can also pass variables to them, so they can be parameterized.  You can call
    # a role more than once with different parameters too.  It might look like this:

      - role: foo
        param1: '{{ item }}'
        param2: '{{ item + "/" + item }}'
        with_items: ['a','b','c']
        when: ansible_os_family == 'RedHat'

    # add as many roles as you like, roles takes a list of roles names
    # these paths can be qualified, but if bare, it will look from them in
    # roles/$rolename relative to the playbook

    # explicit tasks and handlers can be used, but are not required.
    # they will run after the roles if present.

    tasks:

        # you can still have loose tasks/handlers and they will execute after roles

        - shell: echo 'this is a loose task'