Commit a6b4b9a7 by Michael DeHaan

Show more whitespace throughout playbook examples to encourage better standards…

Show more whitespace throughout playbook examples to encourage better standards in first playbooks folks write.
parent 4b281ca5
......@@ -44,9 +44,12 @@ Accelerated mode offers several improvements over the (deprecated) original fire
In order to use accelerated mode, simply add `accelerate: true` to your play::
---
- hosts: all
accelerate: true
tasks:
- name: some task
command: echo {{ item }}
with_items:
......@@ -57,6 +60,7 @@ In order to use accelerated mode, simply add `accelerate: true` to your play::
If you wish to change the port Ansible will use for the accelerated connection, just add the `accelerated_port` option::
---
- hosts: all
accelerate: true
# default port is 5099
......
......@@ -16,9 +16,12 @@ and how frequently you would like to poll for status. The default
poll value is 10 seconds if you do not specify a value for `poll`::
---
- hosts: all
remote_user: root
tasks:
- name: simulate long running op (15 sec), wait for up to 45, poll every 5
command: /bin/sleep 15
async: 45
......@@ -33,9 +36,12 @@ Alternatively, if you do not need to wait on the task to complete, you may
"fire and forget" by specifying a poll value of 0::
---
- hosts: all
remote_user: root
tasks:
- name: simulate long running op, allow to run for 45, fire and forget
command: /bin/sleep 15
async: 45
......
......@@ -305,6 +305,7 @@ This makes a dynamic group of hosts matching certain criteria, even if that grou
# talk to all hosts just so we can learn about them
- hosts: all
tasks:
- group_by: key={{ ansible_distribution }}
......@@ -312,6 +313,7 @@ This makes a dynamic group of hosts matching certain criteria, even if that grou
- hosts: CentOS
gather_facts: False
tasks:
- # tasks that only happen on CentOS go here
......
......@@ -71,10 +71,12 @@ outage windows. Using this with the 'serial' keyword to control the number of h
a good idea::
---
- hosts: webservers
serial: 5
tasks:
- name: take out of load balancer pool
command: /usr/bin/take_out_of_pool {{ inventory_hostname }}
delegate_to: 127.0.0.1
......@@ -87,13 +89,14 @@ a good idea::
delegate_to: 127.0.0.1
These commands will run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that
you can use on a per-task basis: 'local_action'. Here is the same playbook as above, but using the shorthand
syntax for delegating to 127.0.0.1::
These commands will run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that you can use on a per-task basis: 'local_action'. Here is the same playbook as above, but using the shorthand syntax for delegating to 127.0.0.1::
---
# ...
tasks:
- name: take out of load balancer pool
local_action: command /usr/bin/take_out_of_pool {{ inventory_hostname }}
......@@ -108,6 +111,7 @@ Here is an example::
---
# ...
tasks:
- name: recursively copy files from management server to target
local_action: command rsync -a /path/to/files {{ inventory_hostname }}:/path/to/target/
......
......@@ -21,7 +21,9 @@ Contents can be read off the filesystem as follows::
- hosts: all
vars:
contents: "{{ lookup('file', '/etc/foo.txt') }}"
tasks:
- debug: msg="the value of foo.txt is {{ contents }}"
.. _password_lookup:
......@@ -128,6 +130,7 @@ template)::
motd_value: "{{ lookup('file', '/etc/motd') }}"
tasks:
- debug: msg="motd value is {{ motd_value }}"
.. seealso::
......
......@@ -15,8 +15,10 @@ Here is a most basic example::
---
- hosts: all
remote_user: root
vars:
from: "camelot"
vars_prompt:
name: "what is your name?"
quest: "what is your quest?"
......@@ -27,6 +29,7 @@ provide a default value that can be overridden. This can be accomplished using
the default argument::
vars_prompt:
- name: "release_version"
prompt: "Product release version"
default: "1.0"
......@@ -35,9 +38,11 @@ An alternative form of vars_prompt allows for hiding input from the user, and ma
some other options, but otherwise works equivalently::
vars_prompt:
- name: "some_password"
prompt: "Enter password"
private: yes
- name: "release_version"
prompt: "Product release version"
private: no
......@@ -46,6 +51,7 @@ If `Passlib <http://pythonhosted.org/passlib/>`_ is installed, vars_prompt can a
entered value so you can use it, for instance, with the user module to define a password::
vars_prompt:
- name: "my_password2"
prompt: "Enter password2"
private: yes
......
......@@ -42,15 +42,18 @@ A task include file simply contains a flat list of tasks, like so::
---
# possibly saved as tasks/foo.yml
- name: placeholder foo
command: /bin/foo
- name: placeholder bar
command: /bin/bar
Include directives look like this, and can be mixed in with regular tasks in a playbook::
tasks:
- include: tasks/foo.yml
- include: tasks/foo.yml
You can also pass variables into includes. We call this a 'parameterized include'.
......@@ -120,7 +123,9 @@ For example::
- name: this is a play at the top level of a file
hosts: all
remote_user: root
tasks:
- name: say hi
tags: foo
shell: echo "hi..."
......@@ -211,6 +216,7 @@ the roles are evaluated first.
Also, should you wish to parameterize roles, by adding variables, you can do so, like this::
---
- hosts: webservers
roles:
- common
......@@ -220,6 +226,7 @@ Also, should you wish to parameterize roles, by adding variables, you can do so,
While it's probably not something you should do often, you can also conditionally apply roles like so::
---
- hosts: webservers
roles:
- { role: some_role, when: "ansible_os_family == 'RedHat'" }
......@@ -230,6 +237,7 @@ the documentation.
Finally, you may wish to assign tags to the roles you specify. You can do so inline:::
---
- hosts: webservers
roles:
- { role: foo, tags: ["bar", "baz"] }
......@@ -240,13 +248,18 @@ If the play still has a 'tasks' section, those tasks are executed after roles ar
If you want to define certain tasks to happen before AND after roles are applied, you can do this::
---
- hosts: webservers
pre_tasks:
- shell: echo 'hello'
roles:
- { role: some_role }
tasks:
- shell: echo 'still busy'
post_tasks:
- shell: echo 'goodbye'
......
......@@ -136,6 +136,7 @@ Filters Often Used With Conditionals
The following tasks are illustrative of how filters can be used with conditionals::
tasks:
- shell: /usr/bin/foo
register: result
ignore_errors: True
......@@ -691,13 +692,16 @@ the main playbook.
You can do this by using an external variables file, or files, just like this::
---
- hosts: all
remote_user: root
vars:
favcolor: blue
vars_files:
- /vars/external_vars.yml
tasks:
- name: this is just a placeholder
command: /bin/echo foo
......@@ -731,8 +735,10 @@ This is useful, for, among other things, setting the hosts group or the user for
Example::
---
- remote_user: '{{ user }}'
hosts: '{{ hosts }}'
- hosts: '{{ hosts }}'
remote_user: '{{ user }}'
tasks:
- ...
......@@ -765,12 +771,15 @@ As an example, the name of the Apache package may be different between CentOS an
but it is easily handled with a minimum of syntax in an Ansible Playbook::
---
- hosts: all
remote_user: root
vars_files:
- "vars/common.yml"
- [ "vars/{{ ansible_os_family }}.yml", "vars/os_defaults.yml" ]
tasks:
- name: make sure apache is running
service: name={{ apache }} state=running
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment