mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Add a missing :: in an .rst file
Other changes are just eating trailing whitespace.
This commit is contained in:
parent
908a192736
commit
2e8533aec2
1 changed files with 8 additions and 8 deletions
|
@ -600,7 +600,7 @@ The environment can also be stored in a variable, and accessed like so::
|
||||||
http_proxy=http://proxy.example.com:8080
|
http_proxy=http://proxy.example.com:8080
|
||||||
|
|
||||||
tasks:
|
tasks:
|
||||||
|
|
||||||
- apt: name=cobbler state=installed
|
- apt: name=cobbler state=installed
|
||||||
environment: $proxy_env
|
environment: $proxy_env
|
||||||
|
|
||||||
|
@ -954,7 +954,7 @@ As a review, most tasks in ansbile are of this form::
|
||||||
|
|
||||||
- name: ensure the cobbler package is installed
|
- name: ensure the cobbler package is installed
|
||||||
yum: name=cobbler state=installed
|
yum: name=cobbler state=installed
|
||||||
|
|
||||||
However, in some cases, it may be useful to feed arguments directly in from a hash (dictionary). In fact, a very small
|
However, in some cases, it may be useful to feed arguments directly in from a hash (dictionary). In fact, a very small
|
||||||
number of modules (the CloudFormations module is one) actually require complex arguments that can't be fit
|
number of modules (the CloudFormations module is one) actually require complex arguments that can't be fit
|
||||||
into a key=value system. To pass arguments in from a hash (dictionary), do this::
|
into a key=value system. To pass arguments in from a hash (dictionary), do this::
|
||||||
|
@ -972,8 +972,8 @@ into a key=value system. To pass arguments in from a hash (dictionary), do this
|
||||||
my_pets:
|
my_pets:
|
||||||
dogs:
|
dogs:
|
||||||
- fido
|
- fido
|
||||||
- woof
|
- woof
|
||||||
fish:
|
fish:
|
||||||
- limpet
|
- limpet
|
||||||
- nemo
|
- nemo
|
||||||
|
|
||||||
|
@ -992,13 +992,13 @@ In above sections we talked about task includes, and how to do loops using with_
|
||||||
to externalize data from the playbook rules itself, this is possible by combining some concepts.
|
to externalize data from the playbook rules itself, this is possible by combining some concepts.
|
||||||
|
|
||||||
This is not something everyone may need to do at first, but it's a clever trick and deserves explanation.
|
This is not something everyone may need to do at first, but it's a clever trick and deserves explanation.
|
||||||
Here is a top level example playbook that loads variables from an external file and also tasks from an
|
Here is a top level example playbook that loads variables from an external file and also tasks from an
|
||||||
external file. You will note that we use a list (using with_items) as a parameter on the include
|
external file. You will note that we use a list (using with_items) as a parameter on the include
|
||||||
statement.
|
statement::
|
||||||
|
|
||||||
----
|
----
|
||||||
# file: playbook-demo.yml
|
# file: playbook-demo.yml
|
||||||
|
|
||||||
hosts: all
|
hosts: all
|
||||||
vars_files:
|
vars_files:
|
||||||
- config/users.yml
|
- config/users.yml
|
||||||
|
@ -1018,7 +1018,7 @@ them in the file instead. It's up to you::
|
||||||
- name: alice
|
- name: alice
|
||||||
password: cryptedPasswordHere
|
password: cryptedPasswordHere
|
||||||
sshkey: $FILE(/home/alice/id_rsa.pub)
|
sshkey: $FILE(/home/alice/id_rsa.pub)
|
||||||
|
|
||||||
- name: bob
|
- name: bob
|
||||||
password: cryptedPasswordHere
|
password: cryptedPasswordHere
|
||||||
sshkey: $FILE(/home/bob/id_rsa.pub)
|
sshkey: $FILE(/home/bob/id_rsa.pub)
|
||||||
|
|
Loading…
Reference in a new issue