The Assembly Line

A presentation about Ansible at Austin DevOps
September 8, 2014

Transcript

1. The Assembly Line (but paying more than $5/day) Luke Sneeringer Ansible, Inc. luke@sneeringer.com Jonathan Chappell Bazaarvoice jon@jchome.us
2. Us, in 30 seconds. • Formerly of FeedMagnet
 (which is what we'll primarily be discussing) • Software (Luke) & Systems (Jon) • Still fascinated by these...
3. The Problem
4. 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?
5. Development • Home-built development environments are evil. • (...on existing, non-trivial systems) • Development should match production. • (...usually) • Development environments should be inexpensive and convenient.
6. The First Pass
7. 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)
8. 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.
9. 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
10. The Migration
11. 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).
12. 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
13. Brief Introduction
 to Ansible
14. 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.
18. Observations
19. 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.
20. 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.
21. 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.
22. Language Agnosticism • Chef is written in Ruby; Ansible is written in Python. • Chef uses a Ruby DSL for cookbooks. • Ansible uses YAML for playbooks.
23. 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.
24. 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
25. 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.
26. 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.
27. 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.
28. Conclusion
29. Questions?