Sep 2, 2008 was the Tutorials Day @ Rails Conf Europe. I attended Renegade’s Guide to Hacking Rails Internals (partly) and Deploying and Monitoring Ruby on Rails. The first session did exactly what it says – explained the complete internals, digging deep into the code and how to hack them to meet your needs. I thoroughly enjoyed the second tutorial as it covered the deployment in detail and somewhat monitoring. The first part covered the common Application Server and Web/Proxy Servers used for Rails deployment. It explained the different deployment scenarios and their pros/cons. The Application Servers (along with their detailed notes) are: FastCGI Use mod_fcgi Proxy local and remove FastCGI instances Oldest way of deploying Rails Deprecated & Unstable (security problems in impl of Apache2, easy to get zombie processes, works for some) Hard to debug Dont’ use in production Mongrel As an alternative to FastCGI Complete HTTP-server that can load arbitrary Ruby-servlets Built-in Rails support Utility to manage several Mongrel clusters (mongrel_cluster) Very robust, strict HTTP parser, easy to debug Defacto standard deployment with Apache 2.2 and mod_proxy_balancer Can be a bit difficult to setup Not so easy on mass/virtual hosting mod_rails (aka Phusion Passenger) Similar to mod_php Fairly new module of Apache 2.2 Allows Apache to control Rails instances Apache starts/stop app instance depending on the app load Very easy to setup Able to run any RACK-compatible Ruby app Pros Touching a file “restart.txt” and Phusion automatically restarts all the Rails instances All Rails instances are local to a machine HTTP balancer is required to spawn across multiple machines Fairly new but ready for production Makes setup easier – on single machine Multiple server still require load balancer Suitable for mass hosting JRuby, GlassFish & Co Similar to mod_rails where multiple runtimes can run on a single machine WAR-based deployments Suitable for Java shops Database connection pooling I’ll be talking all about Rails and GlassFish in my session tomorrow @ 1:40pm Here are the requirements on Proxy servers: Hide cluster backend from the user Load-balancer backend instances Recognize down hosts Fair scheduler And the different choices (along with their notes) are: Apache2 Introduced mod_proxy_balancer Can speak to multiple backends and balance requests Can act as pure proxy or can also serve static files Deliver static content Pros Very old, mature, stable Many people know how to work with Apache Integrates well with other modules (SVN, DAV, etc) Cons Can be complicated to configure The stock Apache is quite resource-hungry (12-15 KB, where nginx takes 3-5 KB and 20% faster serving of static files) compared to pure proxy solutions nginx Popular Russian web server with good proxy support (40% websites in Russia run nginx) Can load-balance multiple backends and deliver static content Quite popular with Mongrel as Rails backend Simple configuration file – https://brainspl.at/nginx.conf.txt (nginx conf file) Pros Stable, Robust, Fast Use fewer resources (CPU & RAM) than Apache proxy-mode & static files Simple configuration file Can directly talk to memcached – SSI Cons More documentation would be nice No equivalent for many Apache modules LightTPD Lightweight and Fast web server Balancing proxy server Good FastCGI support Used to be popular – until Mongrel came around Nobody is using these days in production Pros Fast & lightweight User fewer resources Simpler configuration file Cons Unstable for some people Slow development cycle More docs would be nice HA-Proxy (also applies to Pen and Pound) Reliable, High performance TCP/HTTP-level balancer (SNMP or MySQL proxying too) Proxying and content inspection No content serving, just a proxy Pros Mature, stable & fast TCP & HTTP Balancing Cons Few Rails examples Usually not needed in Rails setup After discussing all the options in detail, the recommendations were: Small site – Apache 2.2 with mod_rails Medium site – Apache 2.2 as front-end proxy + Mongrel or mod_rails as backend, Deliver static files with Apache.Not nginx because it does not depend on the extra power to deliver static files. Large Rails site – Redundant load-balancer, redundant proxy/web, Mongrel/mod_rails Heavy static files – Dynamic requests to Apache+mod_rails, static files nginx/lighttpd Java Shop – WAR fles + integrate with existing Java landscape and infrastructure Then it explained Capistrano, Webistrano, Macistrano and ran through a practical lab of using them. The tutorial concluded by discussing monitoring. The two criteria for monitoring are: Is it still running ? What are the trends ? The two main recommendations are: Monit Process-level monitoring Checks PID-files, ports and perms Reacts by executing a script and/or alerting Munin Host level monitoring tool Master periodically ask nodes for local data Check system resources and records historical data Allows to recognize trends and make predictions Alerting support And other tools that were mentioned as well such as Nagios, Big Brother, New Relic RPM, FiveRuns and JMX. The slides will be published on Rails Conf website so watch this space. The evening concluded with Q&A from Rails Core Members – DHH, Koz & Jeremy. Here are some of the sessions I plan to attend tomorrow: Welcome (9:00) Morning Keynote (9:15) JRuby: The Other Red Meat (10:45) Rails Software Metrics (11:35) Achieving High Throughput and Scalability with JRuby on Rails (13:40) Rubinius 1.0 (14:30) Security on Rails (15:20) And then there is exhibitor hall as well so will see how much I can attend 🙂 I have to miss the late afternoon and evening sessions/BoFs because of Berlin/Brandenberger JUG preso. Here are some pictures from yesterday: And finally the complete photo album so far: The sessions/exhibit halls start today! Technorati: conf railsconf berlin rubyonrails Ruby