mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Merge pull request #3273 from jlund/ansiblecc-to-ansibleworkscom
Update all ansible.cc references in the documentation to point to ansibleworks.com
This commit is contained in:
commit
b72109a04b
13 changed files with 24 additions and 24 deletions
|
@ -1,7 +1,7 @@
|
||||||
Homepage and documentation source for the Ansible
|
Homepage and documentation source for the Ansible
|
||||||
=================================================
|
=================================================
|
||||||
|
|
||||||
This project hosts the source behind [ansible.cc/docs](http://ansible.cc/docs)
|
This project hosts the source behind [ansibleworks.com/docs](http://www.ansibleworks.com/docs/)
|
||||||
|
|
||||||
Contributions to the documentation are welcome. To make changes, submit a pull request
|
Contributions to the documentation are welcome. To make changes, submit a pull request
|
||||||
that changes the restructured text files in the "rst/" directory only, and Michael can
|
that changes the restructured text files in the "rst/" directory only, and Michael can
|
||||||
|
|
|
@ -75,7 +75,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.
|
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://ansible.cc/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 `in the API chapter <http://www.ansibleworks.com/docs/api.html#external-inventory-scripts>`_.
|
||||||
|
|
||||||
You may wish to schedule a regular refresh of the inventory cache to accomodate for frequent changes in resources:
|
You may wish to schedule a regular refresh of the inventory cache to accomodate for frequent changes in resources:
|
||||||
|
|
||||||
|
@ -90,7 +90,7 @@ Pull Configuration
|
||||||
|
|
||||||
For some the delay between refreshing host information and acting on that host information (i.e. running Ansible tasks against the hosts) may be too long. This may be the case in such scenarios where EC2 AutoScaling is being used to scale the number of instances as a result of a particular event. Such an event may require that hosts come online and are configured as soon as possible (even a 1 minute delay may be undesirable). Its possible to pre-bake machine images which contain the necessary ansible-pull script and components to pull and run a playbook via git. The machine images could be configured to run ansible-pull upon boot as part of the bootstrapping procedure.
|
For some the delay between refreshing host information and acting on that host information (i.e. running Ansible tasks against the hosts) may be too long. This may be the case in such scenarios where EC2 AutoScaling is being used to scale the number of instances as a result of a particular event. Such an event may require that hosts come online and are configured as soon as possible (even a 1 minute delay may be undesirable). Its possible to pre-bake machine images which contain the necessary ansible-pull script and components to pull and run a playbook via git. The machine images could be configured to run ansible-pull upon boot as part of the bootstrapping procedure.
|
||||||
|
|
||||||
More information on pull-mode playbooks can be found `here <http://ansible.cc/docs/playbooks2.html#pull-mode-playbooks>`_.
|
More information on pull-mode playbooks can be found `here <http://www.ansibleworks.com/docs/playbooks2.html#pull-mode-playbooks>`_.
|
||||||
|
|
||||||
(Various developments around Ansible are also going to make this easier in the near future. Stay tuned!)
|
(Various developments around Ansible are also going to make this easier in the near future. Stay tuned!)
|
||||||
|
|
||||||
|
|
|
@ -13,7 +13,7 @@ Ansible modules are a way of adding new client-side logic to ansible.
|
||||||
They can be written in any language. Generally our goal is to include most modules in core ("batteries included!"),
|
They can be written in any language. Generally our goal is to include most modules in core ("batteries included!"),
|
||||||
though a few may remain outside of core depending on use cases and implementations.
|
though a few may remain outside of core depending on use cases and implementations.
|
||||||
|
|
||||||
- `Official "core" ansible modules <http://ansible.cc/docs/modules.html>`_ - various
|
- `Official "core" ansible modules <http://www.ansibleworks.com/docs/modules.html>`_ - various
|
||||||
- `Linode <https://github.com/lextoumbourou/ansible-linode>`_ - Lex Toumbourou
|
- `Linode <https://github.com/lextoumbourou/ansible-linode>`_ - Lex Toumbourou
|
||||||
- `zypper (bash module example) <https://github.com/jpmens/ansible-zypp>`_ - jp\_mens
|
- `zypper (bash module example) <https://github.com/jpmens/ansible-zypp>`_ - jp\_mens
|
||||||
- `additional provisioning-related modules <https://github.com/ansible-provisioning>`_ - jhoekx and dagwieers
|
- `additional provisioning-related modules <https://github.com/ansible-provisioning>`_ - jhoekx and dagwieers
|
||||||
|
@ -27,7 +27,7 @@ Not all modules above may take advantage of this feature. See the official docum
|
||||||
Selected Playbooks
|
Selected Playbooks
|
||||||
``````````````````
|
``````````````````
|
||||||
|
|
||||||
`Playbooks <http://ansible.cc/docs/playbooks.html>`_ are Ansible's
|
`Playbooks <http://www.ansibleworks.com/docs/playbooks.html>`_ are Ansible's
|
||||||
configuration management language. It should be easy to write your own
|
configuration management language. It should be easy to write your own
|
||||||
from scratch for most applications (we keep the language simple for EXACTLY that reason), but it can
|
from scratch for most applications (we keep the language simple for EXACTLY that reason), but it can
|
||||||
be helpful to look at what others have done for reference and see what is possible.
|
be helpful to look at what others have done for reference and see what is possible.
|
||||||
|
@ -100,9 +100,9 @@ Disclaimer
|
||||||
|
|
||||||
Modules and playbooks here may not be using the latest in Ansible
|
Modules and playbooks here may not be using the latest in Ansible
|
||||||
features. When in doubt to the features of a particular version of
|
features. When in doubt to the features of a particular version of
|
||||||
Ansbile, always consult `ansible.cc <http://ansible.cc>`_ and in
|
Ansible, always consult `ansibleworks.com <http://www.ansibleworks.com/>`_ and in
|
||||||
particular see `Best Practices <http://ansible.cc/docs/bestpractices.html>`_ for some tips
|
particular see `Best Practices <http://www.ansibleworks.com/docs/bestpractices.html>`_
|
||||||
and tricks that may be useful.
|
for some tips and tricks that may be useful.
|
||||||
|
|
||||||
Ansible is (C) 2012, `Michael DeHaan <http://twitter.com/laserllama>`_
|
Ansible is (C) 2012, `Michael DeHaan <http://twitter.com/laserllama>`_
|
||||||
and others and is available under the GPLv3 license. Content here is as
|
and others and is available under the GPLv3 license. Content here is as
|
||||||
|
|
|
@ -229,7 +229,7 @@ pointing to python3, so the right python can be found on the managed nodes.
|
||||||
Tagged Releases
|
Tagged Releases
|
||||||
+++++++++++++++
|
+++++++++++++++
|
||||||
|
|
||||||
Tarballs of releases are available on the ansible.cc page.
|
Tarballs of releases are available on the ansibleworks.com page.
|
||||||
|
|
||||||
* `Ansible/downloads <http://ansibleworks.com/releases>`_
|
* `Ansible/downloads <http://ansibleworks.com/releases>`_
|
||||||
|
|
||||||
|
|
|
@ -34,7 +34,7 @@ and /usr/bin/ansible-playbook.
|
||||||
Callback Plugin
|
Callback Plugin
|
||||||
+++++++++++++++
|
+++++++++++++++
|
||||||
|
|
||||||
Refers to some user-written code that can intercept the results from Ansbile and do something with it. Some supplied examples
|
Refers to some user-written code that can intercept the results from Ansible and do something with it. Some supplied examples
|
||||||
in the github project perform custom logging, send email, or even play sound effects.
|
in the github project perform custom logging, send email, or even play sound effects.
|
||||||
|
|
||||||
Check Mode
|
Check Mode
|
||||||
|
@ -143,7 +143,7 @@ if they are not to be accessed on the default SSH port.
|
||||||
Host Specifier
|
Host Specifier
|
||||||
++++++++++++++
|
++++++++++++++
|
||||||
|
|
||||||
Each Play in Ansbile maps a series of tasks (which define the role, purpose, or orders of a system) to a set of systems.
|
Each Play in Ansible maps a series of tasks (which define the role, purpose, or orders of a system) to a set of systems.
|
||||||
|
|
||||||
This "hosts:" directive in each play is often called the hosts specifier.
|
This "hosts:" directive in each play is often called the hosts specifier.
|
||||||
|
|
||||||
|
@ -213,7 +213,7 @@ called an "External Nodes Classifier") and works more or less exactly the same w
|
||||||
Jinja2
|
Jinja2
|
||||||
++++++
|
++++++
|
||||||
|
|
||||||
Jinja2 is the preferred templating language of Ansbile's template module. It is a very simple Python template language that is generally
|
Jinja2 is the preferred templating language of Ansible's template module. It is a very simple Python template language that is generally
|
||||||
readable and easy to write.
|
readable and easy to write.
|
||||||
|
|
||||||
JSON
|
JSON
|
||||||
|
@ -387,7 +387,7 @@ features, paramiko (the default) is a fine choice. Ansible will warn you if it
|
||||||
Tags
|
Tags
|
||||||
++++
|
++++
|
||||||
|
|
||||||
Ansbile allows tagging resources in a playbook with arbitrary keywords, and then running only the parts of the playbook that
|
Ansible allows tagging resources in a playbook with arbitrary keywords, and then running only the parts of the playbook that
|
||||||
correspond to those certain keywords. For instance, it is possible to have an entire OS configuration, and have certain steps
|
correspond to those certain keywords. For instance, it is possible to have an entire OS configuration, and have certain steps
|
||||||
labelled "ntp", and then run just the "ntp" steps to reconfigure the time server information on a remote server.
|
labelled "ntp", and then run just the "ntp" steps to reconfigure the time server information on a remote server.
|
||||||
|
|
||||||
|
|
|
@ -143,7 +143,7 @@ The `vars` section contains a list of variables and values that can be used in t
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
You can also keep variables in separate files and include them alongside inline `vars` with a `vars_files` declaration
|
You can also keep variables in separate files and include them alongside inline `vars` with a `vars_files` declaration
|
||||||
in the play. See the `Advanced Playbooks chapter <http://ansible.cc/docs/playbooks2.html#variable-file-separation>`_
|
in the play. See the `Advanced Playbooks chapter <http://www.ansibleworks.com/docs/playbooks2.html#variable-file-separation>`_
|
||||||
for more info.
|
for more info.
|
||||||
|
|
||||||
These variables can be used later in the playbook like this::
|
These variables can be used later in the playbook like this::
|
||||||
|
|
|
@ -273,7 +273,7 @@ Conditional Execution
|
||||||
`````````````````````
|
`````````````````````
|
||||||
|
|
||||||
(Note: this section covers 1.2 conditionals, if you are using a previous version, select
|
(Note: this section covers 1.2 conditionals, if you are using a previous version, select
|
||||||
the previous version of the documentation, `Ansible 1.1 Docs <http://ansible.cc/docs/released/1.1>`_ .
|
the previous version of the documentation, `Ansible 1.1 Docs <http://www.ansibleworks.com/docs/released/1.1/>`_ .
|
||||||
Those conditional forms continue to be operational in 1.2, although the new mechanisms are cleaner.)
|
Those conditional forms continue to be operational in 1.2, although the new mechanisms are cleaner.)
|
||||||
|
|
||||||
Sometimes you will want to skip a particular step on a particular host. This could be something
|
Sometimes you will want to skip a particular step on a particular host. This could be something
|
||||||
|
@ -972,7 +972,7 @@ feature produces a large amount of output, it is best used when checking a singl
|
||||||
Dictionary & Nested (Complex) Arguments
|
Dictionary & Nested (Complex) Arguments
|
||||||
```````````````````````````````````````
|
```````````````````````````````````````
|
||||||
|
|
||||||
As a review, most tasks in ansbile are of this form::
|
As a review, most tasks in ansible are of this form::
|
||||||
|
|
||||||
tasks:
|
tasks:
|
||||||
|
|
||||||
|
|
|
@ -19,7 +19,7 @@ can install them from pip
|
||||||
$ easy_install pip # if pip is not already available
|
$ easy_install pip # if pip is not already available
|
||||||
$ pip install pyyaml jinja2
|
$ pip install pyyaml jinja2
|
||||||
|
|
||||||
From there, follow ansible instructions on ansible.cc/docs as normal.
|
From there, follow ansible instructions on ansibleworks.com/docs as normal.
|
||||||
|
|
||||||
Test-module
|
Test-module
|
||||||
-----------
|
-----------
|
||||||
|
|
|
@ -25,7 +25,7 @@ module: async_status
|
||||||
short_description: Obtain status of asynchronous task
|
short_description: Obtain status of asynchronous task
|
||||||
description:
|
description:
|
||||||
- "This module gets the status of an asynchronous task. See:
|
- "This module gets the status of an asynchronous task. See:
|
||||||
U(http://ansible.cc/docs/playbooks2.html#asynchronous-actions-and-polling)"
|
U(http://www.ansibleworks.com/docs/playbooks2.html#asynchronous-actions-and-polling)"
|
||||||
version_added: "0.5"
|
version_added: "0.5"
|
||||||
options:
|
options:
|
||||||
jid:
|
jid:
|
||||||
|
@ -42,7 +42,7 @@ options:
|
||||||
choices: [ "status", "cleanup" ]
|
choices: [ "status", "cleanup" ]
|
||||||
default: "status"
|
default: "status"
|
||||||
notes:
|
notes:
|
||||||
- See U(http://ansible.cc/docs/playbooks2.html#asynchronous-actions-and-polling)
|
- See U(http://www.ansibleworks.com/docs/playbooks2.html#asynchronous-actions-and-polling)
|
||||||
requirements: []
|
requirements: []
|
||||||
author: Michael DeHaan
|
author: Michael DeHaan
|
||||||
'''
|
'''
|
||||||
|
|
|
@ -35,7 +35,7 @@ description:
|
||||||
the target host, requests will be sent through that proxy. This
|
the target host, requests will be sent through that proxy. This
|
||||||
behaviour can be overridden by setting a variable for this task
|
behaviour can be overridden by setting a variable for this task
|
||||||
(see `setting the environment
|
(see `setting the environment
|
||||||
<http://ansible.cc/docs/playbooks2.html#setting-the-environment-and-working-with-proxies>`_),
|
<http://www.ansibleworks.com/docs/playbooks2.html#setting-the-environment-and-working-with-proxies>`_),
|
||||||
or by using the use_proxy option.
|
or by using the use_proxy option.
|
||||||
version_added: "0.6"
|
version_added: "0.6"
|
||||||
options:
|
options:
|
||||||
|
|
|
@ -8,7 +8,7 @@ pkgver(){
|
||||||
pkgrel=1
|
pkgrel=1
|
||||||
pkgdesc="A radically simple deployment, model-driven configuration management, and command execution framework"
|
pkgdesc="A radically simple deployment, model-driven configuration management, and command execution framework"
|
||||||
arch=('any')
|
arch=('any')
|
||||||
url="http://ansible.cc"
|
url="http://www.ansibleworks.com"
|
||||||
license=('GPL3')
|
license=('GPL3')
|
||||||
depends=('python2' 'python2-paramiko' 'python2-jinja' 'python2-yaml')
|
depends=('python2' 'python2-paramiko' 'python2-jinja' 'python2-yaml')
|
||||||
makedepends=('git' 'asciidoc' 'fakeroot')
|
makedepends=('git' 'asciidoc' 'fakeroot')
|
||||||
|
|
|
@ -4,7 +4,7 @@ PORTNAME= ansible
|
||||||
PORTVERSION= 1.0
|
PORTVERSION= 1.0
|
||||||
PORTREVISION= 1
|
PORTREVISION= 1
|
||||||
CATEGORIES= python net-mgmt
|
CATEGORIES= python net-mgmt
|
||||||
MASTER_SITES= http://ansible.cc/releases/
|
MASTER_SITES= http://ansibleworks.com/releases/
|
||||||
DISTNAME= ${PORTNAME}-${PORTVERSION}
|
DISTNAME= ${PORTNAME}-${PORTVERSION}
|
||||||
|
|
||||||
MAINTAINER= briancoca+ansible@gmail.com
|
MAINTAINER= briancoca+ansible@gmail.com
|
||||||
|
|
|
@ -10,8 +10,8 @@ Version: 1.3
|
||||||
|
|
||||||
Group: Development/Libraries
|
Group: Development/Libraries
|
||||||
License: GPLv3
|
License: GPLv3
|
||||||
Source0: http://ansible.cc/releases/%{name}-%{version}.tar.gz
|
Source0: http://www.ansibleworks.com/releases/%{name}-%{version}.tar.gz
|
||||||
Url: http://ansible.cc
|
Url: http://www.ansibleworks.com
|
||||||
|
|
||||||
BuildArch: noarch
|
BuildArch: noarch
|
||||||
%if 0%{?rhel} && 0%{?rhel} <= 5
|
%if 0%{?rhel} && 0%{?rhel} <= 5
|
||||||
|
|
Loading…
Reference in a new issue