internet/community.general
3
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2026-05-08 14:22:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

new playbooks best practices page + docs rebuild

Browse Source
This commit is contained in:
Michael DeHaan
2012-05-13 11:56:09 -04:00
parent 4994566124
commit 0127df97b5
17 changed files with 270 additions and 153 deletions
Download Patch File Download Diff File Expand all files Collapse all files

111
rst/bestpractices.rst Normal file
View File

@@ -0,0 +1,111 @@
Best Practices
==============
Here are some tips for making the most of Ansible.
Group By Roles
++++++++++++++
A system can be in multiple groups. See ref:`patterns`. Having groups named after things like
'webservers' and 'dbservers' is repeated in the examples because it's a very powerful concept.
This allows playbooks to target machines based on role, as well as to assign role specific variables
using the group variable system.
Directory Organization
++++++++++++++++++++++
Playbooks should be organized like this::
(root of source control repository)
acme/ # each playbook has a directory
setup.yml # playbook to manage the service
stop.yml # playbook to halt the service (optional)
files/
some_file_path_foo.conf
templates/
etc_acme_conf_acme.conf
etc_other_conf_other.conf
vars/
main.yml
handlers/
main.yml
tasks/
setup.yml
stop.yml
Any directories or files not needed can be omitted. Not all modules may require `vars` or `files` sections, though most
will require `handlers`, `tasks`, and `templates`. To review what each of these sections do, see ref:`playbooks` and ref:`playbooks2`.
The acme/setup.yml playbook would be as simple as::
----
- hosts: webservers
user: root
vars_files
- include: vars/main.yml
tasks:
- include: tasks/setup.yml
handlers:
- include: handlers/main.yml
The tasks are individually broken out in 'acme/tasks/setup.yml', and handlers, which are common to all task files,
are contained in 'acme/handlers/main.yml'. As a reminder, handlers are mostly just used to notify services to restart
when things change, and these are described in ref:`playbooks`.
Including more than one setup file or more than one handlers file is of course legal.
Having playbooks be able to include other playbooks is coming in release 0.5.
Until then, to manage your entire site, simply execute all of your playbooks together, in the order desired.
You don't have to do this though, it's fine to select sections of your infrastructure to manage at a single time.
You may wish to construct simple shell scripts to wrap calls to ansible-playbook.
Miscellaneous Tips
++++++++++++++++++
When you can do something simply, do something simply. Do not reach to use every feature of Ansible together, all
at once. Use what works for you. For example, you should probably not need 'vars', 'vars_files', 'vars_prompt' and '--extra-vars' all at once, while also using an external inventory file.
Optimize for readability. Whitespace between sections of YAML documents and in between tasks is strongly encouraged,
as is usage of YAML comments, which start with "#". It is also useful to comment at the top of each file the purpose of the individual file and the author, including email address.
It is possible to leave off the "name" for a given task, though it is recommended to provide
a descriptive comment about why something is being done instead.
Use version control. Keep your playbooks and inventory file in git (or another version control system), and commit when you make changes to them.
This way you have an audit trail describing when and why you changed the rules automating your infrastructure.
Resist the urge to write the same playbooks and configuration files for heterogeneous distributions. While lots of software packages claim to make this easy on you, the configuration files are often quite different, to the point where it would be easier to treat them as different playbooks. This is why, for example, Ansible has a seperate 'yum' and 'apt' module. Yum and apt have different capabilities, and we don't want to code for the least common denominator.
Use variables for user tunable settings versus having constants in the tasks file or templates, so that it is easy to reconfigure a playbook. Think about this as exposing the knobs to things you would like to tweak.
Since a system can be in more than one group, if you have multiple datacenters or sites, consider putting systems into groups by role, but also different groups by geography. This allows you to assign different variables to different geographies.
.. seealso::
:doc:`YAMLSyntax`
Learn about YAML syntax
:doc:`playbooks`
Review the basic playbook features
:doc:`modules`
Learn about available modules
:doc:`moduledev`
Learn how to extend Ansible by writing your own modules
:doc:`patterns`
Learn about how to select hosts
`Github examples directory <https://github.com/ansible/ansible/tree/master/examples/playbooks>`_
Complete playbook files from the github project source
`Mailing List <http://groups.google.com/group/ansible-project>`_
Questions? Help? Ideas? Stop by the list on Google Groups

1
rst/index.rst
View File

@@ -127,6 +127,7 @@ Contents
YAMLSyntax
playbooks
playbooks2
bestpractices
api
moduledev
faq

12
rst/playbooks.rst
View File

@@ -224,14 +224,8 @@ won't need them for much else.
Notify handlers are always run in the order written.
Power Tricks
````````````
Now that you have the basics down, let's learn some more advanced
things you can do with playbooks.
Include Files And Reuse
+++++++++++++++++++++++
```````````````````````
Suppose you want to reuse lists of tasks between plays or playbooks. You can use
include files to do this.
@@ -306,8 +300,12 @@ Let's run a playbook using a parallelism level of 10::
:doc:`YAMLSyntax`
Learn about YAML syntax
:doc:`playbooks`
Review the basic Playbook language features
:doc:`playbooks2`
Learn about Advanced Playbook Features
:doc:`bestpractices`
Various tips about managing playbooks in the real world
:doc:`modules`
Learn about available modules
:doc:`moduledev`

151
rst/playbooks2.rst
View File

@@ -2,39 +2,12 @@ Advanced Playbooks
==================
Here are some advanced features of the playbooks language. Using all of these features
are not neccessary, but many of them will prove useful.
are not neccessary, but many of them will prove useful. If a feature doesn't seem immediately
relevant, feel free to skip it. For many people, the features documented in `playbooks` will
be 90% or more of what they use in Ansible.
Local Playbooks
+++++++++++++++
It may be useful to use a playbook locally, rather than by connecting over SSH. This can be useful
for assuring the configuration of a system by putting a playbook on a crontab. This may also be used
to run a playbook inside a OS installer, such as an Anaconda kickstart.
To run an entire playbook locally, just set the "hosts:" line to "hosts:127.0.0.1" and then run the playbook like so::
ansible-playbook playbook.yml --connection=local
Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook
use the default remote connection type::
hosts: 127.0.0.1
connection: local
Pull-Mode Playbooks
+++++++++++++++++++
The use of playbooks in local mode (above) is made extremely powerful with the addition of `ansible-pull` in the
0.4 release. A script for setting up ansible-pull is provided in the examples/playbooks directory of the source
checkout.
The basic idea is to use Ansible to set up a remote copy of ansible on each managed node, each set to run via
cron and update playbook source via git. This interverts the default push architecture of ansible into a pull
architecture, which has near-limitless scaling potential. The setup playbook can be tuned to change
the cron frequency, logging locations, and parameters to ansible-pull.
Accessing Hash and Array Variable Data
++++++++++++++++++++++++++++++++++++++
Accessing Complex Variable Data
+++++++++++++++++++++++++++++++
Some provided facts, like networking information, are made available as nested datastructures. To access
them a simple '$foo' is not sufficient, but it is still easy to do. Here's how we get an IP address using
@@ -44,12 +17,17 @@ Ansible 0.4 and later::
It is also possible to access variables whose elements are arrays::
${somelist[1]}
${somelist[0]}
And the array and hash reference syntaxes can be mixed.
Accessing Variables From Other Hosts
++++++++++++++++++++++++++++++++++++
In templates, the simple access form still holds, but they can also be accessed from Jinja2 in more Python-native ways if
that is preferred::
{{ ansible_eth0["ipv4"]["address"] }}
Accessing Information About Other Hosts
+++++++++++++++++++++++++++++++++++++++
If your database server wants to check the value of a 'fact' from another node, or an inventory variable
assigned to another node, it's easy to do so within a template or even an action line (note: this uses syntax available in 0.4 and later)::
@@ -59,8 +37,24 @@ assigned to another node, it's easy to do so within a template or even an action
NOTE: No database or other complex system is required to exchange data between hosts. The hosts that you
want to reference data from must be included in either the current play or any previous play.
External Variables and Prompted or Sensitive Data
+++++++++++++++++++++++++++++++++++++++++++++++++
Magic Variables
+++++++++++++++
Some variables made available to hosts don't come from definitions in a playbook, the inventory file, or discovery from the system. There are only two of these, and are used in special cases that many users won't need.
`groups` is a list (array) of all the groups the current host is in. This can be used in templates using Jinja2
syntax to make template source files that vary based on the group membership (or role) of the host::
{% if 'webserver' in groups %}
# some part of a configuration file that only applies to webservers
{% endif %}
`inventory_hostname` is the name of the hostname as configured in Ansible's inventory host file. This can
be useful for when you don't want to rely on the discovered hostname `ansible_hostname` or for other mysterious
reasons. Don't worry about it unless you think you need it.
Variable File Seperation
++++++++++++++++++++++++
It's a great idea to keep your playbooks under source control, but
you may wish to make the playbook source public while keeping certain
@@ -200,48 +194,6 @@ from turning into arbitrary code with ugly nested ifs, conditionals, and so on -
in more streamlined & auditable configuration rules -- especially because there are a
minimum of decision points to track.
Using Includes To Assign Classes of Systems
+++++++++++++++++++++++++++++++++++++++++++
Include files are really powerful when used to reuse logic between playbooks. You
could imagine a playbook describing your entire infrastructure like
this, in a list of just a few plays::
---
- hosts: atlanta-webservers
vars:
datacenter: atlanta
database: db.atlanta.com
tasks:
- include: tasks/base.yml
- include: tasks/webservers.yml
handlers:
- include: handlers/common.yml
- hosts: atlanta-dbservers
vars:
datacenter: atlanta
tasks:
- include: tasks/base.yml
- include: tasks/dbservers.yml
handlers:
- include: handlers/common.yml
There is one (or more) play defined for each group of systems, and
each play maps each group to several includes. These includes represent
'class definitions', telling the systems what they are supposed to do or be.
In the above example, all hosts get the base configuration first and further
customize it depending on what class or nature of machines they are.
Loop Shorthand
++++++++++++++
@@ -272,13 +224,13 @@ The following construct (new in 0.4) selects the first available file appropriat
which is often much cleaner than putting a lot of if conditionals in a template.
The following example shows how to template out a configuration file that was very different between, say,
CentOS and Debian.
CentOS and Debian::
- name: template a file
action: template src=$item dest=/etc/myapp/foo.conf
first_available_file:
- /srv/templates/myapp/${ansible_distribution}.conf
- /srv/templates/myapp/default.conf
- /srv/templates/myapp/${ansible_distribution}.conf
- /srv/templates/myapp/default.conf
Asynchronous Actions and Polling
@@ -332,12 +284,47 @@ Alternatively, if you do not need to wait on the task to complete, you may
Using a higher value for ``--forks`` will result in kicking off asynchronous
tasks even faster. This also increases the efficiency of polling.
Local Playbooks
+++++++++++++++
It may be useful to use a playbook locally, rather than by connecting over SSH. This can be useful
for assuring the configuration of a system by putting a playbook on a crontab. This may also be used
to run a playbook inside a OS installer, such as an Anaconda kickstart.
To run an entire playbook locally, just set the "hosts:" line to "hosts:127.0.0.1" and then run the playbook like so::
ansible-playbook playbook.yml --connection=local
Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook
use the default remote connection type::
hosts: 127.0.0.1
connection: local
Pull-Mode Playbooks
+++++++++++++++++++
The use of playbooks in local mode (above) is made extremely powerful with the addition of `ansible-pull` in the
0.4 release. A script for setting up ansible-pull is provided in the examples/playbooks directory of the source
checkout.
The basic idea is to use Ansible to set up a remote copy of ansible on each managed node, each set to run via
cron and update playbook source via git. This interverts the default push architecture of ansible into a pull
architecture, which has near-limitless scaling potential. The setup playbook can be tuned to change
the cron frequency, logging locations, and parameters to ansible-pull.
This is useful both for extreme scale-out as well as periodic remediation. Usage of the 'fetch' module to retrieve
logs from ansible-pull runs would be an excellent way to gather and analyze remote logs from ansible-pull.
.. seealso::
:doc:`YAMLSyntax`
Learn about YAML syntax
:doc:`playbooks`
Review the basic playbook features
:doc:`bestpractices`
Various tips about playbooks in the real world
:doc:`modules`
Learn about available modules
:doc:`moduledev`