I've found Puppet to be unreliable running as a daemon - I suspect due to older versions of ruby floating around. So I switched to running it from cron, and it works a lot better. Memory usage doesn't seem to be an issue, and the agent only runs for a few seconds. Use Puppet Dasboard (or something like it) and/or use Nagios to make sure those cron jobs run. I use both.
The main thing is to have Puppet managing itself and the cron job. I have ours set up to run the cron job twice an hour, using the concatenated IP address modulo 30 and modulo 30 + 30 as the times (to keep the clients from hammering the Puppetmaster all at once). Let me know if you go with Puppet and I'll show you how I did it. Part of the reason we chose Puppet was the quantity of documentation and working examples and the helpfulness of the community. I support (and implement) our Puppet environment here at my job. I would highly recommend Mr Turnbull's Pro Puppet book. It is VERY sysadmin focused and will save you a lot of time. The sections on environments, modules, and Dashboard were really helpful. Jeffrey Sent from my iPad On Dec 8, 2011, at 2:59 PM, Luke <lutay...@gmail.com> wrote: > This tool will be used by primarily system admins to automate server > builds app installs, configurations etc. The devs will use it in their > own environment to help automate some of their tasks. I don't think we > have too much Ruby expertise since we are mostly a Java shop. > > In terms of performance I have read that CFengine uses much less > memory and can be faster than puppet. Can anyone comment on the agent > and server memory usage? I have read that the puppet agent can use > 85mb and the server upwards to 1GB after 20-30agents. Is that > accurate? > > I guess which tool would you consider to be the quickest, easy to > implement etc? From what I am seeing the community here seems to be > much more active than the others. I have yet to get a response on the > other forums. > > On Dec 8, 4:39 pm, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote: >> I should also add that a very important consideration is to take in mind >> _who_ will be working with this. Are they developers, sysadmins, QA? Will >> the people working on it be spending a lot of time with >> Puppet/Chef/CFengine, or just a little? Are you planning on writing a >> bunch of custom modules, or relying on the community? What languages does >> your team work on primarily? For example, folks that work with Ruby a lot >> would probably do better with Puppet and Chef. >> >> As a sysadmin, I often see developers get distracted by arguments about >> what's "best" or the most technically advanced. Often they forget that in >> the end the real answer is often which tool gets the job done the quickest, >> with the least amount of labor, and is the most supportable. >> >> Jeffrey. >> >> On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman <dan...@puppetlabs.com>wrote: >> >> >> >> >> >> >> >> >> >>> Instead, I suggest you focus on your ability to learn the concrete use >>> of the tool, and on how effectively you can solve problems with them; >>> doing a small trial of each - solve the same mid-sized problem three >>> times, giving each a day or two - and see what you think works best >>> for your company and culture. >> >>> There is no silver bullet. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
