Think Then Code by Dominic Umbeer

How to Provision a Single-Node Cassandra Cluster with Chef

2014-09-20 - Chef, Cassandra, Vagrant

This article describes how you can quickly install and run a single-node Cassandra cluster with Opscode Chef in a Vagrant box.

Anybody who doesn't know either Chef or Vagrant yet should check out their websites.

Vagrant 1.4.2 with the Berkshelf and Omnibus Vagrant plugins is installed on my local machine. Berkshelf helps you manage your cookbook dependencies without maintaining your own repo, while Omnibus keeps your Chef version in your Vagrant box up-to-date automatically. Both plugins are very handy tools and you should definitely check them out.

Because I don't want to reinvent the wheel, my first step was to find existing cookbooks and my search uncovered the following:

  1. A cookbook from the Opscode community website -
  2. Another cookbook on Github -

At first sight both cookbooks looked promising. The first cookbook had a decent amount of recent downloads and positive ratings. The second one was and is under continuous development.

I started testing the first cookbook, but without success. After various configuration changes I finally got a meaningful error message that the cookbook wasn't able to download the thrift package. The resource isn't available any more. Not good news.

If you want to try it yourself please check out my gist on Github. It includes the Vagrantfile and Berksfile.

After some research I also realised that the last update of this cookbook was released on 31st January 2012, I couldn't find the source code on the internet and I haven't found any useful documentation. Putting all the facts together, my enthusiasm for working with that cookbook went off the boil...

Fortunately we have an alternative cookbook, which actually is great. Installation and usage went smoothly and I was cooking on gas. Everything I had wanted could be achieved with this simple cookbook. (Below you will find the Vagrantfile and Berksfile.)

If I had to say something against it, I do have one small issue, but even that doesn't relate directly to the cookbook itself. What it is, is that the versions of the Cookbook aren't apparent from the repository tags, as the contributors only increase the cookbook version within the metadata.rb.

The dependency definition with Berkshelf would be clearer if we could write something like this

cookbook "cassandra", git: "", tag: "2.0.0"

instead of

cookbook "cassandra", git: "", ref: "e8f260247b9a4897255d2821daeed129a5a352a0"

Who can recognise what cookbook version is hidden behind the commit id? If you can do it … you're a genius ;)


cookbook "cassandra", git: "", ref: "e8f260247b9a4897255d2821daeed129a5a352a0"


# -_- mode: ruby -_-

# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!


Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| = "precise64"

config.vm.box_url = ""

config.berkshelf.enabled = true

config.omnibus.chef_version = :latest

config.vm.provision "shell", inline: "sudo apt-get update"

config.vm.provider :virtualbox do |vb|
  vb.customize ["modifyvm", :id, "--memory", "1024"]

config.vm.provision :chef_solo do |chef|
  chef.add_recipe "cassandra"
    chef.json = {
      :cassandra => {
        :version  => "1.2.13",
        :listen_address => 'localhost',
        :broadcast_address => 'localhost',
        :rpc_address => 'localhost'

Anyway, it doesn’t detract from the effectiveness of this cookbook.

Let us take a look at the attribute definitions. There are three important attributes that need to be defined in order to install and run Cassandra as a single-node cluster, namely listen_address,broadcast_address and rpc_address. All of them need to be set to localhost. Otherwise the Cassandra installation would expect and search for other existing Cassandra nodes, without success.

Cassandra-chef-cookbook from michaelklishin totally works for me and I'm very happy that someone is constantly maintaining it. Keep up the good work, guys! :)