commit
2e6f9804a5
6 changed files with 20 additions and 20 deletions
|
@ -446,7 +446,7 @@ a github pull request to the main project.
|
||||||
Learn about developing plugins
|
Learn about developing plugins
|
||||||
:doc:`developing_api`
|
:doc:`developing_api`
|
||||||
Learn about the Python API for playbook and task execution
|
Learn about the Python API for playbook and task execution
|
||||||
`Github modules directory <https://github.com/ansible/ansible/tree/devel/library>`_
|
`GitHub modules directory <https://github.com/ansible/ansible/tree/devel/library>`_
|
||||||
Browse source of core modules
|
Browse source of core modules
|
||||||
`Mailing List <http://groups.google.com/group/ansible-devel>`_
|
`Mailing List <http://groups.google.com/group/ansible-devel>`_
|
||||||
Development mailing list
|
Development mailing list
|
||||||
|
|
|
@ -286,7 +286,7 @@ following information, which will be utilized for inventory and variables.
|
||||||
Standard Inventory
|
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:
|
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
|
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
|
* 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
|
* 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:
|
.. _windows_installing:
|
||||||
|
|
||||||
Installing on the Control Machine
|
Installing on the Control Machine
|
||||||
``````````````````````````````````
|
`````````````````````````````````
|
||||||
|
|
||||||
On a Linux 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
|
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
|
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.
|
a version that is 3 or higher.
|
||||||
|
|
||||||
You'll run this command again later though, to make sure everything is working.
|
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.
|
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::
|
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
|
# 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.
|
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
|
register: ipconfig
|
||||||
- debug: var=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::
|
||||||
|
|
||||||
- name: test stat module
|
- name: test stat module
|
||||||
hosts: windows
|
hosts: windows
|
||||||
|
|
|
@ -389,7 +389,7 @@ changed the rules that are automating your infrastructure.
|
||||||
Learn how to extend Ansible by writing your own modules
|
Learn how to extend Ansible by writing your own modules
|
||||||
:doc:`intro_patterns`
|
:doc:`intro_patterns`
|
||||||
Learn about how to select hosts
|
Learn about how to select hosts
|
||||||
`Github examples directory <https://github.com/ansible/ansible/tree/devel/examples/playbooks>`_
|
`GitHub examples directory <https://github.com/ansible/ansible/tree/devel/examples/playbooks>`_
|
||||||
Complete playbook files from the github project source
|
Complete playbook files from the github project source
|
||||||
`Mailing List <http://groups.google.com/group/ansible-project>`_
|
`Mailing List <http://groups.google.com/group/ansible-project>`_
|
||||||
Questions? Help? Ideas? Stop by the list on Google Groups
|
Questions? Help? Ideas? Stop by the list on Google Groups
|
||||||
|
|
|
@ -200,7 +200,7 @@ To get the maximum value from a list of numbers::
|
||||||
.. _set_theory_filters:
|
.. _set_theory_filters:
|
||||||
|
|
||||||
Set Theory Filters
|
Set Theory Filters
|
||||||
--------------------
|
------------------
|
||||||
All these functions return a unique set from sets or lists.
|
All these functions return a unique set from sets or lists.
|
||||||
|
|
||||||
.. versionadded:: 1.4
|
.. 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
|
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
|
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
|
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.
|
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.
|
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.
|
||||||
|
|
||||||
.. _variable_file_seperation_details:
|
.. _variable_file_separation_details:
|
||||||
|
|
||||||
Variable File Separation
|
Variable File Separation
|
||||||
````````````````````````
|
````````````````````````
|
||||||
|
|
|
@ -19,7 +19,7 @@ also very easy to run the steps on thelocalhost or testing servers. Ansible lets
|
||||||
The Right Level of Testing
|
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
|
installed, or other such things. Ansible is the system that will ensure these things are declaratively true. Instead, assert these
|
||||||
things in your playbooks.
|
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"
|
- "'not ready' not in cmd_result.stderr"
|
||||||
- "'gizmo enabled' in cmd_result.stdout"
|
- "'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:
|
tasks:
|
||||||
|
|
||||||
|
@ -205,8 +205,8 @@ the pool.
|
||||||
In the event of a problem, fix the few servers that fail using Ansible's automatically generated
|
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.
|
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.
|
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.
|
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
|
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'.
|
modules like 'script', 'stat', 'uri', and 'assert'.
|
||||||
|
|
||||||
Conclusion
|
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
|
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.
|
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
|
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
|
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
|
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
|
||||||
|
|
Loading…
Reference in a new issue