I've not gone beyond a few thousand servers with Puppet but I can share a few things.
* initially it feels like a *whole lot* of busy-work to get to a minimally-useful level * once there, knowing you can rapidly replace things is good for your stress levels! * in my experience the community Puppet modules are almost universally garbage (even when used on the Linux systems they are typically designed for) * don't split your Puppet code up into lots of separate repositories, it becomes too difficult to do very basic things like "check all production environments for X" (been there/done that, it was an unmitigated disaster) * some kind of monitoring of "how recently did Puppet succesfully apply a manifest?" is important to prevent config drift * listen to the linter! Other than the Puppet community module "quality", the same probably applies to any config management tooling; I'm just talking about Puppet because I've used it. I would consider it (much) more important to understand the tools you are using than to change tooling to be fashionable. Also here's some notes I took last year on running Ruby things on OpenBSD: http://jslee.io/post/151188252217/rubygems-and-openbsd Pupistry as mentioned in that post is great if you want to use Puppet but don't want to run a Puppet master server John On 29 December 2017 at 22:31, Ingo Schwarze <schwa...@usta.de> wrote: > Hi Micheal, > > it all depends on your specific needs and the scale of your deployment. > > When people maintain very large numbers of machines and very often > commission new ones and decommission old ones, i often hear such > people say that they wouldn't be able to handle their workload > without tools like ansible or puppet, but i don't have experience > with such tools. > > I still use RCS for a number of config files on a number of machines > where backup is taken care of in some different way. > > I don't have the slightest doubt that there may be situations where > CVS achieves the best balance of simplicity and features provided. > Even if you would give more details about your deployments, nobody > could judge better than you yourself whether that is the case for > your specific purposes. > > CVS is not very actively maintained, neither by the crowd at > nongnu.org nor by OpenBSD, but that shouldn't be much of a problem > for the purpose at hand. It poorly handles branches, renames, and > reverts of change sets touching many files, but probably neither > is relevant for your purpose. In principle, i don't see anything > wrong with using it, if it fits your task. > > Yours, > Ingo > >