2
votes

What is the point in having a master playbook in an Ansible project? The Ansible best practices describe a project layout like this:

production      # inventory file for production servers
staging         # inventory file for staging servers
site.yml        # master playbook
webservers.yml  # playbook for webserver tier
dbservers.yml   # playbook for dbserver tier

The master playbook will look something like this:

# site.yml
---
- include: webservers.yml
- include: dbservers.yml

The webservers and dbservers will look something like this:

---
- name: configure webservers
  hosts: webservers

  tasks:
    (tasks go here)

  roles:
    (roles go here)

Normally, if you had just one inventory file, you might specify it in your ansible.cfg file:

# ansible.cfg
[defaults]
hostfile = inventory

You could then simply run your playbook with the command:

$ ansible-playbook site.yml

But if we split our inventory into two separate files, you'll always need to specify an inventory file when you run the playbook:

$ ansible-playbook -i production site.yml

However, since your webserver or dbserver playbooks are in all likelihood going to specify "hosts: webservers" or "host: dbservers" to indicate these respective groups in your inventory files, why wouldn't you just run these commands?

$ ansible-playbook -i production webservers.yml
$ ansible-playbook -i production dbservers.yml

What does having a site.yml master playbook buy you?

Thanks.

1

1 Answers

5
votes

That example is extremely simple.

Imagine you have a decently complex infrastructure with 15-20 different playbooks for its various components. Such a master playbook will ensure that not only will all the underlying playbooks execute, but also they will execute in the correct order. (ie what should be run first, dbservers.yml or webservers.yml?)