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

The Assembly Line

The Assembly Line

A presentation about Ansible at Austin DevOps
September 8, 2014

Avatar for Luke Sneeringer

Luke Sneeringer

September 08, 2014
Tweet

More Decks by Luke Sneeringer

Other Decks in Technology

Transcript

  1. Us, in 30 seconds. • Formerly of FeedMagnet
 (which is

    what we'll primarily be discussing) • Software (Luke) & Systems (Jon) • Still fascinated by these...
  2. Horizontal Scaling • FeedMagnet ran on an entirely horizontally- scaled

    topology[citation needed]. • One system (comprising multiple servers) per customer. 100 customers. • How do we actually manage this in real life?
  3. Development • Home-built development environments are evil. • (...on existing,

    non-trivial systems) • Development should match production. • (...usually) • Development environments should be inexpensive and convenient.
  4. Apologia for DevOps • DevOps proposes solutions for these problems:

    • How do we have multiple machines in a reasonably consistent state? • How do we manage configuration and migration of machines in bulk? • How do we document our system topology?
 (sort of)
  5. Our Story • Began implementing Chef in 2010. • Spoiler

    Alert: Began moving to Ansible in 2013. • Only implemented production cookbooks; no concept of using devops code for development
 (Vagrant didn't exist yet). • Production servers hosted on Rackspace.
  6. Our Goals ✓ Consistent production servers ✓ Limited tunability of

    certain aspects of servers
 ("small", "medium", etc.) ✓ Easy sysadmin provisioning - Support for development - Reusability - Easy client services provisioning
  7. The Migration • Decided to migrate to Ansible for new

    product in September 2013. • Migrated existing Chef recipes to Ansible roles (with some structure changes) in under a week. • Ansible playbooks and roles also supported local development (with Vagrant).
  8. Our Goals ✓ Consistent production servers ✓ Limited tunability of

    certain aspects of servers
 ("small", "medium", etc.) ✓ Easy sysadmin provisioning ✓ Support for development ✓ Reusability - Easy client services provisioning
  9. Ansible • An Ansible list of "stuff to do" is

    called a playbook. • Reusable pieces within playbooks are called roles. • Playbooks and roles are both defined as structured collections of YAML files.
  10. Agent v. Agentless • The Chef model and Ansible model

    for executing an action on a server are entirely different. • Chef uses an agent (chef-client) installed on the server. • Ansible is agentless.
  11. Agent v. Agentless • Exactly opposite model of performing work:

    • In Chef, a client asks a server what to do, then does it. Actions are tied to the single client machine. • In Ansible, the machine running the playbook connects to the clients and does stuff.
  12. Advantages to Agentless • No need to install the agent

    before orchestrating a server. • Ability to have a playbook interact with server topology as a whole. • Security.
  13. Language Agnosticism • Chef is written in Ruby; Ansible is

    written in Python. • Chef uses a Ruby DSL for cookbooks. • Ansible uses YAML for playbooks.
  14. Language Agnosticism • Chef resources are written in Ruby. •

    Ansible modules can be written in any language. • Executable file; must return valid JSON. • Caveat: All code accepted into Ansible itself must be in Python.
  15. Idempotency • Both Chef resources and Ansible modules are idempotent.

    • ...with minimal exceptions, e.g. shell. • Ansible is very thoroughly idempotent: • linguistics ("state: present", not "action: create") • output
  16. Idempotency • Best practice in Ansible playbooks:
 Subsequent run should

    show no changes. • Not always possible, but usually is; key difficult modules like shell have tools to determine whether to perform actions. • When in doubt, custom modules can handle more complex idempotency situations.
  17. Orchestrate Anywhere • Chef is built around the notion of

    uploading cookbooks to a Chef server
 (knife cookbook upload). • The client-initiated model of Chef requires this (the client must have a way to know where to get the right marching orders from). • Easy to get into confusing situations, and adds hurdles for testing cookbooks.
  18. Orchestrate Anywhere • Ansible is orchestrator-initiated, and doesn't have this

    restriction. At all. • Any machine with Ansible installed and appropriate transport (SSH) credentials can do things. • No need for a second store for code, version control that isn't really version control, etc.