updated documentation fixing #47202 (#47267)

pull/47872/head
Moritz Grimm 6 years ago committed by Alicia Cozine
parent 73141d5035
commit 1a91b797bd

@ -62,7 +62,7 @@ following::
- name: 'YUM - async task' - name: 'YUM - async task'
yum: yum:
name: docker-io name: docker-io
state: installed state: present
async: 1000 async: 1000
poll: 0 poll: 0
register: yum_sleeper register: yum_sleeper

@ -14,12 +14,12 @@ You can find some example playbooks illustrating these best practices in our `an
Content Organization Content Organization
++++++++++++++++++++++ ++++++++++++++++++++++
The following section shows one of many possible ways to organize playbook content. The following section shows one of many possible ways to organize playbook content.
Your usage of Ansible should fit your needs, however, not ours, so feel free to modify this approach and organize as you see fit. Your usage of Ansible should fit your needs, however, not ours, so feel free to modify this approach and organize as you see fit.
One crucial way to organize your playbook content is Ansible's "roles" organization feature, which is documented as part One crucial way to organize your playbook content is Ansible's "roles" organization feature, which is documented as part
of the main playbooks page. You should take the time to read and understand the roles documentation which is available here: :doc:`playbooks_reuse_roles`. of the main playbooks page. You should take the time to read and understand the roles documentation which is available here: :doc:`playbooks_reuse_roles`.
.. _directory_layout: .. _directory_layout:
@ -50,7 +50,7 @@ The top level of the directory would contain files and directories like so::
common/ # this hierarchy represents a "role" common/ # this hierarchy represents a "role"
tasks/ # tasks/ #
main.yml # <-- tasks file can include smaller files if warranted main.yml # <-- tasks file can include smaller files if warranted
handlers/ # handlers/ #
main.yml # <-- handlers file main.yml # <-- handlers file
templates/ # <-- files for use with the template resource templates/ # <-- files for use with the template resource
ntp.conf.j2 # <------- templates end in .j2 ntp.conf.j2 # <------- templates end in .j2
@ -69,7 +69,7 @@ The top level of the directory would contain files and directories like so::
webtier/ # same kind of structure as "common" was above, done for the webtier role webtier/ # same kind of structure as "common" was above, done for the webtier role
monitoring/ # "" monitoring/ # ""
fooapp/ # "" fooapp/ # ""
.. note: If you find yourself having too many top level playbooks (for instance you have a playbook you wrote for a specific hotfix, etc), it may make sense to have a playbooks/ directory instead. This can be a good idea as you get larger. If you do this, configure your roles_path in ansible.cfg to find your roles location. .. note: If you find yourself having too many top level playbooks (for instance you have a playbook you wrote for a specific hotfix, etc), it may make sense to have a playbooks/ directory instead. This can be a good idea as you get larger. If you do this, configure your roles_path in ansible.cfg to find your roles location.
@ -120,7 +120,7 @@ This layout gives you more flexibility for larger environments, as well as a tot
Use Dynamic Inventory With Clouds Use Dynamic Inventory With Clouds
````````````````````````````````` `````````````````````````````````
If you are using a cloud provider, you should not be managing your inventory in a static file. See :doc:`intro_dynamic_inventory`. If you are using a cloud provider, you should not be managing your inventory in a static file. See :doc:`intro_dynamic_inventory`.
This does not just apply to clouds -- If you have another system maintaining a canonical list of systems This does not just apply to clouds -- If you have another system maintaining a canonical list of systems
in your infrastructure, usage of dynamic inventory is a great idea in general. in your infrastructure, usage of dynamic inventory is a great idea in general.
@ -134,7 +134,7 @@ If managing static inventory, it is frequently asked how to differentiate differ
shows a good way to do this. Similar methods of grouping could be adapted to dynamic inventory (for instance, consider applying the AWS shows a good way to do this. Similar methods of grouping could be adapted to dynamic inventory (for instance, consider applying the AWS
tag "environment:production", and you'll get a group of systems automatically discovered named "ec2_tag_environment_production". tag "environment:production", and you'll get a group of systems automatically discovered named "ec2_tag_environment_production".
Let's show a static inventory example though. Below, the *production* file contains the inventory of all of your production hosts. Let's show a static inventory example though. Below, the *production* file contains the inventory of all of your production hosts.
It is suggested that you define groups based on purpose of the host (roles) and also geography or datacenter location (if applicable):: It is suggested that you define groups based on purpose of the host (roles) and also geography or datacenter location (if applicable)::
@ -201,7 +201,7 @@ If we had any default values, or values that were universally true, we would put
--- ---
# file: group_vars/all # file: group_vars/all
ntp: ntp-boston.example.com ntp: ntp-boston.example.com
backup: backup-boston.example.com backup: backup-boston.example.com
We can define specific hardware variance in systems in a host_vars file, but avoid doing this unless you need to:: We can define specific hardware variance in systems in a host_vars file, but avoid doing this unless you need to::
@ -210,8 +210,8 @@ We can define specific hardware variance in systems in a host_vars file, but avo
foo_agent_port: 86 foo_agent_port: 86
bar_agent_port: 99 bar_agent_port: 99
Again, if we are using dynamic inventory sources, many dynamic groups are automatically created. So a tag like "class:webserver" would load in Again, if we are using dynamic inventory sources, many dynamic groups are automatically created. So a tag like "class:webserver" would load in
variables from the file "group_vars/ec2_tag_class_webserver" automatically. variables from the file "group_vars/ec2_tag_class_webserver" automatically.
.. _split_by_role: .. _split_by_role:
@ -254,7 +254,7 @@ Below is an example tasks file that explains how a role works. Our common role
- name: be sure ntp is installed - name: be sure ntp is installed
yum: yum:
name: ntp name: ntp
state: installed state: present
tags: ntp tags: ntp
- name: be sure ntp is configured - name: be sure ntp is configured
@ -309,7 +309,7 @@ For just my webservers in Boston::
ansible-playbook -i production webservers.yml --limit boston ansible-playbook -i production webservers.yml --limit boston
For just the first 10, and then the next 10:: For just the first 10, and then the next 10::
ansible-playbook -i production webservers.yml --limit boston[0:9] ansible-playbook -i production webservers.yml --limit boston[0:9]
ansible-playbook -i production webservers.yml --limit boston[10:19] ansible-playbook -i production webservers.yml --limit boston[10:19]
@ -432,7 +432,7 @@ Alternatively, if only variables are needed::
- debug: - debug:
var: asdf var: asdf
This will pull in variables based on the OS name. This will pull in variables based on the OS name.
.. _ship_modules_with_playbooks: .. _ship_modules_with_playbooks:
@ -455,7 +455,7 @@ Generous use of whitespace to break things up, and use of comments (which start
Always Name Tasks Always Name Tasks
+++++++++++++++++ +++++++++++++++++
It is possible to leave off the 'name' for a given task, though it is recommended to provide a description It is possible to leave off the 'name' for a given task, though it is recommended to provide a description
about why something is being done instead. This name is shown when the playbook is run. about why something is being done instead. This name is shown when the playbook is run.
.. _keep_it_simple: .. _keep_it_simple:

@ -14,7 +14,7 @@ Blocks allow for logical grouping of tasks and in play error handling. Most of w
- name: install httpd and memcached - name: install httpd and memcached
yum: yum:
name: "{{ item }}" name: "{{ item }}"
state: installed state: present
loop: loop:
- httpd - httpd
- memcached - memcached

@ -17,7 +17,7 @@ that tags two tasks with different tags::
tasks: tasks:
- yum: - yum:
name: "{{ item }}" name: "{{ item }}"
state: installed state: present
loop: loop:
- httpd - httpd
- memcached - memcached
@ -55,7 +55,7 @@ This example tags several tasks with one tag, "ntp"::
- name: be sure ntp is installed - name: be sure ntp is installed
yum: yum:
name: ntp name: ntp
state: installed state: present
tags: ntp tags: ntp
- name: be sure ntp is configured - name: be sure ntp is configured
@ -133,7 +133,7 @@ There is no way to 'import only these tags'; you probably want to split into sma
The above information does not apply to `include_tasks` or other dynamic includes, The above information does not apply to `include_tasks` or other dynamic includes,
as the attributes applied to an include, only affect the include itself. as the attributes applied to an include, only affect the include itself.
You can see which tags are applied to tasks, roles, and static imports You can see which tags are applied to tasks, roles, and static imports
by running ``ansible-playbook`` with the ``--list-tasks`` option. You can by running ``ansible-playbook`` with the ``--list-tasks`` option. You can
display all tags applied to the tasks with the ``--list-tags`` option. display all tags applied to the tasks with the ``--list-tags`` option.
@ -156,7 +156,7 @@ Playbook file::
tasks: tasks:
- include_role: - include_role:
name: myrole name: myrole
tags: mytag tags: mytag
Role tasks file:: Role tasks file::

Loading…
Cancel
Save