Merge pull request #110 from johncallender/master
I noticed a few small issues in the new docs
This commit is contained in:
commit
b896157d61
5 changed files with 9 additions and 9 deletions
|
@ -6,7 +6,7 @@ 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
|
||||
A system can be in multiple groups. See :doc:`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
|
||||
|
@ -60,21 +60,21 @@ The acme/setup.yml playbook would be as simple as::
|
|||
|
||||
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`.
|
||||
when things change, and these are described in :doc:`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 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.
|
||||
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.
|
||||
|
|
|
@ -60,7 +60,7 @@ to use it::
|
|||
$ cd ./ansible
|
||||
$ source ./hacking/env-setup
|
||||
|
||||
You can optionally specify an inventory file (see doc:`patterns`) other than /etc/ansible/hosts::
|
||||
You can optionally specify an inventory file (see :doc:`patterns`) other than /etc/ansible/hosts::
|
||||
|
||||
$ echo "127.0.0.1" > ~/ansible_hosts
|
||||
$ export ANSIBLE_HOSTS=~/ansible_hosts
|
||||
|
@ -114,7 +114,7 @@ Debian package recipes can be built from the source checkout, run::
|
|||
make debian
|
||||
|
||||
An Arch PKGBUILD is available on `AUR <https://aur.archlinux.org/packages.php?ID=58621>`_
|
||||
If you have python3 installed on Arch, you probably want to symlink python to python2.::
|
||||
If you have python3 installed on Arch, you probably want to symlink python to python2::
|
||||
|
||||
sudo ln -sf /usr/bin/python2 /usr/bin/python
|
||||
|
||||
|
|
|
@ -335,7 +335,7 @@ Arguments given to 'raw' are run directly through the configured remote shell an
|
|||
only output is returned. There is no error detection or change handler support
|
||||
for this module.
|
||||
|
||||
Example from `/usr/bin/ansible` to bootstrap a legacy python 2.4 host:
|
||||
Example from `/usr/bin/ansible` to bootstrap a legacy python 2.4 host::
|
||||
|
||||
ansible newhost.example.com raw -a "yum install python-simplejson"
|
||||
|
||||
|
|
|
@ -101,7 +101,7 @@ These variables can be used later in the playbook like this::
|
|||
|
||||
$varname
|
||||
|
||||
In templates, the full power of the Jinja2 templating language is also available, which looks like this:
|
||||
In templates, the full power of the Jinja2 templating language is also available, which looks like this::
|
||||
|
||||
{{ varname }}
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ be 90% or more of what they use in Ansible.
|
|||
Accessing Complex Variable Data
|
||||
+++++++++++++++++++++++++++++++
|
||||
|
||||
Some provided facts, like networking information, are made available as nested datastructures. To access
|
||||
Some provided facts, like networking information, are made available as nested data structures. 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
|
||||
Ansible 0.4 and later::
|
||||
|
||||
|
|
Loading…
Reference in a new issue