Here's how to access facts from other hosts (advanced feature)
Michael DeHaan
to put something like an IP address + port number of a database server
in the XML configuration file for the app server. This is somewhat
of an advanced need as TYPICALLY, I'd
think you'd just stick a load balancer in front of things and use well
known ports. However, that's not ALWAYS the case, and you
occasionally need to get the data from facts on certain nodes to use
in templates for OTHER nodes.
I just implemented a way to access variables set or determined from
other hosts. If you are familiar with how this works in Puppet
(requiring storeconfigs (database) plus weird modified spaceship
operators), this is going to be REALLY nice. Orchestration between
multiple tiers of a software system is going to be incredibly easy
with this.
The change enabling this is now available on the integration branch,
but it works just like this:
# an example of accessing an ansible fact (which ARE somewhat nested)
{{ hostvars['bar.example.com']['ansible_eth0']['ipv4']['address'] }}
# an example of accessing a facter fact (which aren't nested)
{{ hostvars['foo.example.com']['facter_hostname']
# an example of defining a host variable via the new YAML host file
system, that was defined like so:
- host: asdf
vars:
database_port: 1234
{{ hostvar['127.0.0.1']['database_port'] }}
I'll update the web documentation on this after 0.0.3 is released,
along with documentation about available Ansible facts.
Note that because of the way this works, if you wish to use the
variables from one set of hosts in another set of hosts, you have
to have either included that host in the current play, or a previous
play. If your playbook needs the appservers to point at the
dbservers, you need to have at least a play with zero or more tasks
first calling the dbservers to load up their data.
I suspect most people won't need this, but the fact that we can do it
-- and that it required so little in terms of code changes -- is a
pretty big deal.
--Michael
Michael DeHaan
following syntax works:
{{ hostvars.get('127.0.0.1').get('some_fact') }}
# and with defaults, if you ever need this:
{{ hostvars.get('127.0.0.1', {}).get('some_fact', 'default') }}
Michel Blanc
> The change enabling this is now available on the integration branch,
> but it works just like this:
>
> # an example of accessing an ansible fact (which ARE somewhat nested)
> {{ hostvars['bar.example.com']['ansible_eth0']['ipv4']['address'] }}
>
> # an example of accessing a facter fact (which aren't nested)
> {{ hostvars['foo.example.com']['facter_hostname']
This sounds really nice. Does this mean I can do something like this :
(excuse my python)
$ cat hosts.j2
# Auto-generated /etc/hosts
{% for k,v in hostvars.iteritems() %}
{{v['ansible_eth0']['ipv4']['address']}} {{ k }}
{% endfor %}
?
Would be very useful for me to automatically generate monitoring
configuration for the host list.
Thanks,
M
--
Michel Blanc - netWorks
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
Michael DeHaan
Hello folks & Michael,This sounds really nice. Does this mean I can do something like this :(excuse my python)$ cat hosts.j2# Auto-generated /etc/hosts{% for k,v in hostvars.iteritems() %}{{v['ansible_eth0']['ipv4']['address']}} {{ k }}{% endfor %}