I'm not sure about your #2 and #3. I've not really experienced either of those and I wouldn't expect they are regular for most people. It would probably be more helpful if you could post more specifics when one of those things happens.
As to #1, it maybe depends on how you administer your systems. Even if files should not be changing under normal circumstances, managing them with Puppet can make sure that doesn't happen (or at least that it's corrected the next agent run). It sounds like you were already putting your configs in version control, from that point it's not a ton of extra overhead to write Puppet code to manage them. If you're just starting out with it, you'll get faster/better at that part too. And if those resources aren't changing, then it's not a lot of overheard for Puppet to deal with them. Agent runs where no changes need to be applied should be pretty fast. I'd also encourage you to think about scenarios like losing a node and having to rebuild it from scratch. Suddenly all of those files that don't normally change are gone and need to be replaced. Puppet can do that very quickly. Or needing to spin up additional nodes to do the same task, that can become very easy. One of the other things I see as a huge benefit with Puppet is that it's self-documenting. If you want to know what's going on with your systems you can just look at the code. I was in a situation about a year ago where I inherited a Puppet install when a co-worker left, and it was a huge advantage, that the code had so much information. And since it's running all the time you don't have to worry about whether it's stale like a Wiki page. That all said, if there's something you feel it's not necessary to manage, then that's up to you and your team. I've definitely found that the more I've used Puppet the easier it's gotten, which means it's less of a burden to take the time to manage extra things. Puppet isn't the best tool for everything, but it's a great one for managing files. There's not really a way to tell an agent to run against just a subset of the manifest sometimes and others other times, without doing something pretty goofy. You can make manging files a bit easier in a few ways, like specifying default attributes/values and using arrays of filenames, if you want to apply the same settings to multiple files. Rich On Monday, June 16, 2014, Stephen Morton <stephen.c.mor...@gmail.com> wrote: > I've got some newbie puppet questions. > My team has a tremendous amount of linux/computer knowledge, but we're new > to Puppet. > We recently started using puppet to manage some 100 servers. Their configs > are all pretty similar with some small changes. > > ---- > History > > Prior to Puppet, we already had a management system that involved having > config files under revision control and the config file repo checked out on > every server and the repo config files symlinked into the appropriate place > in the filesystem. Updating the repo would update these files.This was > mostly just great, with the following limitations: > > > - If the symlink got broken, it didn't work. > - Some files require very specific ownership, or were required not to > be symlinks (e.g. /etc/sudoers. /etc/vsftpd/ files I think) > - Updating a daemon's config file does not mean that the daemon is > restarted. e.g. updating /etc/httpd/conf/httpd.conf does not do a "service > httpd reload" > - You can't add a new symlink. > - All files must be in revision control to link to. Some > security-sensitive files we want to only be available to some servers and > something like puppet that can send files over the network is a good > solution to this. > > ---- > > Puppet to the rescue? > > So we've tried a very conservative Puppet implementation. We've left our > existing infrastructure and we just add new rules in Puppet. So far, we > have a single site.pp file and only a dozen or so rules. But already we're > seeing problems. > > 1. Puppet is good for configuring dynamic stuff that changes. But it > seems silly to have rules for stuff that will be configured just one time > and then will not change. If we set up some files, we don't expect them to > disappear. In fact if they do disappear we might not want them silently > fixed up we probably want to know what's going on. Doing everything in > puppet results in ever-growing manifests. I don't know of a way to specify > different manifests, e.g. every 30 minutes I want Puppet to run and request > the lean and mean regular manifest and then once a week I want it to run > the "make sure everything is in the right place" manifest. > 2. Puppet seems very sensitive to network glitches. We run puppet from > a cron job and errors were so frequent that we just started sending all > output to /dev/null. > 3. Endless certificate issues. It's crazy. So sometimes hosts would > get "dropped"... for unknown reasons their certificates were no longer > accepted. Because we'd already stopped output (see previous bullet point) > we would not know this and the server would be quietly not updated. And > when you get a certificate problem, often simply deleting the cert on the > agent and master won't fix it. Sometimes a restart of the master service > (or more?) is required. > - The solution to this to me is not "you should run puppet dashboard, > then you'd know". This shouldn't be failing in the first place. If > something is that flaky, I don't want to run it. > > (We're running version 3.4.2 on CentOS 6.5, 64-bit.) > > --- > > Questions. > > So my questions for the above three issue are I guess as follows > > 1. Is there a common Puppet pattern to address this? Or am I thinking > about things all wrong. > 2. Is there a way to get puppet to be more fault-tolerant, or at least > complain less? > 3. Are endless certificate woes the norm? Once an agent has > successfully got its certificates working with the server, is it a known > issue that it should sometimes start to subsequently fail? > > > Thanks, > > > Steve > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com > <javascript:_e(%7B%7D,'cvml','puppet-users%2bunsubscr...@googlegroups.com');> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/08b72832-d18a-4397-9587-a769f0ee2d6e%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/08b72832-d18a-4397-9587-a769f0ee2d6e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAPGcbtDBE10KFKmDeDAWGm%3DF48Y1m3gAVuh_gx9vXBvM6C65iw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
