Compiling Node.js from source is easy enough so here’s how.

Installing from a tarball

Node.js needs a few things to compile so make sure they are installed.

1
2

sudo apt-get update
sudo apt-get install build-essential openssl libssl-dev pkg-config

Get the link for the latest tarball from the Source Code link on the Node.js homepage. Then download it and extract it.

1
2
3
4
5

cd /usr/local/src
sudo mkdir node
cd node
sudo wget http://nodejs.org/dist/v0.6.6/node-v0.6.6.tar.gz
sudo tar -xzf node-v0.6.6.tar.gz

Now you can compile and install the binary. By default Node.js will be installed to /usr/local/bin/node and npm will be installed to /usr/local/bin/npm.

1
2
3
4

cd node-v0.6.6/
sudo ./configure
sudo make
sudo make install

Upgrading via a tarball

To upgrade Node.js simply download the new tarball, extract and repeat the installation process.

Installing from Git

If you plan to upgrade each time a new release comes out you may find cloning the Git repository more convenient than downloading and extracting a tarball each time.

You will need Git and the dependencies to be installed first.

1
2

sudo apt-get update
sudo apt-get install git-core build-essential openssl libssl-dev pkg-config

Using Git means that instead of downloading extracting a tarball you can just clone the repository and checkout the latest version. If you need to check the versions that are available run git tag.

1
2
3
4

cd /usr/local/src
sudo git clone git://github.com/joyent/node.git
cd node
sudo git checkout v0.6.6

Now you can compile the binary as before

1
2
3

sudo ./configure
sudo make
sudo make install

Upgrading via Git

To upgrade to a new release of Node.js first pull the latest source.

1
2
3

cd /usr/local/src/node
sudo git checkout master
sudo git pull origin master

Then checkout the latest version where v.x.x.x is the version you want.

1

sudo git checkout vx.x.x

Then follow the installation process as before

1
2
3

sudo ./configure
sudo make
sudo make install

This will upgrade Node.js and overwrite the previous version.

rbenv is great

If you haven’t seen rbenv yet I highly recommend it. It is a small collection of shell scripts that lets you manage rubies on UNIX type machines. To date I’ve used rvm to install versions of ruby and manage gemsets. Don’t get me wrong - I’m hugely greatful to the work that has gone into the rvm project and it is still a great tool. But I prefer the UNIX philosophy of doing one thing well and rbenv embraces that. I also really like that with rbenv you just need to amend your PATH and you are done. It follows UNIX conventions making integration with other UNIX tools easier - for me at least.

rbenv basics

We have a dev machine at work which runs a variety of Sinatra and Rails projects (including a Rails 1 project). As such these projects need lots of different versions of Ruby. To date I’ve used rvm to manage this and it has worked well but I always came up against issues when trying to integrate tools like Monit, puppet or init.d scripts. So I bit the bullet and switched to rbenv.

Each app has a UNIX user so rbenv is installed locally for each user when logged in as the user account

1
2

cd
git clone git://github.com/sstephenson/rbenv.git .rbenv

You need to load rbenv into the shell and you are good to go

1
2
3

echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc

If you have installed ruby-build you can then install rubies with rbenv install.

1

rbenv install 1.9.3-rc1

You can set a global ruby for the user account with

1

rbenv global 1.9.3-rc1

And you can also use an .rbenv-version file to set the version. I choose to use this in projects and check it into git.

Deployment with capistrano

I like that rbenv doesn’t try and manage rubies for you - we have bundler for that. I deploy as the same user as the app accounts so I just need to add the following to my cap recipe to use rbenv since I’m already including require 'bundler/capistrano'.

1
2
3

set efault_environment, {
  'PATH' => "/home/youruser/.rbenv/shims:/home/youruser/.rbenv/bin:$PATH"
}

This loads rbenv into the shell that capistrano uses. That’s pretty much all you need to use your rbenv installed ruby.

Following a thread on github you can also apply a clever technique to allow you switch versions of ruby by pushing a new .rbenv-version file with capistrano. From version 1.1rc bundler allows you to specify a shebang for binstubs. To use this add the following to your capistrano recipe.

1

set :bundle_flags, "--deployment --quiet --binstubs --shebang ruby-local-exec"

This generates executables in the bin folder of your Rails app which reference ruby-local-exec as the shebang. This command will execute whichever ruby is specified in the .rbenv-version file. In my case I have an init.d script to manage unicorn that references bin/unicorn. If I wanted to upgrade the ruby used by the app I would install it on the remote machine and then just update my .rbenv-version file commit, cap deploy and I’m done.

Integrating with other tools

I like to use monit to monitor processes. Monit exexutes scripts with a very limited shell but since rbenv follows UNIX conventions we can easily create a small bash script to load rbenv into the path and then do what we want.

Here’s the script I’m using for starting a resque_worker

1
2
3
4
5
6
7
8
9

#!/usr/bin/env bash
USER=youruser
APP_PATH=/srv/yourapp.com/current
PATH=/home/$USER/.rbenv/bin:/home/$USER/.rbenv/shims:$PATH
RAILS_ENV=production

cd $APP_PATH
RAILS_ENV=$RAILS_ENV bin/rake environment resque:work& > $APP_PATH/log/resque_worker.log
echo $! > $APP_PATH/tmp/pids/resque_worker.pid

Then my monit task looks like this

1
2
3
4

check process yourapp_resque_worker
    with pidfile /srv/yourapp.com/current/tmp/pids/resque_worker.pid
    start program = "/bin/sh -c '/home/youruser/bin/start_resque_worker.sh'" as uid youruser and gid youruser
    stop program = "/bin/sh -c 'cd /srv/yourapp.com/current && kill -s quit `cat tmp/pids/resque_worker.pid` && rm -f tmp/pids/resque_worker.pid; exit 0;'"

Better separation

By using rbenv, bundler, capistrano and monit together we have great separation between what these tools do

• rbenv manages rubies
• bundler manages gems
• capistrano manages deployments
• monit monitors processes

This feels clean and manageable to me.

By using binstubs with the ruby-local-exec shebang we also separate our app from versions of rubies, init.d and monit scripts, making it super easy to upgrade.

Thanks rvm, onwards with rbenv

I’m really grateful to Wayne E Seguin and the work he has put into rvm and I hope the project continues to thrive. rbenv fits the way I work though and I’m really enjoying using it. It makes piecing tools like puppet, monit, init.d scripts, capistrano and bundler much easier, so a big thanks to Sam Stephenson for creating it.

rbenv is great

If you haven’t seen rbenv yet I highly recommend it. It is a small collection of shell scripts that lets you manage rubies on UNIX type machines. To date I’ve used rvm to install versions of ruby and manage gemsets. Don’t get me wrong - I’m hugely greatful to the work that has gone into the rvm project and it is still a great tool. But I prefer the UNIX philosophy of doing one thing well and rbenv embraces that. I also really like that with rbenv you just need to amend your PATH and you are done. It follows UNIX conventions making integration with other UNIX tools easier - for me at least.

rbenv basics

We have a dev machine at work which runs a variety of Sinatra and Rails projects (including a Rails 1 project). As such these projects need lots of different versions of Ruby. To date I’ve used rvm to manage this and it has worked well but I always came up against issues when trying to integrate tools like Monit, puppet or init.d scripts. So I bit the bullet and switched to rbenv.

Each app has a UNIX user so rbenv is installed locally for each user when logged in as the user account

1
2

cd
git clone git://github.com/sstephenson/rbenv.git .rbenv

You need to load rbenv into the shell and you are good to go

1
2
3

echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc

If you have installed ruby-build you can then install rubies with rbenv install.

1

rbenv install 1.9.3-rc1

You can set a global ruby for the user account with

1

rbenv global 1.9.3-rc1

And you can also use an .rbenv-version file to set the version. I choose to use this in projects and check it into git.

Deployment with capistrano

I like that rbenv doesn’t try and manage rubies for you - we have bundler for that. I deploy as the same user as the app accounts so I just need to add the following to my cap recipe to use rbenv since I’m already including require 'bundler/capistrano'.

1
2
3

set efault_environment, {
  'PATH' => "/home/youruser/.rbenv/shims:/home/youruser/.rbenv/bin:$PATH"
}

This loads rbenv into the shell that capistrano uses. That’s pretty much all you need to use your rbenv installed ruby.

Following a thread on github you can also apply a clever technique to allow you switch versions of ruby by pushing a new .rbenv-version file with capistrano. From version 1.1rc bundler allows you to specify a shebang for binstubs. To use this add the following to your capistrano recipe.

1

set :bundle_flags, "--deployment --quiet --binstubs --shebang ruby-local-exec"

This generates executables in the bin folder of your Rails app which reference ruby-local-exec as the shebang. This command will execute whichever ruby is specified in the .rbenv-version file. In my case I have an init.d script to manage unicorn that references bin/unicorn. If I wanted to upgrade the ruby used by the app I would install it on the remote machine and then just update my .rbenv-version file commit, cap deploy and I’m done.

Integrating with other tools

I like to use monit to monitor processes. Monit exexutes scripts with a very limited shell but since rbenv follows UNIX conventions we can easily create a small bash script to load rbenv into the path and then do what we want.

Here’s the script I’m using for starting a resque_worker

1
2
3
4
5
6
7
8
9

#!/usr/bin/env bash
USER=youruser
APP_PATH=/srv/yourapp.com/current
PATH=/home/$USER/.rbenv/bin:/home/$USER/.rbenv/shims:$PATH
RAILS_ENV=production

cd $APP_PATH
RAILS_ENV=$RAILS_ENV bin/rake environment resque:work& > $APP_PATH/log/resque_worker.log
echo $! > $APP_PATH/tmp/pids/resque_worker.pid

Then my monit task looks like this

1
2
3
4

check process yourapp_resque_worker
    with pidfile /srv/yourapp.com/current/tmp/pids/resque_worker.pid
    start program = "/bin/sh -c '/home/youruser/bin/start_resque_worker.sh'" as uid youruser and gid youruser
    stop program = "/bin/sh -c 'cd /srv/yourapp.com/current && kill -s quit `cat tmp/pids/resque_worker.pid` && rm -f tmp/pids/resque_worker.pid; exit 0;'"

Better separation

By using rbenv, bundler, capistrano and monit together we have great separation between what these tools do

• rbenv manages rubies
• bundler manages gems
• capistrano manages deployments
• monit monitors processes

This feels clean and manageable to me.

By using binstubs with the ruby-local-exec shebang we also separate our app from versions of rubies, init.d and monit scripts, making it super easy to upgrade.

Thanks rvm, onwards with rbenv

I’m really grateful to Wayne E Seguin and the work he has put into rvm and I hope the project continues to thrive. rbenv fits the way I work though and I’m really enjoying using it. It makes piecing tools like puppet, monit, init.d scripts, capistrano and bundler much easier, so a big thanks to Sam Stephenson for creating it.

Riding Unicorns

For many reasons I like using Unicorn as a web server for Ruby apps. Ryan Tomayko wrote a great article and the many Unix features that it has. It has the killer feature of supporting hot restarts so you can deploy new releases with zero downtime. This means that in most cases you can deploy as often as you want and end users won’t even notice.

More power == more responsibility

With all of the great stuff that comes with Unicorn there is more configuration to do. This is the point at which the less intrepid opt for Passenger, that to be fair is stil a good option. But if you want a web server that uses great features of Unix and enables hot restarts you should persevere.

For Unicorn you need to set up a reverse proxy with nginx. I’ve written before about how to do that if you need a steer. You’ll also need to use upstart or script in /etc/init.d/ to manage Unicorn. There are a few scripts around on the web. I’ve posted the one that I use up as a gist on Github. You can then use something like this in your capistrano recipes to do a hot restart.

1
2
3
4
5

namespace eploy do
  task :restart do
    sudo "/etc/init.d/unicorn upgrade"
  end
end

This sends a USR2 signal to the Unicorn master process to upgrade itself. It will create a new master process and then switch over when it is ready. See - zero downtime!

Up the workers

The Unicorn master process looks after workers and will reap workers that die from broken apps. In my scenario I was working on a memory constrained box and I wanted to make sure that workers did not consume too much memory. I like to use Monit to monitor processes. You can also use god or bluepill but I’ve found these tools consume much more memory that Monit. Call me old fashioned but I like to use Unix tools if they are available over Ruby.

So I want to monitor the Unicorn workers that are a child processes of the master Unicorn process. Bluepill supports monitoring child processes but it turns out this is easy enough to do with Monit.

Unicorn’s config file has an after_fork method that allows you to write out the pid of a worker. Here’s how

1
2
3
4
5

after_fork do |server, worker|
  defined?(ActiveRecord::Base) && ActiveRecord::Base.establish_connection
  child_pid = server.config[id].sub('.pid', ".#{worker.nr}.pid")
  system("echo #{Process.pid} > #{child_pid}")
end

If you want to see my full unicorn.conf it is here. This will write out the pid of each worker /tmp/pids/unicorn.[pid_id].pid, so now we can use Monit to watch it.

Adding in Monit

Now that we have the pids of workers and an init.d script that can manage workers too (see kill_worker) we can use Monit to keep everything in check. The only downside is that you need to tell Monit about each worker process that you have. If you are spawning and reaping Unicorn workers dynamically with TTIN and TTOU this probably isn’t going to work for you. But if the numbers of workers are fixed you are good.

1
2
3
4
5
6
7

check process unicorn_worker_0
    with pidfile /path/to/your/app/shared/pids/unicorn.0.pid
    start program = "/bin/cat /dev/null"
    stop program = "/etc/init.d/unicorn kill_worker 0"
    if mem is greater than 175.0 MB for 1 cycles then restart
    if cpu is greater than 22% for 2 cycles then alert
    if cpu is greater than 25% for 1 cycles then restart

Monit will watch the worker for memory growth and kill it off if it consumes too much. The unicorn master will spawn a new worker when it is killed so it is a neat solution to keep things running.

Much of this article was derived from Andrew Grim’s article ‘Where Unicorns go to die: Watching unicorn workers with monit’, so thanks to Andrew for the pointers.

Riding Unicorns

For many reasons I like using Unicorn as a web server for Ruby apps. Ryan Tomayko wrote a great article and the many Unix features that it has. It has the killer feature of supporting hot restarts so you can deploy new releases with zero downtime. This means that in most cases you can deploy as often as you want and end users won’t even notice.

More power == more responsibility

With all of the great stuff that comes with Unicorn there is more configuration to do. This is the point at which the less intrepid opt for Passenger, that to be fair is stil a good option. But if you want a web server that uses great features of Unix and enables hot restarts you should persevere.

For Unicorn you need to set up a reverse proxy with nginx. I’ve written before about how to do that if you need a steer. You’ll also need to use upstart or script in /etc/init.d/ to manage Unicorn. There are a few scripts around on the web. I’ve posted the one that I use up as a gist on Github. You can then use something like this in your capistrano recipes to do a hot restart.

1
2
3
4
5

namespace eploy do
  task :restart do
    sudo "/etc/init.d/unicorn upgrade"
  end
end

This sends a USR2 signal to the Unicorn master process to upgrade itself. It will create a new master process and then switch over when it is ready. See - zero downtime!

Up the workers

The Unicorn master process looks after workers and will reap workers that die from broken apps. In my scenario I was working on a memory constrained box and I wanted to make sure that workers did not consume too much memory. I like to use Monit to monitor processes. You can also use god or bluepill but I’ve found these tools consume much more memory that Monit. Call me old fashioned but I like to use Unix tools if they are available over Ruby.

So I want to monitor the Unicorn workers that are a child processes of the master Unicorn process. Bluepill supports monitoring child processes but it turns out this is easy enough to do with Monit.

Unicorn’s config file has an after_fork method that allows you to write out the pid of a worker. Here’s how

1
2
3
4
5

after_fork do |server, worker|
  defined?(ActiveRecord::Base) && ActiveRecord::Base.establish_connection
  child_pid = server.config[id].sub('.pid', ".#{worker.nr}.pid")
  system("echo #{Process.pid} > #{child_pid}")
end

If you want to see my full unicorn.conf it is here. This will write out the pid of each worker /tmp/pids/unicorn.[pid_id].pid, so now we can use Monit to watch it.

Adding in Monit

Now that we have the pids of workers and an init.d script that can manage workers too (see kill_worker) we can use Monit to keep everything in check. The only downside is that you need to tell Monit about each worker process that you have. If you are spawning and reaping Unicorn workers dynamically with TTIN and TTOU this probably isn’t going to work for you. But if the numbers of workers are fixed you are good.

1
2
3
4
5
6
7

check process unicorn_worker_0
    with pidfile /path/to/your/app/shared/pids/unicorn.0.pid
    start program = "/bin/cat /dev/null"
    stop program = "/etc/init.d/unicorn kill_worker 0"
    if mem is greater than 175.0 MB for 1 cycles then restart
    if cpu is greater than 22% for 2 cycles then alert
    if cpu is greater than 25% for 1 cycles then restart

Monit will watch the worker for memory growth and kill it off if it consumes too much. The unicorn master will spawn a new worker when it is killed so it is a neat solution to keep things running.

Much of this article was derived from Andrew Grim’s article ‘Where Unicorns go to die: Watching unicorn workers with monit’, so thanks to Andrew for the pointers.

Slicehost was a game changer

I’ve been a long standing Slicehost customer, after moving from Media Temple. Slicehost was perfect for my needs - I knew my way around Linux so I just wanted SSH access and the ability to configure it myself. At $20 a month Slicehost was a ground-breaking service. Coupled with a blog that spoke to developers about how to do things developers were doing every day it provided a range of distributions and was a massive hit with the developer community. On October 22nd 2008 Slicehost announced that they had been acquired by Rackspace. This was a just reward for what Slicehost had achieved but immediately there were concerns as to the direction of the service.

From public accounts Rackspace has used Slicehost’s underlying technology to build their Rackspace Cloud. In May 2011 Rackspace contacted Slicehost customers to say they would be migrated to the Rackspace Cloud product.

PR Car Crash

The email to customers raised more questions that it gave answers causing many customers to leave Slicehost there and then. There were so many questions that a further post was added to the forum which in fairness addressed many of the questions that customers had. At that point it became clear that the service Rackspace were offering was very different from Slicehost:

• DNS moving to Rackspace’s service. Unknown if it would be free
• Lower bandwidth allowance with pricing moving to pay what you use
• Some servers moving datacenters and changing IP addresses
• Removal of some Slice sizes
• Slicehost API likely to close
• A requirement to migrate to Rackspace by May 2012

Particularly if you use more than 60GB of bandwidth a month the service Rackspace’s Cloud Service would be more expensive.

Free markets are good

Thankfully the hosting market is very competitive and even Slicehost has competition in the form of Linode, a service launched in 2003. Linode offer a very similar service to Slicehost with the ability to provision servers, get SSH access and build it yourself. In fact Linode’s offering to customers is more competitive than Slicehost with 512MB of RAM offered for the entry price of $20 a month. Linode also offer free DNS servers, a great API and has also been a strong hit with the developer coummunity.

After looking at the direction of Rackspace Cloud and what Linode offer for the same price the clear choice was to migrate to the better product: Linode.

The pain of migrating

I’ve been with Slicehost for a while so with that comes many configurations, DNS zones and a server setup exactly how I like it. Rebuilding servers is tedious and sadly I built mine before Puppet was around. I use Puppet at work and this has shown me there is huge value in automating server management, especially in the context of Cloud providers.

After the decision to migrate I was staring at a terminal with many hours of work ahead of me, until the power of open source came to the rescue.

Migrating DNS

Firstly for migrating DNS records Rob Schultz created a short Ruby script to migrate DNS records from Slicehost to Linode. Once you’ve installed the script and necessary gem dependencies migrating your records is as simple at

1

./slicedns2linode.rb domain1.com.

Within a few minutes I had migrated all of my DNS records.

Migrating the server

If you are not already using Chef or Puppet there is a project called Blueprint that lets your reverse engineer a server configuration to a bash script, Puppet manifests or Chef cookbook. There is a good tutorial on a basic migration. Once you’ve installed blueprint and the dependencies you can create a shell script that will build another server with

1

blueprint create -S tutorial

Once you’ve created your scripts, just run them on the target server and it will build the server in the image of the old one.

My experience of Blueprint

The migration via blueprint went very smoothly. I had installed lots of packages adding third party repositories and compiling from source. Other than gitosis packages were mostly copied over and iptables was successfully configured.

Finishing up with scp

Finally I had to copy over website, home folder files and a few config files. The perfect tool for this was scp. First I created a tar.bz2 archive for folders I wanted to copy.

1

tar -cjf vhosts.tar.bz2 /var/www/vhosts

Then I copied over the archive to my new Linode instance

1

scp vhosts.tar.bz2 george@123.456.78.90:/var/www

Finally I unarchived it on the Linode instance

1

tar -xjf vhosts.tar.bz2

The great thing about using this approach is that permissions are preserved.

The last part was to change the name servers for my domains over to Linode.

Thanks Slicehost

Slicehost was a great service and the articles in particular helped me to skill up on UNIX and respond to many different scenarios. I’m sad that Slicehost will no longer be around and in particular that the service offering is so different from Rackspace. Slicehost was cloud hosting before it became trendy and now cloud hosting is something entirely different. I hope Linode can make me as happy - so far so good.

Why I'm moving and how to do it

Slicehost was a game changer

I've been a long standing Slicehost customer, after moving from Media Temple. Slicehost was perfect for my needs - I knew my way around Linux so I just wanted SSH access and the ability to configure it myself. At $20 a month Slicehost was a ground-breaking service. Coupled with a brilliant blog that spoke to developers about how to do things developers were doing every day it provided a range of distributions and was a massive hit with the developer community. On October 22nd 2008 Slicehost announced that they had been acquired by Rackspace. This was a just reward for what Slicehost had achieved but immediately there were concerns as to the direction of the service.

From public accounts Rackspace has used Slicehost's underlying technology to build their Rackspace Cloud. In May 2011 Rackspace contacted Slicehost customers to say they would be migrated to the Rackspace Cloud product.

PR Car Crash

The email to customers raised more questions that it gave answers causing many customers to leave Slicehost there and then. There were so many questions that a further post was added to the forum which in fairness addressed many of the questions that customers had. At that point it became clear that the service Rackspace were offering was very different from Slicehost:

• DNS moving to Rackspace's service. Unknown if it would be free
• Lower bandwidth allowance with pricing moving to pay what you use
• Some servers moving datacenters and changing IP addresses
• Removal of some Slice sizes
• Slicehost API to close
• No support for IPv6
• A requirement to migrate to Rackspace by May 2012

Particularly if you use more than 60GB of bandwidth a month the service Rackspace's Cloud Service would be more expensive.

Free markets are good

Thankfully the hosting market is very competitive and even Slicehost has competition in the form of Linode, a service launched in 2003. Linode offer a very similar service to Slicehost with the ability to provision servers, get SSH access and build it yourself. In fact Linode's offering to customers is more competitive than Slicehost with 512MB of RAM offered for the entry price of $20 a month. Linode also offer free DNS servers, a great API and has also been a strong hit with the developer coummunity. Bandwidth allowances are significantly less with a 25GB quota for Linodes at $20 a month though.

After looking at the direction of Rackspace Cloud and what Linode offer for the same price the clear choice was to migrate to the better product: Linode.

The pain of migrating

I've been with Slicehost for a while so with that comes many configurations, DNS zones and a server setup exactly how I like it. Rebuilding servers is tedious and sadly I built mine before Puppet was around. I use Puppet at work and this has shown me there is huge value in automating server management, especially in the context of Cloud providers.

After the decision to migrate I was staring at a terminal with many hours of work ahead of me, until the power of open source came to the rescue.

Migrating DNS

Firstly for migrating DNS records Rob Schultz created a short Ruby script to migrate DNS records from Slicehost to Linode. Once you've installed the script and necessary gem dependencies migrating your records is as simple at

./slicedns2linode.rb domain1.com.

Within a few minutes I had migrated all of my DNS records. Amazing!

Migrating the server

If you are not already using Chef or Puppet there is a frankly brilliant project called Blueprint that lets your reverse engineer a server configuration to a bash script, Puppet manifests or Chef cookbook. There is a good tutorial on a basic migration. Once you've installed blueprint and the dependencies you can create a shell script that will build another server with

blueprint create -S tutorial

My experience of Blueprint

The migration via blueprint went very smoothly. I had installed lots of packages adding third party repositories and compiling from source. Other than gitosis packages were mostly copied over and iptables was successfully configured.

Finishing up with scp

Finally I had to copy over website, home folder files and a few config files. The perfect tool for this was scp. First I created a tar.bz2 archive for folders I wanted to copy.

tar -cjf vhosts.tar.bz2 /var/www/vhosts

Then I copied over the archive to my new Linode instance

scp vhosts.tar.bz2 george@123.456.78.90:/var/www

Finally I unarchived it on the Linode instance

tar -xjf vhosts.tar.bz2

The great thing about using this approach is that permissions are preserved.

The last part was to change the name servers for my domains over to Linode. This site is now being served from Linode and in a month or so I'll close my Slicehost account. Job done!

Thanks Slicehost

Slicehost was a great service and the articles in particular helped me to skill up on UNIX and helped me to respond to many different scenarios. I'm sad that Slicehost will no longer be around and in particular that the service offering is so different from Rackspace. Slicehost was cloud Hosting before it became trendy and now cloud hosting is something entirely different. I hope Linode can make me as happy - so far so good.

Slicehost was a game changer

I’ve been a long standing Slicehost customer, after moving from Media Temple. Slicehost was perfect for my needs - I knew my way around Linux so I just wanted SSH access and the ability to configure it myself. At $20 a month Slicehost was a ground-breaking service. Coupled with a blog that spoke to developers about how to do things developers were doing every day it provided a range of distributions and was a massive hit with the developer community. On October 22nd 2008 Slicehost announced that they had been acquired by Rackspace. This was a just reward for what Slicehost had achieved but immediately there were concerns as to the direction of the service.

From public accounts Rackspace has used Slicehost’s underlying technology to build their Rackspace Cloud. In May 2011 Rackspace contacted Slicehost customers to say they would be migrated to the Rackspace Cloud product.

PR Car Crash

The email to customers raised more questions that it gave answers causing many customers to leave Slicehost there and then. There were so many questions that a further post was added to the forum which in fairness addressed many of the questions that customers had. At that point it became clear that the service Rackspace were offering was very different from Slicehost:

• DNS moving to Rackspace’s service. Unknown if it would be free
• Lower bandwidth allowance with pricing moving to pay what you use
• Some servers moving datacenters and changing IP addresses
• Removal of some Slice sizes
• Slicehost API likely to close
• A requirement to migrate to Rackspace by May 2012

Particularly if you use more than 60GB of bandwidth a month the service Rackspace’s Cloud Service would be more expensive.

Free markets are good

Thankfully the hosting market is very competitive and even Slicehost has competition in the form of Linode, a service launched in 2003. Linode offer a very similar service to Slicehost with the ability to provision servers, get SSH access and build it yourself. In fact Linode’s offering to customers is more competitive than Slicehost with 512MB of RAM offered for the entry price of $20 a month. Linode also offer free DNS servers, a great API and has also been a strong hit with the developer coummunity.

After looking at the direction of Rackspace Cloud and what Linode offer for the same price the clear choice was to migrate to the better product: Linode.

The pain of migrating

I’ve been with Slicehost for a while so with that comes many configurations, DNS zones and a server setup exactly how I like it. Rebuilding servers is tedious and sadly I built mine before Puppet was around. I use Puppet at work and this has shown me there is huge value in automating server management, especially in the context of Cloud providers.

After the decision to migrate I was staring at a terminal with many hours of work ahead of me, until the power of open source came to the rescue.

Migrating DNS

Firstly for migrating DNS records Rob Schultz created a short Ruby script to migrate DNS records from Slicehost to Linode. Once you’ve installed the script and necessary gem dependencies migrating your records is as simple at

1

./slicedns2linode.rb domain1.com.

Within a few minutes I had migrated all of my DNS records.

Migrating the server

If you are not already using Chef or Puppet there is a project called Blueprint that lets your reverse engineer a server configuration to a bash script, Puppet manifests or Chef cookbook. There is a good tutorial on a basic migration. Once you’ve installed blueprint and the dependencies you can create a shell script that will build another server with

1

blueprint create -S tutorial

Once you’ve created your scripts, just run them on the target server and it will build the server in the image of the old one.

My experience of Blueprint

The migration via blueprint went very smoothly. I had installed lots of packages adding third party repositories and compiling from source. Other than gitosis packages were mostly copied over and iptables was successfully configured.

Finishing up with scp

Finally I had to copy over website, home folder files and a few config files. The perfect tool for this was scp. First I created a tar.bz2 archive for folders I wanted to copy.

1

tar -cjf vhosts.tar.bz2 /var/www/vhosts

Then I copied over the archive to my new Linode instance

1

scp vhosts.tar.bz2 george@123.456.78.90:/var/www

Finally I unarchived it on the Linode instance

1

tar -xjf vhosts.tar.bz2

The great thing about using this approach is that permissions are preserved.

The last part was to change the name servers for my domains over to Linode.

Thanks Slicehost

Slicehost was a great service and the articles in particular helped me to skill up on UNIX and respond to many different scenarios. I’m sad that Slicehost will no longer be around and in particular that the service offering is so different from Rackspace. Slicehost was cloud hosting before it became trendy and now cloud hosting is something entirely different. I hope Linode can make me as happy - so far so good.