Feelings on chef

Chef Infra (archive)
1

I’ve been investigating chef lately, and it’s been a pretty rough ride. The main things I’ve learned:
The overall philosophy is great
Chef’s implementation is massively complex - I’ve found chef harder to set up than most of the entire server deployments I would have it do!
Despite chef-server’s huge infrastructure, it’s not the definitive source of configuration - the repo is.
Mixing of ruby and JSON syntax is confusing
It will get much more usable once stable packages are out (though of course that depends on chef becoming stable itself)
Deployment of straightforward recipes and roles is easy in general; configuration for individual nodes is not.
The part that’s most likely to need version control (node configs) doesn’t live in the repo.
The documentation is good on detail (though suffers from obsolescence as chef has changed a lot over time), but lacks a big picture
It doesn’t help that ubuntu’s vm-builder is fairly broken at present
Chef people on irc are very helpful

I have the feeling that most of chef-server is only really much use if you happen to be building a huge infrastructure for hosting chef, exactly as opscode is, and for everyone else it’s just overly complex.

Not having nodes in the repo and server content being overridden by rake tasks seems to render much of the server pointless (especially the web UI); a folder in the repo for node config and a minimal rest interface talking directly to it (i.e. possibly no database) would probably be sufficient for several thousand nodes. Are there any plans for a chef-server-lite?

Overall, after 3 weeks of investigation, I don’t seem to be much closer to my “10 servers in 10 minutes” ideal, which is really quite disappointing. Now I’m wondering if a simpler approach like pacha would be better.

Marcus

Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info@hand CRM solutions
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk/

2

On Tue, May 4, 2010 at 4:59 AM, Marcus Bointon
marcus@synchromedia.co.uk wrote:

I have the feeling that most of chef-server is only really much use if you happen to be building a huge infrastructure for hosting chef, exactly as opscode is, and for everyone else it's just overly complex.

I'm not going to turn this into a list where we do lots of sales, but
one of the things we do for a living is run Chef for you as a service.
We're happy to hook you up with an account on the Opscode Platform,
at which point you don't have to worry about any of this. :slight_smile:

Not having nodes in the repo and server content being overridden by rake tasks seems to render much of the server pointless (especially the web UI); a folder in the repo for node config and a minimal rest interface talking directly to it (i.e. possibly no database) would probably be sufficient for several thousand nodes. Are there any plans for a chef-server-lite?

Having node configuration in flat files is a TIMTOWTDI thing. In my
experience, I wanted the infrastructure to be more dynamic than that -
in particular, I wanted new nodes to be able to show up essentially
fully configured from the bootstrapping system. The side-effect is
that I never wanted to have to create a file on disk describing each
of the systems. I totally get the pattern, though, and the hooks are
there to support it in things like 'knife node from file'.

Overall, after 3 weeks of investigation, I don't seem to be much closer to my "10 servers in 10 minutes" ideal, which is really quite disappointing. Now I'm wondering if a simpler approach like pacha would be better.

Clearly we have a documentation gap, and likely a place for a "chef
server lite".

Adam

--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com

3

I will make a short reply,

Configuration management is a puzzle you need to put together.

It changes your work flow; so it takes time for this part to happen in an environment that has 0. You cannot force it, trust me on this one. Part adapting your infrastructure to allow this. Part adapting your release, setup, configuration etc... Chef does not give you a PXE boot server. But it gives you a place to post configure your new server preseed/kickstart.

Chef is a piece to this puzzle, a big piece that can complete the circle with time, patience, and hard work. No chef is not designed for opscode; it is designed in mind with all the tools an ops person can and should have at his disposal.

That being said chef is what you make of it. It adopts heavily in the model of TIMTOWTDIT. Read parts and use parts that you want at first... Then use more later... And most importantly do it how you want to... Not how someone else tells you to... Take your path.

Btw, sorry for the late response... As usual

Sent from my iPad

On May 4, 2010, at 4:59 AM, Marcus Bointon marcus@synchromedia.co.uk wrote:

I've been investigating chef lately, and it's been a pretty rough ride. The main things I've learned:
The overall philosophy is great
Chef's implementation is massively complex - I've found chef harder to set up than most of the entire server deployments I would have it do!
Despite chef-server's huge infrastructure, it's not the definitive source of configuration - the repo is.
Mixing of ruby and JSON syntax is confusing
It will get much more usable once stable packages are out (though of course that depends on chef becoming stable itself)
Deployment of straightforward recipes and roles is easy in general; configuration for individual nodes is not.
The part that's most likely to need version control (node configs) doesn't live in the repo.
The documentation is good on detail (though suffers from obsolescence as chef has changed a lot over time), but lacks a big picture
It doesn't help that ubuntu's vm-builder is fairly broken at present
Chef people on irc are very helpful

I have the feeling that most of chef-server is only really much use if you happen to be building a huge infrastructure for hosting chef, exactly as opscode is, and for everyone else it's just overly complex.

Not having nodes in the repo and server content being overridden by rake tasks seems to render much of the server pointless (especially the web UI); a folder in the repo for node config and a minimal rest interface talking directly to it (i.e. possibly no database) would probably be sufficient for several thousand nodes. Are there any plans for a chef-server-lite?

Overall, after 3 weeks of investigation, I don't seem to be much closer to my "10 servers in 10 minutes" ideal, which is really quite disappointing. Now I'm wondering if a simpler approach like pacha would be better.

Marcus

Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info@hand CRM solutions
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk/

!DSPAM:4be00c1a126031804284693!

4

As someone who has an installation with more than 10 nodes and a full
chef-server, it scales pretty good so the complexity paid off. The
cool part about the chef server and client is they communicate using a
REST interface that is well documented. This means a new server
implementation that isn't built to scale to a large network of nodes
is possible with an existing light weight web application framework
like Sinatra.

-lee

On Tue, May 4, 2010 at 7:59 AM, Marcus Bointon
marcus@synchromedia.co.uk wrote:

I've been investigating chef lately, and it's been a pretty rough ride. The main things I've learned:
The overall philosophy is great
Chef's implementation is massively complex - I've found chef harder to set up than most of the entire server deployments I would have it do!
Despite chef-server's huge infrastructure, it's not the definitive source of configuration - the repo is.
Mixing of ruby and JSON syntax is confusing
It will get much more usable once stable packages are out (though of course that depends on chef becoming stable itself)
Deployment of straightforward recipes and roles is easy in general; configuration for individual nodes is not.
The part that's most likely to need version control (node configs) doesn't live in the repo.
The documentation is good on detail (though suffers from obsolescence as chef has changed a lot over time), but lacks a big picture
It doesn't help that ubuntu's vm-builder is fairly broken at present
Chef people on irc are very helpful

I have the feeling that most of chef-server is only really much use if you happen to be building a huge infrastructure for hosting chef, exactly as opscode is, and for everyone else it's just overly complex.

Not having nodes in the repo and server content being overridden by rake tasks seems to render much of the server pointless (especially the web UI); a folder in the repo for node config and a minimal rest interface talking directly to it (i.e. possibly no database) would probably be sufficient for several thousand nodes. Are there any plans for a chef-server-lite?

Overall, after 3 weeks of investigation, I don't seem to be much closer to my "10 servers in 10 minutes" ideal, which is really quite disappointing. Now I'm wondering if a simpler approach like pacha would be better.

Marcus

Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info@hand CRM solutions
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk/

--

Lee Azzarello
drop.io staff hacker

5

On 4 May 2010, at 14:59, Lee Azzarello wrote:

As someone who has an installation with more than 10 nodes and a full
chef-server, it scales pretty good so the complexity paid off.

I meant that sufficient performance to support say, 100 nodes, could probably be achieved using flat text files. For the majority of cases, this is not big and complex stuff, and all the hard work happens on the client anyway. The infrastructure design of chef-server seems tuned for the case where you're deploying to enough nodes to warrant >> 1 chef-server instances (i.e. tens of thousands of nodes)... Sure it will work fine for smaller deployments too, but it's a very big software stack for the job.

The cool part about the chef server and client is they communicate using a
REST interface that is well documented. This means a new server
implementation that isn't built to scale to a large network of nodes
is possible with an existing light weight web application framework
like Sinatra.

That's exactly what I was thinking - has anyone built such a thing?

Marcus

Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info@hand CRM solutions
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk/

6

On Tue, May 4, 2010 at 11:22 PM, Marcus Bointon
marcus@synchromedia.co.ukwrote:

On 4 May 2010, at 14:59, Lee Azzarello wrote:

As someone who has an installation with more than 10 nodes and a full
chef-server, it scales pretty good so the complexity paid off.

I meant that sufficient performance to support say, 100 nodes, could
probably be achieved using flat text files.

I'm still excited about the Chef project but after spending more time with
it I'm a little concerned about the complexity of chef as a configuration
management system.

I currently generate my configuration files using scripts/templates and keep
them in git. It's pretty simple. Even if my git server goes away I can
restore from a backup. It's just text.

Requiring a Chef server to be running in order to configure a server seems
to add more dependencies. I'm not familiar with CouchDB so if that was hosed
I'm concerned about being unable to configure hosts until I'd debugged it.
Adding an AMQP server and solr indexer to the required services also seems
to add more possible points of failure.

(chef-solo seems to remove a lot of complexity from the system)

The idea of Chef updating my HAProxy config when I fire up a new app server
is exciting! I just wonder whether I really need it? Keeping node data under
version control would probably allow me to sleep better at night.

I'm enjoying the discussion. :slight_smile:

  • Mike
7

On 04.05.2010, at 16:16, Mike Bailey wrote:

On Tue, May 4, 2010 at 11:22 PM, Marcus Bointon marcus@synchromedia.co.uk wrote:
On 4 May 2010, at 14:59, Lee Azzarello wrote:

As someone who has an installation with more than 10 nodes and a full
chef-server, it scales pretty good so the complexity paid off.

I meant that sufficient performance to support say, 100 nodes, could probably be achieved using flat text files.

I'm still excited about the Chef project but after spending more time with it I'm a little concerned about the complexity of chef as a configuration management system.

I currently generate my configuration files using scripts/templates and keep them in git. It's pretty simple. Even if my git server goes away I can restore from a backup. It's just text.

Requiring a Chef server to be running in order to configure a server seems to add more dependencies. I'm not familiar with CouchDB so if that was hosed I'm concerned about being unable to configure hosts until I'd debugged it. Adding an AMQP server and solr indexer to the required services also seems to add more possible points of failure.

(chef-solo seems to remove a lot of complexity from the system)

The idea of Chef updating my HAProxy config when I fire up a new app server is exciting! I just wonder whether I really need it? Keeping node data under version control would probably allow me to sleep better at night.

I'm enjoying the discussion. :slight_smile:

why not start out with using chef-solo?

http://wiki.opscode.com/display/chef/Chef+Solo
http://brainspl.at/articles/2009/01/31/cooking-with-chef-101

That's chef without chef server

put all your stuff in a git repo (roles, config-json, cookbooks). use your favorite transport workflow (manually copy it over with ftp or scp, use capistrano) and start
a chef-solo run. you loose the query interface of chef-server but maybe you don't need it.

  • Mike

--
DI Edmund Haselwanter, edmund@haselwanter.com, http://edmund.haselwanter.com/

8

On Wed, May 5, 2010 at 12:22 AM, Haselwanter Edmund
edmund@haselwanter.comwrote:

why not start out with using chef-solo?

http://wiki.opscode.com/display/chef/Chef+Solo
Ruby on Rails Blog / What is Ruby on Rails for?
Cooking Solo with Chef | AkitaOnRails.com

Thanks for the links Edmund. The third one looks interesting (and recent).

  • Mike
9

I too felt that chef-server was overly complex for single server
setups so I hacked together drive-thru:
GitHub - mikehale/drive-thru: Drive-Thru: chef-solo in minutes. It needs to be be re-written to
use capistrano, but I think it is a decent example of going from an
ssh connection to being able to configure a box using version
controlled scripts.

On Tue, May 4, 2010 at 10:22 AM, Haselwanter Edmund
edmund@haselwanter.com wrote:

On 04.05.2010, at 16:16, Mike Bailey wrote:

On Tue, May 4, 2010 at 11:22 PM, Marcus Bointon marcus@synchromedia.co.uk
wrote:

On 4 May 2010, at 14:59, Lee Azzarello wrote:

As someone who has an installation with more than 10 nodes and a full
chef-server, it scales pretty good so the complexity paid off.

I meant that sufficient performance to support say, 100 nodes, could
probably be achieved using flat text files.

I'm still excited about the Chef project but after spending more time with
it I'm a little concerned about the complexity of chef as a configuration
management system.
I currently generate my configuration files using scripts/templates and keep
them in git. It's pretty simple. Even if my git server goes away I can
restore from a backup. It's just text.
Requiring a Chef server to be running in order to configure a server seems
to add more dependencies. I'm not familiar with CouchDB so if that was hosed
I'm concerned about being unable to configure hosts until I'd debugged it.
Adding an AMQP server and solr indexer to the required services also seems
to add more possible points of failure.
(chef-solo seems to remove a lot of complexity from the system)
The idea of Chef updating my HAProxy config when I fire up a new app server
is exciting! I just wonder whether I really need it? Keeping node data under
version control would probably allow me to sleep better at night.
I'm enjoying the discussion. :slight_smile:

why not start out with using chef-solo?
http://wiki.opscode.com/display/chef/Chef+Solo
Ruby on Rails Blog / What is Ruby on Rails for?
Cooking Solo with Chef | AkitaOnRails.com
That's chef without chef server
put all your stuff in a git repo (roles, config-json, cookbooks). use your
favorite transport workflow (manually copy it over with ftp or scp, use
capistrano) and start
a chef-solo run. you loose the query interface of chef-server but maybe you
don't need it.

  • Mike

--
DI Edmund Haselwanter, edmund@haselwanter.com,
http://edmund.haselwanter.com/

10

The chef setup is complex, but the search functionality is by far the most useful piece. We totally depend on this, and it would be harder to make it work without the server implementation as it is. For example, nagios checks, internal DNS and haproxy rules for applications are all configured directly from search results.

The client/server setup is cumbersome, but using chef itself to bootstrap those makes this a painless process.

Joshua

11

On 04.05.2010, at 16:59, Joshua Sierles wrote:

The chef setup is complex, but the search functionality is by far the most useful piece. We totally depend on this, and it would be harder to make it work without the server implementation as it is. For example, nagios checks, internal DNS and haproxy rules for applications are all configured directly from search results.

The client/server setup is cumbersome, but using chef itself to bootstrap those makes this a painless process.

but to get started and used to the chef-way it is much more easier to start with chef-solo. search is powerful, yes. but if
you don't live in a too dynamic world you can provide this kind of information within the json arguments. or, like the guys
at poolpartyrb "calculate" and pass the params.

Joshua

--
DI Edmund Haselwanter, edmund@haselwanter.com, http://edmund.haselwanter.com/

12

but to get started and used to the chef-way it is much more easier to start with chef-solo. search is powerful, yes. but if
you don't live in a too dynamic world you can provide this kind of information within the json arguments. or, like the guys
at poolpartyrb "calculate" and pass the params.

Can you provide an example?

Joshua

13

On 4 May 2010, at 16:22, Haselwanter Edmund wrote:

why not start out with using chef-solo?

http://wiki.opscode.com/display/chef/Chef+Solo
Ruby on Rails Blog / What is Ruby on Rails for?
Cooking Solo with Chef | AkitaOnRails.com

That's chef without chef server

I did start out with that, but despite what I've said, getting chef server up and running was about the easiest part; figuring out clients was far harder! Making clients talk to the server is trivial, but I was expecting chef-server to be more like a split version of chef-solo, rather than something completely different (and in some ways less useful).

put all your stuff in a git repo (roles, config-json, cookbooks). use your favorite transport workflow (manually copy it over with ftp or scp, use capistrano) and start
a chef-solo run. you loose the query interface of chef-server but maybe you don't need it.

Externalising json is significant for me here - doesn't anyone want to version their node configs?

Joshua's mention of searching in chef is interesting - it's actually the first I'd heard of it, despite feeling like I've read a zillion pages of docs lately! I did wonder what solr was doing in there... automating DNS and haproxy would be nice.

Marcus

Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info@hand CRM solutions
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk/

14

Joshua's mention of searching in chef is interesting - it's actually the first I'd heard of it, despite feeling like I've read a zillion pages of docs lately! I did wonder what solr was doing in there... automating DNS and haproxy would be nice.

Marcus,

Here are some examples:

http://github.com/37signals/37s_cookbooks/blob/master/haproxy/templates/default/haproxy.cfg.erb

http://github.com/37signals/37s_cookbooks/blob/master/nagios/templates/default/services.cfg.erb

http://github.com/37signals/37s_cookbooks/blob/master/djbdns/recipes/internal_server.rb

http://github.com/37signals/37s_cookbooks/blob/master/djbdns/templates/default/tinydns-internal-data.erb

Joshua

15

On Tue, May 4, 2010 at 10:16 AM, Mike Bailey mike@bailey.net.au wrote:

On Tue, May 4, 2010 at 11:22 PM, Marcus Bointon marcus@synchromedia.co.uk
wrote:

On 4 May 2010, at 14:59, Lee Azzarello wrote:

As someone who has an installation with more than 10 nodes and a full
chef-server, it scales pretty good so the complexity paid off.

I meant that sufficient performance to support say, 100 nodes, could
probably be achieved using flat text files.

I'm still excited about the Chef project but after spending more time with
it I'm a little concerned about the complexity of chef as a configuration
management system.
I currently generate my configuration files using scripts/templates and keep
them in git. It's pretty simple. Even if my git server goes away I can
restore from a backup. It's just text.

I totally agree. Chef can do configuration management but that's just
one of the features of a full client-server managed network. If all
you need is configuration management I would recommend chef-solo or
another framework entirely. One of the philosophical differences
between Chef and Puppet is that Chef has more dependencies by design
because it has more features. These features are there to automate
your infrastructure, which happens to require configuration
management.

--

Lee Azzarello
drop.io staff hacker

16

On Tue, May 4, 2010 at 6:22 AM, Marcus Bointon
marcus@synchromedia.co.uk wrote:

The cool part about the chef server and client is they communicate using a
REST interface that is well documented. This means a new server
implementation that isn't built to scale to a large network of nodes
is possible with an existing light weight web application framework
like Sinatra.

That's exactly what I was thinking - has anyone built such a thing?

I just wanted to chime in here and say that we've had conversations
about it with a number of people, and a few of them are probably going
to actually start work on it.

From the beginning we've seen the API as the key point of integration

  • if you are API compliant, you are good to go. The chef-server
    implementation clearly comes from my own needs and background -
    larger, more complex deployments where the goal is to do deep
    integration throughout the entire infrastructure. If you look at the
    choices we've made for the chef server, they are reflected in that.
    The different components are segregated, failure of one part of the
    server infrastructure won't necessarily stop everything, etc.

So from our point of view, we're stoked to see people re-use some of
the code we've written and build a more compact chef server
implementation. We talk about how the chef-server is a reference
implementation of the API, and we mean it.

As far as who would maintain the lighter-weight implementation, the
answer is "probably not Opscode", just because of the amount of
cognitive dissonance introducing a third code-base would have. We
would be super happy to collaborate, answer questions, provide hints
to code that could be shared, all of that. We're just not going to be
the guys who write it. :slight_smile:

Adam

--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com

17

On Tue, May 4, 2010 at 8:56 AM, Lee Azzarello lee@dropio.com wrote:

I totally agree. Chef can do configuration management but that's just
one of the features of a full client-server managed network. If all
you need is configuration management I would recommend chef-solo or
another framework entirely. One of the philosophical differences
between Chef and Puppet is that Chef has more dependencies by design
because it has more features. These features are there to automate
your infrastructure, which happens to require configuration
management.

While I think we should get things to the point where Chef is also the
easiest thing for just doing configuration management, you nail the
philosophy.

Adam

--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com