Skip to content
This repository was archived by the owner on Apr 17, 2018. It is now read-only.

Deploying Less Wrong

Jump to bottom
wezm edited this page Nov 10, 2010 · 6 revisions

The page documents the environment and process necessary to deploy Less Wrong.
The steps were verified in an Ubuntu 10.04 environment but should also work on
Mac OS X as well.

Environment

Install the required packages

sudo aptitude install ruby-full git-core build-essential

Install rubygems v1.3.7+

wget http://production.cf.rubygems.org/rubygems/rubygems-1.3.7.tgz
tar zxf rubygems-1.3.7.tgz
cd rubygems-1.3.7
sudo ruby setup.rb --no-format-executable

Install gems
sudo gem install capistrano capistrano-ext right_aws erubis activesupport rake treetop --no-ri --no-rdoc

If you run into any problems with the gems, these versions are known to work:

  • activesupport (3.0.0)
  • capistrano (2.5.19)
  • capistrano-ext (1.2.1)
  • erubis (2.6.6)
  • right_aws (2.0.0)
  • rake (0.8.7)
  • treetop (1.4.8)

NOTE: You must not have the aws gem installed. If you’re not sure whether you do, you won’t after:

gem list aws | grep aws && sudo gem uninstall aws

Credentials

To deploy to production you will need the following:

  • Access to the tricycle lesswrong git repository.
  • Access to the tricycle capistrano repository.
  • The Trike Amazon access key and secret key.
  • The ami root password.
  • Your ssh key added to the authorized_keys for the www-data user on the ami.

Process

The basic development process is:

  1. Develop and test your changes locally on the master branch, push
  2. Merge changes to the staging branch, push
  3. Deploy your changes to staging
  4. Test you changes
  5. Run the manual test script
  6. Merge staging to stable, push
  7. Deploy to production
  8. Check that the production site is operating properly

Deployment

Deployment is managed by capistrano. In order to use the capistrano tasks
for staging and production the EC2_ACCESS_KEY and EC2_SECRET_KEY environment
variables must be set with the appropriate values. They are the same for
staging and production.

export EC2_ACCESS_KEY="Insert access key here"; export EC2_SECRET_KEY="Insert secret key here"

Staging

There is not a persistent staging server running. Instead an EC2 instance
is started on demand using the AMI currently in use in production. Starting
the instance is managed for you.

With the staging branch checked out:

cap staging deploy

If there is not a staging instance already running you will be prompted to
start one. Instances started this way will automatically shutdown after
2 hours. If you wish to cancel the shutdown run the following on the instance
as root:

shutdown -c

In order to test the Less Wrong application running on the staging instance you
must manually set the IP for the lesswrong.com domain to point at the staging
instance.

In /etc/hosts you will need an entry like:

xxx.xxx.xxx.xxx    lesswrong.com

When any of the cap tasks are run against staging you will receive a warning
if this entry in not in /etc/hosts. The warning will tell you the IP address
of the staging instance.

Production

Deploying to production is largely the same as staging, except that there may
be more than one server being deployed to — Capistrano takes care of this.

Prior to deploying to production you must have run through the manual test
script. Run the following in you local environments and perform the steps in
the browser against the staging instance:

rake test:manual

If all the steps in the manual test script were passed you can deploy to
production:

cap production deploy

Useful capistrano tasks

To ssh to a remote server:

cap dev|staging|production ssh

To copy a remote database to the local one:

Production to staging, run the following on the staging server:

APPLICATION_ENV=staging cap production postgresql:duplicate

Staging to local dev machine:

INI=r2/development.ini cap staging postgresql:duplicate

Restart the application server:

cap dev|staging|production deploy:restart
Clone this wiki locally