mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Fix up rst formatting
This commit is contained in:
parent
07d0d2720c
commit
4b75308439
6 changed files with 10 additions and 10 deletions
|
@ -26,7 +26,7 @@ The most obvious is downloading roles from the Ansible Galaxy website::
|
||||||
|
|
||||||
ansible-galaxy install username.rolename
|
ansible-galaxy install username.rolename
|
||||||
|
|
||||||
.. _roles_path:
|
.. _galaxy_cli_roles_path:
|
||||||
|
|
||||||
roles_path
|
roles_path
|
||||||
===============
|
===============
|
||||||
|
|
|
@ -134,11 +134,11 @@ Host Inventory
|
||||||
``````````````
|
``````````````
|
||||||
|
|
||||||
Once your nodes are spun up, you'll probably want to talk to them again. With a cloud setup, it's best to not maintain a static list of cloud hostnames
|
Once your nodes are spun up, you'll probably want to talk to them again. With a cloud setup, it's best to not maintain a static list of cloud hostnames
|
||||||
in text files. Rather, the best way to handle this is to use the ec2 dynamic inventory script. See :ref:`intro_dynamic_inventory`.
|
in text files. Rather, the best way to handle this is to use the ec2 dynamic inventory script. See :doc:`intro_dynamic_inventory`.
|
||||||
|
|
||||||
This will also dynamically select nodes that were even created outside of Ansible, and allow Ansible to manage them.
|
This will also dynamically select nodes that were even created outside of Ansible, and allow Ansible to manage them.
|
||||||
|
|
||||||
See :ref:`intro_dynamic_inventory` for how to use this, then flip back over to this chapter.
|
See :doc:`intro_dynamic_inventory` for how to use this, then flip back over to this chapter.
|
||||||
|
|
||||||
.. _aws_tags_and_groups:
|
.. _aws_tags_and_groups:
|
||||||
|
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
CloudStack Cloud Guide
|
CloudStack Cloud Guide
|
||||||
======================
|
======================
|
||||||
|
|
||||||
.. _introduction:
|
.. _cloudstack_introduction:
|
||||||
|
|
||||||
Introduction
|
Introduction
|
||||||
````````````
|
````````````
|
||||||
|
@ -88,7 +88,7 @@ Use Cases
|
||||||
The following should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start.
|
The following should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start.
|
||||||
|
|
||||||
Use Case: Provisioning in a Advanced Networking CloudStack setup
|
Use Case: Provisioning in a Advanced Networking CloudStack setup
|
||||||
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||||
Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host.
|
Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host.
|
||||||
|
|
||||||
This is how our inventory looks like:
|
This is how our inventory looks like:
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
Rackspace Cloud Guide
|
Rackspace Cloud Guide
|
||||||
=====================
|
=====================
|
||||||
|
|
||||||
.. _introduction:
|
.. _rax_introduction:
|
||||||
|
|
||||||
Introduction
|
Introduction
|
||||||
````````````
|
````````````
|
||||||
|
|
|
@ -552,7 +552,7 @@ The default location is ~/ and can be changed to any writeable path::
|
||||||
|
|
||||||
The directory will be created if it does not already exist.
|
The directory will be created if it does not already exist.
|
||||||
|
|
||||||
.. _roles_path:
|
.. _cfg_roles_path:
|
||||||
|
|
||||||
roles_path
|
roles_path
|
||||||
==========
|
==========
|
||||||
|
|
|
@ -516,14 +516,14 @@ Subsequent loops over the registered variable to inspect the results may look li
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. _loops_and_includes
|
.. _loops_and_includes:
|
||||||
|
|
||||||
Loops and Includes
|
Loops and Includes
|
||||||
|
|
||||||
``````````````````
|
``````````````````
|
||||||
|
|
||||||
In 2.0 you are able to use with_ loops and task includes (but not playbook includes), this adds the ability to loop over the set of tasks in one shot.
|
In 2.0 you are able to use `with_` loops and task includes (but not playbook includes), this adds the ability to loop over the set of tasks in one shot.
|
||||||
There are a couple of things that you need to keep in mind, a included task that has it's own with_ loop will overwrite the value of the special `item` variable.
|
There are a couple of things that you need to keep in mind, a included task that has it's own `with_` loop will overwrite the value of the special `item` variable.
|
||||||
So if you want access to both the include's `item` and the current task's `item` you should use `set_fact` to create a alias to the outer one.::
|
So if you want access to both the include's `item` and the current task's `item` you should use `set_fact` to create a alias to the outer one.::
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue