Taming the Wild Blue Ether

Ready to get our app onto that Rackspace Cloud Server? Me too; let’s do it!

Install

First, on our Mac, we need to install Capistrano, which will deploy our app for us once we have it set up. It’s a Ruby gem. Do the following to get it:

sudo gem sources -a http://gems.github.com/
sudo gem install capistrano

Capify

Now, let’s run these commands from our home directory:

cd workspace/railstest
capify .

Capistrano will add two files to our app, Capfile and config/deploy.rb. Let’s edit config/deploy.rb:

pico config/deploy.rb

Here is one place we can look for help in figuring out what to put in this file so that Capistrano will know where and how to deploy our app.

Below is what our config/deploy.rb file ends up looking like:

set :application, "railstest"
set :repository,  "git@github.com:your_github_username/railstest.git"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
set :deploy_to, "/var/local/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
set :scm, :git
# Or: `accurev`, `bzr`, `cvs`, `darcs`, `git`, `mercurial`, `perforce`, `subversion` or `none`

set :deploy_via, :remote_cache
set :branch, "master"

set :passenger_conf, true
set :user, "app" # Login as?
set :runner, "app" # Run ./script as?
set :use_sudo, false

set :domain, "rails.example.com"

role :web, domain                          # Your HTTP server, Apache/etc
role :app, domain                          # This may be the same as your `Web` server
role :db,  domain, :primary => true        # This is where Rails migrations will run
#role :db,  "your slave db-server here"

set :rails_env, "production"

# If you are using Passenger mod_rails uncomment this:
# if you're still using the script/reapear helper you will need
# these http://github.com/rails/irs_process_scripts

namespace :deploy do
  task :start do ; end
  task :stop do ; end
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
  end
end

Deploy

Now, we’re ready to run “cap” and actually do some things. Let’s follow some steps in the handy guide referenced above:

cap deploy:setup
cap deploy:check
cap deploy:update

Note: The “update” task failed for me the first time I tried it, and I think the “Known Hosts List” section at the bottom of this page explains why. I solved the problem by SSHing into the server and doing the following:

su app
git ls-remote git@github.com:your_github_username/railstest.git master

You should see something like:

The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)?

Type “yes”, and press Enter, and you should see something like:

Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.
502d44c77a98c812eff27e97d542f47ed891fad1        refs/heads/master

I tried “cap deploy:update” again from my Mac and it succeeded.

OK, let’s continue. We’re already on the server, in a shell as the “app” user, so let’s try this:

cd /var/local/railstest/current
rake RAILS_ENV=production db:schema:load

Note: This one didn’t work for me at first either. I found an explanation here, which jibes with what the PostgreSQL manual says. Evidently, the default is for postgresql to only allow UNIX socket connections as a database user with the same name as the operating system user. In our case, we’re running rake as “app”, and rake is trying to connect to postgresql as “railstest”, which isn’t going to work under the default setup. So, let’s change the setup. Type “exit” to get back to your root shell. As root, do this:

pico /etc/postgresql/8.3/main/pg_hba.conf

Comment out the line that says:

local all all ident sameuser

and add a line right below it that says:

local all all trust

Then, run:

sudo su postgres -c "/usr/lib/postgresql/8.3/bin/pg_ctl reload -D /var/lib/postgresql/8.3/main"

to have postgresql reload the config file we just edited. Now, let’s try this step again:

su app
cd /var/local/railstest/current
rake RAILS_ENV=production db:schema:load

It works! Next, do:

./script/console production
app.get("/")

I got a 404 from this, which apparently isn’t a bad thing in our case, because we haven’t configured our app to return anything from that location in production mode.

Next, opening up a web browser on your Mac and browsing to:

http://rails.example.com/javascripts/prototype.js

should return what you would expect.

So, now that we’ve checked every step of the process, let’s run the whole she-bang. In your Mac Terminal, do:

cap deploy

If it works, then we are now at the moment of truth. In our web browser, let’s browse to:

http://rails.example.com/books

Our app should come up! Success! We’re done! WOO-HOO!!!

Conclusion

Thanks for joining me on this journey (if there’s been anyone out there reading this). It’s actually been quite a ride for me, a PHP/MySQL monkey by trade. I hope you’ve had as much fun learning about this stuff as I have. No doubt there’s a better way to do some of the things described in this series. I’ll probably update some of what I’ve written with better methods in future posts. And I’m sure there will be plenty of all-new adventures “On the Rails” in the future. If you have something to share, please feel free to drop me a line. Thanks again, and see you down the road!

I’m going to assume you already have a Rackspace Cloud account. (If you don’t, I’ll leave it to you to rectify the situation.)

Create a Server

Follow these steps to create a Rackspace Cloud Server:

1. Log in to the control panel at manage.rackspacecloud.com.
2. Click on Hosting in the left nav bar, then Cloud Servers.
3. Click Add New Server.
4. Now, it’s time to pick how much RAM and storage space you want (and how much you want to pay per hour). The default, 256 MB RAM and 10 MB storage at $0.015 an hour, is fine for our purposes.
5. Scroll down and give your server a name, like, oh, I don’t know, “Fred” or “Rails-Test” or something.
6. Next, choose your favorite flavor of ice cream operating system. I like Ubuntu 8.04.2 LTS (hardy). Yum. No, wait, I mean apt-get.
7. Finally, click Add Cloud Server.

While it is building your server according to your specifications, the control panel will give you an IP address and a root password. This information will also be emailed to the primary contact email address associated with your account. Be sure to keep it in a safe place.

Once your server is ready, you can SSH into it. In a Terminal, issue the following command:

ssh root@<your_server_IP_address>

Enter your root password when prompted.

Bootstrap That Baby

Marc Chung (formerly of OpenRain, now of redPear) has published, as a GitHub repo, a collection of handy-dandy shell scripts to aid us in bootstrapping a Rails server. I have forked his repo and made a few updates to a few of the scripts. Go here and start to follow the instructions in the README. Update and upgrade Ubuntu, install Git, and clone the Git repo to get the scripts.

Set Up Password-less Authentication

Before we start running scripts, we ought to make it so that we can connect to our remote server from our local Mac without having to type in a password, while at the same time ensuring that no one besides us can connect in this way. (This is necessary for the deployment process to work, as we’ll see in our next episode.) We’ll achieve this by adding the public key we generated earlier on our Mac to an “authorized_keys” file on the remote server. (reference)

1. On the Mac, run “cat ~/.ssh/id_rsa.pub” and copy the result to the clipboard.
2. On the server, run “pico bootstrap/config/root_authorized_keys”. Paste the key into this file and save it (Ctrl-O).
3. On the server, run “pico bootstrap/config/default_authorized_keys”. Paste the key into this file and save it (Ctrl-O).

Edit/Run Scripts

We are going to be running these scripts in order:

00-core.sh
05-ruby.sh
10-misc.sh
15-postgresql.sh
25-apache.sh
36-passenger.sh
40-rails-apps.sh

You can run the core, ruby, and misc scripts out of the box with no command-line arguments.

You should edit the postgresql script before running it, to customize one of the config options. Namely, edit the “add addresses” block in that file. Change the IP addresses to match the machines from which you’ll be remotely connecting to your PostgreSQL database server, if any. If there are none, you can delete this block.

When running the postgresql script, you have to provide four arguments:

1. your admin database user’s password
2. your normal database user’s username (in our case, railstest)
3. your normal database user’s password (we’ll have to add this to our app in railstest/config/database.yml too)
4. the name of the database you want to create for your app (in our case, railstest_production)

Note: This script will install PostgreSQL 8.3 instead of 8.4, as there’s no Ubuntu hardy package for 8.4.

The apache script can be run with no arguments.

The passenger script takes one argument:

1. the public hostname of your server

After running the passenger script, let’s edit one of our Apache config files:

pico /etc/apache2/sites-available/default

Along with the addition and modification of a couple other options, we’re going to change the DocumentRoot to the directory where our app is going to live. Edit the VirtualHost block of the file to look like this:

<VirtualHost *>
    ServerAdmin youremail@yourdomain.com
    ServerName rails.example.com
    DocumentRoot /var/local/railstest/current/public
    RailsBaseURI /
    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>
    <Directory /var/local/railstest/current/public>
        Options Indexes FollowSymLinks -MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
    </Directory>
...

Save the file with Ctrl-O. Exit with Ctrl-X, and then run:

apache2ctl -k graceful

to restart Apache.

Finally, let’s run the rails-apps script with no arguments.

Post-Scripts

After we’ve finished running the scripts, we want to make it so that the server can connect to GitHub and access our app’s code repo during the deployment process.

Let’s generate an SSH keypair on the remote server, but as the “app” user instead of root, since that’s the one that we’ll be running the deployment process as:

sudo su app -c "ssh-keygen -t rsa"

As we did earlier with the keys generated on our Mac, we’ll paste the public key into our GitHub config:

1. Run “cat /home/app/.ssh/id_rsa.pub” on the server and copy the result to the clipboard.
2. On GitHub, go to your repo’s home page and click the “Admin” button.
3. Under the “Deploy Keys” section, click “Add another deploy key”.
4. Give the deploy key a title, like “Production App Server” or something.
5. Paste the contents of the clipboard into the “Key” textarea.
6. Click “Add Key”.

We’re done bootstrapping! Our Rackspace Cloud Server is now prepped and ready to run our app upon its arrival. Be sure to type “exit” to log out and close your SSH connection.

One More Thing

Before we call it quits for this episode, let’s go back to our Mac for a second and make sure we add the normal database user’s password to our config file. In Terminal, from our home directory, do the following:

cd workspace/railstest
pico config/database.yml

Go down to the empty “password:” line in the “production” section at the end of the file and add the password you specified above as the third argument to the postgresql install script. Type Ctrl-O to save the file.

Next Time

In our next episode, we’ll install Capistrano and deploy our app to this baby! See you then!