Environment doc cleanup and showing another use case.

This commit is contained in:
Michael DeHaan 2013-10-02 22:02:11 -04:00
parent e9bd97ea4d
commit fd3fb24fe8
2 changed files with 17 additions and 5 deletions

View file

@ -1,8 +1,17 @@
Delegation, Rolling Updates, and Local Actions
==============================================
Ansible is great at doing things on one host on behalf of another, and in particular this is very applicable
when setting up continuous deployment infrastructure or zero downtime rolling updates.
Being designed for multi-tier deployments since the beginning, Ansible is great at doing things on one host on behalf of another, or doing
local steps with reference to some remote hosts.
This in particular this is very applicable when setting up continuous deployment infrastructure or zero downtime rolling updates, where you
might be talking with load balancers or monitoring systems.
Additional features allow for tuning the orders in which things complete, and assigning a batch window size for how many machines to process
at once during a rolling update.
This section covers all fo these features. For examples of these items in use, please see the 'ansible-examples' repository in
the 'ansible' github organization.
Rolling Update Batch Size
`````````````````````````

View file

@ -4,8 +4,11 @@ Setting the Environment (and Working With Proxies)
.. versionadded:: 1.1
It is quite possible that you may need to get package updates through a proxy, or even get some package
updates through a proxy and access other packages not through a proxy. Ansible makes it easy for you
to configure your environment by using the 'environment' keyword. Here is an example::
updates through a proxy and access other packages not through a proxy.
Occasionally a script you might wish to call may also need certain environment variables set.
Ansible makes it easy for you to configure your environment by using the 'environment' keyword. Here is an example::
- hosts: all
remote_user: root
@ -29,7 +32,7 @@ The environment can also be stored in a variable, and accessed like so::
tasks:
- apt: name=cobbler state=installed
environment: "{{ proxy_env }}"
environment: proxy_env
While just proxy settings were shown above, any number of settings can be supplied. The most logical place
to define an environment hash might be a group_vars file, like so::