From a1444f390d04520a14139eb10e49fb80aedc1ed4 Mon Sep 17 00:00:00 2001 From: Don Naro Date: Tue, 28 Jun 2022 15:07:29 +0100 Subject: [PATCH] Docs: Issue 78082 separate tips and tricks in user guide (3/3) (#78103) --- docs/docsite/rst/ansible_index.rst | 1 + docs/docsite/rst/core_index.rst | 1 + .../rst/tips_tricks/ansible_tips_tricks.rst | 182 ++++++++++++++++++ docs/docsite/rst/tips_tricks/index.rst | 22 +++ .../rst/tips_tricks/yaml/tip_group_by.yaml | 6 + .../rst/tips_tricks/yaml/tip_group_hosts.yaml | 6 + .../tips_tricks/yaml/tip_include_vars.yaml | 6 + docs/docsite/rst/user_guide/index.rst | 2 - .../user_guide/playbooks_best_practices.rst | 178 +---------------- .../rst/user_guide/playbooks_conditionals.rst | 2 +- .../user_guide/playbooks_error_handling.rst | 2 +- .../rst/user_guide/playbooks_filters.rst | 2 +- .../rst/user_guide/playbooks_intro.rst | 2 +- .../rst/user_guide/playbooks_loops.rst | 2 +- .../rst/user_guide/playbooks_reuse.rst | 2 +- .../user_guide/playbooks_reuse_includes.rst | 2 +- .../rst/user_guide/playbooks_reuse_roles.rst | 2 +- .../rst/user_guide/playbooks_templating.rst | 2 +- .../rst/user_guide/playbooks_tests.rst | 2 +- .../rst/user_guide/playbooks_variables.rst | 2 +- 20 files changed, 237 insertions(+), 189 deletions(-) create mode 100644 docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst create mode 100644 docs/docsite/rst/tips_tricks/index.rst create mode 100644 docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml create mode 100644 docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml create mode 100644 docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml diff --git a/docs/docsite/rst/ansible_index.rst b/docs/docsite/rst/ansible_index.rst index 1f8bf782d11..e569f207497 100644 --- a/docs/docsite/rst/ansible_index.rst +++ b/docs/docsite/rst/ansible_index.rst @@ -43,6 +43,7 @@ Ansible releases a new major release approximately twice a year. The core applic user_guide/index win_guide/index + tips_tricks/index .. toctree:: :maxdepth: 2 diff --git a/docs/docsite/rst/core_index.rst b/docs/docsite/rst/core_index.rst index df684acda99..df2d9011fc4 100644 --- a/docs/docsite/rst/core_index.rst +++ b/docs/docsite/rst/core_index.rst @@ -50,6 +50,7 @@ This documentation covers the version of ``ansible-core`` noted in the upper lef user_guide/index win_guide/index + tips_tricks/index .. toctree:: :maxdepth: 2 diff --git a/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst b/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst new file mode 100644 index 00000000000..32c433c9741 --- /dev/null +++ b/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst @@ -0,0 +1,182 @@ +.. _tips_and_tricks: + +General tips +============ + +These concepts apply to all Ansible activities and artifacts. + +Keep it simple +-------------- + +Whenever you can, do things simply. Use advanced features only when necessary, and select the feature that best matches your use case. +For example, you will probably not need ``vars``, ``vars_files``, ``vars_prompt`` and ``--extra-vars`` all at once, while also using an external inventory file. +If something feels complicated, it probably is. Take the time to look for a simpler solution. + +Use version control +------------------- + +Keep your playbooks, roles, inventory, and variables files in git or another version control system and make commits to the repository when you make changes. +Version control gives you an audit trail describing when and why you changed the rules that automate your infrastructure. + +Customize the CLI output +------------------------- + +You can change the output from Ansible CLI commands using :ref:`callback_plugins`. + + +Playbook tips +============= + +These tips help make playbooks and roles easier to read, maintain, and debug. + +Use whitespace +-------------- + +Generous use of whitespace, for example, a blank line before each block or task, makes a playbook easy to scan. + +Always name tasks +----------------- + +Task names are optional, but extremely useful. In its output, Ansible shows you the name of each task it runs. +Choose names that describe what each task does and why. + +Always mention the state +------------------------ + +For many modules, the 'state' parameter is optional. +Different modules have different default settings for 'state', and some modules support several 'state' settings. +Explicitly setting 'state=present' or 'state=absent' makes playbooks and roles clearer. + +Use comments +------------ + +Even with task names and explicit state, sometimes a part of a playbook or role (or inventory/variable file) needs more explanation. +Adding a comment (any line starting with '#') helps others (and possibly yourself in future) understand what a play or task (or variable setting) does, how it does it, and why. + +Inventory tips +============== + +These tips help keep your inventory well organized. + +Use dynamic inventory with clouds +--------------------------------- + +With cloud providers and other systems that maintain canonical lists of your infrastructure, use :ref:`dynamic inventory ` to retrieve those lists instead of manually updating static inventory files. +With cloud resources, you can use tags to differentiate production and staging environments. + +Group inventory by function +--------------------------- + +A system can be in multiple groups. See :ref:`intro_inventory` and :ref:`intro_patterns`. +If you create groups named for the function of the nodes in the group, for example *webservers* or *dbservers*, your playbooks can target machines based on function. +You can assign function-specific variables using the group variable system, and design Ansible roles to handle function-specific use cases. +See :ref:`playbooks_reuse_roles`. + +Separate production and staging inventory +----------------------------------------- + +You can keep your production environment separate from development, test, and staging environments by using separate inventory files or directories for each environment. +This way you pick with -i what you are targeting. +Keeping all your environments in one file can lead to surprises! +For example, all vault passwords used in an inventory need to be available when using that inventory. +If an inventory contains both production and development environments, developers using that inventory would be able to access production secrets. + +.. _tip_for_variables_and_vaults: + +Keep vaulted variables safely visible +------------------------------------- + +You should encrypt sensitive or secret variables with Ansible Vault. +However, encrypting the variable names as well as the variable values makes it hard to find the source of the values. +To circumvent this, you can encrypt the variables individually using ``ansible-vault encrypt_string``, or add the following layer of indirection to keep the names of your variables accessible (by ``grep``, for example) without exposing any secrets: + +#. Create a ``group_vars/`` subdirectory named after the group. +#. Inside this subdirectory, create two files named ``vars`` and ``vault``. +#. In the ``vars`` file, define all of the variables needed, including any sensitive ones. +#. Copy all of the sensitive variables over to the ``vault`` file and prefix these variables with ``vault_``. +#. Adjust the variables in the ``vars`` file to point to the matching ``vault_`` variables using jinja2 syntax: ``db_password: {{ vault_db_password }}``. +#. Encrypt the ``vault`` file to protect its contents. +#. Use the variable name from the ``vars`` file in your playbooks. + +When running a playbook, Ansible finds the variables in the unencrypted file, which pulls the sensitive variable values from the encrypted file. +There is no limit to the number of variable and vault files or their names. + +Note that using this strategy in your inventory still requires *all vault passwords to be available* (for example for ``ansible-playbook`` or `AWX/Ansible Tower `_) when run with that inventory. + +Execution tricks +================ + +These tips apply to using Ansible, rather than to Ansible artifacts. + +Try it in staging first +----------------------- + +Testing changes in a staging environment before rolling them out in production is always a great idea. +Your environments need not be the same size and you can use group variables to control the differences between those environments. + +Update in batches +----------------- + +Use the 'serial' keyword to control how many machines you update at once in the batch. +See :ref:`playbooks_delegation`. + +.. _os_variance: + +Handling OS and distro differences +---------------------------------- + +Group variables files and the ``group_by`` module work together to help Ansible execute across a range of operating systems and distributions that require different settings, packages, and tools. +The ``group_by`` module creates a dynamic group of hosts that match certain criteria. +This group does not need to be defined in the inventory file. +This approach lets you execute different tasks on different operating systems or distributions. + +For example, the following play categorizes all systems into dynamic groups based on the operating system name: + +.. literalinclude:: yaml/tip_group_by.yaml + :language: yaml + +Subsequent plays can use these groups as patterns on the ``hosts`` line as follows: + +.. literalinclude:: yaml/tip_group_hosts.yaml + :language: yaml + +You can also add group-specific settings in group vars files. +In the following example, CentOS machines get the value of '42' for `asdf` but other machines get '10'. +You can also use group vars files to apply roles to systems as well as set variables. + +.. code-block:: yaml + + --- + # file: group_vars/all + asdf: 10 + + --- + # file: group_vars/os_CentOS.yml + asdf: 42 + +.. note:: + All three names must match: the name created by the ``group_by`` task, the name of the pattern in subsequent plays, and the name of the group vars file. + +You can use the same setup with ``include_vars`` when you only need OS-specific variables, not tasks: + +.. literalinclude:: yaml/tip_include_vars.yaml + :language: yaml + +This pulls in variables from the `group_vars/os_CentOS.yml` file. + +.. seealso:: + + :ref:`yaml_syntax` + Learn about YAML syntax + :ref:`working_with_playbooks` + Review the basic playbook features + :ref:`list_of_collections` + Browse existing collections, modules, and plugins + :ref:`developing_modules` + Learn how to extend Ansible by writing your own modules + :ref:`intro_patterns` + Learn about how to select hosts + `GitHub examples directory `_ + Complete playbook files from the github project source + `Mailing List `_ + Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/tips_tricks/index.rst b/docs/docsite/rst/tips_tricks/index.rst new file mode 100644 index 00000000000..dd44f90f357 --- /dev/null +++ b/docs/docsite/rst/tips_tricks/index.rst @@ -0,0 +1,22 @@ +.. _tips_tricks_index: +.. _playbooks_best_practices: + +####################### +Ansible tips and tricks +####################### + +.. note:: + + **Making Open Source More Inclusive** + + Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. + +Welcome to the Ansible tips and tricks guide. +These tips and tricks have helped us optimize our Ansible usage and we offer them here as suggestions. +We hope they will help you organize content, write playbooks, maintain inventory, and execute Ansible. +Ultimately, though, you should use Ansible in the way that makes most sense for your organization and your goals. + +.. toctree:: + :maxdepth: 2 + + ansible_tips_tricks \ No newline at end of file diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml new file mode 100644 index 00000000000..4c39a63f266 --- /dev/null +++ b/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml @@ -0,0 +1,6 @@ +- name: talk to all hosts just so we can learn about them + hosts: all + tasks: + - name: Classify hosts depending on their OS distribution + group_by: + key: os_{{ ansible_facts['distribution'] }} \ No newline at end of file diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml new file mode 100644 index 00000000000..b4e2fc009fd --- /dev/null +++ b/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml @@ -0,0 +1,6 @@ +- hosts: os_CentOS + gather_facts: False + tasks: + # Tasks for CentOS hosts only go in this play. + - name: Ping my CentOS hosts + ansible.builtin.ping: \ No newline at end of file diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml new file mode 100644 index 00000000000..aae27c34385 --- /dev/null +++ b/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml @@ -0,0 +1,6 @@ +- hosts: all + tasks: + - name: Set OS distribution dependent variables + include_vars: "os_{{ ansible_facts['distribution'] }}.yml" + - debug: + var: asdf \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/index.rst b/docs/docsite/rst/user_guide/index.rst index 9e473ab2ffa..839dbbb1df9 100644 --- a/docs/docsite/rst/user_guide/index.rst +++ b/docs/docsite/rst/user_guide/index.rst @@ -16,7 +16,6 @@ Quickly find answers in the following sections or expand the table of contents b Writing tasks, plays, and playbooks =================================== -* I'm writing my first playbook. What should I :ref:`know before I begin `? * I have a specific use case for a task or play: * Executing tasks with elevated privileges or as a different user with :ref:`become ` @@ -84,7 +83,6 @@ Here is the complete list of resources in the Ansible User Guide: cheatsheet playbooks_intro playbooks - playbooks_best_practices become playbooks_loops playbooks_delegation diff --git a/docs/docsite/rst/user_guide/playbooks_best_practices.rst b/docs/docsite/rst/user_guide/playbooks_best_practices.rst index ce8b1c9b0f9..6395e391306 100644 --- a/docs/docsite/rst/user_guide/playbooks_best_practices.rst +++ b/docs/docsite/rst/user_guide/playbooks_best_practices.rst @@ -1,181 +1,7 @@ -.. _playbooks_tips_and_tricks: -.. _playbooks_best_practices: +:orphan: *************** Tips and tricks *************** -These tips and tricks have helped us optimize our Ansible usage, and we offer them here as suggestions. We hope they will help you organize content, write playbooks, maintain inventory, and execute Ansible. Ultimately, though, you should use Ansible in the way that makes most sense for your organization and your goals. - -.. contents:: - :local: - -General tips -============ - -These concepts apply to all Ansible activities and artifacts. - -Keep it simple --------------- - -Whenever you can, do things simply. Use advanced features only when necessary, and select the feature that best matches your use case. For example, you will probably not need ``vars``, ``vars_files``, ``vars_prompt`` and ``--extra-vars`` all at once, while also using an external inventory file. If something feels complicated, it probably is. Take the time to look for a simpler solution. - -Use version control -------------------- - -Keep your playbooks, roles, inventory, and variables files in git or another version control system and make commits to the repository when you make changes. Version control gives you an audit trail describing when and why you changed the rules that automate your infrastructure. - -Customize the CLI output -------------------------- - -You can change the output from Ansible CLI commands using :ref:`callback_plugins`. - - -Playbook tips -============= - -These tips help make playbooks and roles easier to read, maintain, and debug. - -Use whitespace --------------- - -Generous use of whitespace, for example, a blank line before each block or task, makes a playbook easy to scan. - -Always name tasks ------------------ - -Task names are optional, but extremely useful. In its output, Ansible shows you the name of each task it runs. Choose names that describe what each task does and why. - -Always mention the state ------------------------- - -For many modules, the 'state' parameter is optional. Different modules have different default settings for 'state', and some modules support several 'state' settings. Explicitly setting 'state=present' or 'state=absent' makes playbooks and roles clearer. - -Use comments ------------- - -Even with task names and explicit state, sometimes a part of a playbook or role (or inventory/variable file) needs more explanation. Adding a comment (any line starting with '#') helps others (and possibly yourself in future) understand what a play or task (or variable setting) does, how it does it, and why. - -Inventory tips -============== - -These tips help keep your inventory well organized. - -Use dynamic inventory with clouds ---------------------------------- - -With cloud providers and other systems that maintain canonical lists of your infrastructure, use :ref:`dynamic inventory ` to retrieve those lists instead of manually updating static inventory files. With cloud resources, you can use tags to differentiate production and staging environments. - -Group inventory by function ---------------------------- - -A system can be in multiple groups. See :ref:`intro_inventory` and :ref:`intro_patterns`. If you create groups named for the function of the nodes in the group, for example *webservers* or *dbservers*, your playbooks can target machines based on function. You can assign function-specific variables using the group variable system, and design Ansible roles to handle function-specific use cases. See :ref:`playbooks_reuse_roles`. - -Separate production and staging inventory ------------------------------------------ - -You can keep your production environment separate from development, test, and staging environments by using separate inventory files or directories for each environment. This way you pick with -i what you are targeting. Keeping all your environments in one file can lead to surprises! For example, all vault passwords used in an inventory need to be available when using that inventory. If an inventory contains both production and development environments, developers using that inventory would be able to access production secrets. - -.. _tip_for_variables_and_vaults: - -Keep vaulted variables safely visible -------------------------------------- - -You should encrypt sensitive or secret variables with Ansible Vault. However, encrypting the variable names as well as the variable values makes it hard to find the source of the values. To circumvent this, you can encrypt the variables individually using ``ansible-vault encrypt_string``, or add the following layer of indirection to keep the names of your variables accessible (by ``grep``, for example) without exposing any secrets: - -#. Create a ``group_vars/`` subdirectory named after the group. -#. Inside this subdirectory, create two files named ``vars`` and ``vault``. -#. In the ``vars`` file, define all of the variables needed, including any sensitive ones. -#. Copy all of the sensitive variables over to the ``vault`` file and prefix these variables with ``vault_``. -#. Adjust the variables in the ``vars`` file to point to the matching ``vault_`` variables using jinja2 syntax: ``db_password: {{ vault_db_password }}``. -#. Encrypt the ``vault`` file to protect its contents. -#. Use the variable name from the ``vars`` file in your playbooks. - -When running a playbook, Ansible finds the variables in the unencrypted file, which pulls the sensitive variable values from the encrypted file. There is no limit to the number of variable and vault files or their names. - -Note that using this strategy in your inventory still requires *all vault passwords to be available* (for example for ``ansible-playbook`` or `AWX/Ansible Tower `_) when run with that inventory. - -Execution tricks -================ - -These tips apply to using Ansible, rather than to Ansible artifacts. - -Try it in staging first ------------------------ - -Testing changes in a staging environment before rolling them out in production is always a great idea. Your environments need not be the same size and you can use group variables to control the differences between those environments. - -Update in batches ------------------ - -Use the 'serial' keyword to control how many machines you update at once in the batch. See :ref:`playbooks_delegation`. - -.. _os_variance: - -Handling OS and distro differences ----------------------------------- - -Group variables files and the ``group_by`` module work together to help Ansible execute across a range of operating systems and distributions that require different settings, packages, and tools. The ``group_by`` module creates a dynamic group of hosts matching certain criteria. This group does not need to be defined in the inventory file. This approach lets you execute different tasks on different operating systems or distributions. For example: - -.. code-block:: yaml - - --- - - - name: talk to all hosts just so we can learn about them - hosts: all - tasks: - - name: Classify hosts depending on their OS distribution - group_by: - key: os_{{ ansible_facts['distribution'] }} - - # now just on the CentOS hosts... - - - hosts: os_CentOS - gather_facts: False - tasks: - - # tasks that only happen on CentOS go in this play - -The first play categorizes all systems into dynamic groups based on the operating system name. Later plays can use these groups as patterns on the ``hosts`` line. You can also add group-specific settings in group vars files. All three names must match: the name created by the ``group_by`` task, the name of the pattern in subsequent plays, and the name of the group vars file. For example: - -.. code-block:: yaml - - --- - # file: group_vars/all - asdf: 10 - - --- - # file: group_vars/os_CentOS.yml - asdf: 42 - -In this example, CentOS machines get the value of '42' for asdf, but other machines get '10'. -This can be used not only to set variables, but also to apply certain roles to only certain systems. - -You can use the same setup with ``include_vars`` when you only need OS-specific variables, not tasks: - -.. code-block:: yaml - - - hosts: all - tasks: - - name: Set OS distribution dependent variables - include_vars: "os_{{ ansible_facts['distribution'] }}.yml" - - debug: - var: asdf - -This pulls in variables from the group_vars/os_CentOS.yml file. - -.. seealso:: - - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`working_with_playbooks` - Review the basic playbook features - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Learn how to extend Ansible by writing your own modules - :ref:`intro_patterns` - Learn about how to select hosts - `GitHub examples directory `_ - Complete playbook files from the github project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups +This page has moved to :ref:`tips_and_tricks`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_conditionals.rst b/docs/docsite/rst/user_guide/playbooks_conditionals.rst index a0bd1506d67..6216aa59a37 100644 --- a/docs/docsite/rst/user_guide/playbooks_conditionals.rst +++ b/docs/docsite/rst/user_guide/playbooks_conditionals.rst @@ -526,7 +526,7 @@ Possible values (sample, not complete list): An introduction to playbooks :ref:`playbooks_reuse_roles` Playbook organization by roles - :ref:`playbooks_best_practices` + :ref:`tips_and_tricks` Tips and tricks for playbooks :ref:`playbooks_variables` All about variables diff --git a/docs/docsite/rst/user_guide/playbooks_error_handling.rst b/docs/docsite/rst/user_guide/playbooks_error_handling.rst index 5a5c3a4d443..389ef0b28de 100644 --- a/docs/docsite/rst/user_guide/playbooks_error_handling.rst +++ b/docs/docsite/rst/user_guide/playbooks_error_handling.rst @@ -267,7 +267,7 @@ You can also use blocks to define responses to task errors. This approach is sim :ref:`playbooks_intro` An introduction to playbooks - :ref:`playbooks_best_practices` + :ref:`tips_and_tricks` Tips and tricks for playbooks :ref:`playbooks_conditionals` Conditional statements in playbooks diff --git a/docs/docsite/rst/user_guide/playbooks_filters.rst b/docs/docsite/rst/user_guide/playbooks_filters.rst index 7e2f0de6efa..7a4c7f47a6c 100644 --- a/docs/docsite/rst/user_guide/playbooks_filters.rst +++ b/docs/docsite/rst/user_guide/playbooks_filters.rst @@ -2191,7 +2191,7 @@ This can then be used to reference hashes in Pod specifications: Looping in playbooks :ref:`playbooks_reuse_roles` Playbook organization by roles - :ref:`playbooks_best_practices` + :ref:`tips_and_tricks` Tips and tricks for playbooks `User Mailing List `_ Have a question? Stop by the google group! diff --git a/docs/docsite/rst/user_guide/playbooks_intro.rst b/docs/docsite/rst/user_guide/playbooks_intro.rst index d299d63dbc0..d62433b0aa9 100644 --- a/docs/docsite/rst/user_guide/playbooks_intro.rst +++ b/docs/docsite/rst/user_guide/playbooks_intro.rst @@ -145,7 +145,7 @@ The `ansible-lint default rules `_ page Learn about YAML syntax :ref:`working_with_playbooks` Review the basic Playbook language features - :ref:`playbooks_best_practices` + :ref:`tips_and_tricks` Tips and tricks for playbooks :ref:`playbooks_variables` Variables in playbooks diff --git a/docs/docsite/rst/user_guide/playbooks_templating.rst b/docs/docsite/rst/user_guide/playbooks_templating.rst index d44f9bf327c..d4805522329 100644 --- a/docs/docsite/rst/user_guide/playbooks_templating.rst +++ b/docs/docsite/rst/user_guide/playbooks_templating.rst @@ -51,7 +51,7 @@ fmt Looping in playbooks :ref:`playbooks_reuse_roles` Playbook organization by roles - :ref:`playbooks_best_practices` + :ref:`tips_and_tricks` Tips and tricks for playbooks `Jinja2 Docs `_ Jinja2 documentation, includes the syntax and semantics of the templates diff --git a/docs/docsite/rst/user_guide/playbooks_tests.rst b/docs/docsite/rst/user_guide/playbooks_tests.rst index ed88ba7410e..75e041bc11a 100644 --- a/docs/docsite/rst/user_guide/playbooks_tests.rst +++ b/docs/docsite/rst/user_guide/playbooks_tests.rst @@ -516,7 +516,7 @@ When looking to determine types, it may be tempting to use the ``type_debug`` fi Looping in playbooks :ref:`playbooks_reuse_roles` Playbook organization by roles - :ref:`playbooks_best_practices` + :ref:`tips_and_tricks` Tips and tricks for playbooks `User Mailing List `_ Have a question? Stop by the google group! diff --git a/docs/docsite/rst/user_guide/playbooks_variables.rst b/docs/docsite/rst/user_guide/playbooks_variables.rst index f1b46612e6f..5682a45864b 100644 --- a/docs/docsite/rst/user_guide/playbooks_variables.rst +++ b/docs/docsite/rst/user_guide/playbooks_variables.rst @@ -502,7 +502,7 @@ For information about advanced YAML syntax used to declare variables and have mo Looping in playbooks :ref:`playbooks_reuse_roles` Playbook organization by roles - :ref:`playbooks_best_practices` + :ref:`tips_and_tricks` Tips and tricks for playbooks :ref:`special_variables` List of special variables