This is the first part of a step-by-step case study as I walk through the technical issues surrounding setting up a production server for a rails app, and deploying it in a manageable way. I’m a programmer, not a system administrator, but the rapidly changing requirements for best-practices rails deployment seem to have created a need for specialist knowledge that neither sysadmins, or programmers, always have.

So, this is a guide written for programmers, with only a very basic knowledge of how to get around on a linux box. I’m going to talk about the reasons for my decisions, as well as just what shell commands I executed, and I’m going to dedicate each installment of this series of posts to one solid and fully working step on the path to having your dream app out there in the wild and running smoothly.

Arranging Hosting

Life Used to be Simple (with Shared Hosting)

If you’ve worked on PHP or Perl web sites, then like me you’ve probably used a lot of shared hosting. Shared hosting is cheap, because the hosting company doesn’t really have to tell you how many sites are on the same machine, providing that many of them don’t take up many resources. With static HTML, or even PHP and Perl, shared hosting actually works pretty well. You can’t guarantee uptime, or do anything really wacky, but it’s a great way to get your code out there without needing to know anything about administering a server.

Unfortunately, this approach doesn’t get you quite as far with rails. The problem is, most shared hosting is apache based, and rails just doesn’t run too well with Apache and fastcgi. Having said that, that’s the exact method used to host this blog, so clearly it’s not to be ruled out entirely.

All the Cool Kids Have Mongrels

At some point, however, you want a bit more speed and reliability. For me, it was because I wanted to release a new web application, and although I didn’t expect massive interest, I didn’t want to deal with scaling issues in the first few months.

Mongrel looks like the go. It’s the current darling of the rails crowd. It’s designed specifically to run rails, and “they” say that it does so very fast for quite a few major production applications. Also, it’s the same server that we generally use in development, and that helps me feel confident that I know how it’s going to perform.

Obviously I’ll be going into mongrel in more detail later, but the point to consider now is that suddenly we talking about running a fairly non-standard and long running process. We’re entering the area of managing our own server here, and that means no more shared hosting. Our application isn’t the next flickr just yet, so we can’t afford a dedicated machine, so the solution is a VPS.

VPS Hosting Options

A Virtual Private Server feels like using a whole machine, but obviously it’s only allocated a finite slice of the hardware resources. There are heaps of providers offering VPS hosting out there. There are a very select few, who actually know how to do the rails deployment thing, and will manage it for you (such as RailsMachine, and RailsPlayground). This is a pretty good option for many, although it will cost you about four or five times the price of doing it yourself. Still your time is worth money, so it might be worth leaving to the experts.

But, we haven’t done that have we. Otherwise I wouldn’t have written this guide, and you wouldn’t be reading it. So lets presume that you’re going to go ahead and buy a cheap bare bones VPS hosting package, and do the rest yourself. I went with slicehost.com. They’re dirt cheap, at US$20 per month for a VPS with 256 Mb of RAM. The also provide really simple tools for upgrading your account, re-creating your VPS, and picking your OS.

Of their choice of operating systems, I’ve picked Ubuntu Linux, Dapper (the latest major release). I don’t care for any arguments about which linux distros are the best, but my only linux knowledge comes from using it on the desktop, so I’m moderately familiar with Ubuntu. Also, it’s common enough that there is ubuntu specific information on the net about ruby on rails.

Our Shiny New VPS

We now have our very own operating system running in relative isolation on a machine humming away in a data-center somewhere. In the case of slice host, that machine is in Texas somewhere (which is the opposite side of the planet from me).

We’re going to approach our setup tasks in programmer oriented fashion. Slowly, carefully, and with an eye to how to automate things (because we’re essentially lazy people, so automation is our friend). With slice host, the first thing that you get is the root password, and they only display it once for you, so you need to write it down quickly, so that you can log in, and change it.

Although these setup instructions wont be specific to Slice Host, some of them will be specific to Ubuntu Dapper. In particular, Ubuntu on slicehost is initially setup with very little software installed. This is a common approach, and a good one, so hopefully we’ll only install things that we understand well enough to administer properly.

Getting Access

Changing the Root Password

At the moment, we have a root username and password, and it’s also a password that’s been transmitted across the web, so we really should change it. We also know that we want to do most of our work on the site as a non-root user. We’ll try and follow the philosophy of allowing the least access to the system needed, both for security reasons, and also to help prevent our own silly mistakes.

We were given a static IP address for our VPS. I’m going to use the string IP_ADDRESS in this text, and you can replace that with your servers IP address in any commands that I specify. We don’t have a domain name to use yet, so we’ll be using the IP by itself for a little while.

So, let’s log in:

    ssh root@IP_ADDRESS

First, we’re going to change that root password. Type the command “passwd”. It will ask for for a new password (twice), and then it will be set. You don’t need to use this password often, so don’t pick something simple that you use everyone else. Use a good solid password.

Creating a Non-Root User

Ok, we need a user that isn’t root. This is you, on the machine. You will want to use a username that makes sense to you, it also helps if it’s the same username as your local machine (if you use a *nix machine), since that saves you having to type it. I’ll refer to your username as YOUR_USER.

    adduser YOUR_USER
    su YOUR_USER
    passwd
    exit

What we did there was create the new user, then change to the new user using the “su” command, and change our password. Typing “exit” leaves us as root again.

Coming Up Next

We’ll go over using ssh keys to protect your login, and then installing ruby and rails and other required software on the new server.