AMI's, autoscaling, Fact Caching, registering results, modular playbooks, and continuous integration

[Robb Wagoner]

Hello all,

I have a rather complicated playbook which orchestrates the following plays: (a) input validation (extra-vars w/ asserts), (b) launching an EC2 instance, (c) configuring the instance, (d) fact gathering, (e) building and tagging an AMI from the instance, (f) using the AMI and the gathered facts to build Launch Configurations with user-data, (g) updating a couple of ASGs used for continuous integration (CI), and (h) terminating the instance launched at (b). 

I am using Jenkins as the Ansible control host. The above playbook seems quite "heavy" and am wondering if there is a cleaner way to group the plays, into separate playbooks & Jenkins jobs. I'm most uncomfortable with (g) step being tied to the whole playbook, but I need to reference rather complicated Launch Configuration names (with Git SHA's in them) from the previous step (f).

Does Fact Caching works with Registered variables? I.e. if when I build the AMI and register the result in one Jenkins job, can I reference the registered variable in a later job? The facts would be for the Jenkins host (localhost).

Thanks,

Robb

[Brian Coca]

no, registered variables are not facts, you can use the template
module to create a local fact in /etc/ansible/facts.d/ and trigger
fact gathering again.

> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/7bf109bc-d199-4e1e-a62b-3b5d3f8638d2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Brian Coca

[ro...@pandastrike.com]

Very interesting approach/tip. Thanks Brian!