Let me emphasize the beauty of running Puppet out of cron. Not only do you not end up with resource leaks (or just simple consumption when you don't need it), but you also get much more reliable load on your puppet masters. Further, if you are wiling to make a trivial effort to write a site-specific fqdn_rand() work-alike function, you can even arrange to be sure that updates roll across related servers in a reliable way.
On Thu, Dec 8, 2011 at 6:08 PM, Jeffrey Watts <[email protected]>wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected] > >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 [email protected]. > > To unsubscribe from this group, send email to > [email protected]. > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
