mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
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
|
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.
|
'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
|
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,
|
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
|
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.
|
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.
|
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.
|
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.
|
You may wish to construct simple shell scripts to wrap calls to ansible-playbook.
|
||||||
|
|
||||||
Miscellaneous Tips
|
Miscellaneous Tips
|
||||||
++++++++++++++++++
|
++++++++++++++++++
|
||||||
|
|
||||||
When you can do something simply, do something simply. Do not reach to use every feature of Ansible together, all
|
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,
|
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.
|
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
|
$ cd ./ansible
|
||||||
$ source ./hacking/env-setup
|
$ 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
|
$ echo "127.0.0.1" > ~/ansible_hosts
|
||||||
$ export ANSIBLE_HOSTS=~/ansible_hosts
|
$ export ANSIBLE_HOSTS=~/ansible_hosts
|
||||||
|
@ -114,7 +114,7 @@ Debian package recipes can be built from the source checkout, run::
|
||||||
make debian
|
make debian
|
||||||
|
|
||||||
An Arch PKGBUILD is available on `AUR <https://aur.archlinux.org/packages.php?ID=58621>`_
|
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
|
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
|
only output is returned. There is no error detection or change handler support
|
||||||
for this module.
|
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"
|
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
|
$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 }}
|
{{ varname }}
|
||||||
|
|
||||||
|
|
|
@ -9,7 +9,7 @@ be 90% or more of what they use in Ansible.
|
||||||
Accessing Complex Variable Data
|
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
|
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::
|
Ansible 0.4 and later::
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue