mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Use addresses and names reserved for documentation
Trying to preserve the meaning of the examples. Not all occurrences in `docsite/rst/playbooks_lookups.rst` have been changed for instance to allow the unchanged examples to be used for testing. Related to: #17479
This commit is contained in:
parent
ae8ec31700
commit
d76dd56ca3
13 changed files with 46 additions and 48 deletions
|
@ -76,7 +76,7 @@ required. For a specific host, this script returns the following variables:
|
|||
"version": "latest"
|
||||
},
|
||||
"location": "westus",
|
||||
"mac_address": "00-0D-3A-31-2C-EC",
|
||||
"mac_address": "00-00-5E-00-53-FE",
|
||||
"name": "object-name",
|
||||
"network_interface": "interface-name",
|
||||
"network_interface_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/networkInterfaces/object-name1",
|
||||
|
|
|
@ -255,7 +255,7 @@ For a given host, the inventory script provides the following host variables:
|
|||
"version": "latest"
|
||||
},
|
||||
"location": "westus",
|
||||
"mac_address": "00-0D-3A-31-2C-EC",
|
||||
"mac_address": "00-00-5E-00-53-FE",
|
||||
"name": "object-name",
|
||||
"network_interface": "interface-name",
|
||||
"network_interface_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/networkInterfaces/object-name1",
|
||||
|
|
|
@ -115,15 +115,15 @@ This is how our inventory looks like:
|
|||
jumphost
|
||||
|
||||
[webserver]
|
||||
web-01.example.com public_ip=1.2.3.4
|
||||
web-02.example.com public_ip=1.2.3.5
|
||||
web-01.example.com public_ip=198.51.100.20
|
||||
web-02.example.com public_ip=198.51.100.21
|
||||
|
||||
[db-server]
|
||||
db-01.example.com
|
||||
db-02.example.com
|
||||
|
||||
[jumphost]
|
||||
jump.example.com public_ip=1.2.3.6
|
||||
jump.example.com public_ip=198.51.100.22
|
||||
|
||||
As you can see, the public IPs for our web servers and jumphost has been assigned as variable ``public_ip`` directly in the inventory.
|
||||
|
||||
|
|
|
@ -72,7 +72,7 @@ Control how modules connect to the Docker API by passing the following parameter
|
|||
|
||||
docker_host
|
||||
The URL or Unix socket path used to connect to the Docker API. Defaults to ``unix://var/run/docker.sock``.
|
||||
To connect to a remote host, provide the TCP connection string. For example: ``tcp://192.168.99.100:2376``. If
|
||||
To connect to a remote host, provide the TCP connection string. For example: ``tcp://192.0.2.23:2376``. If
|
||||
TLS is used to encrypt the connection to the API, then the module will automatically replace 'tcp' in the
|
||||
connection URL with 'https'.
|
||||
|
||||
|
@ -170,7 +170,7 @@ examples to get you started:
|
|||
|
||||
# Any container's ssh port exposed on 0.0.0.0 will be mapped to
|
||||
# another IP address (where Ansible will attempt to connect via SSH)
|
||||
DOCKER_DEFAULT_IP=1.2.3.4 ./docker.py --pretty
|
||||
DOCKER_DEFAULT_IP=192.0.2.5 ./docker.py --pretty
|
||||
|
||||
# Run as input to a playbook:
|
||||
ansible-playbook -i ~/projects/ansible/contrib/inventory/docker.py docker_inventory_test.yml
|
||||
|
|
|
@ -200,23 +200,23 @@ following information, which will be utilized for inventory and variables.
|
|||
"_meta": {
|
||||
"hostvars": {
|
||||
"test": {
|
||||
"ansible_host": "1.1.1.1",
|
||||
"rax_accessipv4": "1.1.1.1",
|
||||
"rax_accessipv6": "2607:f0d0:1002:51::4",
|
||||
"ansible_host": "198.51.100.1",
|
||||
"rax_accessipv4": "198.51.100.1",
|
||||
"rax_accessipv6": "2001:DB8::2342",
|
||||
"rax_addresses": {
|
||||
"private": [
|
||||
{
|
||||
"addr": "2.2.2.2",
|
||||
"addr": "192.0.2.2",
|
||||
"version": 4
|
||||
}
|
||||
],
|
||||
"public": [
|
||||
{
|
||||
"addr": "1.1.1.1",
|
||||
"addr": "198.51.100.1",
|
||||
"version": 4
|
||||
},
|
||||
{
|
||||
"addr": "2607:f0d0:1002:51::4",
|
||||
"addr": "2001:DB8::2342",
|
||||
"version": 6
|
||||
}
|
||||
]
|
||||
|
@ -262,11 +262,11 @@ following information, which will be utilized for inventory and variables.
|
|||
"rax_name_attr": "name",
|
||||
"rax_networks": {
|
||||
"private": [
|
||||
"2.2.2.2"
|
||||
"192.0.2.2"
|
||||
],
|
||||
"public": [
|
||||
"1.1.1.1",
|
||||
"2607:f0d0:1002:51::4"
|
||||
"198.51.100.1",
|
||||
"2001:DB8::2342"
|
||||
]
|
||||
},
|
||||
"rax_os-dcf_diskconfig": "AUTO",
|
||||
|
@ -322,22 +322,22 @@ The ``rax_facts`` module provides facts as followings, which match the ``rax.py`
|
|||
|
||||
{
|
||||
"ansible_facts": {
|
||||
"rax_accessipv4": "1.1.1.1",
|
||||
"rax_accessipv6": "2607:f0d0:1002:51::4",
|
||||
"rax_accessipv4": "198.51.100.1",
|
||||
"rax_accessipv6": "2001:DB8::2342",
|
||||
"rax_addresses": {
|
||||
"private": [
|
||||
{
|
||||
"addr": "2.2.2.2",
|
||||
"addr": "192.0.2.2",
|
||||
"version": 4
|
||||
}
|
||||
],
|
||||
"public": [
|
||||
{
|
||||
"addr": "1.1.1.1",
|
||||
"addr": "198.51.100.1",
|
||||
"version": 4
|
||||
},
|
||||
{
|
||||
"addr": "2607:f0d0:1002:51::4",
|
||||
"addr": "2001:DB8::2342",
|
||||
"version": 6
|
||||
}
|
||||
]
|
||||
|
@ -383,11 +383,11 @@ The ``rax_facts`` module provides facts as followings, which match the ``rax.py`
|
|||
"rax_name_attr": "name",
|
||||
"rax_networks": {
|
||||
"private": [
|
||||
"2.2.2.2"
|
||||
"192.0.2.2"
|
||||
],
|
||||
"public": [
|
||||
"1.1.1.1",
|
||||
"2607:f0d0:1002:51::4"
|
||||
"198.51.100.1",
|
||||
"2001:DB8::2342"
|
||||
]
|
||||
},
|
||||
"rax_os-dcf_diskconfig": "AUTO",
|
||||
|
|
|
@ -114,7 +114,7 @@ Here is lamp_haproxy's ``group_vars/all`` file. As you might expect, these varia
|
|||
|
||||
---
|
||||
httpd_port: 80
|
||||
ntpserver: 192.168.1.2
|
||||
ntpserver: 192.0.2.23
|
||||
|
||||
This is a YAML file, and you can create lists and dictionaries for more complex variable structures.
|
||||
In this case, we are just setting two variables, one for the port for the web server, and one for the
|
||||
|
|
|
@ -49,7 +49,7 @@ Now that you've installed Ansible, it's time to get started with some basics.
|
|||
Edit (or create) ``/etc/ansible/hosts`` and put one or more remote systems in it. Your
|
||||
public SSH key should be located in ``authorized_keys`` on those systems::
|
||||
|
||||
192.168.1.50
|
||||
192.0.2.50
|
||||
aserver.example.org
|
||||
bserver.example.org
|
||||
|
||||
|
@ -147,4 +147,3 @@ To enable basic logging on the control machine see :doc:`intro_configuration` do
|
|||
Questions? Help? Ideas? Stop by the list on Google Groups
|
||||
`irc.freenode.net <http://irc.freenode.net>`_
|
||||
#ansible IRC chat channel
|
||||
|
||||
|
|
|
@ -49,9 +49,9 @@ To make things explicit, it is suggested that you set them if things are not run
|
|||
|
||||
Suppose you have just static IPs and want to set up some aliases that live in your host file, or you are connecting through tunnels. You can also describe hosts like this::
|
||||
|
||||
jumper ansible_port=5555 ansible_host=192.168.1.50
|
||||
jumper ansible_port=5555 ansible_host=192.0.2.50
|
||||
|
||||
In the above example, trying to ansible against the host alias "jumper" (which may not even be a real hostname) will contact 192.168.1.50 on port 5555. Note that this is using a feature of the inventory file to define some special variables. Generally speaking this is not the best
|
||||
In the above example, trying to ansible against the host alias "jumper" (which may not even be a real hostname) will contact 192.0.2.50 on port 5555. Note that this is using a feature of the inventory file to define some special variables. Generally speaking this is not the best
|
||||
way to define variables that describe your system policy, but we'll share suggestions on doing this later. We're just getting started.
|
||||
|
||||
Adding a lot of hosts? If you have a lot of hosts following similar patterns you can do this rather than listing each hostname::
|
||||
|
|
|
@ -28,8 +28,8 @@ It is also possible to address a specific host or set of hosts by name::
|
|||
|
||||
one.example.com
|
||||
one.example.com:two.example.com
|
||||
192.168.1.50
|
||||
192.168.1.*
|
||||
192.0.2.50
|
||||
192.0.2.*
|
||||
|
||||
The following patterns address one or more groups. Groups separated by a colon indicate an "OR" configuration.
|
||||
This means the host may be in either one group or the other::
|
||||
|
@ -110,4 +110,3 @@ Easy enough. See :doc:`intro_adhoc` and then :doc:`playbooks` for how to apply
|
|||
Questions? Help? Ideas? Stop by the list on Google Groups
|
||||
`irc.freenode.net <http://irc.freenode.net>`_
|
||||
#ansible IRC chat channel
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ and run the task again::
|
|||
PLAY ***************************************************************************
|
||||
|
||||
TASK [wrong variable] **********************************************************
|
||||
fatal: [192.168.1.1]: FAILED! => {"failed": true, "msg": "ERROR! 'wrong_var' is undefined"}
|
||||
fatal: [192.0.2.10]: FAILED! => {"failed": true, "msg": "ERROR! 'wrong_var' is undefined"}
|
||||
Debugger invoked
|
||||
(debug) p result
|
||||
{'msg': u"ERROR! 'wrong_var' is undefined", 'failed': True}
|
||||
|
@ -42,10 +42,10 @@ and run the task again::
|
|||
(debug) p task.args
|
||||
{u'data': '{{ var1 }}'}
|
||||
(debug) redo
|
||||
ok: [192.168.1.1]
|
||||
ok: [192.0.2.10]
|
||||
|
||||
PLAY RECAP *********************************************************************
|
||||
192.168.1.1 : ok=1 changed=0 unreachable=0 failed=0
|
||||
192.0.2.10 : ok=1 changed=0 unreachable=0 failed=0
|
||||
|
||||
This time, the task runs successfully!
|
||||
|
||||
|
@ -66,14 +66,14 @@ Print values used to execute a module::
|
|||
(debug) p task.args
|
||||
{u'name': u'{{ pkg_name }}'}
|
||||
(debug) p vars
|
||||
{u'ansible_all_ipv4_addresses': [u'192.168.1.1'],
|
||||
{u'ansible_all_ipv4_addresses': [u'192.0.2.10'],
|
||||
u'ansible_architecture': u'x86_64',
|
||||
...
|
||||
}
|
||||
(debug) p vars['pkg_name']
|
||||
u'bash'
|
||||
(debug) p host
|
||||
192.168.1.1
|
||||
192.0.2.10
|
||||
(debug) p result
|
||||
{'_ansible_no_log': False,
|
||||
'changed': False,
|
||||
|
|
|
@ -295,8 +295,8 @@ record type that should be queried. This can be done by either passing-in
|
|||
additional parameter of format ``qtype=TYPE`` to the ``dig`` lookup, or by
|
||||
appending ``/TYPE`` to the *FQDN* being queried. For example::
|
||||
|
||||
- debug: msg="The TXT record for gmail.com. is {{ lookup('dig', 'gmail.com.', 'qtype=TXT') }}"
|
||||
- debug: msg="The TXT record for gmail.com. is {{ lookup('dig', 'gmail.com./TXT') }}"
|
||||
- debug: msg="The TXT record for example.org. is {{ lookup('dig', 'example.org.', 'qtype=TXT') }}"
|
||||
- debug: msg="The TXT record for example.org. is {{ lookup('dig', 'example.org./TXT') }}"
|
||||
|
||||
If multiple values are associated with the requested record, the results will be
|
||||
returned as a comma-separated list. In such cases you may want to pass option
|
||||
|
@ -310,16 +310,16 @@ In case of reverse DNS lookups (``PTR`` records), you can also use a convenience
|
|||
syntax of format ``IP_ADDRESS/PTR``. The following three lines would produce the
|
||||
same output::
|
||||
|
||||
- debug: msg="Reverse DNS for 8.8.8.8 is {{ lookup('dig', '8.8.8.8/PTR') }}"
|
||||
- debug: msg="Reverse DNS for 8.8.8.8 is {{ lookup('dig', '8.8.8.8.in-addr.arpa./PTR') }}"
|
||||
- debug: msg="Reverse DNS for 8.8.8.8 is {{ lookup('dig', '8.8.8.8.in-addr.arpa.', 'qtype=PTR') }}"
|
||||
- debug: msg="Reverse DNS for 192.0.2.5 is {{ lookup('dig', '192.0.2.5/PTR') }}"
|
||||
- debug: msg="Reverse DNS for 192.0.2.5 is {{ lookup('dig', '5.2.0.192.in-addr.arpa./PTR') }}"
|
||||
- debug: msg="Reverse DNS for 192.0.2.5 is {{ lookup('dig', '5.2.0.192.in-addr.arpa.', 'qtype=PTR') }}"
|
||||
|
||||
By default, the lookup will rely on system-wide configured DNS servers for
|
||||
performing the query. It is also possible to explicitly specify DNS servers to
|
||||
query using the ``@DNS_SERVER_1,DNS_SERVER_2,...,DNS_SERVER_N`` notation. This
|
||||
needs to be passed-in as an additional parameter to the lookup. For example::
|
||||
|
||||
- debug: msg="Querying 8.8.8.8 for IPv4 address for example.com. produces {{ lookup('dig', 'example.com', '@8.8.8.8') }}"
|
||||
- debug: msg="Querying 198.51.100.23 for IPv4 address for example.com. produces {{ lookup('dig', 'example.com', '@198.51.100.23') }}"
|
||||
|
||||
In some cases the DNS records may hold a more complex data structure, or it may
|
||||
be useful to obtain the results in a form of a dictionary for future
|
||||
|
|
|
@ -107,8 +107,8 @@ class LookupModule(LookupBase):
|
|||
example.com qtype=A # same
|
||||
example.com/TXT # specific qtype
|
||||
example.com qtype=txt # same
|
||||
192.168.1.2/PTR # reverse PTR
|
||||
^^ shortcut for 2.1.168.192.in-addr.arpa/PTR
|
||||
192.0.2.23/PTR # reverse PTR
|
||||
^^ shortcut for 23.2.0.192.in-addr.arpa/PTR
|
||||
example.net/AAAA @nameserver # query specified server
|
||||
^^^ can be comma-sep list of names/addresses
|
||||
|
||||
|
@ -128,7 +128,7 @@ class LookupModule(LookupBase):
|
|||
flat = True
|
||||
|
||||
for t in terms:
|
||||
if t.startswith('@'): # e.g. "@10.0.1.2,192.168.1.1" is ok.
|
||||
if t.startswith('@'): # e.g. "@10.0.1.2,192.0.2.1" is ok.
|
||||
nsset = t[1:].split(',')
|
||||
nameservers = []
|
||||
for ns in nsset:
|
||||
|
|
|
@ -24,7 +24,7 @@ options:
|
|||
docker_host:
|
||||
description:
|
||||
- "The URL or Unix socket path used to connect to the Docker API. To connect to a remote host, provide the
|
||||
TCP connection string. For example, 'tcp://192.168.99.100:2376'. If TLS is used to encrypt the connection,
|
||||
TCP connection string. For example, 'tcp://192.0.2.23:2376'. If TLS is used to encrypt the connection,
|
||||
the module will automatically replace 'tcp' in the connection URL with 'https'."
|
||||
required: false
|
||||
default: "unix://var/run/docker.sock"
|
||||
|
@ -90,4 +90,4 @@ notes:
|
|||
DOCKER_TLS, DOCKER_TLS_VERIFY and DOCKER_TIMEOUT. If you are using docker machine, run the script shipped
|
||||
with the product that sets up the environment. It will set these variables for you. See
|
||||
https://docker-py.readthedocs.org/en/stable/machine/ for more details.
|
||||
'''
|
||||
'''
|
||||
|
|
Loading…
Reference in a new issue