mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
[Doc] Update Conditional Imports (#35492)
* [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:
parent
75ab070c63
commit
ce80485ecd
1 changed files with 8 additions and 19 deletions
|
@ -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
|
||||
````````````````````````````````````````````````
|
||||
|
|
Loading…
Reference in a new issue