Mastering Ansible

Chapter 1
Inventory parameters
ansible_shell_type
ansible_python_interpreter
ansible\_\*\_interpreter
Behaviour
This is the shell type of the target system.
By default, commands are formatted using
the sh-style syntax. Setting this to csh or
fish will cause commands to be executed on
target systems to follow those shell's syntax
instead
This is the target host Python path. This
is useful for systems with more than one
Python, systems that are not located at /
usr/bin/python (such as \*BSD), or for
systems where /usr/bin/python is not a 2.X
series Python. We do not use the /usr/bin/
env mechanism as it requires the remote user's
path to be set right and also assumes that the
Python executable is named Python, where
the executable might be named something like
python26.
This works for anything such as Ruby or
Perl and works just like ansible_python_
interpreter. This replaces the shebang of
modules which run on that host
Dynamic inventories
A static inventory is great and enough for many situations. But there are times when
a statically written set of hosts is just too unwieldy to manage. Consider situations
where inventory data already exists in a different system, such as LDAP, a cloud
computing provider, or an in-house CMDB (inventory, asset tracking, and data
warehousing) system. It would be a waste of time and energy to duplicate that data,
and in the modern world of on-demand infrastructure, that data would quickly grow
stale or disastrously incorrect.
Another example of when a dynamic inventory source might be desired is when
your site grows beyond a single set of playbooks. Multiple playbook repositories
can fall into the trap of holding multiple copies of the same inventory data, or
complicated processes have to be created to reference a single copy of the data. An
external inventory can easily be leveraged to access the common inventory data
stored outside of the playbook repository to simplify the setup. Thankfully, Ansible
is not limited to static inventory files.
[ 7 ]