Deploying Less Wrong
Clone this wiki locally
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.
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
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
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.
The basic development process is:
- Develop and test your changes locally on the master branch, push
- Merge changes to the staging branch, push
- Deploy your changes to staging
- Test you changes
- Run the manual test script
- Merge staging to stable, push
- Deploy to production
- Check that the production site is operating properly
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"
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
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
/etc/hosts you will need an entry like:
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.
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:
If all the steps in the manual test script were passed you can deploy to
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