mirror of
https://github.com/ansible-collections/community.general.git
synced 2025-10-21 03:23:59 -07:00
Minor docs restructuring
This commit is contained in:
Michael DeHaan
parent
12fd193450
commit
2cafb8d221
22 changed files with 260 additions and 294 deletions
|
|
@ -1,9 +0,0 @@
|
|||
Communicate and Get Involved
|
||||
===========================
|
||||
|
||||
* Join the `ansible-project mailing list <http://groups.google.com/group/ansible-project>`_ on Google Groups
|
||||
* Join `#ansible <irc://irc.freenode.net/#ansible>`_ on the `freenode IRC network <http://freenode.net/>`_
|
||||
* Visit the `project page <https://github.com/ansible/ansible>`_ on Github
|
||||
|
||||
- View the `issue tracker <https://github.com/ansible/ansible/issues>`_
|
||||
|
||||
|
|
@ -35,18 +35,15 @@ Design Goals
|
|||
* Be usable as non-root
|
||||
* Create the easiest config management system to use, ever.
|
||||
|
||||
About the Author
|
||||
````````````````
|
||||
Communicate and Get Involved
|
||||
````````````````````````````
|
||||
|
||||
Michael DeHaan is a Raleigh, NC based software developer and architect. He created other
|
||||
DevOps programs such as Cobbler, the popular Linux install server.
|
||||
Cobbler is used to deploy mission critical systems all over the planet, in industries
|
||||
ranging from massively multiplayer gaming, core internet infrastructure, finance,
|
||||
chip design, and more. Michael also helped co-author of Func, which is used
|
||||
to orchestrate systems in lots of diverse places.
|
||||
* Join the `ansible-project mailing list <http://groups.google.com/group/ansible-project>`_ on Google Groups
|
||||
* Join `#ansible <irc://irc.freenode.net/#ansible>`_ on the `freenode IRC network <http://freenode.net/>`_
|
||||
* Visit the `project page <https://github.com/ansible/ansible>`_ on Github
|
||||
|
||||
- View the `issue tracker <https://github.com/ansible/ansible/issues>`_
|
||||
|
||||
Ansible is an GPLv3 licensed open source project, so see the contributions section for how to
|
||||
get involved.
|
||||
|
||||
Contents
|
||||
========
|
||||
|
|
@ -61,5 +58,18 @@ Contents
|
|||
playbooks
|
||||
examples
|
||||
api
|
||||
communicate
|
||||
man
|
||||
|
||||
About the Author
|
||||
````````````````
|
||||
|
||||
Michael DeHaan is a Raleigh, NC based software developer and architect. He created other
|
||||
DevOps programs such as Cobbler, the popular Linux install server.
|
||||
Cobbler is used to deploy mission critical systems all over the planet, in industries
|
||||
ranging from massively multiplayer gaming, core internet infrastructure, finance,
|
||||
chip design, and more. Michael also helped co-author of Func, which is used
|
||||
to orchestrate systems in lots of diverse places.
|
||||
|
||||
Ansible is an GPLv3 licensed open source project, so see the contributions section for how to
|
||||
get involved.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
Ansible Modules
|
||||
===============
|
||||
|
||||
Ansible ships with a number of modules that can be executed directly on remote hosts or through
|
||||
ansible playbooks.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:doc:`examples`
|
||||
|
|
@ -10,16 +13,8 @@ Ansible Modules
|
|||
:doc:`api`
|
||||
Examples of using modules with the Python API
|
||||
|
||||
|
||||
About Modules
|
||||
`````````````
|
||||
|
||||
Ansible ships with a number of modules that can be executed directly on remote hosts or through
|
||||
ansible playbooks.
|
||||
|
||||
|
||||
Idempotence
|
||||
```````````
|
||||
Module Idempotence
|
||||
```````````````````
|
||||
|
||||
Most modules other than command are idempotent, meaning they will seek to avoid changes
|
||||
unless a change needs to be made. When using ansible playbooks, these modules can
|
||||
|
|
@ -189,7 +184,7 @@ yum
|
|||
This module is in plan.
|
||||
|
||||
|
||||
WRITING YOUR OWN MODULES
|
||||
writing your own modules
|
||||
````````````````````````
|
||||
|
||||
To write your own modules, simply follow the convention of those already available in
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Patterns
|
||||
========
|
||||
The Inventory File, Patterns, and Groups
|
||||
========================================
|
||||
|
||||
How to select hosts you wish to manage
|
||||
|
||||
|
|
@ -10,6 +10,9 @@ How to select hosts you wish to manage
|
|||
:doc:`playbooks`
|
||||
Learning ansible's configuration management language
|
||||
|
||||
Inventory File Format
|
||||
+++++++++++++++++++++
|
||||
|
||||
Ansible works against multiple systems in your infrastructure at the
|
||||
same time. It does this by selecting portions of systems listed in Ansible's inventory file,
|
||||
which defaults to /etc/ansible/hosts, and looks like this::
|
||||
|
|
@ -25,45 +28,36 @@ which defaults to /etc/ansible/hosts, and looks like this::
|
|||
two.example.com
|
||||
three.example.com
|
||||
|
||||
Targetting All Systems
|
||||
``````````````````````
|
||||
|
||||
The pattern 'all' or '*' targets all systems in the inventory file.
|
||||
|
||||
Specific Hosts
|
||||
``````````````
|
||||
Selecting Targets
|
||||
+++++++++++++++++
|
||||
|
||||
It is possible to address specific hosts:
|
||||
These patterns target all hosts in the inventory file::
|
||||
|
||||
all
|
||||
*
|
||||
|
||||
It is also possible to address specific hosts::
|
||||
|
||||
one.example.com
|
||||
one.example.com:two.example.com
|
||||
|
||||
Groups
|
||||
``````
|
||||
|
||||
The following patterns address one or more groups:
|
||||
The following patterns address one or more groups, which are denoted with the bracket
|
||||
headers in the inventory file::
|
||||
|
||||
webservers
|
||||
webservers:dbservers
|
||||
|
||||
There is also a magic group 'ungrouped' which selects systems not in a group.
|
||||
|
||||
Wildcards
|
||||
`````````
|
||||
|
||||
Individual hosts, but not groups, can also be referenced using wildcards:
|
||||
|
||||
*.example.com
|
||||
*.com
|
||||
|
||||
Mixing Things Up
|
||||
````````````````
|
||||
|
||||
Specific hosts, wildcards, and groups can all be mixed in the same pattern
|
||||
It's also ok to mix wildcard patterns and groups at the same time::
|
||||
|
||||
one*.com:dbservers
|
||||
|
||||
It is not possible to target a host not in the inventory file.
|
||||
|
||||
NOTE: It is not possible to target a host not in the inventory file.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Playbooks
|
||||
=========
|
||||
Playbooks: Ansible for Deployment, Configuration Management, and Orchestration
|
||||
==============================================================================
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
@ -11,22 +11,20 @@ Playbooks
|
|||
Learn about how to select hosts
|
||||
|
||||
|
||||
Playbooks are a completely different way to use ansible and are particularly awesome.
|
||||
|
||||
They are the basis for a really simple configuration management and deployment system, unlike any that already exist, and one that is very well suited to deploying complex multi-machine applications. While you might run the main ansible program for ad-hoc tasks, playbooks are more likely to be kept in source control and used to push out your configuration or assure the configurations of your remote systems are in spec.
|
||||
Playbooks are a completely different way to use ansible and are particularly awesome. They are the basis for a really simple configuration management and deployment system, unlike any that already exist, and one that is very well suited to deploying complex multi-machine applications. While you might run the main ansible program for ad-hoc tasks, playbooks are more likely to be kept in source control and used to push out your configuration or assure the configurations of your remote systems are in spec.
|
||||
|
||||
|
||||
Playbook Example
|
||||
````````````````
|
||||
|
||||
Playbooks are expressed in YAML format and have a minimum of syntax. Each playbook is composed
|
||||
of one or more patterns in a list. By composing a playbook of multiple patterns, it is possible
|
||||
of one or more 'plays' in a list. By composing a playbook of multiple 'plays', it is possible
|
||||
to orchestrate multi-machine deployments, running certain steps on all machines in
|
||||
the webservers group, then certain steps on the database server group, then more commands
|
||||
back on the webservers group, etc::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
- hosts: webservers
|
||||
vars:
|
||||
http_port: 80
|
||||
max_clients: 200
|
||||
|
|
@ -45,38 +43,39 @@ back on the webservers group, etc::
|
|||
Hosts line
|
||||
``````````
|
||||
|
||||
The hosts line is alist of one or more groups or host patterns, seperated by colons.::
|
||||
|
||||
webservers:dbservers:*.foo.example.com
|
||||
The hosts line is alist of one or more groups or host patterns, seperated by colons, as
|
||||
described in the 'patterns' documentation.
|
||||
|
||||
Vars section
|
||||
````````````
|
||||
|
||||
A list of variables that can be used in the 'action' lines of the template, or in
|
||||
included templates. Variables are deferenced like this::
|
||||
A list of variables that can be used in the templates, action lines, or included files.
|
||||
Variables are deferenced using ``jinja2`` syntax like this::
|
||||
|
||||
{{ varname }}
|
||||
|
||||
These variables will be pushed down to the managed systems for use in templating operations.
|
||||
These variables will be pushed down to the managed systems for use in templating operations, where
|
||||
the way to dereference them in templates is exactly the same.
|
||||
|
||||
Further, if there are discovered variables about the system (say, if facter or ohai were
|
||||
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'
|
||||
and Ohai variables are prefixed with 'ohai'.
|
||||
system just like explicitly set variables. Facter variables are prefixed with 'facter_'
|
||||
and Ohai variables are prefixed with 'ohai_'.
|
||||
|
||||
Tasks list
|
||||
``````````
|
||||
|
||||
Tasks are executed in order, one at a time, against all machines matched by the host
|
||||
pattern, before moving on to the next task. Failed tasks are taken out of the rotation.
|
||||
Each play contains a list of tasks. Tasks are executed in order, one at a time, against
|
||||
all machines matched by the play's host pattern, before moving on to the next task.
|
||||
Hosts with failed tasks are taken out of the rotation for the entire playbook. If things fail,
|
||||
correct the problem and rerun. Modules other than command are idempotent, meaning if you
|
||||
run them again, they will make the changes they are told to make to bring the system to
|
||||
the desired state.
|
||||
|
||||
Task name and comment
|
||||
`````````
|
||||
Task name and action
|
||||
`````````````````````
|
||||
|
||||
Each task has a name (required) and optional comment. This is for informational purposes only
|
||||
|
||||
Task action
|
||||
```````````
|
||||
Every task must have a name, which is included in the output from running the playbook.
|
||||
|
||||
The action line is the name of an ansible module followed by parameters. Usually these
|
||||
are expressed in key=value form, except for the command module, which looks just like a Linux/Unix
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue