I have series of module servers that serve modules to the host. I don't use puppetmasters though. In a nutshell, I have a manifest server called the 'puppeteer' that generates manifests based on meta data stored in a database. Well, it will be in database soon. For now it's in XML files. The meta data contains everything from modules and what version of the modules a host should have as well as things like variables, virtual resources, resource defaults and classes. When it's time for a host to do a puppet run, the puppeteer generates a manifest and puts an entry in to a queue for that host. A service on the host, called 'puppetstring' polls the queue every few seconds for work. When there's an entry in the queue for it, it pulls down its data (the manifest and modules it needs). It syncs up the modules and the appropriate version from the local module servers (puppetcache servers) and executes the manifest.
This awards me much flexibility. Basically my modules rarely contain data, just structure. The contents of files, and even entire resources themselves can be controlled through a web interface and be deployed on the host, site or global level. This also allows me to do automated rollouts where I have a sequence of hosts do runs and based on their success or failure, I can determine whether or not to move on to the next step. This also allows me to allow certain control over specific machines and resources to end users. My database engineers can, for instance, control the contents of the tnsnames.ora files on all Oracle clients through a web interface. I can also put logic in to my scheduling of runs based on external criteria. For instance, if the cluster has a lot of work to do for the next two hours, don't do puppet runs every thirty minutes but instead every hour to reduce the CPU load. Or maybe don't do a run on a cluster node if more than 40% of the cluster nodes are currently doing runs. The web interface has yet to actually be built and I'm really sure whether or not I should extend on The Foreman or role out my own, but that's another topic. I've promised several people a blog post on all this and one day I'll deliver on that promise :) On Nov 16, 2009, at 9:43 PM, Ohad Levy wrote: > > > On Tue, Nov 17, 2009 at 11:33 AM, Scott Smith <sc...@ohlol.net> wrote: > > > Oh, no. We have some pretty cool deployment tools that I use to deploy > puppetmasters. I can also use them to update manifests as if they were > config updates to any other app. > you are not using puppet to manage your puppetmasters? > > > We have something like 4k or so hosts in prod (and another 1k or so in > qa/dev) so it's pretty much a necessity =) > I know the feeling > > It also allows me to enforce a true development lifecycle model for > Puppet. The manifests, configs, and everything else really do look like > any other app we develop/maintain. > This is the main reason why we've started using environments, this was one of > the only ways we could ensure that a host manifest will change only if it was > planned to release. > the testing process was also simplified a lot, as you can just create a test > env with the same links (actually puppet does it all for you) but you can > just play with the links to point to newer versions of your modules. > > on a side note, if you are willing, I'm interested in the performance of > Foreman (http://theforeman.org) in a large infrastructure (for the Puppet > reports, inventory etc) , I'll appreciate it if you are willing to provide > feedback > > cheers, > Ohad > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
