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 de...
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 ...
Nanite agents
consist of multiple Actors
Nanite agents advertise
their services and status
      Feeds#crawl
       advertises:
      /feeds/crawl
Load average is ...
Nanite Mappers
Track nanites and their advertised services and status


   Can do dispatch based on a number of factors

 ...
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...
Nanite gives us:
• Presence, we know when nanites are ready
  for requests or not.
• Self assembly, nanites can come and g...
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
plat...
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

         ...
1. State Based Configuration
         Management
        Treat instances as throw away

        Prefer rebuilding from scra...
EYAAS
Custom Gentoo or Ubuntu Linux
 State based config management
         Ad hoc Change
      Extensive Monitoring
      ...
EYAAS

   Bridge multiple providers
 Highly tuned databases on EY
   Elastic app servers on ec2
Will support any compellin...
JSON “DNA” describes your deployments. Servers can
  be built from bare metal to spec in a few minutes.
Questions?
Ruby Deployment
Ruby Deployment
Ruby Deployment
Ruby Deployment
Upcoming SlideShare
Loading in...5
×

Ruby Deployment

8,283

Published on

1 Comment
13 Likes
Statistics
Notes
  • Ezra gave this talk at the Addison Wesley conference:
    Voices That Matter: Professional Ruby Conference, in Boston. And folks were blown away.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
8,283
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
168
Comments
1
Likes
13
Embeds 0
No embeds

No notes for slide

Ruby Deployment

  1. 1. Ruby Deployment Ezra Zygmuntowicz http://engineyard.com
  2. 2. Brief History
  3. 3. Webrick
  4. 4. Apache + FastCGI
  5. 5. Lighttpd + FastCGI
  6. 6. Lighttpd + SCGI
  7. 7. Apache + FCGID
  8. 8. Mongrel + Apache
  9. 9. Mongrel + Lighttpd
  10. 10. Lightspeed
  11. 11. Mongrel + Nginx WIN!
  12. 12. Thin or Ebb + Nginx WIN!(sometimes)
  13. 13. Passenger(with caveats)
  14. 14. State of the art now: Passenger for shared hosting/small VPS Nginx + Mongrel or Thin for high volume production deployments
  15. 15. Woah! That is 10 different options!
  16. 16. Woah! That is 10 different options! And I rewrote my deployment book almost that many times :(
  17. 17. And it was already out of date when it shipped ;)
  18. 18. Rack: the great equalizer
  19. 19. Now with that out of the way...
  20. 20. Nanite: A world of services
  21. 21. Nanite is a new way of building scalable backends for web apps
  22. 22. Built around RabbitMQ • Written in erlang, clusterable, highly scalable, fast as hell. • AMQP protocol provides many nice features • Transient, Persistent and Transactional semantics
  23. 23. Nanite agents consist of multiple Actors
  24. 24. Nanite agents advertise their services and status Feeds#crawl advertises: /feeds/crawl Load average is advertised as default status
  25. 25. 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
  26. 26. Multiple Dispatch Styles
  27. 27. Least loaded dispatch and the fitness function
  28. 28. 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
  29. 29. 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
  30. 30. File Streaming
  31. 31. Rack over Nanite
  32. 32. Nanite makes it easy to scale web app backends Git it on GitHub: http://github.com/ezmobius/nanite
  33. 33. EYAAS Engine Yard As A Service Engine Yard abstracted from Engine Yard
  34. 34. EYAAS Engine Yard As A Service Clouds are too low level for average humans
  35. 35. EYAAS Engine Yard As A Service First Target: AWS
  36. 36. EYAAS Engine Yard As A Service Next Target: Your own Servers in your own DC, any new cloud computing platforms that pop up.
  37. 37. Demo
  38. 38. A Different Way of Thinking
  39. 39. It’s all about the Automation
  40. 40. 1. State Based Configuration Management Repeatable Idempotent
  41. 41. 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
  42. 42. 1. State Based Configuration Management Treat instances as throw away Prefer rebuilding from scratch Only persist what truly needs to be persistent
  43. 43. EYAAS Custom Gentoo or Ubuntu Linux State based config management Ad hoc Change Extensive Monitoring 24/7 support High Level Cloud
  44. 44. EYAAS Bridge multiple providers Highly tuned databases on EY Elastic app servers on ec2 Will support any compelling new cloud platforms
  45. 45. JSON “DNA” describes your deployments. Servers can be built from bare metal to spec in a few minutes.
  46. 46. Questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×