Ruby Deployment


Published on

1 Comment
  • Ezra gave this talk at the Addison Wesley conference:
    Voices That Matter: Professional Ruby Conference, in Boston. And folks were blown away.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Ruby Deployment

  1. 1. Ruby Deployment Ezra Zygmuntowicz
  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:
  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?