@ -286,7 +286,7 @@ following information, which will be utilized for inventory and variables.
Standard Inventory
++++++++++++++++++
When utilizing a standard ini formatted inventory file (as opposed to the inventory plugin), it may still be adventageous to retrieve discoverable hostvar information from the Rackspace API.
When utilizing a standard ini formatted inventory file (as opposed to the inventory plugin), it may still be advantageous to retrieve discoverable hostvar information from the Rackspace API.
This can be achieved with the ``rax_facts`` module and an inventory file similar to the following:
@ -795,7 +795,7 @@ and less information has to be shared with remote hosts.
Orchestration in the Rackspace Cloud
++++++++++++++++++++++++++++++++++++
Ansible is a powerful orchestration tool, and rax modules allow you the opportunity to orchestrate complex tasks, deployments, and configurations. The key here is to automate provisioning of infrastructure, like any other pice of software in an environment. Complex deployments might have previously required manual manipulation of load balancers, or manual provisioning of servers. Utilizing the rax modules included with Ansible, one can make the deployment of additional nodes contingent on the current number of running nodes, or the configuration of a clustered application dependent on the number of nodes with common metadata. One could automate the following scenarios, for example:
Ansible is a powerful orchestration tool, and rax modules allow you the opportunity to orchestrate complex tasks, deployments, and configurations. The key here is to automate provisioning of infrastructure, like any other piece of software in an environment. Complex deployments might have previously required manual manipulation of load balancers, or manual provisioning of servers. Utilizing the rax modules included with Ansible, one can make the deployment of additional nodes contingent on the current number of running nodes, or the configuration of a clustered application dependent on the number of nodes with common metadata. One could automate the following scenarios, for example:
* Servers that are removed from a Cloud Load Balancer one-by-one, updated, verified, and returned to the load balancer pool
* Expansion of an already-online environment, where nodes are provisioned, bootstrapped, configured, and software installed
@ -22,7 +22,7 @@ Note that it is expected you have a basic understanding of Ansible prior to jump
.._windows_installing:
Installing on the Control Machine
``````````````````````````````````
`````````````````````````````````
On a Linux control machine::
@ -59,7 +59,7 @@ communication channel that leverages Windows remoting::
ansible windows [-i inventory] -m win_ping --ask-vault-pass
If you haven't done anything to prep your systems yet, this won't work yet. This is covered in a later
section about how to enable powershell remoting - and if neccessary - how to upgrade powershell to
section about how to enable powershell remoting - and if necessary - how to upgrade powershell to
a version that is 3 or higher.
You'll run this command again later though, to make sure everything is working.
@ -95,7 +95,7 @@ Windows modules as listed in the `"windows" subcategory of the Ansible module in
Browse this index to see what is available.
In many cases, it may not be neccessary to even write or use an Ansible module.
In many cases, it may not be necessary to even write or use an Ansible module.
In particular, the "script" module can be used to run arbitrary powershell scripts, allowing Windows administrators familiar with powershell a very native way to do things, as in the following playbook::
@ -128,7 +128,7 @@ Modules (ps1 files) should start as follows::
# code goes here, reading in stdin as JSON and outputting JSON
The above magic is neccessary to tell Ansible to mix in some common code and also know how to push modules out. The common code contains some nice wrappers around working with hash data structures and emitting JSON results, and possibly a few more useful things. Regular Ansible has this same concept for reusing Python code - this is just the windows equivalent.
The above magic is necessary to tell Ansible to mix in some common code and also know how to push modules out. The common code contains some nice wrappers around working with hash data structures and emitting JSON results, and possibly a few more useful things. Regular Ansible has this same concept for reusing Python code - this is just the windows equivalent.
What modules you see in windows/ are just a start. Additional modules may be submitted as pull requests to github.
@ -179,7 +179,7 @@ Running individual commands uses the 'raw' module, as opposed to the shell or co
register: ipconfig
- debug: var=ipconfig
And for a final example, here's how to use the win_stat module to test for file existance. Note that the data returned by the win_stat module is slightly different than what is provided by the Linux equivalent::
And for a final example, here's how to use the win_stat module to test for file existence. Note that the data returned by the win_stat module is slightly different than what is provided by the Linux equivalent::
@ -200,7 +200,7 @@ To get the maximum value from a list of numbers::
.._set_theory_filters:
Set Theory Filters
--------------------
------------------
All these functions return a unique set from sets or lists.
..versionadded:: 1.4
@ -713,7 +713,7 @@ enabled. Why might this be useful?
Imagine, for instance, a very large infrastructure with thousands of hosts. Fact caching could be configured to run nightly, but
configuration of a small set of servers could run ad-hoc or periodically throughout the day. With fact-caching enabled, it would
not be neccessary to "hit" all servers to reference variables and information about them.
not be necessary to "hit" all servers to reference variables and information about them.
With fact caching enabled, it is possible for machine in one group to reference variables about machines in the other group, despite
the fact that they have not been communicated with in the current execution of /usr/bin/ansible-playbook.
@ -831,7 +831,7 @@ Don't worry about any of this unless you think you need it. You'll know when yo
Also available, *inventory_dir* is the pathname of the directory holding Ansible's inventory host file, *inventory_file* is the pathname and the filename pointing to the Ansible's inventory host file.
@ -14,12 +14,12 @@ we'll go into some patterns for integrating tests of infrastructure and discuss
By incorporating a degree of testing into your deployment workflow, there will be fewer surprises when code hits production and, in many cases,
tests can be leveraged in production to prevent failed updates from migrating across an entire installation. Since it's push-based, it's
also very easy to run the steps on thelocalhost or testing servers. Ansible lets you insert as many checks and balances into your upgrade workflow as you would like to have.
also very easy to run the steps on thelocalhost or testing servers. Ansible lets you insert as many checks and balances into your upgrade workflow as you would like to have.
The Right Level of Testing
``````````````````````````
Ansible resources are models of desired-state. As such, it should not be neccessary to test that services are running, packages are
Ansible resources are models of desired-state. As such, it should not be necessary to test that services are running, packages are
installed, or other such things. Ansible is the system that will ensure these things are declaratively true. Instead, assert these
things in your playbooks.
@ -91,7 +91,7 @@ And the assert module makes it very easy to validate various kinds of truth::
- "'not ready' not in cmd_result.stderr"
- "'gizmo enabled' in cmd_result.stdout"
Should you feel the need to test for existance of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice::
Should you feel the need to test for existence of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice::
tasks:
@ -205,8 +205,8 @@ the pool.
In the event of a problem, fix the few servers that fail using Ansible's automatically generated
retry file to repeat the deploy on just those servers.
Achieving Continous Deployment
``````````````````````````````
Achieving Continuous Deployment
```````````````````````````````
If desired, the above techniques may be extended to enable continuous deployment practices.
@ -221,7 +221,7 @@ Some Ansible users use the above approach to deploy a half-dozen or dozen times
offline. A culture of automated QA is vital if you wish to get to this level.
If you are still doing a large amount of manual QA, you should still make the decision on whether to deploy manually as well, but
it can still help to work in the rolling update patterns of the previous section and encorporate some basic health checks using
it can still help to work in the rolling update patterns of the previous section and incorporate some basic health checks using
modules like 'script', 'stat', 'uri', and 'assert'.
Conclusion
@ -235,9 +235,9 @@ However, as Ansible is designed as a multi-tier orchestration system, it makes i
a playbook run, either using loose tasks or roles. When used with rolling updates, testing steps can decide whether to put a machine
back into a load balanced pool or not.
Finally, because Ansible errors propogate all the way up to the return code of the Ansible program itself, and Ansible by default
Finally, because Ansible errors propagate all the way up to the return code of the Ansible program itself, and Ansible by default
runs in an easy push-based mode, Ansible is a great step to put into a build environment if you wish to use it to roll out systems
as part of a Continous Integration/Continous Delivery pipeline, as is covered in sections above.
as part of a Continuous Integration/Continuous Delivery pipeline, as is covered in sections above.
The focus should not be on infrastructure testing, but on application testing, so we strongly encourage getting together with your
QA team and ask what sort of tests would make sense to run every time you deploy development VMs, and which sort of tests they would like
Pascal Borreli
10 years ago