Welcome to the second FiveRuns blog post to automate server configuration for Ruby on Rails. We received great feedback and suggestions about the original script, Automatic Rails at Slicehost, which installed the basics. This time we’ll use standards like Capistrano deployment, separate web and application layers and an active database backend. While the Hello World application surely dazzled your friends and family, this time we’ll take it up a notch and deploy a working, full stack community web application, Trevor Turk’s cool Rails app, Eldorado.
The What
This script connects to a new Ubuntu 8.04 server and configures all necessary applications and libraries. Since we are installing a lot more this time, it’s a bit long to post here, so I’ve linked to it on Github. You still only need to provide 2 pieces of information: the target address of your server and the password. Execute the script locally which downloads Eldorado, the associated configuration files and then connects to your server to push the installation.
The previous script installed:- Ruby 1.8.6
- Rubygems 1.2
- Sqlite3
- MySQL 5.0.51a
- Thin 0.8.2
- Hello World example Rails application
- nginx 0.5.33
- Mongrel 1.1.5
- Eldorado Rails application
- Capistrano deployment
- Rubygems 1.3
The How
1. Download the script from Github. I’ve abbreviated the URL.
wget http://tinyurl.com/57sjce -O configure_ubuntu_eldorado.sh
2. Run the script.
sh configure_ubuntu_eldorado.sh
That’s it! You’ll be asked for your password twice, once to set up the OS via ssh and once to run the Capistrano deployment tasks. Speaking of passwords, best practices include dedicated deployment and MySQL user accounts. This script uses the root account for simplicity.
The Why
The script originated as a DRY effort for Slicehost deployments. You can now point it at other providers, remote Ubuntu servers or virtual machines. It’s become a handy way to explore a working Rails environment without manually installing every component. Also, writing configuration automation is a great way to hone your deployment skills. Thanks go to Trotter Cashion for the suggestion to maintain the scripts on Github, where they’ve been forked and extended. Check out Jørgen Orehøj Erichsen’s blog adding support for Passenger and Ruby Enterprise Edition.
All the scripts and configuration files are on Github so feel free to post any feedback or suggestions.
Continued Discussion
4 responses to this entry
Nice script, I might have to purloin some of it.
I’m working on a similar effort to automate rails deployment to EC2 instances, taking it one step further to allow role specific deployment to multiple virtual servers. If you are interested, check out the rubber project on github.
At some point I’d like to abstract out the EC2 bits to make this a one stop solution no matter your deployment environment, seeking contributors :)
on October 19, 2008 at 07:13 PM
Arg. This really isn’t the best way to do configuration management.
What happens when you need to update your install procedures because you need another gem, or you want to throw some monitoring in there? The script lacks idempotency, so you’ll have to log into all the machines you’ve run that script on and do the upgrade manually.
Provisioning a machine is only one part of deployment – maintaining a machine is the hard part, but fortunately there are tools out there to help.
Have a look at Puppet. It has a high level language for describing how you want your machines configured, and a library for applying that configuration to lots of different Unixes.
It’s also really easy to version your infrastructure by keeping your Puppet configuration in git. You make a change to your configuration that explodes 3 months down the line? git blame to the rescue.
Finally, you can get updated RubyGems packages for Ubuntu at https://launchpad.net/~ubuntu-ruby-backports so you don’t have to roll your own. Have Puppet manage your /etc/apt/sources.list and you’ll be set. :-)
on October 20, 2008 at 07:00 PM
Hi Lindsay,
Thanks for your feedback. We actually use Puppet extensively at FiveRuns. Also our own FiveRuns Manage monitoring, TuneUp optimization, monit, Nagios, Splunk and others are in process too, but until the automation scripts are modularized, they are posted incrementally.
This isn’t intended to replace the operational maintenance of Rails servers and not to run more than once per target. It just quickly configures an example, production environment from bare install. From that point it’s accessible for inspection, management or package upgrades.
Best, Mark
on October 20, 2008 at 09:38 PM
G’day Mark, It’s good to hear you’re using Puppet, but from a best practices perspective I would be really concerned about perpetuating the use of ssh-in-a-for-loop through these sample scripts.
You can totally use Puppet to handle the initial provisioning of a machine, leaving you to focus on writing one set of configuration for all your servers. This means you don’t need to manage separate groups of provisioning scripts and Puppet manifests that essentially do the same thing.
Cheers! Lindsay
on October 21, 2008 at 05:44 AM