Ruby DeploymentEzra 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 agentsconsist of multiple Actors

Nanite agents advertisetheir services and status

Feeds#crawladvertises:/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

Engine Yard abstracted from

Engine Yard

EYAASEngine Yard As A

Service

EYAASEngine Yard As A

Service

Clouds are too low level for

average humans

EYAASEngine Yard As A

Service

First Target:AWS

EYAASEngine 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

Custom Gentoo or Ubuntu LinuxState based config management

Ad hoc ChangeExtensive Monitoring

24/7 supportHigh Level Cloud

EYAAS

Bridge multiple providersHighly tuned databases on EY

Elastic app servers on ec2Will support any compelling new

cloud platforms

EYAAS

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

Questions?