RST reformatting a few things
This commit is contained in:
parent
358859d2f3
commit
7a4df9e2fc
2 changed files with 16 additions and 8 deletions
|
@ -84,13 +84,21 @@ key in ``authorized_keys``::
|
||||||
aserver.example.org
|
aserver.example.org
|
||||||
bserver.example.org
|
bserver.example.org
|
||||||
|
|
||||||
Now try this:
|
Set up SSH agent to avoid retyping passwords::
|
||||||
|
|
||||||
ssh-agent bash
|
ssh-agent bash
|
||||||
ssh-add ~/.ssh/id_rsa
|
ssh-add ~/.ssh/id_rsa
|
||||||
|
|
||||||
|
Now ping all your nodes::
|
||||||
|
|
||||||
ansible all -m ping
|
ansible all -m ping
|
||||||
|
|
||||||
|
Now run a live command on all of your nodes::
|
||||||
|
|
||||||
|
ansible all /bin/echo hello
|
||||||
|
|
||||||
Congratulations. You've just contacted your nodes with Ansible. It's now time to read some
|
Congratulations. You've just contacted your nodes with Ansible. It's now time to read some
|
||||||
of the more real-world examples, and explore what you can do with different modules, as well
|
of the more real-world examples, and explore what you can do with different modules, as well
|
||||||
as the Ansible playbooks language.
|
as the Ansible playbooks language. Ansible is not just about running commands, but you already
|
||||||
|
have a working infrastructure!
|
||||||
|
|
||||||
|
|
|
@ -54,7 +54,7 @@ Vars section
|
||||||
````````````
|
````````````
|
||||||
|
|
||||||
A list of variables and values that can be used in the plays. These can be used in templates
|
A list of variables and values that can be used in the plays. These can be used in templates
|
||||||
or 'action' lines and are dereferenced using ```jinja2``` syntax like this:
|
or 'action' lines and are dereferenced using ```jinja2``` syntax like this::
|
||||||
|
|
||||||
{{ varname }}
|
{{ varname }}
|
||||||
|
|
||||||
|
@ -62,12 +62,12 @@ Further, if there are discovered variables about the system (say, if facter or o
|
||||||
installed) these variables bubble up back into the playbook, and can be used on each
|
installed) these variables bubble up back into the playbook, and can be used on each
|
||||||
system just like explicitly set variables. Facter variables are prefixed with 'facter_'
|
system just like explicitly set variables. Facter variables are prefixed with 'facter_'
|
||||||
and Ohai variables are prefixed with 'ohai_'. So for instance, if I wanted to write the
|
and Ohai variables are prefixed with 'ohai_'. So for instance, if I wanted to write the
|
||||||
hostname into the /etc/motd file, I could say:
|
hostname into the /etc/motd file, I could say::
|
||||||
|
|
||||||
- name: write the motd
|
- name: write the motd
|
||||||
- action: template src=/srv/templates/motd.j2 dest=/etc/motd
|
- action: template src=/srv/templates/motd.j2 dest=/etc/motd
|
||||||
|
|
||||||
And in /srv/templates/motd.j2:::
|
And in /srv/templates/motd.j2::
|
||||||
|
|
||||||
You are logged into {{ facter_hostname }}
|
You are logged into {{ facter_hostname }}
|
||||||
|
|
||||||
|
@ -96,7 +96,7 @@ command line. See the module documentation for more info.
|
||||||
|
|
||||||
Variables, as mentioned above, can be used in action lines. So if, hypothetically, you wanted
|
Variables, as mentioned above, can be used in action lines. So if, hypothetically, you wanted
|
||||||
to make a directory on each system named after the hostname ... yeah, that's I know silly ... you could
|
to make a directory on each system named after the hostname ... yeah, that's I know silly ... you could
|
||||||
do it like so:
|
do it like so::
|
||||||
|
|
||||||
- name: make a directory
|
- name: make a directory
|
||||||
- action: mkdir /tmp/{{ facter_hostname }}
|
- action: mkdir /tmp/{{ facter_hostname }}
|
||||||
|
@ -125,12 +125,12 @@ Includes
|
||||||
|
|
||||||
Not all tasks have to be listed directly in the main file. An include file can contain
|
Not all tasks have to be listed directly in the main file. An include file can contain
|
||||||
a list of tasks (in YAML) as well, optionally passing extra variables into the file.
|
a list of tasks (in YAML) as well, optionally passing extra variables into the file.
|
||||||
Variables passed in can be deferenced like this (assume a variable named 'user')
|
Variables passed in can be deferenced like this (assume a variable named 'user')::
|
||||||
|
|
||||||
{{ user }}
|
{{ user }}
|
||||||
|
|
||||||
For instance, if deploying multiple wordpress instances, I could contain all of my tasks
|
For instance, if deploying multiple wordpress instances, I could contain all of my tasks
|
||||||
in a wordpress.yml file, and use it like so:
|
in a wordpress.yml file, and use it like so::
|
||||||
|
|
||||||
- tasks:
|
- tasks:
|
||||||
- include: wordpress.yml user=timmy
|
- include: wordpress.yml user=timmy
|
||||||
|
|
Loading…
Reference in a new issue