danielsdeleo

#!/usr/bin/env ruby

recipe_path = ARGV[0]

if recipe_path.nil?
  STDERR.puts "usage: chef-apply RECIPE_FILE"
  exit 1
end

recipe_path = File.expand_path(recipe_path)

jtimberman

application "redmine" do
  path "/opt/redmine"
  owner "nobody"
  group "nogroup"
  repository "git://github.com/redmine/redmine.git"
  revision "2.0-stable"
  packages ["build-essential",
            "git",
            "postgresql-server-dev-all",
            "libgraphicsmagick++-dev",

jtimberman

# Put this in ~/chef-repo/data_bags/aws/main.rb
# Upload it to the Chef Server with:
#
#   knife data bag item rb aws main.rb
#
# Export the two AWS values for your account.

{
  'id' => "main",
  'aws_access_key_id' => ENV['AWS_ACCESS_KEY_ID'],

jrochkind

A Capistrano Rails Guide

by Jonathan Rochkind, http://bibwild.wordpress.com

why cap?

Capistrano automates pushing out a new version of your application to a deployment location.

I've been writing and deploying Rails apps for a while, but I avoided using Capistrano until recently. I've got a pretty simple one-host deployment, and even though everyone said Capistrano was great, every time I tried to get started I just got snowed under not being able to figure out exactly what I wanted to do, and figured I wasn't having that much trouble doing it "manually".

ordinaryzelig

I'm a fan of MiniTest::Spec. It strikes a nice balance between the simplicity of TestUnit and the readable syntax of RSpec. When I first switched from RSpec to MiniTest::Spec, one thing I was worried I would miss was the ability to add matchers. (A note in terminology: "matchers" in MiniTest::Spec refer to something completely different than "matchers" in RSpec. I won't get into it, but from now on, let's use the proper term: "expectations").

Understanding MiniTest::Expectations

Let's take a look in the code (I'm specifically referring to the gem, not the standard library that's built into Ruby 1.9):

# minitest/spec.rb

module MiniTest::Expectations

jtimberman

#!./bin/knife exec

# A knife exec script to change chef node's name, preserving all the attributes.
#
# Usage: knife exec rename-node.rb old-name new-name
#
# Script retrieves the Node object, changes its 'name' attribute,
# creates new Node object with updated name and rest of attributes
# untouched. Then it deletes old Node and Client objects from
# database, and logs into the server to update it:

fnichol

Vagrant apt-cacher-ng Box

Simple and easy, just:

mkdir apt-cacher-ng && cd apt-cacher-ng
curl -LO https://raw.github.com/gist/1747868/Vagrantfile
vagrant up

Tail the logs perhaps?

jtimberman

# Knife Configuration File.
#
# This is a Ruby DSL to set configuration parameters for Knife's
# general options. The default location for this file is
# ~/.chef/knife.rb. If multiple Chef repositories are used,
# per-repository configuration files can be created. A per repository
# configuration file must be .chef/knife.rb in the base directory of
# the Chef repository. For example,
#
#     ~/Development/chef-repo/.chef/knife.rb

karmi

require 'fog'
require 'chef/config'

Chef::Config.from_file('./.chef/knife.rb')
EC2 = Fog::Compute.new provider:              'AWS',
                       region:                Chef::Config[:knife][:region],
                       aws_access_key_id:     Chef::Config[:knife][:aws_access_key_id],
                       aws_secret_access_key: Chef::Config[:knife][:aws_secret_access_key]

servers = EC2.servers.select { |s| s.tags["Name"] =~ /ec2\-test\-/ && s.state == "running" }

fnichol

Installation

gem install thor
mkdir -p ~/vagrants && cd ~/vagrants
curl -LO https://raw.github.com/gist/1528832/vagrantify
chmod 755 vagrantify

Usage

./vagrantify init webserver