Chef and Puppet recommendations [closed]

问题:

I'd like to ask about when and in what circumstances you'd use puppet and when you'd use chef. I've also found rump which is a puppet-solo type of thing where you iterate a single server to its configuration and then push that to a series of servers, allowing you to see changes directly.

My question: which of the above should I use and in what ways? Could someone help me?

My aim is in the context of continuous integration, continuous deployment in a mono/.Net environment with rake and git. I would like to package, version and deploy web applications easily and would like to use recepies for a load balancer for multiple web servers. Being able to take these down quickly and not have any downtime in between upgrades.

回答1:

I'd use Puppet but I'm kinda biased as I wrote a book about it and work there. :) In addition to Rump you can also use Puppet in its apply mode - which is the same as chef-solo. Although Rump wraps some goodness around the process that's worth trying out.

I'd give Puppet a shot here using Rump as a wrap around - you can both use the Puppet DSL OR Ruby DSL (Chef only has a Ruby DSL). It's very easy to create "environments" using Puppet and to integrate a git/CI workflow with your deployments. It's also easy to integrate with Rake tasks or the like.

回答2:

Having used both, I would say that it depends on what you look for. In my opinion:

• Chef is more developer-oriented. If you're a Ruby guru, you'll love it.

• Puppet is more sysadmin-oriented. It has a non-ruby DSL so it's more difficult to propagate mistakes to your machines (imho).

Puppet creates more readable and stable code but it's also slow to deploy new features. That's probably what you'll want in a big enterprise structure which strongly believes in your DevOps work.

With Chef you can achieve complex tasks with less code, time effort. You can use all the ruby magic without having to create a Puppet construct. This is good, for instance, when your Company doesn't truly believes in DevOps value and you're constantly struggling against time to prove your manager wrong :-) I personally find Puppet a bit slower to execute when you develop new features, which can be a bit of a pain.

My suggestion is: if you're a sysadmin with some development skills, go for Puppet. If you're good with Ruby (or Python), go for Chef.

I also tried rump and I'm playing with it. It helps, it's cool, but I still don't see a huge value except lazy typing of rump go instead of puppet apply -vd --modulepath=. module/manifests/init.pp. :)

回答3:

In the end I ended up with puppet + vagrant which allows me to run/rerun/test puppet manifests:

first install VirtualBox, then:

gem install puppet
gem install vagrant

then:

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

then edit ./Vagrantfile to say:

Vagrant::Config.run do |config|

  config.vm.box = "base"
  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = "manifests"
    puppet.module_path = "modules"
  end

  # rest here
end

then add a node definition to manifests/default.pp, like:

group { "puppet":
  ensure => "present",
}
file { '/etc/motd':
    content => "Welcome to your Vagrant-built virtual machine!\n"
}

then run:

vagrant up

Now you've got a puppet-managed virtual machine that you can play with, and any manifest that you change goes into source control. And you can iterate quickly without having to resort to rump.

回答4:

If you are familiar with Ruby, I suggest you try Chef than Puppet. Using chef&ruby, you can run very complicated task. However puppet is more clean domain defined than chef. Good or not, all up to your actual work.

回答5:

Another big difference between Puppet and Chef that hasn't been mentioned is that Puppet will do all of the manifest compilation on the Server, whereas Chef (and cfengine) will do some or all of the work on the client.

What this means is * Less CPU footprint on your client from running puppet, and * Add-in Modules written in Puppet run on the server only.

The second part is important, because it makes it much easier to integrate Puppet with your other architecture. For example, if you want to pull data via an API from another application, under Puppet you only need install the necessary API modules on the Puppetmaster, and only need to grant that one server access to the API. Any credentials necessary also remain on the puppetmaster - much more secure.

We're integrated Puppet and SecretServer (to auto-rotate root passwords using puppet and store them into SecretServer). This would not have been possible or secure under Chef, as I understand the model.