Robin Wenglewski - Articles

Push-Configuration and -Deployment with Chef Solo and Littlechef

2012-01-10T23:00:00Z

Introduction

Chef, Puppet and babushka are great tools for automating machine configuration and deployment. However, where babushka is not enterprise-ready, Chef and Puppet are designed for a server/client architecture. There are several cases where you do not want your servers to pull configuration automatically from a central place, but rather push your configuration to the nodes. Both, Chef and Puppet, provide a way to run recipes locally. However, as this is not the main use case, doing so lacks some level of usability.

There are two projects which got my attention as a wrapper around chef-solo: littlechef and soloist. Soloist seems to be made for configuring the current machine, whereas the strength of littlechef seems to be pushing and configuring remote machines.

I will describe here my setup for pushing configurations to nodes by utilizing littlechef.

Littlechef

There is a great blog post for getting started with little chef. In short, follow the installation guide on littlechef to get started. After the installation, you should have the command fix available in your path. To create your littlechef kitchen run


1
2
3

  mkdir littlechef
cd littlechef
fix new_kitchen

This should give you the folder structure described on littlechef:

auth.cfg: Authentication information needed to be able to connect to the nodes
nodes/: After recipes are run on [Nodes][], their configuration is stored here in JSON format. You can manually edit them or even add new ones. The name of a node should be its FQDN
cookbooks/: This will be your [Cookbooks][] repository
site-cookbooks/: Here you can override upstream cookbooks (Opscode’s, for example)
roles/: Where Chef [Roles][] are defined in JSON
data_bags/: Chef [Data Bags][]. JSON databag items. Search is supported
plugins/: Your plugin tasks

Installing cookbooks

Now there are several ways to install external cookbooks. I use braid because it keeps the cookbook code directly in the repository and can thus just be cloned and used on another machine (no git submodule init and no librarian-chef install).

With Braid


1
2

  gem install braid
braid add --branch master git://github.com/fnichol/chef-rbenv.git cookbooks/rbenv

This downloads the repository to cookbooks/rbenv, adds the information about the location and branch of the repository to a .braids file and commits it with the message

fa7c4c8 Braid: Add mirror ‘cookbooks/rbenv’ at ‘9ecda8b’ (2 minutes ago)

Using Librarian

The Librarian gem aims to be Bundler for your Chef cookbooks. Include a reference to the cookbook in a Cheffile and run librarian-chef install. To install with Librarian:


1
2
3
4
5
6
7
8

  gem install librarian
cd chef-repo
librarian-chef init
cat >> Cheffile <<END_OF_CHEFFILE
cookbook 'rbenv',
  :git => 'git://github.com/fnichol/chef-rbenv.git', :ref => 'v0.6.0'
END_OF_CHEFFILE
librarian-chef install

Using knife-github-cookbooks

The knife-github-cookbooks gem is a plugin for knife that supports installing cookbooks directly from a GitHub repository. To install with the plugin:


1
2
3

  gem install knife-github-cookbooks
cd chef-repo
knife cookbook github install fnichol/chef-rbenv/v0.6.0

As a Git Submodule

A common practice (which is getting dated) is to add cookbooks as Git submodules. This is accomplishes like so:


1
2
3

  cd chef-repo
git submodule add git://github.com/fnichol/chef-rbenv.git cookbooks/rbenv
git submodule init && git submodule update

Note: the head of development will be linked here, not a tagged release.

As a Tarball

If the cookbook needs to downloaded temporarily just to be uploaded to a Chef Server or Opscode Hosted Chef, then a tarball installation might fit the bill:


1
2
3

  cd chef-repo/cookbooks
curl -Ls https://github.com/fnichol/chef-rbenv/tarball/v0.6.0 | tar xfz - && \
  mv fnichol-chef-rbenv-* rbenv

Testing cookbooks with Vagrant

Vagrant can be used for starting virtual machines from the command line and configuring them with chef or puppet recipes. To avoid reinstalling my servers or creating EC2 machines, I use vagrant for testing my cookbooks.

For this to work you need to install VirtualBox. Then you can follow the installation guide on the vagrant website:


1
2
3

  gem install vagrant
vagrant box add base http://files.vagrantup.com/lucid32.box
vagrant init

You can find different pre-packaged boxes on vagrantbox.es. Before running vagrant up, you need to enable automatic configuration with chef-solo. Therefore, put this block in your Vagrantfile which should have been created by the vagrant init command:


1
2
3
4
5
6
7
8
9
10
11
12
13
14

  config.vm.provision :chef_solo do |chef|
  chef.cookbooks_path = "cookbooks"
  chef.add_recipe "quc"

  # You may also specify custom JSON attributes:
  chef.json = {"quc" => {
                "repository" => "https://rweng:pw@github.com/rweng/project.git",
                "dump" => "http://dl.dropbox.com/u/456244/dump",
                "data" => "http://dl.dropbox.com/u/456244/data.zip",
                "postfix" => {
                        "mydomain" => "domain.com"
                }
        }}
end

chef.json can contain arbitrary data that you want to pass into your cookbooks. I use it for sensitive information like passwords. When running vagrant up, you should get a detailed log about what is done in your recipes.

Using Littlechef

Authentication

My auth.cfg file contains only a reference to the default ssh configuration file:


1
2

  [userinfo]
ssh-config = ~/.ssh/config

You should handle all login related stuff in there. Please note that there is currently a bug when setting HostName to an IP instead of a FQDN.

Deploying Chef

Before applying your cookbooks to a remote machine, you need to make sure that chef is installed on it. Therefore, you can run fix node:youdomain.com deploy_chef. As described in the littlechef readme, deploy_chef:ask=no runs deploy_chef without confirmation.

If the machine was already configured with littlechef, the node.json file is downloaded and put in the node directory. This way, the json configuration does not have to be set again manually.

Applying Cookbooks

To apply a recipe to a node run




  fix node:domain.com recipe:vim




  fix node:domain.com recipe:"vim::test,othercookbook::recipe"

This creates the file nodes/domain.com.json with the content


1
2
3
4
5
6

  {
    "ipaddress": "10.192.221.110",
    "run_list": [
        "recipe[vim]"
    ]
}

You can add other attributes in this file to override the cookbook attributes:


1
2
3
4
5
6
7
8
9

  {
    "ipaddress": "10.192.221.110",
    "run_list": [
        "recipe[vim]"
    ],
    "vim": {
        "install_path": "/usr/local/vim"
        }
}

Conclusion

I learned to love littlechef. It enables me to push my cookbooks to remote machines and deploy my applications without having a chef master.

Feel free to point out any (spelling) mistakes or open questions in the comments.

References

From RVM to rbenv

2011-12-28T23:00:00Z

I decided to move from RVM to rbenv. rbenv is getting a lot of hype lately. Instead of overriding cd like rvm, it uses the already available UNIX functionality like adjusting the PATH to the ruby to use.

My move is mainly motivated by curiosity, although I have had some problems with rvm before and I hope that using rbenv will avoid them. During the migration, I mainly followed this excellent guide. Here is a summary with some additional information:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

  # remove all rvm files
$ rvm implode
WARN: Are you SURE you wish for rvm to implode?      
This will recursively remove /Users/robin/.rvm and other rvm traces?      
(type 'yes' or 'no')> 
yes
Removing rvm-shipped binaries (rvm-prompt, rvm, rvm-sudo rvm-shell and rvm-auto-ruby)
Removing rvm wrappers in /Users/robin/.rvm/bin
Hai! Removing /Users/robin/.rvm

/Users/robin/.rvm has been removed.
rvm has been fully removed. Note you may need to manually remove /etc/rvmrc and ~/.rvmrc if they exist still.%

$ rm ~/.rvmrc

# install rbenv and ruby-build
$ brew update
$ brew install rbenv
$ brew install ruby-build

Now we add eval "$(rbenv init -)" to .zshenv as described in the rbenv README. After starting a new session, we should be able to see the current ruby being used with rbenv global (which should be system). Run rbenv versions to see all rubies that can be installed with ruby-build. To install ruby 1.9.2, run rbenv install 1.9.2-p290. Now you can set this as the default ruby with rbenv global 1.9.2-p290. Deleting a ruby version and its gems is as easy as rm -r ~/.rbenv/versions/[VERSION].

Bundler

rbenv does not come with gemset support. rbenv-gemset is an extension for rbenv that brings this functionality to rbenv. However, bundler is a pretty awesome tool for managing gems and dependencies so I decided to stick only with that. After installing the gem and running bundle install in one of my projects I noticed that the binaries of the dependencies were missing. Usually with rbenv, you only have to install the gem and run rbenv rehash to make the binaries available.

After researching this a little bit I noticed, that the missing binaries are not a problem but a feature. Binaries of projects managed with bundler are usually executed with bundle exec [BINARY] anyway. Since I am lazy I usually run bundle exec only when I know that a different version than the globally available one is specified in the Gemfile. However, it is far safer to always use bundle exec. Running them this way works just fine and with an alias like alias be=bundle exec it is not so much overhead.

During my research of the missing binaries in bundler I stumbled upon bundle config and the .bundle/config file. The .bundle/config file can be in you app or home directory and defines the bundler configuration. The following two commands cause bundle to always install gems and binaries in the project folder. This is great because it does not clutter up my global gemset. However, don’t forget to add both directories to your .gitignore file ;)


1
2

  bundle config PATH vendor/bundle
bundle config BIN .bin

zsh theme

2011-09-24T22:00:00Z

I made an oh-my-zsh zsh theme. This is how it looks like:

The current path in blue is starting the first line. If the current path is a git repository, the time since the last commit is displayed as well as the current branch. If behind the branch is an asterix, there are uncommited files in the repository. The color of the git information is dependent on the time since the last commit.

The second line, the execution line, starts with a flash in red after which you can enter your commands. At the end of the line, the current username and machine is displayed.

Another feature is that the error code is shown in red if a command failed. If you like the theme, feel free to download it from my github repository.

iTerm2 error

2011-09-07T22:00:00Z

After upgrading iTerm2, i got the following error:


1
2

  ## exec failed ##
login No such file or directory

Fix it by deleting .MacOSX/environment.plist.

Configuration Management: Chef, Puppet, Babushka, Sprinkle and Co

2011-09-06T22:00:00Z

TL;DR

All CM tools suck at some points. But going without one is no alternative. Use chef. Or babushka, if chef has a too steep learning curve and you don’t need to manage tons of nodes.

Intro

There is an awful load of tools available for Configuration Management. This is good, because, like Terence Perr put it: “Automation can make critical things work only one way: the right way.” Additionally, automation increases productivity and consistency.

But out of this pool of tools, which one fits your needs best? Let’s take a peek at these tools:

Puppet

Puppet a CM tool written in Ruby and (now) released under the Apache license. It is usually operated in a client/server mode, but you can also run puppet “programs” locally with puppet apply. Puppet “programs” are called manifests and are written in puppets own external DSL RALsh (Resource Abstraction Layer). RALsh looks like this:


1
2
3
4
5
6
7
8
9

  user { 'xyz':
   home => '/home/xyz',
   shell => '/bin/bash',
   uid => '1000',
   comment => 'xyz,,,',
   gid => '1000',
   groups => ['adm','dialout','cdrom','sudo'],
   ensure => 'present'
}

As you can see, in puppet you define how a system should look like. Puppet figures out the rest. In the example above, puppet makes sure that the user xyz is present.

The resources can have dependencies. The way these dependencies are managed one of the main differences to chef. Puppet creates an internal graph of dependencies. This way of calculating dependencies is called graph-based ordering. It then sends the RALsh to the nodes which act based on the it.

There is also a Ruby API available. This API, however, is hardly used and quite ugly.

A short history excursion: Luke Kanies is the guy who started puppet. Before puppet, he was the one main contributor (besides the author) to cfengine. Cfengine used to be THE CM Tool. So why start puppet?

I made my living off of cfengine for a year or three and did everything I could to make it better, including writing the most widely published tutorials on it; in the end, my decision to rewrite was based on a development process that was essentially entirely closed to anything other than simple bug fixes. Even then, I would have forked but I didn’t think I could have worked with C productively, so I decided to pick a language I thought I’d be more productive in. - Luke Kanies

Ok, at last some stats for you to interpret:

github repository: 373 followers, 183 forks
irc channel: 514 members online

Links

Chef

Like puppet, chef is written in Ruby. The “programs” in chef are called recipes and collected in cookbooks. Recipes are written in a Ruby DSL:


1
2
3
4
5
6
7
8

  user "random" do
  comment "Random User"
  uid 1000
  gid "users"
  home "/home/random"
  shell "/bin/zsh"
  password "$1$JJsvHslV$szsCjVEroftprNn4JHtDi."
end

Like puppet, chef usually runs in a client/server mode. However, chef solo allows you to run chef recipes without a server. Although not visible in the example above, chef defines actions to bring the system in a desired state. This is contrary to puppets “describe how the system should be”-mentality. Here is better example than the user above:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

  vim_dir = ENV["HOME"] + "/.vim"
script "clone dotvim from github" do
        interpreter "bash"
        url = "http://github.com/rweng/dotvim.git"

        code "git clone #{url} #{vim_dir}"
        not_if { File.directory? vim_dir }
end

script "clone vundle from github" do
  interpreter "bash"
  url = "http://github.com/gmarik/vundle.git"

  code "git clone #{url} #{vim_dir}/bundle/vundle"
  not_if {File.directory? "#{vim_dir}/bundle/vundle" }
end

script "install vundles" do
  interpreter "bash"
  code "vim -u #{vim_dir}/vundle.vim -U NONE +'silent! BundleInstall' +qall"
end

The three script tags are applied one after another. This is the way chef works: Where puppet creates an internal dependency graph, dependency management in puppet is done by ordering the dependencies correctly in the recipe. This is called procedural ordering.

A quote from engineyard:

The big advantage Chef has over Puppet is that the codebase is 1/10th the size and it is pure ruby, including the recipe DSL. Puppet’s biggest flaw is its configuration language that is not quite ruby and not quite turing complete. So you end up wrestling with it to get it to do anything.

Opscode, the main company behind chef, does not promote a distributed way of sharing cookbooks since it is against their business model. However, there are some ways to keep track of remote cookbooks. One I really like is knife-github. However, knife-github only works in a client/server setup. And although Opscode does provide a chef-server for five nodes for free, you often just don’t want it.

Now there are a couple of tools that make using chef-solo easier. Littlechef is the one with the most github followers. However, it is written in python. But there are also tools for Ruby around. I use a custom-made for setting up my OS X, virtual machines and server. But this is something for a different post.

Alright then, at last the infos about the community:

github repository: 1131 followers, 520 forks
238 members inline in irc channel

Links

Sprinkle

Enough of the industries big shots. Let’s get to easier tools for small clusters. Sprinkle is such a tool.

A couple of days ago, Miso Engineering brought out a great post explaining Sprinke in depth. It is also mentioned in another CM tools comparing article. I like the syntax and the way of abstracting packages. The following example actually creates two packages, the package postgres, and the virtual package database:


1
2
3
4
5
6
7

  package :postgres, :provides => :database do
  description "provides prostgres"
  version "1.1.1"
  source 'http://example.com/postgres.tgz'
  requires :build_essential
  verify { has_executable 'psql' }
end

Unfortunately, the commit rate at the github repository implies that the project is not heavily developed anymore. In the time between May 17th and 21st of August there were no commits at all.

I also miss the following features:

a sprinkle folder to keep all packages and to install packages and policies without supplying the file where they are found
and a tighter integration with github repositories

So Sprinkle is nothing for me, but maybe for you?

Babushka

As you can see in my deps repo, Babushka is the tool that I have explored most (together with chef). Babushkas awesome strength is that it is incredibly easy to write own deps and make them based on some other, foreign deps. But first things first: To install babushka you copy a one-liner from babushka.me:

bash -c "`curl babushka.me/up`"

This installs babushka on your system. After that you can start creating own deps by putting any ruby files in the ~/.babushka/deps directory.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

  dep "babushka switched" do
  # if we would require other deps, we could do this like this:
  # requires "other dep", "github-user:other dep"

  # once the variable user is used, 
  # babushka asks the user for the value and remembers it
  define_var :user, :default => "benhoskings", 
   :message => "Which github users babushka do you want to use?"


  # we can put arbitrary ruby code in our deps, like this little helper method
  def babushka_path; "/usr/local/babushka"; end


  # the met? block tests, if the dependency is already satisfied.
  # in this case we cd into the babushka path and check, if the origin of the
  # babushka repository is set to the users github repository
  met? do
    cd babushka_path do
      shell("git remote -v")[/^origin.+\/#{var :user}\/.+$/]
    end
  end

  # met? returns something == false, then execute the meet block
  # after the meet block got executed, the met? block is run again
  # to ensure that the dep is now satisfied
  meet do
    cd babushka_path do
      shell "git remote set-url origin git://github.com/#{var :user}/babushka.git"
    end
  end
end

If this dependency is in your ~/.babushka/deps folder, you can run it with babushka "babushka switched". But the really cool thing is that you can also run it directly from github by putting the github user name before the dep name. In this case: babushka "rweng:babushka switched". My babushka-deps repository will be cloned in ~/.babushka/sources/rweng and then the dep will be executed. If it doesn’t work, just copy the code over to your deps directory or call babushka edit "rweng:babushka switched" to directly jump with your editor to the dep. Is that cool or what?

Now the other neat feature of babushka is the way to discover deps. Let’s say I am looking for a way to install nginx on my server. I execute babushka search nginx to get an overview over the public deps that contain the word nginx. The output even contains the success rate of installations.

However, right now babushkas codebase is a mess. The only developer is ben hoskings who does this project occasionally in his spare time. Another problem is that there is no way to specify a maintainer, a version or a more detailed description in the deps.

Other Tools

Blueprint comes in handy if you have a server and you got to scale. With blueprint you can easily make a snapshot of installed packages and configurations of one server and apply them on another one.

Do is an incredibly lightweight framework for running some commands on the server, uploading a file, and so on.

Gitpusshuden is a git-based deployment framework. Check out the 7 min introduction on their website

Oh, and there is also Moonshine which basically only sets up a Rails Stack automatically.

Links

article comparing chef, puppet, babushka, sprinkle, gitpusshuden