Skip to content

Vagrant: ShellProvisioner vs. Chef

In my last blog entry, I demo'd how to get started with Vagrant and the ShellProvisioner.

To further illustrate how amazingly simple it is to get started on some Ruby, I'll convert the shell script from my last blog post to a little recipe for chef. Same objective, we install a PEAR package — but it could be anything really.

Follow me.


This is the shell script from before:


apt-get update

apt-get install -y php5 php5-cli php-pear
hash -r

pear upgrade-all
pear install -f HTTP_Request2


Create a cookbooks directory and create structure for your first cookbook in it:

$ mkdir -p my-cookbooks/first/recipes/

Create a default.rb file with the following content:

# my-cookbooks/first/recipes/default.rb
execute "apt-get update"

packages = ["php5", "php5-cli", "php-pear"]

packages.each|p| do
  package p

execute "pear upgrade-all"
execute "pear install -f HTTP_Request2"

The recipe is later referred to as first or first::default (name of the recipe directory, name of the .rb).

It's so simple it hurts. ;)

Step by step

  1. I run apt-get update using Chef's execute resource.
  2. I create an array of the packages (Arrays are ordered in Ruby, hashes are not (up until Ruby 1.9.x). Order is important here.)
  3. I run pear upgrade-all using the execute resource.
  4. I run pear install using the execute resource.


The Vagrantfile looks slightly different when you provision with chef-solo: do |config|
  config.vm.define :web do |web_config|       = "lucid64"
    web_config.vm.host_name = "web"
    web_config.vm.provision :chef_solo do |chef|
      chef.cookbooks_path = "PATH-TO-YOUR-COOKBOOKS"
      chef.add_recipe "first"
      chef.log_level = :debug


The important bit: the path to the location of your cookbooks — could be an /absolute/path or ./../relative/path.

Because a Vagrantfile is essentially Ruby code, anything goes here.

Further reading

Getting started with Chef and Ruby can be intimidating or even frustrating at times. Google "chef cookbooks" and you know what I mean.

These links are what you need:


Save, and enjoy — vagrant up.

Vagrant sans Ruby

Development, testing, staging and production — this is how most people devide up different environments for application development.

Maintenance and setup of these environments is often not a trivial goal to achieve. Having worked with a couple different code bases and setups over the last decade, I often noticed things like environment specific hacks (if ($env == 'testing') { ... }) in application code and service configurations and a lot of manual labour all around. It's still very common that code deployed to staging does not work — but it worked for you right?

And it's also too common that members of a team do not know how something works because whoever set it up is currently out sick or on vacation.

My opinion is that the best setup currently available is something like: chef(-solo) on the server and Vagrant on the desktop. Something like because aside from chef, there is also puppet, cfengine and a couple others. Leaving specific projects aside, it really just boils down to automation (within reason).

Automation in my opinion is not just the easiest but the only viable way to setup development, testing, staging and production environments. Without some automation in place it's required that all team members know how all of it works when maybe that is not yet important and the end goal is that all environments actually resemble each other.

Enter Vagrant

Vagrant is a very nifty toolkit to bootstrap Virtualbox images. Bootstrapping means installing your application stack into one or multiple virtual machines in order to resemble production a lot better.

So a lot of times when I rave about how useful Vagrant and chef are, I get the crazy eye from PHP developers:

You want me to learn Ruby to setup my local development environment?

My response:

  1. Do not fear the Ruby.
  2. You don't have to. (Well, not a whole lot!)

Real talk

First off, of course you need Virtualbox — get a download from their website or use your package manager.

Then, it's not possible to avoid Ruby a 100% — after all Vagrant is written in Ruby.

When you're on a Linux or a Mac, this is usually enough (you may need sudo unless you RVM):

$ sudo gem install vagrant

For a sudo-less install, use RVM:

$ sudo gem install rvm
$ rvm install
$ rvm use 1.8.7

When set up, this is what you do:

$ gem install vagrant

RVM allows me to run multiple versions of ruby side by side and also leverage local gem installs — per Ruby version. Think of it as a nifty way to run multiple PHP versions and have a PEAR install per version — similar projects exist for PHP today:

To learn more about RVM, visit their website.

Once vagrant is installed, we can continue!

ShellProvisioner for fun and profit

So, in case you are more comfortable writing some shell script for the time being — Vagrant got you covered!

First off, create a new Vagrantfile for your project:

$ mkdir -p Documents/workspaces/blog-example/
$ cd Documents/workspaces/blog-example
$ vagrant init lucid64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`` for more information on using Vagrant.

lucid64 (Ubuntu Lucid 10.04, 64bit) is the name of one of my local box files for Vagrant. In case you haven't got a box yet, head over to There are a couple images you (aka box files) you can download. To get the lucid64 box, use the following command:

$ vagrant box add lucid64

Once you made it past vagrant init, you should have a Vagrantfile with a lot of stuff in there.

While it's not important for my tutorial, I recommend you review it some (other time). The created Vagrantfile contains examples for all the provisioners (puppet, chef and shell) and a couple other configuration options, etc..

Let's skip over this and get to the ShellProvisioner.

This is all you need

First off, let's create a shell script in the same directory and put something like this in it:


apt-get update

apt-get install -y php5 php5-cli php-pear
hash -r

pear upgrade-all
pear install -f HTTP_Request2

What does it do?

  1. Update local package sources.
  2. Install php5, cli interpreter and PEAR installer
  3. reload environment
  4. upgrade all installed PEAR packages
  5. install PEAR HTTP_Request2

When you're done editing, make sure to chmod +x it.

Simple as that.

Putting your shell script to use

Replace your Vagrantfile with the following: do |config| = "lucid64"
  config.vm.provision :shell, :path => "./"


Then, run vagrant up and watch it provision. :)

Enter your virtual machine with vagrant ssh and verify HTTP_Request2 is installed:

$ vagrant ssh                                                                                                                                                               [14:16:08]
Linux lucid64 2.6.32-33-server #70-Ubuntu SMP Thu Jul 7 22:28:30 UTC 2011 x86_64 GNU/Linux
Ubuntu 10.04.3 LTS

Welcome to the Ubuntu Server!
 * Documentation:
Last login: Thu Jul 21 14:08:15 2011 from
[email protected]:~$ pear list -c pear
Installed packages, channel
Package          Version State
Archive_Tar      1.3.10  stable
Console_Getopt   1.3.1   stable
HTTP_Request2    2.1.1   stable
Net_URL2         2.0.0   stable
PEAR             1.9.4   stable
Structures_Graph 1.0.4   stable
XML_Util         1.2.1   stable

Yay — your first steps into automation!


That's all for today — Vagrant with almost no Ruby. I hope this gets many more started!

Composer and chef updates

Here are some updates on my chef resource for composer:

It started off with a PR where I was asked to include code that would download (and install) a composer.phar if none existed. Not a bad idea in general, but also not something I want to impose on anyone, so I decided to create a new action (or in chef-lingo goal) instead.


Up until now, my php_composer resource supported :install which runs php composer.phar install when a composer.phar is in the designated directory:

php_composer "/var/www/app" do
  action :install

Since an hour or so ago, it also supports :setup. And :setup will download composer for you if requested:

php_composer "/var/www/app" do
  action [:setup, :install]

Note: I'm not sure if this is a good idea for a couple of reasons — the most obvious one: could be unavailable when you run your deployment. And then there may or may not be changes in the latest composer.phar which require you to make adjustments to your local composer.json. I prefer my deployments rock-solid to minimize side-effects! :)

Getting started

My resource will use composer but it's generally a chef-no-no to also install the tools required by the resource.

A small list of items you will need:

  • php 5.3+
  • the Phar extension
  • git-core (and/or subversion)
  • unzip (or PHP's zip extension)

For an idea how to set these up with chef, see my vagrant-test::default recipe.


I haven't really decided on a roadmap, but here are a few things I want to implement in the coming weeks:

  • If you're feeling frisky: support for php composer.phar self-update.
  • Support for php composer.phar update!
  • An attribute to provide the location of a phar (e.g. local or network file-system, CDN, etc.).
  • Support for --install-dir.

I'm open to contributions on any of these items, my requirements are:

  • Code must be robust.
  • Code must be robust.
  • Your additions should work on Ubuntu and Linux in general. :)


That's all. Check it out on Github!

Zend Framework: CRUD

Update, 2012-05-24: Fixed some typos and added the screenshot (eyecandy!).

I think it took me (or us) a couple attempts to get this right — let me introduce you to Zf_Crud, a CRUD controller for the Zend Framework.

What's CRUD?

CRUD is an acronym and stands for:

  • Create
  • Read
  • Update
  • Delete

A general purpose for CRUD are administrative interfaces — view records, create them, update them or delete them. Think of phpMyAdmin as a very general purpose CRUD interface. One you need some SQL-fu for.

In my experience, such interfaces are most likely or often the very last item on a project. Not too many people (myself included) like to build these interfaces primarily because we have build them before. They are necessary non-the-less: not everybody on a project is a developer and feels comfortable writing SQL queries into phpMyAdmin to get data out (or in).


Zf_Crud aims to provide you with an interface for any table possible — think of it as a phpMyAdmin more tailored towards your data and (thanks to Twitter Bootstrap and the Easybib_Form_Decorator) prettier!


Note: We haven't setup a PEAR package yet. I'll get to it soon, but feel free to submit a PR with a package.xml.


The only technical dependencies are PHP 5.3+ and the Easybib_Form_Decorator:

$ pear channel-discover
$ pear install easybib/Easybib_Form_Decorator

The other dependency is a working Zend Framework (1) application and an idea what you're doing.


To setup Zf_Crud, clone (or export) it into your local vendor library:

Our Zend Framework projects have the following structure:

  • app/modules/<module>/library/vendor

To export with git, just do the following:

$ cd app/modules/foo/library/vendor
$ git clone git:// ./Zf_Crud
$ cd Zf_Crud && rm -rf .git

Then check it into your own VCS.

If you don't have git (and cannot install it), get a download of Zf_Crud from Github.

Composer, you ask?

With the initial public release, we also added composer:

  "require": {
    "php": ">=5.3.0",
    "lagged/Zf_Crud": "0.5.1"


Working with Zf_Crud should be super-simple and easy!

In your module (e.g. foo), create a controller in app/modules/foo/controllers/AdminController.php.

use Lagged\Zf\Crud\Autoload as CrudAutoload;
use Lagged\Zf\Crud\Controller as CrudController;

require_once dirname(__DIR__) . '/library/vendor/Zf_Crud/library/Autoload.php';

class Foo_AdminController extends CrudController
    protected $model = 'Foo_Model_SomeTable';
    protected $title = 'My Interface';

Next, create a plain model using Zend_Db_Table_Abstract:

class Foo_Model_SomeTable extends Zend_Db_Table_Abstract
    protected $_name = 'some_table';

The (naming convention in ZF1 is not PSR-0 and a little weird. In case it's not obvious: the) model should live in: app/modules/foo/models/SomeTable.php.

Last but not least: Zend_Db_Table means RDBMS. Zf_Crud expects a Zend_Registry-key called dbAdapter to work. If your's is called differently, skip to the "Convention over Configuration" section.

Anyway — once these two files created (and assuming the rest is setup correctly), you should see something like the following:


Convention over configuration

I'm a fan of convention over configuration and it's the approach we selected when we build Zf_Crud.

The idea is that it should work out of the box without setting up a huge application.ini or DIC, in case you want to tinker with it when you're up and running, here is how.

Since you're extending from the Lagged\Zf\Crud\Controller, this controller has a few configuration options. Configuration is probably too advanced since these are essentially a bunch of class-properties you can overwrite in your class or via init():

// setup here
class Foo_AdminController extends CrudController
    protected $model = 'Foo_Model_SomeTable';
    protected $dbAdapter = 'db';

Some of the gems are:

  • $where: a WHERE-clause for the data query
  • $order: column to order by
  • $hidden: hide these columns from display
  • $count: number of items per page


We've been using this code for a couple months now for various items. We recently tagged an early 0.5.1 which suggests that this code is still a WIP and a moving target. The configuration bits are not too great elegant yet. So there are a lot of rough edges to be aware of.

The bottom line is that Zf_Crud has been good for us since it allows us to take the pain out of building administrative interfaces. In most cases it's setup in an hour tops and then we can move on to build something more interesting than a couple forms and views to display and edit data.

If you have anything to add — comments and pull-requests welcome!

Expose services via an ssh tunnel

Ever since I remember, I have this inability to learn the most basic things, until I actually write down a couple notes or instructions somewhere. This is one of these notes blog posts — so in case it's too basic, just skip over it. Or bear with me.

ssh tunnels — useful and powerful. They can help me with all kinds of trickery — e.g. usually for remoting through a tight firewall setup to access remote resources. So point taken there are a lot of GUIs for this, but if you spend a couple minutes with the ssh man page, you will realize how amazingly simple they are.

My example for an ssh tunnel put to good use is our production gearman setup: The gearmands runs isolated on EC2. On the upside: pretty secure, but the downside is that the service is unavailable when you need to a little live data for some local tests. When we added an interface to get more visibility into the processes we push through gearman, of course we couldn't access it.

A tunnel to the rescue!

Consider this:

[email protected]$ screen -S gearman-ssh-tunnel
[email protected]$ ssh -L 2222: production-gearmand
Linux Ubuntu SMP AMD64

Last login: Sat May  5 16:22:47 2012 from YYY.YYY.YYY.YYY
[email protected]:~$

("ctrl + a + d", to detach from screen.)

So what does that do?

First off, we are starting a session in screen: it's called "gearman-ssh-tunnel". You could use tmux as well, but screen works just as nice.

The consecutive command maps port 2222 on my (local) macbook to a service running on the server production-gearmand (this is via .ssh/config) but only listens on

Your .ssh/config could look like this:

Host production-gearmand
User till
IdentityFile ~/.ssh/gearman.pem

If I wanted to connect to this server in a PHP-script on my macbook, I would use the following configuration:

$client = new GearmanClient;
$client->addServer('', 2222);

Run it from the terminal:

[email protected]$ php gearman-ping.php


Need to stop the tunnel?

The following command lets you resume your session with screen:

[email protected]$ screen -r gearman-ssh-tunnel

Type exit twice, or hit "ctrl + d" to log off the server and "ctrl + d" again to kill the screen. Done.


Bonus points if you use this from your VM in vagrant. But otherwise, that's all for today.