Automating an AWS Complex Infrastructure With Ansible: Lessons learned

From template tricks to major caveats, I will share my experiences migrating a complex AWS infrastructure from a semi manual configuration (WebUI+boto scripts) to a fully automated one via Ansible.
Related code and more here

https://github.com/jaimegago/ansible-bay-area-meetup/tree/master/automate_public_cloud_07_16_14

Transcript

1. Automating an AWS complex infrastructure via Ansible Lessons learned Jaime Gago @JaimeGagoTech
2. Automating the Public Cloud Layer
3. Background Story Migrating AWS to VPC • Complex architecture (route53, ELBs, ASGs, EC2 Types, Sec Groups, multiple regions and AZ, EIPs, EC2 User data leveraged in downstream automation,...) • Mainly Web UI (some automation via Boto scripts and AWS CLI) • Puppet Shop (application + OS layer) • Army of 2 (Systems Engineers)
4. Why Ansible ? • Cloud Formation limits • KISS/Learning Curve • Cloud modules (20+ AWS) • FOSS
5. Engineering Process Ansible Playbooks AWS Account keys in Shell Environment Ansible Head Ansible Patched Modules AWS Account keys in Shell Environment boto
6. I’ll just change this one line… http://devopsreactions.tumblr.com/post/84505783088/ill-just-change-this-one-line
7. Safeguards • Test AWS account + S3 trick (always_run: true) • --check --diff (not very effective in my use case) • --list-tasks --tags
8. Ansible Data Structure • All vars define in one file (group vars) • 1 playbook per “service” • 1 “Network” + 1 “Security group” playbook per region • Tasks are tagged with region + purpose • Playbook of playbooks
9. Network playbook
10. Security Playbook
11. Service playbook
12. Future • Connect Ansible data with Puppet (e.g. service ports) • More Safeguards (e.g. disable runs that with changing tasks > x%) • Automated Tests (Continuous Delivery Style)