mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
89 lines
3 KiB
ReStructuredText
89 lines
3 KiB
ReStructuredText
.. _patterns:
|
|
|
|
Patterns
|
|
++++++++
|
|
|
|
Patterns in Ansible are how we decide which hosts to manage. This can mean what hosts to communicate with, but in terms
|
|
of :doc:`playbooks` it actually means what hosts to apply a particular configuration or IT process to.
|
|
|
|
We'll go over how to use the command line in :doc:`intro_examples` section, however, basically it looks like this::
|
|
|
|
ansible <pattern_goes_here> -m <module_name> -a <arguments>
|
|
|
|
Such as::
|
|
|
|
ansible webservers -m service -a "name=httpd state=restarted"
|
|
|
|
Anyway, to use Ansible, you'll first need to know how to tell Ansible which hosts in your inventory to talk to.
|
|
This is done by designating particular host names or groups of hosts.
|
|
|
|
The following patterns target all hosts in the inventory::
|
|
|
|
all
|
|
*
|
|
|
|
Basically 'all' is an alias for '*'. It is also possible to address a specific host or hosts::
|
|
|
|
one.example.com
|
|
one.example.com:two.example.com
|
|
192.168.1.50
|
|
192.168.1.*
|
|
|
|
The following patterns address one or more groups. Groups seperated by a colon indicate an "OR" configuration.
|
|
This means the host may be in either one group or the other::
|
|
|
|
webservers
|
|
webservers:dbservers
|
|
|
|
You can exclude groups as well, for instance, all machines must be in the group webservers but not in the group phoenix::
|
|
|
|
webservers:!phoenix
|
|
|
|
You can also specify the intersection of two groups. This would mean the hosts must be in the group webservers and
|
|
the host must also be in the group staging::
|
|
|
|
webservers:&staging
|
|
|
|
You can do combinations::
|
|
|
|
webservers:dbservers:&staging:!phoenix
|
|
|
|
The above configuration means "all machines in the groups 'webservers' and 'dbservers' are to be managed if they are in
|
|
the group 'staging' also, but the machines are not to be managed if they are in the group 'phoenix' ... whew!
|
|
|
|
You can also use variables if you want to pass some group specifiers via the "-e" argument to ansible-playbook, but this
|
|
is uncommonly used::
|
|
|
|
webservers:!{{excluded}}:&{{required}}
|
|
|
|
You also don't have to manage by strictly defined groups. Individual host names, IPs and groups, can also be referenced using
|
|
wildcards::
|
|
|
|
*.example.com
|
|
*.com
|
|
|
|
It's also ok to mix wildcard patterns and groups at the same time::
|
|
|
|
one*.com:dbservers
|
|
|
|
And if the pattern starts with a '~' it is treated as a regular expression::
|
|
|
|
~(web|db).*\.example\.com
|
|
|
|
While we're jumping a bit ahead, additionally, you can add an exclusion criteria just by supplying the "--limit" flag to /usr/bin/ansible or /usr/bin/ansible-playbook.
|
|
|
|
ansible-playbook site.yml --limit datacenter2
|
|
|
|
Easy enough. See :doc:`intro_adhoc` and then :doc:`playbooks` for how to apply this knowledge.
|
|
|
|
.. seealso::
|
|
|
|
:doc:`intro_adhoc`
|
|
Examples of basic commands
|
|
:doc:`playbooks`
|
|
Learning ansible's configuration management language
|
|
`Mailing List <http://groups.google.com/group/ansible-project>`_
|
|
Questions? Help? Ideas? Stop by the list on Google Groups
|
|
`irc.freenode.net <http://irc.freenode.net>`_
|
|
#ansible IRC chat channel
|
|
|