My name is Seth Chisamore.
Former IBMer, former FIMer currently I'm principal architect for MaxMedia an interactive agency in Atlanta, GA. I create rich internet and web applications using open source technology. I love my wife, our triplets and independent music.


Vital Stuff:
=> Resume
=> Github / schisamo
=> Twitter / schisamo
=> FriendFeed / schisamo
=> Del.icio.us / schisamo
=> Flickr / schisamo
=> Facebook / schisamo
=> Linkedin / schisamo
=> Last.fm / schisamo
=> Vimeo / schisamo


Powered by:
=> The Rackspace Cloud
=> Tumblr
=> Coffee

Twitter Updates

posted on twitter. click to follow me »
14 07 10

Scoble Interview: Opscode + MaxMedia

Not long ago John Willis (VP of services at Opscode) and I gave a quick interview with Robert Scoble discussing how my company, MaxMedia, has leveraged Opscode Chef and the Rackspace Cloud to scale our small development team and save money. Figure the video can speak for itself:

19 02 10

ATLRUG Chef Presentation

Last week I gave a presentation to the Atlanta Ruby User’s Group discussing Maxmedia’s use of Opscode Chef (and the Opscode Platform) for managing our Rackspace Cloud infrastructure. The presentation was titled “Scaling People: The 5 Ws of Chef @ MaxMedia” and talks about how Chef not only helps scale one’s infrastructure but can also help scale a small team of people:

Lucky for all of you my ugly mug never appears on camera but…you still have to listen to my voice! If you live in Atlanta and are even remotely interested in Ruby I highly recommend making the monthly ATLRUG meetings….if for nothing else come for the free pizza!

04 02 10

Nodes 2 Hosts

As MaxMedia’s virtualized infrastructure grows, I’ve found myself tiring of looking up IP addresses every time I need to SSH into a box. Deciding it was time to work smarter, I threw together a quick ruby script that will generate a local hosts file that maps a nodes ip address to it’s fully qualified domain name (fqdn). This task was a piece of cake with Knife (Chef’s command-line utility), the Chef server search index, and a little ruby-foo:

#!/usr/bin/env ruby
require ‘rubygems’
require ‘json’
require ‘chef’
 
hosts = ”# Host File generated from Chef Search on #{Time.now}\n
# perform search via knife and loop through results
JSON.parse(%x(knife list_nodes)).each do |n|
  # parse result as Chef::Node..uses the result json_type
  node = JSON.parse(%x(knife show_node —node=#{n}))
  # extract ipaddress and fqdn
  hosts « #{node.ipaddress}\t\t#{node.fqdn}\n
end
# append our localhost info
hosts « “127.0.0.1\t\tlocalhost
255.255.255.255\t\tbroadcasthost
::1\t\t\tlocalhost
fe80::1%lo0\t\tlocalhost\n
puts hosts

Just paste the output into your Mac’s /etc/hosts file and your ready to roll.

16 01 10

Cooking with Opscode Chef

My company, MaxMedia, has been in the process of moving our traditional co-located hosting to a virtualized cloud-based platform (we chose the Rackspace Cloud). It’s been great way for a small interactive agency to save some money and reinvest it in neat toys like the 16 TB ZFS JBOD we built for our motion team! The tool we have chosen to manage all of this is virtualization is Opscode Chef.

Chef is a state-based, configuration management tool written entirely in Ruby. It is scalable and completely open-source. The 37 Signal’s team describes it as “Rails for sysadmins”! With Chef you don’t write scripts to configure your infrastructure you write code that programs it. Chef builds on the following core concepts:

  • Nodes - these are the actual servers you want to configure. Chef performs all work down on the nodes…this makes scaling Chef to large multi-thousand node deployments easy. A node has a list of recipes and a bag of attributes (both discussed below).
  • Recipes - represent a declarative description of how you want part of a node to be configured. They are written in an easy to understand Ruby DSL and allow you to drop into regular Ruby anytime you want. These recipes describe a series of resources that should be in a particular state - for example, packages that should be installed, services that should be running, or files that should be written.
  • Cookbooks - Recipes (along with templates and attributes) are grouped together into Cookbooks. They should be as generic as possible and work across many different nodes and platforms (ie Ubuntu and CentOS). A cookbook is also the Chef unit of distribution, shared among the community, that live in a central Git repository.
  • Attributes - used to differentiate the same cookbook on two different nodes. The attributes in a cookbook represent a set of sane default values for “tunable” settings which are then overridden by a node or role. Attributes also persist between Chef runs.
  • Roles - roles represent a higher level of functionality…something like an application server or a database server. A role may contain multiple cookbooks and be applied across multiple nodes.

Being a developer turned infrastructure architect, it’s been nice to write familiar Ruby code that describes every aspect of our infrastructure. This Chef code also acts as documentation for that infrastructure, which can be rebuilt at any point in time. This has opened up some amazing possibilities: think about redeploying data centers or changing cloud providers in minutes…not weeks.

In the spirit of the growing Chef community I’ve also written a few Chef cookbooks which are free for everyone to use:

  • MongoDB - installs and configures MongoDb on a node.
  • Scout Agent - installs the Scout Agent gem and schedules it to run via Cron.
Fork them and add support for RHEL/CentOS (we’re an Ubuntu shop!) or some other platform!