Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Ansible - Reasons For Creation / Lessons Learne...

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 :)

Michael DeHaan

February 12, 2015
Tweet

More Decks by Michael DeHaan

Other Decks in Technology

Transcript

  1. 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)
  2. - Phrase Used In Microsoft vs Linux Debates, (c) 2000.

    “You wouldn’t buy a car with the hood welded shut.”
  3. 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
  4. 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
  5. 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
  6. Module Types Typical service, package, file, scm, template, … Load

    balancing Cloud provisioning (*) Database setup
  7. 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
  8. 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.
  9. 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.
  10. 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!