@ -220,30 +220,19 @@ but it is easily handled with a minimum of syntax in an Ansible Playbook::
As a reminder, the various YAML files contain just keys and values::
As a reminder, the various YAML files contain just keys and values::
---
---
# for vars/CentOS.yml
# for vars/RedHat.yml
apache: httpd
apache: httpd
somethingelse: 42
somethingelse: 42
How does this work? If the operating system was 'CentOS', the first file Ansible would try to import
How does this work? For Red Hat operating systems ('CentOS', for example), the first file Ansible tries to import
would be 'vars/CentOS.yml', followed by '/vars/os_defaults.yml' if that file
is 'vars/RedHat.yml'. If that file does not exist, Ansible attempts to load 'vars/os_defaults.yml'. If no files in
did not exist. If no files in the list were found, an error would be raised.
the list were found, an error is raised.
On Debian, it would instead first look towards 'vars/Debian.yml' instead of 'vars/CentOS.yml', before
falling back on 'vars/os_defaults.yml'. Pretty simple.
To use this conditional import feature, you'll need facter or ohai installed prior to running the playbook, but
On Debian, Ansible first looks for 'vars/Debian.yml' instead of 'vars/RedHat.yml', before
you can of course push this out with Ansible if you like::
falling back on 'vars/os_defaults.yml'.
# for facter
Ansible's approach to configuration -- separating variables from tasks, keeping your playbooks
ansible -m yum -a "pkg=facter state=present"
from turning into arbitrary code with nested conditionals - results in more streamlined and auditable configuration rules because there are fewer decision points to track.
ansible -m yum -a "pkg=ruby-json state=present"
# for ohai
ansible -m yum -a "pkg=ohai state=present"
Ansible's approach to configuration -- separating variables from tasks, keeps your playbooks
from turning into arbitrary code with ugly nested ifs, conditionals, and so on - and results
in more streamlined & auditable configuration rules -- especially because there are a