Dolly – The case against deploy drama

These are the slides from a presentation I made concerning deployments and how we can avoid downtime and drama.

Dolly – Deploying



Oh, the places you’ll go…

Inspired from the Practicing Ruby entry, I somewhat clarified the code a little (for my taste) and learned that the call stack in Ruby is:

0) Undefined method resolution
1) Methods defined in the object’s singleton class (i.e. the object itself)
2) Modules mixed into the singleton class in reverse order of inclusion
3) Methods defined by the object’s class
4) Modules included into the object’s class in reverse order of inclusion
5) Methods defined by the object’s superclass, i.e. inherited methods

module ModuleA
 def foo
   "- Mixed in method defined by ModuleA\n" + super
module ModuleB
  def foo
   "- Mixed in method defined by ModuleB\n" + super
module ModuleC
  def foo
   "- Extended in method defined by ModuleC\n" + super
module ModuleD
  def foo
   "- Extended in method defined by ModuleD\n" + super
class A
 def foo
   "- Instance method defined by A\n"
class B < A
 include ModuleA
 include ModuleB
 def foo
    "- Instance method defined by B\n" + super
  def method_missing(method)
   puts "- method_missing (#{method}) on b. Redeirecting to\n"
b =
 "- Method defined directly on an instance of B\n" + super
def b.method_missing(method)
 "- method_missing (#{method}) on b. Calling super\n" + super
puts "Calling 'bar' on b of type #{b.class}:\n"

Which gives:

~/projects/ita/ruby$ ruby test.rb

Calling ‘bar’ on b of type B:

– method_missing (bar) on b. Redeirecting to
– method_missing (bar) on b. Calling super
– Method defined directly on an instance of B
– Extended in method defined by ModuleD
– Extended in method defined by ModuleC
– Instance method defined by B
– Mixed in method defined by ModuleB
– Mixed in method defined by ModuleA
– Instance method defined by A

Follow the conversation on Stack Overflow.

Puppet book review

This book is an excellent Puppet book for beginners and professionals alike.

I manage a software team and have read this book cover-to-cover in order to study Puppet for our team’s use on a daily basis.

Despite step-by-step instructions for the initial installation, I needed some tinkering since different OSs have slightly different distributions, but once I had a server and agent running on two different VMs (Ubuntu) – there was an “Aha!” moment when the agent had emacs automatically installed on it! Getting past the initial installation phase allowed me to really enjoy the rest of the book as well as enjoy Puppet itself.

Puppet is not trivial, but the book covers its concepts very clearly and one “gets” it quite early on (especially if you get your hands dirty and follow along the examples).

The book then expertly guides the reader to its “pro” section detailing use of Puppet with configuration management tools such as git and db-based storage.

It then goes on to detail how to use AMQ with Puppet for scaling. I doubt I will use such a robust configuration, but was thrilled to see how flexible and extensible Puppet is by use of load-balancers and integration with Apache/Passenger.

Overall, the book is well written, and I would highly recommend it as a *text book* for Puppet. This is a readable text book on the subject – not a reference manual, although it has countless links to the reference manuals.

I always wanted to learn Puppet, and this book certainly is the one to read if you’re dealing with configuration management whether as a developer or a DevOps person.

Setting up a Rails server on a GoDaddy VPS

I thought my experience with setting up a Centos 5 box from scratch with Rails 3.1 would be helpful to some readers.

1. Get a VM – this one is on GoDaddy, just for kicks.

Demo config:

Operating System: CentOS 5
Disk Space: 20 GB
And it costs $30 a month. Not too bad.

2. Get some tools

Become root for that: “$ su -”

Then issue:

# yum groupinstall ‘Development Tools’
# yum groupinstall ‘Development Libraries’
# exit

3. Install your ssh key for logins

Copy your key to ~/.ssh/authorized_keys

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

4. Install node.js

Become root for that: “$ su -”
Then issue:

# cd /root
# wget
# gunzip node-v0.4.11.tar.gz
# tar -xf node-v0.4.11.tar
# cd node-v0.4.11
# ./configure
# make
# make install
# exit

5. Install Git

Become root for that: “$ su -”
Then issue:

# yum install gettext-devel expat-devel curl-devel zlib-devel openssl-devel
# yum install zlib-devel
# yum install openssl-devel
# yum install perl
# yum install cpio
# yum install expat-devel
# yum install gettext-devel

# wget
# tar xzvf git-latest.tar.gz
# cd git-{date}
# autoconf
#./configure –with-curl=/usr/local
# make
# make install
# exit

6. Install RVM

$ bash < <(curl -s

then add
[[ -s “/home/your-user/.rvm/scripts/rvm” ]] && source “/home/your-user/.rvm/scripts/rvm”
to the end of .bash_profile

8. Install readine

$ rvm pkg install readline

9. Install ruby

$ rvm install 1.9.2 –with-readline-dir=$rvm_path/usr

10. Create a gemset

$ rvm gemset create rails3.1

$ rvm –default use 1.9.2@rails3.1

11. Load Rails3.1

$ export LC_CTYPE=en_US.UTF-8

$ export LANG=en_US.UTF-8

$ gem install rails 3.1

12. Create ssh key for git repo

$ ssh-keygen -t rsa

13. Upload the public key to your repo

Make sure the end of the key file has a newline

Test access by issuing
$ git clone ssh://

14. Install bundler

$ gem install bundler

Test bundler by running ‘bundle install’ in the directory created by (6)

15. Install mysql

Become root for that: “$ su -”

Then issue:

# yum install mysql
# /etc/init.d/mysqld start
# exit

16. Get a copy of your project

From git by cloning the repo and run ‘rake spec’ to see that everything is installed and running correctly
This assumes you use rSpec, else run ‘rake test’, or whatever testing framework you use.

17. Install passenger

$ gem install passenger
$ passenger start

18. Test it out…

Navigate to http://xxxx:3000 to see your app!

Hello world!

This seems to be a nice place to organise my thoughts. Please don’t think that I presume that those are at all worthy to be published just because they appear here. I’ll use this shoebox as a platform to solicit constructive criticism in order to chop away at my ignorance.