mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Much rejoicing, ansibleworks.com is now ansible.com
Also note AWX is named "Tower" now, as we found that simpler.
This commit is contained in:
parent
8a1abd9da3
commit
81e9a60589
19 changed files with 52 additions and 66 deletions
|
@ -28,6 +28,10 @@ clean:
|
|||
@echo "Cleaning up editor backup files"
|
||||
find . -type f \( -name "*~" -or -name "#*" \) -delete
|
||||
find . -type f \( -name "*.swp" \) -delete
|
||||
@echo "Cleaning up generated rst"
|
||||
-rm rst/list_of_*.rst
|
||||
-rm rst/*_by_category.rst
|
||||
-rm rst/*_module.rst
|
||||
|
||||
.PHONEY: docs clean
|
||||
|
||||
|
|
|
@ -1,11 +0,0 @@
|
|||
AnsibleWorks AWX
|
||||
````````````````
|
||||
|
||||
`AnsibleWorks <http://ansibleworks.com>`_, who also sponsors the Ansible community, also produces 'AWX', which is a web-based solution that makes Ansible even more easy to use for IT teams of all kinds. It's designed to be the hub for all of your automation tasks.
|
||||
|
||||
AWX allows you to control access to who can access what, even allowing sharing of SSH credentials without someone being able to transfer those credentials. Inventory can be graphically managed or synced with a wide variety of cloud sources. It logs all of your jobs, integrates well with LDAP, and has an amazing browsable REST API. Command line tools are available for easy integration
|
||||
with Jenkins as well.
|
||||
|
||||
Find out more about AWX features and how to download it on the `AWX webpage <http://ansibleworks.com/ansibleworks-awx>`_. AWX
|
||||
is free for usage for up to 10 nodes, and comes bundled with amazing support from AnsibleWorks. As you would expect, AWX is
|
||||
installed using Ansible playbooks!
|
|
@ -11,6 +11,5 @@ Learn how to build modules of your own in any language, and also how to extend A
|
|||
developing_modules
|
||||
developing_plugins
|
||||
|
||||
Developers will also likely be interested in the fully-discoverable `REST API <http://ansibleworks.com/ansibleworks-awx>`_ that is part of AnsibleWorks AWX. It's great for embedding Ansible in all manner of applications.
|
||||
|
||||
Developers will also likely be interested in the fully-discoverable in :doc:`tower`. It's great for embedding Ansible in all manner of applications.
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ write various plugins, and you can plug in inventory data from external data sou
|
|||
covers the Runner and Playbook API at a basic level.
|
||||
|
||||
If you are looking to use Ansible programmatically from something other than Python, trigger events asynchronously,
|
||||
or have access control and logging demands, take a look at `AnsibleWorks AWX <http://ansibleworks.com/ansibleworks-awx>`_
|
||||
or have access control and logging demands, take a look at :doc:`tower`
|
||||
as it has a very nice REST API that provides all of these things at a higher level.
|
||||
|
||||
Ansible is written in its own API so you have a considerable amount of power across the board.
|
||||
|
|
|
@ -91,7 +91,7 @@ The data to be added to the top level JSON dictionary looks like this::
|
|||
How to develop modules
|
||||
:doc:`developing_plugins`
|
||||
How to develop plugins
|
||||
`AnsibleWorks AWX <http://ansibleworks.com/ansibleworks-awx>`_
|
||||
`Ansible Tower <http://ansible.com/ansible-tower>`_
|
||||
REST API endpoint and GUI for Ansible, syncs with dynamic inventory
|
||||
`Development Mailing List <http://groups.google.com/group/ansible-devel>`_
|
||||
Mailing list for development topics
|
||||
|
|
|
@ -158,7 +158,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
|
||||
was static and predictable. (If you are using AWX, it will use database order, so this isn't a problem even if you are using cloud
|
||||
was static and predictable. (If you are using doc:`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::
|
||||
|
@ -234,15 +234,15 @@ Once the library is ready, SHA512 password values can then be generated as follo
|
|||
Can I get training on Ansible or find commercial support?
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Yes! See `AnsibleWorks.com <http://ansibleworks.com>`_ or email `info@ansibleworks.com <mailto:info@ansibleworks.com>`_.
|
||||
Yes! See `our Guru offering <http://www.ansible.com/ansible-guru>_` for online support, and support is also included with :doc:`tower`. You can also read our `service page <http://www.ansible.com/ansible-services>`_ and email `info@ansible.com <mailto:info@ansible.com>`_ for further details.
|
||||
|
||||
.. _web_interface:
|
||||
|
||||
Is there a web interface / REST API / etc?
|
||||
++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Yes! AnsibleWorks makes a great product that makes Ansible even more powerful
|
||||
and easy to use: `AnsibleWorks AWX <http://ansibleworks.com/ansible-awx/>`_.
|
||||
Yes! Ansible, Inc makes a great product that makes Ansible even more powerful
|
||||
and easy to use. See :doc:`tower`.
|
||||
|
||||
.. _docs_contributions:
|
||||
|
||||
|
@ -256,9 +256,7 @@ Great question! Documentation for Ansible is kept in the main project git repos
|
|||
I don't see my question here
|
||||
++++++++++++++++++++++++++++
|
||||
|
||||
We're happy to help.
|
||||
|
||||
See the `Resources <http://www.ansibleworks.com/community/>`_ section of the documentation home page for a link to the IRC and Google Group.
|
||||
Please see the section below for a link to IRC and the Google Group, where you can ask your question there.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
|
@ -1,12 +1,7 @@
|
|||
AnsibleWorks Galaxy
|
||||
```````````````````
|
||||
Ansible Galaxy
|
||||
``````````````
|
||||
|
||||
.. image:: https://galaxy.ansibleworks.com/static/img/galaxy_logo_small.png
|
||||
:alt: AnsibleWorks Galaxy Logo
|
||||
:width: 619px
|
||||
:height: 109px
|
||||
|
||||
`AnsibleWorks Galaxy <http://galaxy.ansibleworks.com>`_, is a free site for finding, downloading, rating, and reviewing all kinds of community developed Ansible roles and can be a great way to get a jumpstart on your automation projects.
|
||||
`Ansible Galaxy <http://galaxy.ansible.com>`_, is a free site for finding, downloading, rating, and reviewing all kinds of community developed Ansible roles and can be a great way to get a jumpstart on your automation projects.
|
||||
|
||||
You can sign up with social auth, and the download client 'ansible-galaxy' is included in Ansible 1.4.2 and later.
|
||||
|
||||
|
|
|
@ -105,7 +105,7 @@ Host Inventory
|
|||
|
||||
Once your nodes are spun up, you'll probably want to talk to them again. The best way to handle his is to use the ec2 inventory plugin.
|
||||
|
||||
Even for larger environments, you might have nodes spun up from Cloud Formations or other tooling. You don't have to use Ansible to spin up guests. Once these are created and you wish to configure them, the EC2 API can be used to return system grouping with the help of the EC2 inventory script. This script can be used to group resources by their security group or tags. Tagging is highly recommended in EC2 and can provide an easy way to sort between host groups and roles. The inventory script is documented `in the API chapter <http://www.ansibleworks.com/docs/api.html#external-inventory-scripts>`_.
|
||||
Even for larger environments, you might have nodes spun up from Cloud Formations or other tooling. You don't have to use Ansible to spin up guests. Once these are created and you wish to configure them, the EC2 API can be used to return system grouping with the help of the EC2 inventory script. This script can be used to group resources by their security group or tags. Tagging is highly recommended in EC2 and can provide an easy way to sort between host groups and roles. The inventory script is documented doc:`api` section.
|
||||
|
||||
You may wish to schedule a regular refresh of the inventory cache to accommodate for frequent changes in resources:
|
||||
|
||||
|
@ -144,14 +144,14 @@ Read :ref:`ansible-pull` for more information on pull-mode playbooks.
|
|||
|
||||
.. _aws_autoscale:
|
||||
|
||||
AWX Autoscaling
|
||||
+++++++++++++++
|
||||
Autoscaling with Ansible Tower
|
||||
++++++++++++++++++++++++++++++
|
||||
|
||||
AnsibleWorks's "AWX" product also contains a very nice feature for auto-scaling use cases. In this mode, a simple curl script can call
|
||||
:doc:`tower` also contains a very nice feature for auto-scaling use cases. In this mode, a simple curl script can call
|
||||
a defined URL and the server will "dial out" to the requester and configure an instance that is spinning up. This can be a great way
|
||||
to reconfigure ephemeral nodes. See the AWX documentation for more details. Click on the AWX link in the sidebar for details.
|
||||
to reconfigure ephemeral nodes. See the Tower documentation for more details. Click on the Tower link in the sidebar for details.
|
||||
|
||||
A benefit of using the callback in AWX over pull mode is that job results are still centrally recorded and less information has to be shared
|
||||
A benefit of using the callback in Tower over pull mode is that job results are still centrally recorded and less information has to be shared
|
||||
with remote hosts.
|
||||
|
||||
.. _aws_use_cases:
|
||||
|
@ -179,7 +179,7 @@ Example 2
|
|||
|
||||
Example 2: I'm using AutoScaling to dynamically scale up and scale down the number of instances. This means the number of hosts is constantly fluctuating but I'm letting EC2 automatically handle the provisioning of these instances. I don't want to fully bake a machine image, I'd like to use Ansible to configure the hosts.
|
||||
|
||||
There are several approaches to this use case. The first is to use the inventory plugin to regularly refresh host information and then target hosts based on the latest inventory data. The second is to use ansible-pull triggered by a user-data script (specified in the launch configuration) which would then mean that each instance would fetch Ansible and the latest playbook from a git repository and run locally to configure itself. You could also use the AWX callback feature.
|
||||
There are several approaches to this use case. The first is to use the inventory plugin to regularly refresh host information and then target hosts based on the latest inventory data. The second is to use ansible-pull triggered by a user-data script (specified in the launch configuration) which would then mean that each instance would fetch Ansible and the latest playbook from a git repository and run locally to configure itself. You could also use the Tower callback feature.
|
||||
|
||||
.. _aws_builds:
|
||||
|
||||
|
|
|
@ -174,7 +174,7 @@ rax.py
|
|||
To use the rackspace dynamic inventory script, copy ``rax.py`` from ``plugins/inventory`` into your inventory directory. You can specify credentials
|
||||
for ``rax.py`` utilizing the ``RAX_CREDS_FILE`` environment variable.
|
||||
|
||||
.. note:: Users of AnsibleWorks AWX will note that dynamic inventory is natively supported by AWX, and all you have to do is associate a group with your Rackspace Cloud credentials, and it will easily synchronize without going through these steps::
|
||||
.. note:: Users of doc:`tower` will note that dynamic inventory is natively supported by Tower, and all you have to do is associate a group with your Rackspace Cloud credentials, and it will easily synchronize without going through these steps::
|
||||
|
||||
$ RAX_CREDS_FILE=~/.raxpub ansible all -i rax.py -m setup
|
||||
|
||||
|
@ -575,15 +575,15 @@ Advanced Usage
|
|||
|
||||
.. _awx_autoscale:
|
||||
|
||||
AWX Autoscaling
|
||||
+++++++++++++++
|
||||
Autoscaling with Tower
|
||||
++++++++++++++++++++++
|
||||
|
||||
AnsibleWorks's "AWX" solution also contains a very nice feature for auto-scaling use cases.
|
||||
:doc:`tower` also contains a very nice feature for auto-scaling use cases.
|
||||
In this mode, a simple curl script can call a defined URL and the server will "dial out" to the requester
|
||||
and configure an instance that is spinning up. This can be a great way to reconfigure ephmeral nodes.
|
||||
See the AWX documentation for more details. Click on the AWX link in the sidebar for details.
|
||||
See the Tower documentation for more details.
|
||||
|
||||
A benefit of using the callback in AWX over pull mode is that job results are still centrally recorded
|
||||
A benefit of using the callback in Tower over pull mode is that job results are still centrally recorded
|
||||
and less information has to be shared with remote hosts.
|
||||
|
||||
.. _pending_information:
|
||||
|
|
|
@ -262,12 +262,10 @@ Now that you have an automated way to deploy updates to your application, how do
|
|||
|
||||
Depending on your environment, you might be deploying continuously to a test environment, running an integration test battery against that environment, and then deploying automatically into production. Or you could keep it simple and just use the rolling-update for on-demand deployment into test or production specifically. This is all up to you.
|
||||
|
||||
For integration with Continuous Integration systems, you can easily trigger playbook runs using the ``ansible-playbook`` command line tool, or, if you're using AnsibleWorks AWX, the ``awx-cli`` or the built-in REST API. (The AWX-cli command 'joblaunch' will spawn a remote job over the REST API and is pretty slick).
|
||||
For integration with Continuous Integration systems, you can easily trigger playbook runs using the ``ansible-playbook`` command line tool, or, if you're using :doc:`tower`, the ``tower-cli`` or the built-in REST API. (The tower-cli command 'joblaunch' will spawn a remote job over the REST API and is pretty slick).
|
||||
|
||||
This should give you a good idea of how to structure a multi-tier application with Ansible, and orchestrate operations upon that app, with the eventual goal of continuous delivery to your customers. You could extend the idea of the rolling upgrade to lots of different parts of the app; maybe add front-end web servers along with application servers, for instance, or replace the SQL database with something like MongoDB or Riak. Ansible gives you the capability to easily manage complicated environments and automate common operations.
|
||||
|
||||
If you need help or if you have questions, stop by the mailing list or the IRC channel, or email us at info@ansibleworks.com.
|
||||
|
||||
.. seealso::
|
||||
|
||||
`lamp_haproxy example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_
|
||||
|
@ -278,7 +276,7 @@ If you need help or if you have questions, stop by the mailing list or the IRC c
|
|||
An introduction to playbook roles
|
||||
:doc:`playbooks_variables`
|
||||
An introduction to Ansible variables
|
||||
`AnsibleWorks: Continuous Delivery <http://www.ansibleworks.com/continuous-delivery/>`_
|
||||
`Ansible.com: Continuous Delivery <http://www.ansible.com/ansible-continuous-delivery>`_
|
||||
An introduction to Continuous Delivery with Ansible
|
||||
|
||||
|
||||
|
|
|
@ -16,9 +16,7 @@ We believe simplicity is relevant to all sizes of environments and design for bu
|
|||
Ansible manages machines in an agentless manner. There is never a question of how to
|
||||
upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled. As OpenSSH is one of the most peer reviewed open source components, the security exposure of using the tool is greatly reduced. Ansible is decentralized -- it relies on your existing OS credentials to control access to remote machines; if needed it can easily connect with Kerberos, LDAP, and other centralized authentication management systems.
|
||||
|
||||
You may be interested in reading about `some notable Ansible users <http://www.ansibleworks.com/users/>`_.
|
||||
|
||||
This documentation covers the current released version of Ansible (1.4.4) and also some development version features (1.5). For recent features, in each section, the version of Ansible where the feature is added is indicated. AnsibleWorks releases a new major release of Ansible approximately every 2 months. The core application evolves somewhat conservatively, valuing simplicity in language design and setup, while the community around new modules and plugins being developed and contributed moves very very quickly, typically adding 20 or so new modules in each release.
|
||||
This documentation covers the current released version of Ansible (1.4.4) and also some development version features (1.5). For recent features, in each section, the version of Ansible where the feature is added is indicated. Ansible, Inc releases a new major release of Ansible approximately every 2 months. The core application evolves somewhat conservatively, valuing simplicity in language design and setup, while the community around new modules and plugins being developed and contributed moves very very quickly, typically adding 20 or so new modules in each release.
|
||||
|
||||
.. _an_introduction:
|
||||
|
||||
|
@ -33,7 +31,7 @@ This documentation covers the current released version of Ansible (1.4.4) and al
|
|||
modules_by_category
|
||||
guides
|
||||
developing
|
||||
awx
|
||||
tower
|
||||
community
|
||||
galaxy
|
||||
faq
|
||||
|
|
|
@ -287,7 +287,7 @@ the user running Ansible has permissions on the logfile::
|
|||
This behavior is not on by default. Note that ansible will, without this setting, record module arguments called to the
|
||||
syslog of managed machines. Password arguments are excluded.
|
||||
|
||||
For Enterprise users seeking more detailed logging history, you may be interested in `AnsibleWorks AWX <http://ansibleworks.com/ansibleworks-awx>`_.
|
||||
For Enterprise users seeking more detailed logging history, you may be interested in :doc:`tower`.
|
||||
|
||||
.. _lookup_plugins:
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ or a piece of expensive enterprisey CMDB software.
|
|||
|
||||
Ansible easily supports all of these options via an external inventory system. The plugins directory contains some of these already -- including options for EC2/Eucalyptus, Rackspace Cloud, and OpenStack, examples of some of which will be detailed below.
|
||||
|
||||
`AnsibleWorks AWX <http://ansibleworks.com/ansibleworks-awx/>`_ also provides a database to store inventory results that is both web and REST Accessible. AWX syncs with all Ansible dynamic inventory sources. By having a database record of all of your hosts, it's easy to correlate past event history and see which ones have had failures on their last playbook runs.
|
||||
doc:`tower` also provides a database to store inventory results that is both web and REST Accessible. Tower syncs with all Ansible dynamic inventory sources you might be using, and also includes a graphical inventory editor. By having a database record of all of your hosts, it's easy to correlate past event history and see which ones have had failures on their last playbook runs.
|
||||
|
||||
For information about writing your own dynamic inventory source, see :doc:`developing_inventory`.
|
||||
|
||||
|
@ -24,7 +24,7 @@ For information about writing your own dynamic inventory source, see :doc:`devel
|
|||
Example: The Cobbler External Inventory Script
|
||||
``````````````````````````````````````````````
|
||||
|
||||
It is expected that many Ansible users with a reasonable amount of physical hardware may also be `Cobbler <http://cobbler.github.com>`_ users. (note: Cobbler was originally written by Michael DeHaan and is now lead by James Cammarata, who also works for AnsibleWorks).
|
||||
It is expected that many Ansible users with a reasonable amount of physical hardware may also be `Cobbler <http://cobbler.github.com>`_ users. (note: Cobbler was originally written by Michael DeHaan and is now lead by James Cammarata, who also works for Ansible, Inc).
|
||||
|
||||
While primarily used to kickoff OS installations and manage DHCP and DNS, Cobbler has a generic
|
||||
layer that allows it to represent data for multiple configuration management systems (even at the same time), and has
|
||||
|
|
|
@ -127,7 +127,7 @@ Also note that host key checking in paramiko mode is reasonably slow, therefore
|
|||
.. _a_note_about_logging:
|
||||
|
||||
Ansible will log some information about module arguments on the remote system in the remote syslog. To enable basic
|
||||
logging on the control machine see :doc:`intro_configuration` document and set the 'log_path' configuration file setting. Enterprise users may also be interested in `AnsibleWorks AWX <http://ansibleworks.com/ansibleworks-awx>`_. AWX provides a very robust database logging feature where it is possible to drill down and see history based on hosts, projects, and particular inventories over time -- explorable both graphically and through a REST API.
|
||||
logging on the control machine see :doc:`intro_configuration` document and set the 'log_path' configuration file setting. Enterprise users may also be interested in :doc:`tower`. Tower provides a very robust database logging feature where it is possible to drill down and see history based on hosts, projects, and particular inventories over time -- explorable both graphically and through a REST API.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
|
@ -210,7 +210,7 @@ Readers that use virtualenv can also install Ansible under virtualenv, though we
|
|||
Tarballs of Tagged Releases
|
||||
+++++++++++++++++++++++++++
|
||||
|
||||
Packaging Ansible or wanting to build a local package yourself, but don't want to do a git checkout? Tarballs of releases are available on the `Ansible/downloads <http://ansibleworks.com/releases>`_ page.
|
||||
Packaging Ansible or wanting to build a local package yourself, but don't want to do a git checkout? Tarballs of releases are available on the `Ansible downloads <http://releases.ansible.com/ansible>`_ page.
|
||||
|
||||
These releases are also tagged in the `git repository <https://github.com/ansible/ansible/releases>`_ with the release version.
|
||||
|
||||
|
|
|
@ -319,15 +319,10 @@ The resulting order of execution would be as follows::
|
|||
.. note::
|
||||
Variable inheritance and scope are detailed in the :doc:`playbooks_variables`.
|
||||
|
||||
AnsibleWorks Galaxy
|
||||
```````````````````
|
||||
Ansible Galaxy
|
||||
``````````````
|
||||
|
||||
.. image:: https://galaxy.ansibleworks.com/static/img/galaxy_logo_small.png
|
||||
:alt: AnsibleWorks Galaxy Logo
|
||||
:width: 619px
|
||||
:height: 109px
|
||||
|
||||
`AnsibleWorks Galaxy <http://galaxy.ansibleworks.com>`_, is a free site for finding, downloading, rating, and reviewing all kinds of community developed Ansible roles and can be a great way to get a jumpstart on your automation projects.
|
||||
`Ansible Galaxy <http://galaxy.ansible.com>`_, is a free site for finding, downloading, rating, and reviewing all kinds of community developed Ansible roles and can be a great way to get a jumpstart on your automation projects.
|
||||
|
||||
You can sign up with social auth, and the download client 'ansible-galaxy' is included in Ansible 1.4.2 and later.
|
||||
|
||||
|
|
|
@ -818,7 +818,7 @@ First off, group variables are super powerful.
|
|||
|
||||
Site wide defaults should be defined as a 'group_vars/all' setting. Group variables are generally placed alongside
|
||||
your inventory file. They can also be returned by a dynamic inventory script (see :doc:`intro_dynamic_inventory`) or defined
|
||||
in things like AnsibleWorks AWX from the UI or API::
|
||||
in things like :doc:`tower` from the UI or API::
|
||||
|
||||
---
|
||||
# file: /etc/ansible/group_vars/all
|
||||
|
|
|
@ -3,7 +3,7 @@ Quickstart Video
|
|||
|
||||
We've recorded a short video that shows how to get started with Ansible that you may like to use alongside the documentation.
|
||||
|
||||
The `quickstart video <http://ansibleworks.com/quickstart/>`_ is about 20 minutes long and will show you some of the basics about your
|
||||
The `quickstart video <http://ansible.com/ansible-resources>`_ is about 20 minutes long and will show you some of the basics about your
|
||||
first steps with Ansible.
|
||||
|
||||
Enjoy, and be sure to visit the rest of the documentation to learn more.
|
||||
|
|
10
docsite/rst/tower.rst
Normal file
10
docsite/rst/tower.rst
Normal file
|
@ -0,0 +1,10 @@
|
|||
Ansible Tower
|
||||
`````````````
|
||||
|
||||
`Ansible Tower <http://ansible.com/ansible-tower>`_ (formerly 'AWX') is a web-based solution that makes Ansible even more easy to use for IT teams of all kinds. It's designed to be the hub for all of your automation tasks.
|
||||
|
||||
Tower allows you to control access to who can access what, even allowing sharing of SSH credentials without someone being able to transfer those credentials. Inventory can be graphically managed or synced with a wide variety of cloud sources. It logs all of your jobs, integrates well with LDAP, and has an amazing browsable REST API. Command line tools are available for easy integration with Jenkins as well. Provisioning callbacks provide great support for autoscaling topologies.
|
||||
|
||||
Find out more about Tower features and how to download it on the `Ansible Tower webpage <http://ansible.com/ansible-tower>`_. Tower
|
||||
is free for usage for up to 10 nodes, and comes bundled with amazing support from Ansible, Inc. As you would expect, Ansible is
|
||||
installed using Ansible playbooks!
|
Loading…
Reference in a new issue