Ansible - Reasons For Creation / Lessons Learned / Etc

This deck is the framework for a theoretical conversation on why configuration management exists, and lessons learned in building a general purpose system that attempts to work "for everyone" and what building that was like (with a bit of intro content in the middle in case people hadn't seen Ansible yet -- hard getting generic talks right!). There's also a bit as to where things might go in the future.

Deck may not make great sense without talk :)

Transcript

1. Text Ansible Michael DeHaan (@laserllama) for Percona University Raleigh, 2015
2. Background Created Cobbler in 2006 (Red Hat) Created Func in 2007, w/ Adrian Likins & Seth Vidal Created Ansible, Feb 2012 (note: no longer with Ansible Inc)
3. Bookmarks: docs.ansible.com & github.com/ansible/ansible
4. Quick Audience Poll
5. Thesis: Automation Systems Exist To Make Up For Linux Not Having A Reasonable API.
6. - Phrase Used In Microsoft vs Linux Debates, (c) 2000. “You wouldn’t buy a car with the hood welded shut.”
7. If Linux was a Car Metric, English, and completely random part sizes Three non-interconnected gas tasks (one is diesel) Comes only partly assembled Must build your own roads Mechanic sneaks into garage at night, randomly replaces parts Tires may be deprecated in next version, says project lead of Tires 1.0 We’d still love it
8. Original Ansible Goals Why were config management and application systems separate? Originally designed to solve multi-tier deployment scenarios, especially cases like load-balanced rolling updates, and make configuration management systems less painful. Manage systems over SSH (no DNS, NTP, cert, CVE, etc, fun) Push based by default for greater n-tier control, but support pull modes. Maximally readable by users who have never seen it Be declarative or imperative as needed (states AND processes). Remove as much in-penetrable techno-babble from the genre as possible
9. In Case You Haven’t Seen Ansible:
10. Inventory Groups/Hosts/Variables Can source from: Text files AWS / Rackspace / GCP / other public cloud OpenStack / VMWare / other private cloud Any CMDB Any script that can return JSON
11. Module Types Typical service, package, file, scm, template, … Load balancing Cloud provisioning (*) Database setup
12. Roles
13. Role Structure
14. Rolling Update (HaProxy/Nagios) (also works with cloud/hw load balancers)
15. Containers, Anyone? Have docker image mapped Port 8000 to (old port) 80 Deploy new docker image 8000 to 81 Reconfigure load balancer to point to 81 Drop old Docker image Jesse Keating: https://www.youtube.com/watch?v=Mqo9_yTrHeQ
16. Other Language Features Asychronous operations Conditionals Loops Tags Dry Run Mode (—check) Vault
17. Plugin Points Modules - any dynamic language Action Plugins Filters Callbacks
18. Lessons Learned Mostly related to early development choices that we sorted out later… Shortcut of skipping type/provider type abstraction (see Puppet) in the beginning saved a lot of time, but would have been nice to have to ensure consistency. Worked out ok, but very hard to add later. While modules were super powerful, bring in less modules into the core system (245 = too many). GREAT for adoption and they keep up, but spend lots of time on maintaining. (Example: cloud). It’s very hard to get quality sample content in any community site (see Puppet Forge, Chef Cookbooks, Galaxy, etc). Devs/Admins/Ops still need better ways to make things reusable and that paradigm is not golden images or very specialized repos. Have had started with Jinja2 templates and eliminated in the in-house ${foo} and conditionals that Jinja2 finally replaced about a year later. Jinja2 still causes enough user questions. Slow down optimizations for early OSS contributions and focus more on core code design, which is ok, but not super malleable. I love architecture but the project pace at times could crush that. Current ‘v2’ tree effort intended to be a strong refactor.
19. Where’s The Future? All efforts at better automation are good. Immutable Systems methods, containerization and PaaS seek alternatives to config tools, but I’m not 100% happy with them yet. Classic automation wishes there were better ways too, but is doing things for what need to be done to glue Linux together. As such, it’s not going anywhere soon! Many people don’t want to change, or can’t change, the way they write apps. Often it’s strategic to have choice. CM is a necessary evil, serving purposes of good, because there are too many things to glue together. It feels rough sometimes because Linux is rough, and things bubble up. The good automation serves is that of buying time for other things as well as reducing human error from manual or forgotten steps. In many cases, we’re still very explicitly pushing bits, and looking for higher level abstractions.
20. The End Learn Ansible: http://docs.ansible.com, or something other system, but learn something :) Contact info: michael.dehaan on gmail, @laserllama on twitter Questions? / Thanks!