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.
Any system management solution that requires anything more than a bare machine with SSH and sudo is, in my book, not terribly practical, because these are the lowest common denominator on what you'll get from any hosting provider or OS install.
In a nutshell: I shouldn't need to configure my servers before I configure my servers.
Let me endorse both of the above posts. Having now spent many months tinkering with Puppet, I wish to god I had fully understood the value of not using any of Puppet's server features but had instead just shipped the manifests via some other method and applied them locally.
If you need a super-performant version of that strategy (which you probably don't) try googling up Twitter's "murder" project. (Not as violent as it sounds! It's the crow kind of murder.)
Until I read this thread, I didn't even think of that as an option -- everything in the Puppet documentation, and the community, and in what they offer as far as training courses, indicates that Puppet's client-and-server are the light and the way to rightness.
I'll have to take a second look at the Puppet manifest system coupled with Capistrano (which I really like), but it still irks me that there isn't one tool to handle configuration management across a large number of servers.
Any solid, good Howto's; we're using puppet as well and had the same issues. We use Capistrano + Puppet + some custom scripts; we would like to get rid of the latter.
Is there any howto for setting up a completely clean/empty Linux (Ubuntu / Debian) with RVM as Ruby installer? But thanks for this; at least now I know there is a solution :)
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...
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.
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.
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 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?
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.
Any system management solution that requires anything more than a bare machine with SSH and sudo is, in my book, not terribly practical, because these are the lowest common denominator on what you'll get from any hosting provider or OS install.
In a nutshell: I shouldn't need to configure my servers before I configure my servers.