removes last :doc: links in other sections of the docs (#58432)
* removes last :doc: links in other sections of the docs * fix references to playbooks intro page
This commit is contained in:
parent
9b96da9aa1
commit
44b6f2ff56
8 changed files with 37 additions and 37 deletions
|
@ -51,7 +51,7 @@ Automated routing of pull requests is handled by a tool called `Ansibot <https:/
|
|||
|
||||
Being moderately familiar with how the workflow behind the bot operates can be helpful to you, and -- should things go awry -- your feedback can be helpful to the folks that continually help Ansibullbot to evolve.
|
||||
|
||||
A detailed explanation of the PR workflow can be seen in the :doc:`development_process`
|
||||
A detailed explanation of the PR workflow can be seen in the :ref:`community_development_process`.
|
||||
|
||||
Maintainers (BOTMETA.yml)
|
||||
-------------------------
|
||||
|
@ -68,6 +68,6 @@ If you'd like to step down as a maintainer, please submit a PR to the ``BOTMETA.
|
|||
Tools and other Resources
|
||||
=========================
|
||||
|
||||
* `PRs in flight, organised by directory <https://ansible.sivel.net/pr/byfile.html>`_.
|
||||
* Ansibullbot: https://github.com/ansible/ansibullbot
|
||||
* :doc:`development_process`
|
||||
* `PRs in flight, organized by directory <https://ansible.sivel.net/pr/byfile.html>`_
|
||||
* `Ansibullbot <https://github.com/ansible/ansibullbot>`_
|
||||
* :ref:`community_development_process`
|
||||
|
|
|
@ -19,12 +19,12 @@ The network devices (and/or servers) you manage with Ansible. Managed nodes are
|
|||
Inventory
|
||||
================================================================================
|
||||
|
||||
A list of managed nodes. An inventory file is also sometimes called a "hostfile". Your inventory can specify information like IP address for each managed node. An inventory can also organize managed nodes, creating and nesting groups for easier scaling. To learn more about inventory, see :doc:`the Working with Inventory<../../user_guide/intro_inventory>` pages.
|
||||
A list of managed nodes. An inventory file is also sometimes called a "hostfile". Your inventory can specify information like IP address for each managed node. An inventory can also organize managed nodes, creating and nesting groups for easier scaling. To learn more about inventory, see :ref:`the Working with Inventory<intro_inventory>` section.
|
||||
|
||||
Modules
|
||||
================================================================================
|
||||
|
||||
The units of code Ansible executes. Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. You can invoke a single module with a task, or invoke several different modules in a playbook. For an idea of how many modules Ansible includes, take a look at the :doc:`list of all modules<../../modules/modules_by_category>` or the :ref:`list of network modules<network_modules>`.
|
||||
The units of code Ansible executes. Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. You can invoke a single module with a task, or invoke several different modules in a playbook. For an idea of how many modules Ansible includes, take a look at the :ref:`list of all modules <modules_by_category>` or the :ref:`list of network modules<network_modules>`.
|
||||
|
||||
Tasks
|
||||
================================================================================
|
||||
|
@ -34,4 +34,4 @@ The units of action in Ansible. You can execute a single task once with an ad-ho
|
|||
Playbooks
|
||||
================================================================================
|
||||
|
||||
Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :doc:`../../user_guide/playbooks_intro`.
|
||||
Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`.
|
||||
|
|
|
@ -256,6 +256,6 @@ To see the original value, you can use the debug module. Please note if your YAM
|
|||
|
||||
Vault content can only be decrypted with the password that was used to encrypt it. If you want to stop using one password and move to a new one, you can update and re-encrypt existing vault content with ``ansible-vault rekey myfile``, then provide the old password and the new password. Copies of vault content still encrypted with the old password can still be decrypted with old password.
|
||||
|
||||
For more details on building inventory files, see :doc:`the introduction to inventory<../../user_guide/intro_inventory>`; for more details on ansible-vault, see :doc:`the full Ansible Vault documentation<../../user_guide/vault>`.
|
||||
For more details on building inventory files, see :ref:`the introduction to inventory<intro_inventory>`; for more details on ansible-vault, see :ref:`the full Ansible Vault documentation<vault>`.
|
||||
|
||||
Now that you understand the basics of commands, playbooks, and inventory, it's time to explore some more complex Ansible Network examples.
|
||||
|
|
|
@ -22,7 +22,7 @@ Before you work through this tutorial you need:
|
|||
Install Ansible
|
||||
==================================================
|
||||
|
||||
Install Ansible using your preferred method. See :doc:`../../installation_guide/intro_installation`. Then return to this tutorial.
|
||||
Install Ansible using your preferred method. See :ref:`installation_guide`. Then return to this tutorial.
|
||||
|
||||
Confirm the version of Ansible (must be >= 2.5):
|
||||
|
||||
|
|
|
@ -54,17 +54,17 @@ Use ``ansible-doc -t become <plugin name>`` to see specific documentation and ex
|
|||
|
||||
.. seealso::
|
||||
|
||||
:doc:`../user_guide/playbooks`
|
||||
:ref:`about_playbooks`
|
||||
An introduction to playbooks
|
||||
:doc:`inventory`
|
||||
:ref:`inventory_plugins`
|
||||
Ansible inventory plugins
|
||||
:doc:`callback`
|
||||
:ref:`callback_plugins`
|
||||
Ansible callback plugins
|
||||
:doc:`../user_guide/playbooks_filters`
|
||||
:ref:`playbooks_filters`
|
||||
Jinja2 filter plugins
|
||||
:doc:`../user_guide/playbooks_tests`
|
||||
:ref:`playbooks_tests`
|
||||
Jinja2 test plugins
|
||||
:doc:`../user_guide/playbooks_lookups`
|
||||
:ref:`playbooks_lookups`
|
||||
Jinja2 lookup plugins
|
||||
`User Mailing List <https://groups.google.com/group/ansible-devel>`_
|
||||
Have a question? Stop by the google group!
|
||||
|
|
|
@ -274,7 +274,7 @@ other non-iterable types returned by a plugin were accepted without error or war
|
|||
Lookup
|
||||
-------
|
||||
|
||||
A new option was added to lookup plugins globally named ``error`` which allows you to control how errors produced by the lookup are handled, before this option they were always fatal. Valid values for this option are ``warn``, ``ignore`` and ``strict``. See the :doc:`lookup <../plugins/lookup>` page for more details.
|
||||
A new option was added to lookup plugins globally named ``error`` which allows you to control how errors produced by the lookup are handled, before this option they were always fatal. Valid values for this option are ``warn``, ``ignore`` and ``strict``. See the :ref:`lookup <lookup_plugins>` page for more details.
|
||||
|
||||
|
||||
Porting custom scripts
|
||||
|
|
|
@ -280,7 +280,7 @@ Where does the configuration file live and what can I configure in it?
|
|||
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
|
||||
See :doc:`../installation_guide/intro_configuration`.
|
||||
See :ref:`intro_configuration`.
|
||||
|
||||
.. _who_would_ever_want_to_disable_cowsay_but_ok_here_is_how:
|
||||
|
||||
|
@ -397,7 +397,7 @@ How do I access a variable of the first host in a group?
|
|||
|
||||
What happens if we want the ip address of the first webserver in the webservers group? Well, we can do that too. Note that if we
|
||||
are using dynamic inventory, which host is the 'first' may not be consistent, so you wouldn't want to do this unless your inventory
|
||||
is static and predictable. (If you are using :doc:`../reference_appendices/tower`, it will use database order, so this isn't a problem even if you are using cloud
|
||||
is static and predictable. (If you are using :ref:`ansible_tower`, it will use database order, so this isn't a problem even if you are using cloud
|
||||
based inventory scripts).
|
||||
|
||||
Anyway, here's the trick:
|
||||
|
@ -479,7 +479,7 @@ Once the library is ready, SHA512 password values can then be generated as follo
|
|||
python -c "from passlib.hash import sha512_crypt; import getpass; print(sha512_crypt.using(rounds=5000).hash(getpass.getpass()))"
|
||||
|
||||
Use the integrated :ref:`hash_filters` to generate a hashed version of a password.
|
||||
You shouldn't put plaintext passwords in your playbook or host_vars; instead, use :doc:`../user_guide/playbooks_vault` to encrypt sensitive data.
|
||||
You shouldn't put plaintext passwords in your playbook or host_vars; instead, use :ref:`playbooks_vault` to encrypt sensitive data.
|
||||
|
||||
In OpenBSD, a similar option is available in the base system called encrypt(1):
|
||||
|
||||
|
@ -559,7 +559,7 @@ We also offer free web-based training classes on a regular basis. See our `webin
|
|||
Is there a web interface / REST API / etc?
|
||||
++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Yes! Ansible, Inc makes a great product that makes Ansible even more powerful and easy to use. See :doc:`../reference_appendices/tower`.
|
||||
Yes! Ansible, Inc makes a great product that makes Ansible even more powerful and easy to use. See :ref:`ansible_tower`.
|
||||
|
||||
|
||||
.. _docs_contributions:
|
||||
|
@ -575,7 +575,7 @@ Great question! Documentation for Ansible is kept in the main project git repos
|
|||
How do I keep secret data in my playbook?
|
||||
+++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
If you would like to keep secret data in your Ansible content and still share it publicly or keep things in source control, see :doc:`../user_guide/playbooks_vault`.
|
||||
If you would like to keep secret data in your Ansible content and still share it publicly or keep things in source control, see :ref:`playbooks_vault`.
|
||||
|
||||
If you have a task that you don't want to show the results or command given to it when using -v (verbose) mode, the following task or playbook attribute can be useful::
|
||||
|
||||
|
@ -685,9 +685,9 @@ Please see the section below for a link to IRC and the Google Group, where you c
|
|||
|
||||
.. seealso::
|
||||
|
||||
:doc:`../user_guide/playbooks`
|
||||
:ref:`working_with_playbooks`
|
||||
An introduction to playbooks
|
||||
:doc:`../user_guide/playbooks_best_practices`
|
||||
:ref:`playbooks_best_practices`
|
||||
Best practices advice
|
||||
`User Mailing List <https://groups.google.com/group/ansible-project>`_
|
||||
Have a question? Stop by the google group!
|
||||
|
|
|
@ -35,7 +35,7 @@ To pass authentication credentials as environment variables::
|
|||
export ALICLOUD_ACCESS_KEY='Alicloud123'
|
||||
export ALICLOUD_SECRET_KEY='AlicloudSecret123'
|
||||
|
||||
To store authentication credentials in a vars_file, encrypt them with :doc:`Ansible Vault<../user_guide/vault>` to keep them secure, then list them::
|
||||
To store authentication credentials in a vars_file, encrypt them with :ref:`Ansible Vault<vault>` to keep them secure, then list them::
|
||||
|
||||
---
|
||||
alicloud_access_key: "--REMOVED--"
|
||||
|
|
Loading…
Reference in a new issue