Ruby Deployment
Ezra Zygmuntowicz
http://engineyard.com

Brief History

Webrick

Apache + FastCGI

Lighttpd + FastCGI

Lighttpd + SCGI

Apache + FCGID

Mongrel + Apache

Mongrel + Lighttpd

Lightspeed

Mongrel + Nginx
WIN!

Thin or Ebb + Nginx
WIN!(sometimes)

Passenger(with caveats)

State of the art now:
Passenger for shared
hosting/small VPS
Nginx + Mongrel or Thin
for high volume
production deployments

Woah! That is 10
different options!

Woah! That is 10
different options!
And I rewrote my
deployment book
almost that many
times :(

And it was already out
of date when it
shipped ;)

Rack: the great equalizer

Now with that out of
the way...

Nanite: A world of
services

Nanite is a new way of
building scalable
backends for web apps

Built around RabbitMQ
• Written in erlang, clusterable, highly
scalable, fast as hell.
• AMQP protocol provides many nice
features
• Transient, Persistent and Transactional
semantics

Nanite agents
consist of multiple Actors

Nanite agents advertise
their services and status
Feeds#crawl
advertises:
/feeds/crawl
Load average is advertised
as default status

Nanite Mappers
Track nanites and their advertised services and status
Can do dispatch based on a number of factors
Run inside your Merb or Rails app
State of all nanites is replicated across all mappers

Multiple Dispatch
Styles

Least loaded dispatch
and the fitness function

Agents ping the mapper exchange
every @ping_time seconds.
Mappers track the state of all
nanites and remove them from
mapping if they haven’t reported in
within a timeout

Nanite gives us:
• Presence, we know when nanites are ready
for requests or not.
• Self assembly, nanites can come and go and
can run anywhere with zero configuration
in the mappers.
• Dispatch based on load or any fitness
function that suits your app
• Easily take advantage of cloud

File Streaming

Rack over Nanite

Nanite makes it easy to
scale web app backends
Git it on GitHub:
http://github.com/ezmobius/nanite

EYAAS
Engine Yard As A
Service
Engine Yard
abstracted from
Engine Yard

EYAAS
Engine Yard As A
Service
Clouds are too
low level for
average humans

EYAAS
Engine Yard As A
Service
First Target:
AWS

EYAAS
Engine Yard As A
Service
Next Target:
Your own Servers in
your own DC, any
new cloud computing
platforms that pop up.

Demo

A Different Way of
Thinking

It’s all about the
Automation

1. State Based Configuration
Management
Repeatable
Idempotent

1. State Based Configuration
Management
Treat an instance like a referentially transparent function
f(config) -> Fully Configured Instance
Calling f(config) will *always* create the same instance
whenever config == config

1. State Based Configuration
Management
Treat instances as throw away
Prefer rebuilding from scratch
Only persist what truly needs to be persistent

EYAAS
Custom Gentoo or Ubuntu Linux
State based config management
Ad hoc Change
Extensive Monitoring
24/7 support
High Level Cloud

EYAAS
Bridge multiple providers
Highly tuned databases on EY
Elastic app servers on ec2
Will support any compelling new
cloud platforms

JSON “DNA” describes your deployments. Servers can
be built from bare metal to spec in a few minutes.

Questions?