Provisioning AWS with ansible <our story>

different approaches to provisioning AWS with ansible

Transcript

1. Provisioning AWS with Ansible <Our story>
2. Husband and a Father Operations guy @informatiq Ramez Hanna
3. Ops Lead @ goocreate.com The only artist-friendly HTML5 & WebGL production tool We’re hiring goocreate.com/jobs/
4. This is Work In Progress we are still looking into what is most optimum
5. The Goal code -> build -> stage -> test -> prod We have that already...YAY
6. The Goal Errrr, what about feature branches? And… When did you provision this prod?
7. The Goal Parallel cycles [provision] -> code -> build -> stage -> deploy provision -> code -> build -> stage -> merge
8. The Goal How about variations of the product...
9. Let’s take a step back • we need to be able to recreate prod. • we need to be able to alter production • we need to be able to create multiple clones for feature branches • we need to automate as much as possible • we need to keep the wheels turning while we figure out what we will do Specs
10. Where we started with all the bling of a point and click
11. What is wrong with that? If I have to explain it, I’m definitely in the wrong place
12. Where do we start? Of course from the tools AWS provides
13. Cloudformation • Whole infrastructure described in one file • single command to provision / tear down • WOW
14. What is wrong with that? • Our template is huge ( > 500k ) • We needed to pass lots of variables because we used the same template to launch multiple parallel envs • debugging the template was not easy
15. Using jinja and boto in house python code, consumes jinja templated cloudfromation file and produces a cloudformation stack
16. What is wrong with that? • own code needs to be maintained, and continuously implement features • boto is not super intuitive, at least to me • smaller template but still...
17. Enter Ansible Our chosen tool for automation and configuration management
18. Template + Cloudfromation • no more messing with boto • all info (facts) of the new env are immediately available for rest of ansible
19. Snapshot provisioning new stack with buildbot
20. What is wrong with that? • inherits the problems from the cloudformation approach (next slide)
21. Limitations of cloudformation • our infra is still young and changes a lot • updating a stack can be tricky • upgrading OS for an instance involves updating the stack • updating stacks is not nice As we are continuously modifying the infra, cloudformation is not flexible enough
22. Areas of improvements • simplify the stack a little • split the cloudformation into multiple ones
23. Ansible AWS modules • ec2_vpc • ec2 • ec2_group • ec2_asg • ec2_elb • ec2_vol • route53 • etc...
24. • flexible • granular • better readability • updating “stack” is easy • Configure stack So • easily upgrade (replace) instances • extend the infra more easily • better integration with CI/CD cycles
25. What is wrong with that? • it seems easier now to write json :) • teardown is not as easy as in CF • transitioning will not be easy
26. Mix CF with ansible modules CF to create the less changing resources VPC, subnets, route tables Ansible create Instances, SG, ELB, RDS Ansible reconfigure everything Hybrid
27. As I said earlier It’s a work in progress
28. Ansible can orchestrate any other tool, even with the basic command module Hence you can mix and match ansible modules with any other technology Tools should be piped together Others
29. The Goal Provisioning is part of our cycle Infrastructure changes as your product changes and it should be integrated with your CI/CD Ansible helps orchestrate the whole cycle at Goo including the provisioning cycle
30. Thank you