*This is a pseudo name for prominent config management tool Our team of three was formed to figure out exactly how to be “DevOpsy”. The goal was to write applications that we thought added value to the business unit and for our customers, to consume all the latest and greatest products and to give our experience back to customers. Is this everyone’s story in the room? Eventually, we had many web applications and needed to figure out how to get them all deployed. We started with simple shell scripts and some Upstart jobs — it sucked. We used Fabric because it was familiar, and filled in all the gaps weren’t well-solved by mere shell. Along came “Cook”…
for prominent config management tool I took the two-day course and wasn’t able to accomplish anything by the time I was done. Cook made me feel stupid. I knew this was not the way forward.
us to manage their servers: add this user, add this package, configure this vhost, fetch this log file. Some of this is tedious, boring work. Rackspace has many Sys Ads — smart people. Accelerating their work pleases customers and saves money. How do we automate away tedious, repeatable, error-prone work?
script that adds a specific GID, adds a user, then updates the password. Using current tools, this script runs serially and takes about an hour to work on 100 machines.
less) to do the same thing. All were written independently of one another, vary wildly in functionality, offer pretty poor validation, none incorporated testing… ! We need to write fewer shell scripts. So how do we do that?
up all these sessions is wasted; every keystroke is essentially gone, unless we want to scrape shell history files, record sessions, or use some other magical, nonsensical tool. The work isn’t repeatable! This is not the answer!
• Creates a new CLI Ransack is custom Ansible. It’s the paring of custom inventory scripts, to gather information about our customers, with a CLI that is more appropriate for our workflow.
Parallelization • Consistency • Idempotency • Community So let’s talk about why Ansible makes sense for this by talking about some of the features it provides. ! For time, we’re skipping over a lot of the reasons why we chose Ansible. :) !
• Two types • Static • Dynamic What is inventory? It’s “stuff” to be managed. Servers, VMs, containers. We started with inventory because it’s the first logical step to getting Ansible to do work on Rackspace machines. There are two types, static and dynamic, but we’re primarily concerned with getting data at runtime which is all about dynamic inventory.
Ansible commands and playbooks work! Having inventory scripts available means that anyone comfortable with Ansible can go ahead and run any playbook using Rackpsace inventory.
References for use We are deep in code. Ransack uses the Inventory, Runner, and Playbook classes. Basically we hook in at the core of the API, gather inventory from our dynamic inventory scripts, and then instantiate a Runner or Playbook to go out and do the work. The “ansible” command is the reference implementation of the API, though there are some docs to get you started. ! !
for Ansible in order to play nicely with our customer’s SSH configurations, our internal networks. Suppress warnings (like ControlPersist messages) Implement best practices (always SSH, no pipelining, longer timeout) Play nicely with our changes (modules, scripts)
$ ransack-cloud --args ACCOUNT LIMIT MODULE --module-args The API is used so we can provide a “custom” interface that provides reasonable arguments like account information, inventory/limit specs, modules and module args.
self-documenting. Problematic because we had to carefully pick out a subset of modules to wrap argparse around, so that we could document like this. In the future we’ll probably parse module documentation dynamically to make every module (with limited exceptions) available.
\ --password --update-password always Command example adding a user to account 8271 on device 334141. Notice the —as-root flag to keep SysAds from worrying about HOW to escalate privileges.
that would set up a virtualenv, install Ransack. Later this was consolidated into the “super mega installer” to cover OS X, Gentoo, Ubuntu, EL 6, Fedora, Debian, and Arch. This method sucks, primarily because of pyrax dependencies (PBR) dependencies, issues with versions of pip and distribute.
launched on a local machine without the need to install a heavy VM or Hypervisor. This is problematic, however, because Docker usage across our SysAd audience is still pretty low.