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

Ansible - Reasons For Creation / Lessons Learned / Etc

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. 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