Setup script to get Ruby and Rails running on Ubuntu with one command using RailsReady

Posted by Bhushan Ahire | Posted in git, Rails, ruby, Subversion | Posted on 05-12-2011

0

How would you like to get a full Ruby on Rails stack up on Ubuntu with one command?

Now you can by running Rails Ready. Rails Ready is a setup script that gets Ruby and Rails running on a fresh install of Ubuntu with one command (Tested on Ubuntu server 10.04 LTS (Long-term Support)).

This is a brand new project by Josh Frye that he uses all the time to setup VMs, but there’s always testing to be done and improvements to be made.

Running the Script

Check out railsready.sh to see everything Rails Ready is doing.

  sudo wget --no-check-certificate https://github.com/joshfng/railsready/raw/master/railsready.sh && bash railsready.sh

The script will then ask if you want to build Ruby from source or install RVM. If you want to watch the magic happen just run tail -f ~/railsready/install.log.

What gets installed?

  • An updated system (Linux only)
  • Homebrew (OSX only)
  • Ruby 1.9.3 latest patch level (installed to /usr/local/bin/ruby) or RVM running 1.9.3 latest patch level
  • Imagemagick
  • libs needed to run Rails (sqlite, mysql, etc)
  • Bundler, Passenger, and Rails gems
  • Git

All you need to do is install NGINX or Apache, run passenger-install-nginx-module or passenger-install-apache-module, upload your app, point your vhost config to your apps public directory and go!

A note about RVM+passenger+nginx: Passenger installed via RVM can’t locate the OpenSSL package installed on Ubuntu. A user contributed fix is as follows:

rvm remove 1.9.2
rvm package install openssl
rvm install 1.9.2 --with-openssl-dir=$HOME/.rvm/usr
rvmsudo passenger-install-nginx-module

Hope this guide will be helpful to you.

Setup Capistrano to deploy Rails application on Amazon EC2 with Git

Posted by Bhushan G Ahire | Posted in capistrano, git, Rails, ruby, Security, Subversion | Posted on 17-02-2010

0

1: Create a new Rails app – we’ll call is ‘deploytest’

$ rails deploytest
$ cd deploytest

2: Create a local Git repository for it

$ git init
$ git add *
$ git commit -a -m 'initial commit'
$ git status

3: Create a couple of Capistrano files

$ capify .

4: Edit config/deploy.rb

# The name of your app
set :application, "deploytest"
# The directory on the EC2 node that will be deployed to
set :deploy_to, "/var/www/apps/#{application}"
# The type of Source Code Management system you are using
set :scm, :git
# The location of the LOCAL repository relative to the current app
set :repository,  "."
# The way in which files will be transferred from repository to remote host
# If you were using a hosted github repository this would be slightly different
set :deploy_via, :copy

# The address of the remote host on EC2 (the Public DNS address)
set :location, "ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com"
# setup some Capistrano roles
role :app, location
role :web, location
role :db,  location, :primary => true

# Set up SSH so it can connect to the EC2 node - assumes your SSH key is in ~/.ssh/id_rsa
set :user, "root"
ssh_options[:keys] = [File.join(ENV["HOME"], ".ssh", "id_rsa")]

The only account on a default EC2 instance is root. You probably want to create a second user that is responsible for your application.

5: Copy your SSH public key to your EC2 node

$ scp -i ~/my-ec2-keypair ~/.ssh/id_rsa.pub root@ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com:/root/.ssh/authorized_keys2

NOTE the filename authorized_keys2 – not authorized_keys!!

6: Setup the EC2 node for Capistrano deployment.
From your LOCAL machine, not the EC2 node:

$ cap deploy:setup

7: Finally, deploy your application

$ cap deploy

You will see lots of output and with this dummy application some of those will report errors/warnings. Don’t worry about that for now.

8: Check that the Deployment was successful
Connect to the EC2 node with SSH the regular way, cd to the app directory and check that everything is there. If that is all working then you are ready to deploy a real application and add custom tasks for managing the database, restarting the server etc.

Bear in mind that Capistrano add new ‘releases’ of your software in separate directories and symlinks the ‘current’ directory to the latest. So the root of your deployed application is the ‘current’ subdirectory.

Hope this will help you setting up your ec2 instance with capistrano.

Step-By-Step setup slicehost server (fedora) for rails application.

Posted by Bhushan Ahire | Posted in capistrano, Rails, Subversion | Posted on 22-07-2009

1

Synchronize old svn with all revision history to new repository

Posted by Bhushan Ahire | Posted in Subversion | Posted on 04-03-2008

0

First, create a SVN user for svnsync to use – let’s call this the ’svnsync user’. The easiest (and best) way to do this is edit the svnserve.conf and passwd files:

conf/svnserve.conf


# Uncomment this line.
password-db = passwd

conf/passwd


svnsync = secret

This gives read and write access to the ’svnsync user’. The svnsync program will authenticate with our repositories as this user via the svn:// protocol (i.e. via svnserve).

Next, we need to create a pre-revprop-change hook for the destination repository. The svnsync documentation has a detailed explanation. Create a hooks/pre-revprop-change file under your destination repository’s directory.


#!/bin/sh
USER="$3"

if [ "$USER" = "svnsync" ]; then exit 0; fi

echo "Only the svnsync user can change revprops" >&2
exit 1

Make it executable, and then initialize the sync:


chmod +x hooks/pre-revprop-change
svnsync init file:///var/svn/repositories/destination_repos svn://source.host/source_repos

Don’t worry, this only sets up the sync – there’s no actual data copying yet. Syncing your repository data may take a long time if you have a big source repository, so I suggest using nohup to run the code overnight (or something), or at least saving the output in a log. Either way, the command to start the sync is:

svnsync sync --username svnsync file:///var/svn/repositories/testsync/

You should start seeing svnsync committing in changes from your source repository. Instant gratification (well, almost)! Should your svnsync process get aborted or killed, you can remove the hanging lock by running:

svn propdel svn:sync-lock --revprop -r 0

Setting up ‘on-the-fly’ syncing

So now you have your source and destination repositories synced, but what happens when you start committing changes to your source repository? Nothing! That’s because svnsync is merely a passive syncing tool (meaning you have to run it to sync, instead of it knowing when to sync automatically).

There are two ways you can setup ‘real-time’ syncing:

  1. Use cron (or a similar scheduler) on the destination repository server. Add something like this to your crontab:
    * * * * * /usr/local/bin/svnsync --non-interactive sync svn://source.host/source_repos

    This basically runs svnsync on your destination repository server every minute to pull down any changes to your source repository.

  2. Add a post-commit hook to the source repository. I found this svnsync entry by Paul Querna that has a sample post-commit hook. If I recall correctly I tried it but it didn’t work for me, so I settled on using cron to sync up my repositories.