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?
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" } |
# 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 |
#!./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: |
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").
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
by Jonathan Rochkind, http://bibwild.wordpress.com
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".
# 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'], |
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", |
#!/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) |
# Simple web server | |
# Use N_ envvar to identify the process | |
run lambda {|env| | |
[ 200, {}, "Ok @ #{ENV["N_"]}"] | |
} |