wbrawner/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

[Doc] Update Conditional Imports (#35492)

Browse source 
* [Doc] Update Conditional Imports

facter/ohai is not needed for the ansible internal facts
also fix that os_family for centos is redhat

* Copy edit.
This commit is contained in:
Klaas Demter 2018-02-20 21:12:12 +01:00 committed by scottb
parent 75ab070c63
commit ce80485ecd
1 changed files with 8 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
docs/docsite/rst/user_guide/playbooks_conditionals.rst
View file

@ -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::
---
# for vars/CentOS.yml
# for vars/RedHat.yml
apache: httpd
somethingelse: 42
How does this work? If the operating system was 'CentOS', the first file Ansible would try to import
would be 'vars/CentOS.yml', followed by '/vars/os_defaults.yml' if that file
did not exist. If no files in the list were found, an error would be 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.
How does this work? For Red Hat operating systems ('CentOS', for example), the first file Ansible tries to import
is 'vars/RedHat.yml'. If that file does not exist, Ansible attempts to load 'vars/os_defaults.yml'. If no files in
the list were found, an error is raised.
To use this conditional import feature, you'll need facter or ohai installed prior to running the playbook, but
you can of course push this out with Ansible if you like::
On Debian, Ansible first looks for 'vars/Debian.yml' instead of 'vars/RedHat.yml', before
falling back on 'vars/os_defaults.yml'.
# for facter
ansible -m yum -a "pkg=facter state=present"
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
minimum of decision points to track.
Ansible's approach to configuration -- separating variables from tasks, keeping your playbooks
from turning into arbitrary code with nested conditionals - results in more streamlined and auditable configuration rules because there are fewer decision points to track.
Selecting Files And Templates Based On Variables
````````````````````````````````````````````````