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
   

   View Slide

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)
   

   View Slide

3. Bookmarks:
   docs.ansible.com &
   github.com/ansible/ansible
   

   View Slide

4. Quick Audience Poll
   

   View Slide

5. Thesis: Automation Systems Exist To Make
   Up For Linux Not Having A Reasonable API.
   

   View Slide

6. - Phrase Used In Microsoft vs Linux Debates, (c) 2000.
   “You wouldn’t buy a car with the hood welded shut.”
   

   View Slide

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
   

   View Slide

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
   

   View Slide

9. In Case You Haven’t Seen
   Ansible:
   

   View Slide

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
    

    View Slide

11. Module Types
    Typical service, package, file, scm, template, …
    Load balancing
    Cloud provisioning (*)
    Database setup
    

    View Slide

12. Roles
    

    View Slide

13. Role Structure
    

    View Slide

14. Rolling Update (HaProxy/Nagios)
    (also works with cloud/hw load balancers)
    

    View Slide

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
    

    View Slide

16. Other Language Features
    Asychronous operations
    Conditionals
    Loops
    Tags
    Dry Run Mode (—check)
    Vault
    

    View Slide

17. Plugin Points
    Modules - any dynamic language
    Action Plugins
    Filters
    Callbacks
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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!
    

    View Slide