Comment by Goladus | Hacker News Reader

Comment by Goladus | Hacker News Reader

Parent Full thread

Puppet requires both a puppet server (Rails) and client, SSL key exchange, firewall rules for the puppet server, proper DNS records for everything, and a host of dependencies, all of which you need to set up before you can actually do anything.

Not to join the chorus of "that's not actually true" I do want to take a step further and say that's not even the way I'd recommend using puppet.

The puppet server gives you an alternate authentication method (SSL vs SSH is a toss-up imho), a fileserver (rsync is better), a "dumb client" model where clients are only given the files and configs they actually need, and a master server to process all the manifests and load them into memory, etc., which might under some circumstances (which I have never encountered) help performance. That's about it. If anyone else has other insights on the benefits of deploying a master I'd be happy to hear them.

If you don't need any of those things, you don't ever need to deploy a puppet server. You need ruby and its dependencies, you need facter and its dependencies, and possibly a couple of other libraries (ruby-augeas, etc.), most of which are built in to modern distributions. Ideally you will use revision control as soon as possible. Rsync your manifests and run the puppet client on them directly. That method scales up or down really well and is generally more flexible (see the comment below about difficulty testing changes)

> You need ruby and its dependencies, you need facter and its dependencies, and possibly a couple of other libraries (ruby-augeas, etc.),

But how is that nice? Perl, sh, bash are built in to every distribution. Learn from the RVM setup; it's very good. Or better; just deliver OS packages; we didn't get this far with aptitude to have everyone roll their own!?

On Ubuntu Lucid EC2 images there is no Ruby and if there was, I don't want it; I want RVM. So basically, you are saying that to provision my server I need to provision my server...

Another comment said it can be done auto; is that true or do we still need to install Ruby etc? We have it all automated now, but the use for Puppet is kind of gone; by the time Puppet is up and running, > 80% of the required software is already installed...

Sounds like puppet's not worth it for you, then.

Puppet is not a server provisioning tool. It's not a "roll-your-own" aptitude, it's a different approach to the problem. Puppet is primarily meant to manage the sort of end-user configuration for which packages only provide defaults. If you're handling all of that with the package manager, or if your need to manage configuration is minimal, then don't use puppet. It doesn't have lots of dependencies but it does have some, and it's language is syntaxy.

Yes, I liked the way it can be scripted, but I guess I did understand the purpose then. When you search on Google for provisioning servers + rails, you come onto Puppetmaster almost exclusively. I'll keep an eye on it anyway. Thanks for the insights.

I'm not sure why you'd say puppet isnt a server provisioning tool. This managing of configurations you talk about, the way puppet interacts with package managers to install packages, these are the tasks I think about when I hear server provisioning.

Provisioning and configuration management are converging, but aren't the same thing. I agree that you can use puppet to help a lot with provisioning servers, but that's not its reason for being.

Provisioning is the process of taking a baremetal server and making it usable. Configuration management is about organizing ongoing changes to the infrastructure.

Red Hat Kickstart and Solaris Jumpstart are examples of provisioning tools that don't help much with configuration management. Cobbler is provisioning tool built on Kickstart. Systemimager is a cloning-style provisioning tool.

These tools all help you get an OS up and running on a machine. Optionally, most of them can be used to do a great deal of software installation and system configuration beyond the basic OS install. But most of them aren't, for example, especially interested in helping with issues like adding a new apache virtualhost to httpd.conf, or a new DNS zone to named.conf, or a new root cron entry to run on all application servers, or reconfigure iptables on every system. Tools like puppet and cfengine are very interested in these scenarios.

The line is fuzzy, but when standing on one side or the other its obviously there somewhere.

Puppet is not a server provisioning tool.

Unless I misunderstand you, it certainly is when using Vagrant.

Why is installing Ruby "provisioning my server" while installing Puppet is somehow "not provisioning my server"?

I have one issue with this: I actually like clients being given only the files and configurations they need. Using rsync or git to propagate the puppet manifests implies that each remote host gets all the files, and in those there may be sensitive informations for the other hosts (database passwords for example).

In this scenario, if one of the hosts is compromised, much more information is leaked than in the case of a puppet server. How do you deal with this problem?

Reply on news.ycombinator.com