I am currently migrating a largish (thousands of nodes) site away from using Chef and back to using config files in packages, because it's simpler and has the same effect.
Having been round the houses with cfengine, Chef, Puppet and more now I think these tools are, overall, a poor use of time. In general they're 99% used as config blasters: Yet Another Way To Put Files Onto A Computer.
Turns out, packaging systems already did that and have better dependency analysis.
This also helps to match the lifecycle of configuration management objects with that of the components they configure. I've seen far too many sites that had one big hairball of a Chef/Puppet repository that tried to service the needs of multiple conflicting application releases.
The final nail in the Chef coffin is that it encourages parameterisation of config files rather than configuration by convention, which is simpler and less prone to production-environment gotchas.
Everything else they do can be replaced by a very small shell script.
> Turns out, packaging systems already did that and have better dependency analysis.
The one thing that keeps me from wanting to switch entirely to apt for deployment is its insane insistence that multiple versions of the same package may not be installed at once. This is (usually) fine for user-level stuff, but there are lots of legitimate reasons to want to keep multiple versions installed in a deployment situation.
I have written tons of fabfiles and Fabric is a great project. However it isn't intended to managed system state. It is great for code deployment but not suited to configuration management.
Puppet/Chef/Cfengine are different to Fabric/Capistrano
The former are pull management, eg nodes request configuration. The latter are push management, eg main server pushes to nodes.
My main concern is that you did not point out your requirements. So you leaped from one technology to a different one because puppet was 'maximum pain'.
I use Chef, but without the server (chef-solo). I have a hard time stomaching the idea of dealing with a Merb application (an abandoned framework) that has some rather complex dependencies (couchdb & rabbitmq). That being said, plenty of peers have told me that they have not experienced any problems with running a Chef server.
Maybe this means I should just fork up the cash for hosted Chef, but I don't see it as a 100$ a month value (I currently have 10 nodes and treat them all as ephemeral).
I do wonder why this is never brought up. Is it not seen as a red flag to anyone else that the core of Chef is built on Merb?
If you are unhappy with Merb then convert it to pure rack or sinatra and send a pull request. It works and it's seriously as low of a priority as I can imagine. The server is nothing more than an API endpoint. You can (and people have) rewritten the entire server component in Python.
Just as a warning: If you/anyone decides to self host a chef server, you have to get the chef-server cookbook (or your couchdb will never get compacted) and you can't be running ruby 1.9.1 (or the server will have ~1 week uptime before crashing randomly)
As for the core being built on merb. I don't really notice it. You'll probably never have a reason to go into the chef-server internals to change something. Besides that, it's not like it has to be serving 30k requests per second or anything.
Otherwise, the
Issues I've run into with chef-server: it was a little annoying to get everything installed and playing together. Couchdb + solr are very temperamental. After everything was running and stabilized(1.9.1 bad!) I've had no issues with it.
Am I totally missing some obvious Chef documentation? The entirety of the documentation when I last looked seemed to be the wiki + the one 50-page O'Reilly book.
I ended up literally printing out the wiki. (And the wiki seemed to be in a state of pretty extreme flux and/or disagreement with what blog posts suggested was best practice.)
The business model of the companies promoting Puppet and Chef seems to be to charge for support and/or hosted services. Which is fine. But is it leading to abysmal documentation?
"The business model of the companies promoting Puppet and Chef seems to be to charge for support and/or hosted services. Which is fine. But is it leading to abysmal documentation?"
This is one of the reasons we're moving Puppet Labs from being a support company to a product company, and not for hosted services.
If your bread and butter comes in from support, you have no incentive to actually make your product easier to use. There are plenty of enterprise-y software companies who make lots of money operating like this, but that's not the sort of company I want to work for.
I'm quite proud of the rapid improvement we've made on the Puppet Docs over the last year since we hired NickF, our most excellent tech writer:
I was a bit confused by the "excellent reference documentation" regarding Chef, as well. The documentation I have read has been out of sync, occasionally contradictory piece-meal. I have yet to find anything more useful than just reading recipes.
I wonder if the author knows of resources other than that book and the wiki.
I tried out both Puppet and Chef a while ago, and was also a bit confused by the Chef documentation when trying to do anything beyond the basics.
While not brilliant, the Puppet docs seemed better and when added to the Pro Puppet book ( http://www.amazon.com/Pro-Puppet-James-Turnbull/dp/143023057... ) are more than adequate, so I just picked Puppet on that basis alone, and have not had any issues.
Another useful tool , in conjunction with Puppet/Chef is Blueprint which lets you build configurations from existing servers , http://devstructure.com/ .
Something that wasn't visible in the article: Not that Puppet is extremely better here, but I really hate how much manual tweaking Chef requires after installing from a package and the experience in running it needed. You cannot easily scale it (indexed database pretty much needs to stay in one place), couchdb stops replication at random and it seems that chef doesn't deal well with document versioning in general since I keep running into a situation where the cookbook is not on the list after uploading, or a visible cookbook cannot be deleted. It also sometimes requires reindexing for some unknown reason, or the attributes don't work properly in search.
I prefer to work with Chef much more than Puppet (as a user/developer), but I wouldn't want to be responsible for running Chef cluster itself. There are too many different elements to learn and take care of. Unfortunately official hosted service is very expensive, so there's no good alternative once you need many nodes.
I'm running both chef and puppet in production, so I will add my (slightly cynic) comparison here:
When comparing Chef to puppet then Chef comes out as the pragmatist. Once up and running most common every-day tasks are less painful in chef. Apart from that its main advantage over puppet (to me) is that it allows to semi-sanely manage transient hosts (cloud/EC2) that enter/exit a cluster ad hoc. Puppet can also do that in theory, in practice you'd rather want to fork your eyes out with a spoon.
However, the pragmatism comes at a price: The chef-implementation is an absolute and unmitigated disaster.
You'll spend quite a bit of quality time initially to get the six dozen components to play ball and to fix up basics that shouldn't need fixing (i.e. you'll want to ensure that everything is under version control and not just the parts that chef deems worth versioning).
Over the first couple months you'll also see the odd server-crash while you figure out the peculiarities of your particular installation. Chef is very heavy on dependencies and the exact software-versions depend on when and how you install (pkgs vs source-code).
However, once you're over that hump and if you're not too worried about standing on the shoulders of 'a one-eyed amongst the blind' then the whole cookbooks/roles/runlists arrangement is quite comfortable to work with.
Just don't expect features like dry-run, real idempotency or clean dependency tracking that some would consider "basic" for such a tool. Also don't expect a security-model at all; to my knowledge all hosts that are authorized to talk to a chef-server can see all cookbooks and databags on that server.
If you care a lot about those latter minor quibbles then perhaps Puppet might be more your thing.
Puppet is conceptually much cleaner (night/day difference), which sadly and ironically is also its biggest drawback; they took it too far. Puppet made a bad decision early on by inventing their own language. This decision will be your personal ball on a chain for the lifetime of your puppet deployment.
But, is it really that bad?
Well. Yes.
After the initial (steep) learning curve there's only a small plateau of reward before you begin to run into the more subtle issues. The most commonly heard complaints about the language are the ass-backwards class/variable-inheritance and the blurry (and effectively undocumented) divide between what should go into the manifests (sorta like chefs "cookbooks") and what into a storage layer called "extdata" (sorta somewhat like chefs "databags"). But rest assured, there's plenty more, I don't want to spoil it all at once here.
So, yes, you will hate puppet every time you have to make a complex change.
Yet for some it might still be worth it, here's some of my reasons: Once you finally have something up and running puppet feels much more predictable and "solid" than chef. You can actually dry-run and test (most) changes before rolling them out. Puppet will provide meaningful error messages in most situations (unlike the esoteric chef stack-traces). The puppet daemon is just that; one daemon (unlike the conglomerate of moving parts that comprises a chef deployment). Generally speaking there is much less "magic" in puppet than in chef. You will almost always know precisely what went wrong - a pretty important attribute that chef unfortunately doesn't share.
Oh, and no least: the puppet documentation is heads and shoulders above chef (although the latter has improved recently).
So, if you're in the market, good luck making your choice. I'm not making a recommendation here because, quite frankly, I wouldn't recommend either to anyone other than my worst enemy. ;-)
I (with advice from co-workers) decided against chef for two main reasons: Dependencies and complexity of implementation, and gut instinct from reading the literature. So I'm not surprised to see that it can be a little shaky.
I also looked at cfengine3, and I liked the language, although I am not a fan of the "promise/promiser" terminology, the concept is consistently applied and as a result the language grammar is much simpler than puppet's. It basically came down to not being able to really choose between puppet and cfengine3 without actually trying them, and since I cared less about identifying the optimal tool than just getting stuff done I selected puppet arbitrarily.
I rejected bcfg2 mainly because it seemed very server-oriented and although there was documentation for setting up the system there wasn't a lot of documentation about how to actually configure systems. I've revisited bcfg2 lately and the situation doesn't seem to have improved much. (eg I can't find a decent reference for the configuration language anywhere online. There's no equivalent to that puppet page that lists all the data types.) I also think the choice for XML as the configuration language is suboptimal but I could probably work with it.
So we went with puppet, and although I left the position several months later (for unrelated reasons) we were already hitting some of those issues you mentioned.
Incidentally, you don't even need the daemon to run puppet, so long as you're willing apply your own security model and distribution method (rsync over ssh, etc/).
From a complete outsider's point of view, it sounds as if the state of the art SCM tools are at the pre-2005 level of VCS tools. Chef and Puppet are the SCM equivalents of CVS or Subversion. The Git/Mercurial equivalents (in terms of power) have yet to appear. Does this analogy make sense?
I have no real experience with configuration management, but I'm confused why the programming language matters?
It seems to me like people complaining about Make being a poor programming language.... IT'S NOT FOR PROGRAMMING! It's for build sequencing. Every single program on your computer is a command-line-invocation away. Let Make handle incrementally executing external scripts based on timestamps, and let real programming languages do what they do best.
Isn't the point of Puppet to have an idempotent declarative language. And can't it execute arbitrary programs?
I'm interested to know why someone would not recommend CM (or atleast not recommend puppet/chef). I think despite its faults, I've seen that many problems become non-issues when you are using puppet. OTOH, I've seen organizations struggle for months(or for ever) with what could have been a simple solution with puppet.
Could it be you made the wrong design decisions both times? Sometimes, people try to do complex things in puppet, when they should using puppet just to push out that cronjob or init script, or rpm/apt package to handle the complexity.
Can you give more details like how many serves you have? Do you have a complex combination of hardware(physical + virtual) and operating system platforms?
Do you have a complex combination of apps on these platforms? Did you use the "environments" feature of puppet/chef? (Environments are totally broken in puppet) Did you use Dashboard/Foreman or Grill(chef only) and did that make things easier?
Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef?
The correct answer to this entire question is "yes". Use whichever tool encourages you to adopt proper configuration management.
Yes, there's a gap that the current crop of CM tools don't address (and why we see new versions of capistrano clones with a bit of system management sprinkled in) but the three major tools right now - Puppet, Chef and CFengine are all at a state where they address 95% of the use cases for system management and automation.
A little while ago I wrote a piece comparing Puppet vs Chef on 10 different criteria and concluded that Puppet wins on all of them: http://bitfieldconsulting.com/puppet-vs-chef
It stimulated a very interesting discussion in comments in which some of the leading lights from both communities (and there is some overlap) took part.
A little while ago is a bit of a stretch. BOTH communities have moved far and beyond the state of things in that article.
The fact of the matter is that X vs. Y is ENTIRELY subjective. It isn't a sporting event where there's a clear cut way to call a winner.
Some people like Puppet. Some people like Chef. Anyone trying to decide between ANY software - whether two competing client libraries or something as critical as configuration management owes it to themselves and the company to try all the options. The one that's best is the one that encourages you to adopt configuration management.
This is a good write up. As someone who just recently started messing with Chef I found comparison articles non-existent. Though I have already put in several weeks with Chef and will probably stick with it I think Puppet looks like a great product as well. I hope both of these projects continue to gain users. It would be great to see them both compete/innovate well into the future. With that said I would like to see Chef's documentation increase and the merb application replaced by something else as someone else suggested. In the end they are both great tools and if you are sys admin it wouldn't hurt to learn one really well and become familiar with the other just like working with different Linux distros such as RHEL/Ubuntu only increases your sys admin skills.
I've been happy with Kokki and Fabric, no complaints yet: https://github.com/samuel/kokki If I outgrow it I'll be happy to switch to chef or puppet, but it is still convenient to keep everything in Python.
While I often see "Puppet vs Chef", I never see Bcfg2 mentioned. Is its low mindshare related to its quality, it's exclusion from the set of Ruby-based config management tools, its origin in the government space, or its terrible name?
Not only is Bcfg2's explicit configuration structure unpleasant to work with, the heart of it is in XML. I tried to use Bcfg2 and was easily put off by the required structure. The fact that Bcfg2 stems from the science/math community was actually the only thing that kept from overlooking it completely.
I honestly have not a single clue about Puppet or Chef, but the company I work for uses bcfg2. All of the SAs hate it with a passion. We have written so much code around it to make it usable that it could probably compare with amount of code in bcfg2 (well not really, but it's a lot).
bcfg2 works well. It aims toward 100% fully managed servers (i.e. package dependency management, full /etc management) more than Chef/Puppet (but other than DoD/banking, 100% management isn't worth it). Other reasons I prefer Chef are 1) solo mode, 2) more dynamic recipes with ruby 3) more out-of-the-box resources (dirs, files, templates, users, etc)
CFEngine has really great, comprehensive, reference documentation and really very poor, basically non-existent, tutorial or getting-started information. In order to actually get work done, you need to know a good bit more than how to install it and what the bundle syntax looks like. Puppet OTOH excels in this.
So while the tools are roughly equivalent in capability, if you're new to configuration management in general I think you'll have a lot better success getting started with Puppet.
I'm curious about this as well. Does anyone have any experience with this? It would be interesting to hear someone's opinion since CFEngine seems to have been around for awhile.
This article came at an excellent time: I've recently been setting up test deployments of both Puppet and Chef for potential HPC use, and this article confirms a lot of my impressions. In particular, that Puppet has much better documentation (especially for doing the initial setup) and a more sysadmin-friendly language, but that Chef makes it easier to carry out complex tasks.
Despite some cool things I've been able to do in Chef, Puppet is probably going to end up the winner, if for no other reason than it having much much better support for RHEL and clones (ie Scientific Linux). Chef was extremely unimpressive there in many ways, and anything related to deployment where the wiki includes the line "RPM installation via ELFF has been deprecated" is going to be a non-starter in the HPC world. (Or doesn't, anymore... any mention of RPM seems to have been scrubbed now.)
We're probably only going to use it on infrastructure/head nodes though: our compute nodes are provisioned on ramdisk statelessly using Warewulf, and are easier to reconfigure with a reboot/redeploy than via CM.
It's sad that chef differs so much depending on server/solo usage:
Without chef-server using so called "chef-solo" lacks a lot of good things:
+ (remote) bootstrapping + distribution (like "little-chef"; non-official)
+ data bags (third party cookbook only; non-official)
+ search (e.g. on a central file system based data-base which gets dumped into a json that will be uploaded on bootstrap/update time (push))
As others stated, running your own chef-server (even external/paying for it) brings a new risc factor into your provisioning business and if you depend on data bags and search you'll most likely not be able to bootstrap new app servers when your chef server is down. This is a huge SPOF.
For those getting started with Configuration Management, I would recommmend "Getting Started with Configuration Management" by Cory Lueninghoener (in April 2011 issue of USENIX ;login: magazine): http://www.usenix.org/publications/login/2011-04/openpdfs/Lu...
I haven't used Puppet but I have had the misfortune of using Chef (1k+ node deployment). But for a free alternative its not bad, it gets the job done sure we'll have to sacrifice or work around it but in the end you can do what you need to do with it. Yes, its not RightScale but thats why RightScale is not free.
I haven't tried out scalr my self but I hear it described as an alternative to RightScale with 90% of the features at 10% of the cost.
If anyone here has used scalr please enlighten us of on its current state.
Depends on what you mean by deployment. We use puppet for managing our os, packages and basic file structure. We use home-grown bash scripts for deploying new versions of applications.
For keeping track of os-level packages and the like, I find Puppet much better than something I could build myself. It doesn't just take care of the initial setup, but also handles incremental changes. And it does so in a largely declarative language. It all guarantees that the entire installation is documented and replicable.
I prefer bash scripting for this as well. With a small ops team, pushing for adoption of Puppet or Chef, and definitely cfengine, can be difficult. However having a backbone for running the scripts and providing reporting is a great benefit.
I used slack[1] for a short while, but then started my own configuration management framework for Perl[2]. I wanted to have templating and better reporting, and also had hopes of keeping a very slim rulesest -- forcing any extraneous functions to per-instance (bash|perl|python|.*) scripts. I need to get back to developing and testing it though.
I don't think you know what you're missing, actually. I recommend trying it out. In fact, you should be using Puppet or Chef even if you're just one guy with just one server to manage.
The reason is that by encoding your configuration in a metalanguage such as Puppet's, you have described your environment independent of the actual box. If the box goes down and you need to swap in a new one, you just run Puppet again, and it will magically turn into the old box.
If you need to replace the box with faster hardware, for example, just run Puppet on the new box, and it will (if you have done your job properly) become identical to the new one. Suddenly need 10 boxes to handle a load spike? Just boot up 10 cloud VMs and point them at the Puppet server.
Since these systems are modular and lightweight, you can easily describe hundreds of vastly different boxes using a single configuration.
I've been using puppet recently, one thing I wish for is an easier way to pull in other puppet's users modules. I've looked at puppetforge some but I balk at actually downloading the files to run locally. Is chef better in this regard?
[+] [-] inopinatus|14 years ago|reply
Having been round the houses with cfengine, Chef, Puppet and more now I think these tools are, overall, a poor use of time. In general they're 99% used as config blasters: Yet Another Way To Put Files Onto A Computer.
Turns out, packaging systems already did that and have better dependency analysis.
This also helps to match the lifecycle of configuration management objects with that of the components they configure. I've seen far too many sites that had one big hairball of a Chef/Puppet repository that tried to service the needs of multiple conflicting application releases.
The final nail in the Chef coffin is that it encourages parameterisation of config files rather than configuration by convention, which is simpler and less prone to production-environment gotchas.
Everything else they do can be replaced by a very small shell script.
[+] [-] technomancy|14 years ago|reply
The one thing that keeps me from wanting to switch entirely to apt for deployment is its insane insistence that multiple versions of the same package may not be installed at once. This is (usually) fine for user-level stuff, but there are lots of legitimate reasons to want to keep multiple versions installed in a deployment situation.
[+] [-] socratic|14 years ago|reply
What tools do you end up using? Some sort of custom apt repository plus some shell scripts? What does it look like?
[+] [-] spez|14 years ago|reply
We have since switch to Fabric http://fabfile.org, and are much happier.
[+] [-] bryanwb|14 years ago|reply
[+] [-] Encave|14 years ago|reply
More info after slide 42 here: http://www.slideshare.net/ffunction/fabric-cuisine-and-watch...
[+] [-] Joakal|14 years ago|reply
The former are pull management, eg nodes request configuration. The latter are push management, eg main server pushes to nodes.
My main concern is that you did not point out your requirements. So you leaped from one technology to a different one because puppet was 'maximum pain'.
[+] [-] techscruggs|14 years ago|reply
Maybe this means I should just fork up the cash for hosted Chef, but I don't see it as a 100$ a month value (I currently have 10 nodes and treat them all as ephemeral).
I do wonder why this is never brought up. Is it not seen as a red flag to anyone else that the core of Chef is built on Merb?
[+] [-] lusis|14 years ago|reply
[+] [-] Woost|14 years ago|reply
As for the core being built on merb. I don't really notice it. You'll probably never have a reason to go into the chef-server internals to change something. Besides that, it's not like it has to be serving 30k requests per second or anything.
Otherwise, the Issues I've run into with chef-server: it was a little annoying to get everything installed and playing together. Couchdb + solr are very temperamental. After everything was running and stabilized(1.9.1 bad!) I've had no issues with it.
[+] [-] davnola|14 years ago|reply
[+] [-] socratic|14 years ago|reply
I ended up literally printing out the wiki. (And the wiki seemed to be in a state of pretty extreme flux and/or disagreement with what blog posts suggested was best practice.)
The business model of the companies promoting Puppet and Chef seems to be to charge for support and/or hosted services. Which is fine. But is it leading to abysmal documentation?
[+] [-] nigelk|14 years ago|reply
This is one of the reasons we're moving Puppet Labs from being a support company to a product company, and not for hosted services.
If your bread and butter comes in from support, you have no incentive to actually make your product easier to use. There are plenty of enterprise-y software companies who make lots of money operating like this, but that's not the sort of company I want to work for.
I'm quite proud of the rapid improvement we've made on the Puppet Docs over the last year since we hired NickF, our most excellent tech writer:
http://docs.puppetlabs.com/
I particularly like the solution focused docs he's done, as opposed to the dry reference material that presupposes a lot of knowledge.
http://docs.puppetlabs.com/learning/
Anyway, just wanted to point out that that's not our business model.
(Product Manager at Puppet Labs)
[+] [-] techscruggs|14 years ago|reply
I wonder if the author knows of resources other than that book and the wiki.
[+] [-] sheff|14 years ago|reply
While not brilliant, the Puppet docs seemed better and when added to the Pro Puppet book ( http://www.amazon.com/Pro-Puppet-James-Turnbull/dp/143023057... ) are more than adequate, so I just picked Puppet on that basis alone, and have not had any issues.
Another useful tool , in conjunction with Puppet/Chef is Blueprint which lets you build configurations from existing servers , http://devstructure.com/ .
[+] [-] viraptor|14 years ago|reply
I prefer to work with Chef much more than Puppet (as a user/developer), but I wouldn't want to be responsible for running Chef cluster itself. There are too many different elements to learn and take care of. Unfortunately official hosted service is very expensive, so there's no good alternative once you need many nodes.
[+] [-] moe|14 years ago|reply
When comparing Chef to puppet then Chef comes out as the pragmatist. Once up and running most common every-day tasks are less painful in chef. Apart from that its main advantage over puppet (to me) is that it allows to semi-sanely manage transient hosts (cloud/EC2) that enter/exit a cluster ad hoc. Puppet can also do that in theory, in practice you'd rather want to fork your eyes out with a spoon.
However, the pragmatism comes at a price: The chef-implementation is an absolute and unmitigated disaster.
You'll spend quite a bit of quality time initially to get the six dozen components to play ball and to fix up basics that shouldn't need fixing (i.e. you'll want to ensure that everything is under version control and not just the parts that chef deems worth versioning).
Over the first couple months you'll also see the odd server-crash while you figure out the peculiarities of your particular installation. Chef is very heavy on dependencies and the exact software-versions depend on when and how you install (pkgs vs source-code).
However, once you're over that hump and if you're not too worried about standing on the shoulders of 'a one-eyed amongst the blind' then the whole cookbooks/roles/runlists arrangement is quite comfortable to work with.
Just don't expect features like dry-run, real idempotency or clean dependency tracking that some would consider "basic" for such a tool. Also don't expect a security-model at all; to my knowledge all hosts that are authorized to talk to a chef-server can see all cookbooks and databags on that server.
If you care a lot about those latter minor quibbles then perhaps Puppet might be more your thing.
Puppet is conceptually much cleaner (night/day difference), which sadly and ironically is also its biggest drawback; they took it too far. Puppet made a bad decision early on by inventing their own language. This decision will be your personal ball on a chain for the lifetime of your puppet deployment.
But, is it really that bad? Well. Yes.
After the initial (steep) learning curve there's only a small plateau of reward before you begin to run into the more subtle issues. The most commonly heard complaints about the language are the ass-backwards class/variable-inheritance and the blurry (and effectively undocumented) divide between what should go into the manifests (sorta like chefs "cookbooks") and what into a storage layer called "extdata" (sorta somewhat like chefs "databags"). But rest assured, there's plenty more, I don't want to spoil it all at once here.
So, yes, you will hate puppet every time you have to make a complex change.
Yet for some it might still be worth it, here's some of my reasons: Once you finally have something up and running puppet feels much more predictable and "solid" than chef. You can actually dry-run and test (most) changes before rolling them out. Puppet will provide meaningful error messages in most situations (unlike the esoteric chef stack-traces). The puppet daemon is just that; one daemon (unlike the conglomerate of moving parts that comprises a chef deployment). Generally speaking there is much less "magic" in puppet than in chef. You will almost always know precisely what went wrong - a pretty important attribute that chef unfortunately doesn't share.
Oh, and no least: the puppet documentation is heads and shoulders above chef (although the latter has improved recently).
So, if you're in the market, good luck making your choice. I'm not making a recommendation here because, quite frankly, I wouldn't recommend either to anyone other than my worst enemy. ;-)
[+] [-] Goladus|14 years ago|reply
I also looked at cfengine3, and I liked the language, although I am not a fan of the "promise/promiser" terminology, the concept is consistently applied and as a result the language grammar is much simpler than puppet's. It basically came down to not being able to really choose between puppet and cfengine3 without actually trying them, and since I cared less about identifying the optimal tool than just getting stuff done I selected puppet arbitrarily.
I rejected bcfg2 mainly because it seemed very server-oriented and although there was documentation for setting up the system there wasn't a lot of documentation about how to actually configure systems. I've revisited bcfg2 lately and the situation doesn't seem to have improved much. (eg I can't find a decent reference for the configuration language anywhere online. There's no equivalent to that puppet page that lists all the data types.) I also think the choice for XML as the configuration language is suboptimal but I could probably work with it.
So we went with puppet, and although I left the position several months later (for unrelated reasons) we were already hitting some of those issues you mentioned.
Incidentally, you don't even need the daemon to run puppet, so long as you're willing apply your own security model and distribution method (rsync over ssh, etc/).
[+] [-] reinhardt|14 years ago|reply
[+] [-] snprbob86|14 years ago|reply
It seems to me like people complaining about Make being a poor programming language.... IT'S NOT FOR PROGRAMMING! It's for build sequencing. Every single program on your computer is a command-line-invocation away. Let Make handle incrementally executing external scripts based on timestamps, and let real programming languages do what they do best.
Isn't the point of Puppet to have an idempotent declarative language. And can't it execute arbitrary programs?
[+] [-] ashayh|14 years ago|reply
Could it be you made the wrong design decisions both times? Sometimes, people try to do complex things in puppet, when they should using puppet just to push out that cronjob or init script, or rpm/apt package to handle the complexity.
Can you give more details like how many serves you have? Do you have a complex combination of hardware(physical + virtual) and operating system platforms?
Do you have a complex combination of apps on these platforms? Did you use the "environments" feature of puppet/chef? (Environments are totally broken in puppet) Did you use Dashboard/Foreman or Grill(chef only) and did that make things easier?
Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef?
[+] [-] blantonl|14 years ago|reply
In all seriousness (kinda), many thanks for the great write up on the current state of provisioning tools.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] lusis|14 years ago|reply
Yes, there's a gap that the current crop of CM tools don't address (and why we see new versions of capistrano clones with a bit of system management sprinkled in) but the three major tools right now - Puppet, Chef and CFengine are all at a state where they address 95% of the use cases for system management and automation.
[+] [-] lobster_johnson|14 years ago|reply
[+] [-] keithlard|14 years ago|reply
It stimulated a very interesting discussion in comments in which some of the leading lights from both communities (and there is some overlap) took part.
[+] [-] lusis|14 years ago|reply
The fact of the matter is that X vs. Y is ENTIRELY subjective. It isn't a sporting event where there's a clear cut way to call a winner.
Some people like Puppet. Some people like Chef. Anyone trying to decide between ANY software - whether two competing client libraries or something as critical as configuration management owes it to themselves and the company to try all the options. The one that's best is the one that encourages you to adopt configuration management.
[+] [-] pwelch|14 years ago|reply
[+] [-] rizumu|14 years ago|reply
[+] [-] kbd|14 years ago|reply
[+] [-] agj|14 years ago|reply
Not only is Bcfg2's explicit configuration structure unpleasant to work with, the heart of it is in XML. I tried to use Bcfg2 and was easily put off by the required structure. The fact that Bcfg2 stems from the science/math community was actually the only thing that kept from overlooking it completely.
[+] [-] vvpan|14 years ago|reply
[+] [-] Goladus|14 years ago|reply
Client-server model
Insufficient online documentation for what seems to be a verbose and somewhat limited configuration language.
The XML is a minor turnoff but for me it's more a question of what the language is doing. Eg:
In puppet, you define a list of packages and then install them with one declaration or do any number of other things with that same list.[+] [-] nstielau|14 years ago|reply
[+] [-] leoc|14 years ago|reply
[+] [-] esessoms|14 years ago|reply
So while the tools are roughly equivalent in capability, if you're new to configuration management in general I think you'll have a lot better success getting started with Puppet.
[+] [-] pwelch|14 years ago|reply
[+] [-] ajdecon|14 years ago|reply
Despite some cool things I've been able to do in Chef, Puppet is probably going to end up the winner, if for no other reason than it having much much better support for RHEL and clones (ie Scientific Linux). Chef was extremely unimpressive there in many ways, and anything related to deployment where the wiki includes the line "RPM installation via ELFF has been deprecated" is going to be a non-starter in the HPC world. (Or doesn't, anymore... any mention of RPM seems to have been scrubbed now.)
We're probably only going to use it on infrastructure/head nodes though: our compute nodes are provisioned on ramdisk statelessly using Warewulf, and are easier to reconfigure with a reboot/redeploy than via CM.
(edit to clarify)
[+] [-] rmoriz|14 years ago|reply
Without chef-server using so called "chef-solo" lacks a lot of good things:
As others stated, running your own chef-server (even external/paying for it) brings a new risc factor into your provisioning business and if you depend on data bags and search you'll most likely not be able to bootstrap new app servers when your chef server is down. This is a huge SPOF.[+] [-] atsaloli|14 years ago|reply
and my own report from Configuration Management Summit last year: http://www.usenix.org/publications/login/2010-10/openpdfs/Co...
[+] [-] knodi|14 years ago|reply
I haven't tried out scalr my self but I hear it described as an alternative to RightScale with 90% of the features at 10% of the cost.
If anyone here has used scalr please enlighten us of on its current state.
https://scalr.net/
[+] [-] maratd|14 years ago|reply
Why? I prefer to simply write my own bash deployment scripts. Seems easier.
[+] [-] troels|14 years ago|reply
For keeping track of os-level packages and the like, I find Puppet much better than something I could build myself. It doesn't just take care of the initial setup, but also handles incremental changes. And it does so in a largely declarative language. It all guarantees that the entire installation is documented and replicable.
[+] [-] agj|14 years ago|reply
I used slack[1] for a short while, but then started my own configuration management framework for Perl[2]. I wanted to have templating and better reporting, and also had hopes of keeping a very slim rulesest -- forcing any extraneous functions to per-instance (bash|perl|python|.*) scripts. I need to get back to developing and testing it though.
1: http://code.google.com/p/slack/
2: http://search.cpan.org/~agj/Csistck-0.05/lib/Csistck.pm
[+] [-] lobster_johnson|14 years ago|reply
The reason is that by encoding your configuration in a metalanguage such as Puppet's, you have described your environment independent of the actual box. If the box goes down and you need to swap in a new one, you just run Puppet again, and it will magically turn into the old box.
If you need to replace the box with faster hardware, for example, just run Puppet on the new box, and it will (if you have done your job properly) become identical to the new one. Suddenly need 10 boxes to handle a load spike? Just boot up 10 cloud VMs and point them at the Puppet server.
Since these systems are modular and lightweight, you can easily describe hundreds of vastly different boxes using a single configuration.
[+] [-] bostonvaulter2|14 years ago|reply
[+] [-] jarin|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]