Hi Chefs!
I would like to present Little Chef, a new project that integrates with Chef.
LittleChef is actually an offspring of The Overmind, which was released a
couple of weeks ago
(http://mail-archives.apache.org/mod_mbox/incubator-libcloud/201010.mbox/<AANLkTinZ-i0CoQABkdhA=E+veYhYrQh4sWLQtxDaWXPY@mail.gmail.com>).
Overmind aims to be a complete server management application. The first release
features server provisioning, and we want to tackle Configuration Management
next. We have decided on Chef, but as The Overmind wants to know everything
about its minions, we won’t be using Chef Server.
To explore the possibility of just using Chef Solo, LittleChef was born. It is
a tiny framework that replaces a subset of the functionality of Chef Server
using a push-based system.
Instead of needing a server to let your nodes pull info from, recipes are
automatically “pushed” to nodes every time you want to configure them. You
install LittleChef on your desktop/laptop, and work in “kitchens”
(deployment directories), where you have a cookbooks dir, a roles dir and a
nodes dir. That’s it.
Right now, in version 0.1 LittleChef:
* Allows to apply a recipe or role to a particular node
* Saves recipes, roles and attributes for every node in configuration
files, which can afterwards be edited to override attributes
* Updates cookbooks on every node automagically, without the need for repo
syncing
* Can reconfigure every node
* Understands simple queries like showing all nodes with particular recipes
* Can’t bake cookies yet
There is an extensive README explaining installation and usage details.
FAQ
Q: “Wait, wait, did the world really need this duplication of efforts?”
A: “You are right. I am very sorry that I deprived the world of a couple of
hours of my precious hacking time to code those 200 lines of code. I hope the
world doesn’t mourn such a devastating loss for too long.”
Yes, you read that right. The whole thing is just a 200 lines of Python code.
Yes, you read that right. It is written in Python.
Python talking to Ruby. Yes, I am crazy and hope that this is the beginning of
a beautiful friendship.
The repo site: (http://github.com/tobami/littlechef)
Now, what is my purpose with this weird project besides experimenting and why
do I think anyone would be interested?
LittleChef is in essence a Pocket Chef (sadly an already registered trademark).
There are three areas in which a Pocket Chef could be useful:
* For newbies: Newcomers can have a hard time getting Chef running for the
first time, specially if they are evaluating other alternatives and have little
time, and even harder if they don’t have an inkling of Ruby. In the docs you
rightly recommend to get your feet wet with Chef Solo first, thus avoiding all
the Chef Server set-up/authentication overhead. But there are still to many
things to figure out at once. You should ideally only have to figure out a
single thing: how a cookbook works (and gets executed). With LittleChef, you
download the project to a directory on your computer and are immediately ready
to go. There is even a chef-solo deployment script that fetches opscode
packages for various distributions.
* For development: while developing new cookbooks, you can currently edit
recipes at your working system, check-in changes and have the chef-clients
execute the new version of the cookbooks. That is not an optimal work-flow,
because you end-up checking in small or experimental changes. With LittleChef
you develop cookbooks at your LittleChef/cookbooks/ directory, certainly under
source control. When you make changes and want to try them out, you just
execute “fab host:hostname recipe:mynewrecipe”. The cookbooks dir will get
gzipped, uploaded to the node, and the recipe run by chef-solo. When your
recipe has attained “delicious” status, you can then check in your changes.
Note that this is not incompatible with using Shef.
* For very small deployments: LittleChef will never be a full replacement
for the Chef server. A push architecture and configuration file is not the
right way to manage lots of servers. I can imagine though, small organizations
managing small numbers of servers (1-6) using LittleChef, thus avoiding the
need for a Chef server. They would possibly not have even considered using
Chef, but in this way they can manage their servers “the right way “(with a
CMS!) from the start.
This project, and even more a possible integration of Chef into Overmind, have
only been possible because of some great design decisions in Chef development:
* Having chef-solo in addition to chef-client
* Using json as the input/command issuing format, which removes language
barriers
* In cookbooks, having attributes you can override listed in json format
will allow for even more powerful integration.
I have a couple of suggestions so that Chef can remain a component other
projects can integrate seamlessly:
* Cookbooks: always clearly mark what cookbooks cannot be run without a
Chef server. Even better: always make them work without a chef server, by
listing the dynamic attributes in metadata.json and attributes/default.rb
* In general, continue considering Chef Solo a first-class citizen. That
means lots of little things like for example not starting the chef-client
service on package installation, so that chef-solo users don’t have to disable
the chef-client service every time after installation (which happens for
debian, but is done right for RHEL and CentOS)
Happy cooking, and careful with those nodes!
Remember, although a famous Chef used to say that “Anyone can cook”,
Little Chef says:
“Yeah. Anyone can, that doesn’t mean that anyone should”.
Miquel Torres
