← Back to branch summary

~canonical-ci-engineering/ubuntu-ci-services-itself/ansible

« back to all changes in this revision

Viewing changes to docsite/rst/guide_aws.rst

  • Committer: Package Import Robot
  • Author(s): Michael Vogt
  • Date: 2013-12-03 08:17:05 UTC
  • mto: This revision was merged to the branch mainline in revision 6.
  • Revision ID: package-import@ubuntu.com-20131203081705-q0t7wlepvpcbiidu
Tags: upstream-1.4.1+dfsg
Import upstream version 1.4.1+dfsg

Show diffs side-by-side

added added

removed removed

Lines of Context:
docsite/rst/guide_aws.rst
96
96
 
97
97
The method above ties the configuration of a host with the provisioning step.  This isn't always ideal and leads us onto the next section.
98
98
 
99
 
:: _aws_advanced:
 
99
.. _aws_advanced:
100
100
 
101
101
Advanced Usage
102
102
``````````````
103
103
 
104
 
:: _aws_host_inventory:
 
104
.. _aws_host_inventory:
105
105
 
106
106
Host Inventory
107
107
++++++++++++++
118
118
 
119
119
Put this into a crontab as appropriate to make calls from your Ansible master server to the EC2 API endpoints and gather host information.  The aim is to keep the view of hosts as up-to-date as possible, so schedule accordingly. Playbook calls could then also be scheduled to act on the refreshed hosts inventory after each refresh.  This approach means that machine images can remain "raw", containing no payload and OS-only.  Configuration of the workload is handled entirely by Ansible.  
120
120
 
121
 
:: _aws_pull:
 
121
.. _aws_pull:
122
122
 
123
123
Pull Configuration
124
124
++++++++++++++++++
129
129
 
130
130
(Various developments around Ansible are also going to make this easier in the near future.  Stay tuned!)
131
131
 
132
 
:: _aws_autoscale:
 
132
.. _aws_autoscale:
133
133
 
134
134
AWX Autoscaling
135
135
+++++++++++++++
141
141
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
142
142
with remote hosts.
143
143
 
144
 
:: _aws_use_cases:
 
144
.. _aws_use_cases:
145
145
 
146
146
Use Cases
147
147
`````````
148
148
 
149
149
This section covers some usage examples built around a specific use case.
150
150
 
151
 
:: _aws_cloudformation_example:
 
151
.. _aws_cloudformation_example:
152
152
 
153
153
Example 1
154
154
+++++++++
159
159
 
160
160
.. note:: Ansible also has a cloudformation module you may wish to explore.
161
161
 
162
 
:: _aws_autoscale_example:
 
162
.. _aws_autoscale_example:
163
163
 
164
164
Example 2
165
165
+++++++++
168
168
 
169
169
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.
170
170
 
171
 
:: _aws_builds:
 
171
.. _aws_builds:
172
172
 
173
173
Example 3
174
174
+++++++++
185
185
 
186
186
.. note:: more examples of this are pending.   You may also be interested in the ec2_ami module for taking AMIs of running instances.
187
187
 
188
 
:: _aws_pending:
 
188
.. _aws_pending:
189
189
 
190
190
Pending Information
191
191
```````````````````