In this presentation I explain how you can start with a simple, standard deploy, then expand that into a multi-stage deploy. And finally I refactor that using the capistrano-ext gem to give you the framework for a extensible multi-stage deployment strategy for the long haul.

On August, 28th I presented a talk about how to use the Vagrant gem to build a chef-solo development environment. It’s a great way to locally provision and test chef recipes without the need of a VPS account or an external service.

Shared Folder Demo

local$
ls
echo "<h1>Hello from a Vagrant VM</h1>" > index.html
vagrant ssh

vagrant$
ls /vagrant
wget -qO- 127.0.0.1

BROWSER
http://localhost:4567

local$ 
cd ~/code/personal/chef_projects/demo/
mkdir -p chef/cookbooks/main/recipes/
touch chef/cookbooks/main/recipes/default.rb
touch solo.rb
touch node.json
subl .

Presented at the Utah Valley Ruby Brigade on May 8th, I discussed how to use chef-solo to take a blank provisioned VPS and apply chef recipes. These recipes can then build the server you desire and chef is a Ruby DSL built by Opscode.

Tonight marks the passing of a computer that I’ve had for 10 years!

10 years ago there was a big schism in the RAM architecture world. And when I was building my machine I got caught in the middle of this debate. Should I go with DIMM or RIMM memory? What was better technology? At that particular moment, DIMM’s main selling point (if I even remember correctly) was price. And that’s ultimately how they won. Like the argument of VHS versus Beta, Beta may have been the better technology, but VHS made it to market cheaper. Probably because Sony was being proprietary dorks about Beta, but that’s not what this is about…

Yet I chose RIMMs, why? Because you don’t know the POWER of the dark side! In hind sight I backed the wrong horse. Because even though in 2003 1 GB of ram seemed like a lot, eventually when I wanted to upgrade later, the costs to upgrade were so prohibitive it would have been cheaper to replace the motherboard and CPU, than upgrade to 2GB of ram.

Ironically it was that 2GB upgrade that was the final nail in the coffin of our tale, but we’ll come back to this…

Over the years that machine has seen every configuration and upgrade possible. I’ve had multiple optical burners, a number of hard drive configurations from single system to RAID arrays. I’ve upgraded the video card 3 different times, and even on an AGP 8x slot no less! The final card being one that could actually run modern flash sites like Hulu decently (paired with a CPU upgrade as well.)

And through it all the motherboard, the original GIGABYTE GA-8IHXP rev 2.1 has been the champion. I even eventually renamed this computer “Blue Phoenix” because it has risen from the ashes of so many re-configurations that it seemed unbreakable. (Blue was from the color of case at the time.)

This computer even survived two cross-country moves from Utah to Florida, then Florida back to Utah, and still worked fine. The only problem I had when we got back from Florida was the case had got banged up by my Aluminum Mac tower so bad, that it was really scratched up. So I decided to buy a new case and thus, the phoenix rose from the ashes, reborn again as the “Dark Phoenix” in it’s new black case.

I’ve got other computers I use now on a daily basis. Like the one I’m typing this blog post on, my iMac. But I still had uses for the “Dark Phoenix”. As I mentioned before, I had upgraded the CPU and with that upgrade I was able to have a better response with running video capture card and turning the computer into a HTPC (Home Theater Personal Computer).

Basically it could serve as a DVR (Digital Video Recorder) and record TV for us, and we could watch anything recorded on the Xbox. Or we could pause live TV. It was great!

Then my mom’s computer died on her and she needed to have a computer, until she got a replacement. So I offered her my Dark Phoenix box as a temporary replacement. She has had it for the past few months and then we just replaced it with a Macbook Air for her.

That’s when I brought the Dark Phoenix home, and had bought 2 GB of ram to put into the machine. Time had finally caught up where the RIMM prices were low enough that I could justify the upgrade. And so I began to try and put the ram in.

At first it wouldn’t boot up, so I replaced the old ram back in and tried to reboot and it came back up, but not consistently.

The next day, while I was on the phone with someone from work, a loud POP noise came from the direction of the computer. I checked to see if there were any suspicious “electronics smells” that usually accompany a bad frying of circuits, but there was nothing.

So this weekend I tore down the entire machine and cleaned everything. I built it back up to the bare minimums, using only the old ram (which should have worked because it was working before). And I even tried replacing the video card (part of a minimum boot up) with an old video card. And still… no luck.

It is with profound sadness that I must bid farewell to my friend the Dark Phoenix. To me, at least, psychologically, if I have to replace the motherboard, the machine just isn’t the same and is a new computer. The motherboard is the “heart and soul”, and all other components are just upgrades.

RIP Dark Phoenix. 8/3/2002 - 1/22/2012

On Tuesday I was given the opportunity to give a presentation on rake at our Utah Valley ruby brigade.  I chose to cover some of the basic building blocks and comparative history of other build tools.

I was inspired by Martin Fowler’s Using the Rake Build Language and Josh Nichols presentation Rake: The Familiar Stranger.

Hudson CI

The Hudson Continuous Integration server, built on Java, has been adopted by Dr. Nic. He has pioneered the engineyard-hudson project that helps grease the wheels and get a Hudson server running on Engine Yard’s AppCloud in just minutes.

Dr. Nic recorded the screencast footage and then I assisted by providing my best “radio voice” for the final voice-over and mixed in our latest screencast mojo.

REVISION: Hudson became Jenkins, check out the blog article on how to Boot Up Your Own Dedicated Jenkins CI in Two Commands and https://github.com/engineyard/eycloud-app-jenkins/ is the updated repository.

Fun With Sledgehammers

While I was recently in San Francisco we had a company meeting and celebrated a huge milestone. We had recently completed an almost year-long migration from our original legacy hardware to our new cloud based virtual machine offerings.

And so Tom Mornini and Ed Muller were able to take a swing at some of the original hardware with a Sledgehammer.

Quickcasts

To answer an answer quickly, and in screencast form, I created the Amazon Out of Capacity Quickcast and published it.

The most popular size EY AppCloud offers is the High CPU Medium. Sometime this size will not be available at the time a user would like to boot an instance. So this video outlines a simple step you can take to get the instance to boot, even when demand is high.

Knowing How To Upgrade

This screencast shows you how to upgrade your Engine Yard AppCloud instance from it’s current size to the next size you need. Whether that’s small to medium or more.

Now if you just knew when to upgrade. I mean other than after hours…

Server Setup

By the end of this screencast you’ll have a server running on linode with MySQL, REE, Passenger and Nginx ready to receive your application.

I will provide code snippets here in the blog article so you can copy and paste them into your terminal.

Boot Linode Instance

The steps in the screencast outline what to do, there isn’t anything you need to copy and paste from this section.

Setup Deploy User

I’ll be using the convention of root#, deploy$ and local$ to make it clear where and what user the command needs to be run as and where.

root# adduser deploy
root# visudo

# in the visudo file add the deploy user
deploy ALL=(ALL) ALL

root# /etc/init.d/ssh reload

Local Configuration

# Setup a ssh hostname.
local$ nano ~/.ssh/config

Host rumblebox
Hostname     173.230.157.182
User         deploy

# Authme function
local$ nano ~/.profile

function authme {
ssh $1 'cat >>.ssh/authorized_keys' <~/.ssh/id_dsa.pub
}

# source your profile
local$ . ~/.profile

# log in and create .ssh folder
local$ ssh rumblebox
deploy$ cd ~
deploy$ mkdir -p .ssh

# now you'll be able to send your ssh key
local$ authme rumblebox
local$ ssh rumblebox # and you'll be logged in without a password prompt.

# If you have a passphrase on your ssh key you can use this cool trick:
local$ ssh-agent sh -c 'ssh-add < /dev/null && bash'

Install Server Packages

# prepare ubuntu
deploy$ sudo apt-get install build-essential git-core zlib1g-dev libssl-dev libreadline5-dev
deploy$ sudo apt-get update
deploy$ sudo apt-get upgrade

# install mysql
deploy$ sudo apt-get install mysql-server-5.1 mysql-client-5.1 libmysqlclient-dev zlib1g-dev libmysql-ruby1.8

# start mysql server
deploy$ sudo /etc/init.d/mysql start

# Test your sign in, change to *your* password
deploy$ mysql -uroot -prumbleROCK!

# install REE
deploy$ cd /usr/local/src
deploy$ sudo wget http://rubyforge.org/frs/download.php/71096/ruby-enterprise-1.8.7-2010.02.tar.gz
deploy$ sudo tar -xzvf ruby-enterprise-1.8.7-2010.02.tar.gz
deploy$ cd ruby-enterprise-1.8.7-2010.02
deploy$ sudo ./installer

# NOTE: change prefix to /usr/local so we don't have to mess with the PATH environment variable

# install nginx
deploy$ sudo passenger-install-nginx-module

# NOTE: remember to change prefix to /usr/local again

# configure nginx
deploy$ sudo nano /usr/local/conf/nginx.conf

server {
listen 80;
server_name _;
root /home/deploy/youstack/current/public;
passenger_enabled on;
}

# start nginx
deploy$ sudo /usr/local/sbin/nginx

IMPORTANT! Before your first bundler install on production will work you need to change permissions on the ~/.gem folder to deploy user.

deploy$ cd ~
deploy$ sudo chown -R deploy:deploy .gem/

Deployment Setup

After these steps and the second screencast you’ll be deploying to your Rails Rumble server! Let’s get started.

Generate Your App & Repo

local$ rails new youstack
local$ cd youstack/

local$ git init
local$ touch tmp/.gitignore log/.gitignore vendor/.gitignore

# .gitignore
.bundle
db/*.sqlite3
log/*.log
tmp/**/*
.DS_Store
.project

local$ git status
local$ git add .
local$ commit -a

# the 'git remote' command is an ex., you'll use the one for your team.
local$ git remote add origin git@github.com:filmprog/youstack.git
local$ git push origin master

Setup Github Deploy Key

# connect to the server and generate a key
local$ ssh rumblebox
deploy$ ssh-keygen -t rsa
deploy$ cat ~/.ssh/id_rsa.pub

# the git ls-remote command needs to be run before you can deploy
deploy$ git ls-remote git@github.com:filmprog/youstack.git

Configure Cap, Bundler & DB

Capistrano

local$ capify .

1. Copy and paste the deploy.rb from the following gist:

http://gist.github.com/625562

1. And replace the :application, :password, and :repository values.

2. Also you’ll need to update the IP address for your server.

Bunder

1. Add MySQL in the production group.

1
2
3

group :production do
gem 'mysql', '2.8.1'
end

1. Move SQLite 3 to development/testing group.

2. Run ‘bundle install’ locally.

   local$ bundle install

Database

production:
adapter: mysql
encoding: utf8
reconnect: false
database: youstack_production
pool: 5
username: root
password: rumbleROCK!
socket: /var/run/mysqld/mysqld.sock

Deploy Your App

# commit your changes and push them to github
local$ git status
local$ git commit -a -m "adding capistrano, bundler and database configuration"
local$ git push

# setup the folders and do your first deploy
local$ cap deploy:setup
local$ cap deploy:check
local$ cap deploy

# create your database on the server
cap> cd /home/deploy/youstack/current/; rake RAILS_ENV=production db:create