If you found this article and are expecting a post about the Matrix Blue/Red pill analogy combined with a fairytale animal then I’m afraid you’re on the wrong page. If however, you’re interested in a fast, kick-ass Ruby on rails environment then you ARE in the right place.
Getting a stable, Ruby on Rails app running in a production environment can often be tricky. Sometimes there’s different Ruby versions installed, different users might have different gem paths, environment variables need to be set, RVM needs to be considered, unicorn, nginx, apache- sometimes it’s a complete and utter mess.
That’s why my advice is simple. Keep it simple. With Halftone, the only Rails application on the server is Halftone. We don’t share resources with any other application. Since I started from scratch on a clean server, our rails app has the bare minimum needed to run. Only one Ruby version, one repository of gems, one HTTP server and one process monitoring software.
I cannot stress this enough, keep your app’s system requirements simple and isolated.
Below I’m going to run through the software I use to keep things dandy at Halftoneapp.
Bluepill
Bluepill is a process monitoring engine written in Ruby.
We love Ruby here at Halftone so it was hard to pass up working with configuration files which accept Ruby code. Bluepill monitors our Unicorn process, if it runs amuck and starts chewing up valuable memory or CPU usage – we send a QUIT signal which starts a graceful shutdown, allowing Unicorn to finish. Unicorn will then spawn a new worker process to make up for the dead unicorn, as sad as that sounds.
We did start out using GOD, however recently switched to Bluepill due to its ability to monitor child processes such as those spawned by Unicorn.
How did we install it?
gem install bluepill
sudo mkdir /var/bluepill (Bluepill requires this folder as per it's docs)
sudo chown appuser.appuser /var/bluepill
How do we run it?
First you’ll need a configuration file. We’ve uploaded a version of the Bluepill config we use, though modified slightly with extended comments. You can find it here.
DON’T FREAK OUT. Yes, the configuration file linked above is lengthy but don’t be scared – take some time to read it all and become familiar with the settings.
We run Bluepill as a local user, the same user that runs our Rails application.
To start Bluepill run
[bash]bluepill load /path/to/unicorn.pill –no-privileged[/bash]
This starts Bluepill and should start Unicorn. Run ps -aux to see if all looks swell. Keep an eye on the Bluepill log to debug any problems you may encounter.
Visit Bluepill for more details.
Note! Because we’ve started Bluepill with the no-privileged mode, you’ll need to specify this everytime you interact with it.
For example;
[bash]bluepill stop unicorn –no-privileged[/bash]
[bash]bluepill start unicorn –no-privileged[/bash]
In order to take advantage of syslog logging, you’ll need to follow the instructions in the Bluepill README on how to setup syslogd.
UNICORN
Straight from the homepage; “Unicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels”.
Or in simple terms, Unicorn gets in, serves the request and then gets the heck outta there. Unicorn does not implement persistent connections which can often leave client connections idle; holding up valuable worker processes. All our intensive, lengthy processes are handled by Resque; a background job processor (we’ll talk about that in a separate post).
“Unicorns don’t care if you believe in them any more than you care if they believe in you”
How did we install it?
gem install unicorn
Visit the Unicorn website for more details.
What about our config file?
There’s not much to Unicorn. Simply point it to your Rails app, set the number of worker processes you’d like and away you go. See here for a sample unicorn config.
How do you run it?
If you’re using Bluepill to manage Unicorn, you’ll see how we start Unicorn in the config file. Otherwise you can launch Unicorn manually using the following.
[bash]/path/to/unicorn_rails -Dc unicorn.conf.rb -E production[/bash]
Nginx
We use Nginx to reverse proxy HTTP requests to Unicorn.
A request comes in for halftoneapp.com/blah and Nginx sends this to Unicorn via a unix socket.
How did we install it?
On Debian –
We added the following to the Nginx configuration file.
[bash]
server {
server_name yourdomain.com;
root /home/yourappuser/app/current/public;
try_files /system/maintenance.html $uri $uri/index.html @app;
location @app {
proxy_pass http://unix:/home/yourappuser/app/shared/sockets/yourappuser.sock;
}
error_page 404 400 500 502 /error.html;
location = /error.html {
root /var/www;
}
}
[/bash]
The important part is lining up the proxy_pass option to the same socket you’ve specified in the Listen option in the Unicorn configuration file.
Parting lines
I hope this helps you in your quest for the ultimate Ruby on Rails environment. If you have any questions or if something I’ve said is incorrect (we are human after all), feel free to leave a comment below.
