diff --git a/docs/docsite/rst/user_guide/playbooks_async.rst b/docs/docsite/rst/user_guide/playbooks_async.rst index a8572c104ef..08193688a0a 100644 --- a/docs/docsite/rst/user_guide/playbooks_async.rst +++ b/docs/docsite/rst/user_guide/playbooks_async.rst @@ -62,7 +62,7 @@ following:: - name: 'YUM - async task' yum: name: docker-io - state: installed + state: present async: 1000 poll: 0 register: yum_sleeper diff --git a/docs/docsite/rst/user_guide/playbooks_best_practices.rst b/docs/docsite/rst/user_guide/playbooks_best_practices.rst index 70a45e30aeb..b6146c7a2ac 100644 --- a/docs/docsite/rst/user_guide/playbooks_best_practices.rst +++ b/docs/docsite/rst/user_guide/playbooks_best_practices.rst @@ -14,12 +14,12 @@ You can find some example playbooks illustrating these best practices in our `an 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. 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: @@ -50,7 +50,7 @@ The top level of the directory would contain files and directories like so:: common/ # this hierarchy represents a "role" tasks/ # main.yml # <-- tasks file can include smaller files if warranted - handlers/ # + handlers/ # main.yml # <-- handlers file templates/ # <-- files for use with the template resource 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 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. @@ -120,7 +120,7 @@ This layout gives you more flexibility for larger environments, as well as a tot 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 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 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):: @@ -201,7 +201,7 @@ If we had any default values, or values that were universally true, we would put --- # file: group_vars/all 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:: @@ -210,8 +210,8 @@ We can define specific hardware variance in systems in a host_vars file, but avo foo_agent_port: 86 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 -variables from the file "group_vars/ec2_tag_class_webserver" automatically. +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. .. _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 yum: name: ntp - state: installed + state: present tags: ntp - name: be sure ntp is configured @@ -309,7 +309,7 @@ For just my webservers in Boston:: ansible-playbook -i production webservers.yml --limit boston 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[10:19] @@ -432,7 +432,7 @@ Alternatively, if only variables are needed:: - debug: 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: @@ -455,7 +455,7 @@ Generous use of whitespace to break things up, and use of comments (which start 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. .. _keep_it_simple: diff --git a/docs/docsite/rst/user_guide/playbooks_blocks.rst b/docs/docsite/rst/user_guide/playbooks_blocks.rst index 36cae6d7fb3..5550e025255 100644 --- a/docs/docsite/rst/user_guide/playbooks_blocks.rst +++ b/docs/docsite/rst/user_guide/playbooks_blocks.rst @@ -14,7 +14,7 @@ Blocks allow for logical grouping of tasks and in play error handling. Most of w - name: install httpd and memcached yum: name: "{{ item }}" - state: installed + state: present loop: - httpd - memcached diff --git a/docs/docsite/rst/user_guide/playbooks_tags.rst b/docs/docsite/rst/user_guide/playbooks_tags.rst index 50a24bfa51d..14d8e44d5a9 100644 --- a/docs/docsite/rst/user_guide/playbooks_tags.rst +++ b/docs/docsite/rst/user_guide/playbooks_tags.rst @@ -17,7 +17,7 @@ that tags two tasks with different tags:: tasks: - yum: name: "{{ item }}" - state: installed + state: present loop: - httpd - memcached @@ -55,7 +55,7 @@ This example tags several tasks with one tag, "ntp":: - name: be sure ntp is installed yum: name: ntp - state: installed + state: present tags: ntp - 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, 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 display all tags applied to the tasks with the ``--list-tags`` option. @@ -156,7 +156,7 @@ Playbook file:: tasks: - include_role: name: myrole - tags: mytag + tags: mytag Role tasks file::