Steve, I think you said you put all your configuration in a single site.pp. This is often bad form and limits the flexibility of your deployment. Something we do is layout modules.
The common pattern is: /etc/puppet/environments/production -> Manifests/site.pp -> Hieradata/*.yaml -> Modules/foo This keeps everything in the production environment. All of your clients will do this normally. One of the beauties of doing this is you may want to do a cron job weekly that runs with a different environment like "weekly". To take advantage of the flexibility you may want to group servers into buckets by sticking custom facts and including modules based off them. As for the Network issues. I think you may be running your puppetmaster with the built in webbrick server. In my experience this offers a single threaded approach to the puppetmaster with it failing if more than one client connects at a time. Setup apache and run Passenger to allow for multiple threads. Info on Environments: http://docs.puppetlabs.com/puppet/latest/reference/environments.html#enabling-directory-environments (note this was introduced in 3.5 so you may want to checkout the legacy way to achieve the same thing. ) Passenger with Apache: http://docs.puppetlabs.com/guides/passenger.html Finally to get visiblity into the network I would strongly suggest setting up PuppetDB with Puppetboard as puppet Dashboard is effectivly dead. Info on PuppetDB http://docs.puppetlabs.com/puppetdb/2.0/install_from_packages.html PuppetBoard module on the forge. https://forge.puppetlabs.com/nibalizer/puppetboard Last tip I would give to someone new is use an IDE that helps you code. Puppetlabs maintains Geppetto for this purpose. http://docs.puppetlabs.com/geppetto/4.0/ On Mon, Jun 16, 2014 at 1:33 PM, Stephen Morton <[email protected]> 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAOwhAco2zb2D7C-W%3DhC57HGETRg_cd-38ZcWQSUp4dRJjXF%3DaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
