I've not gone beyond a few thousand servers with Puppet but I can share a
* initially it feels like a *whole lot* of busy-work to get to a
* once there, knowing you can rapidly replace things is good for your
* in my experience the community Puppet modules are almost universally
(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
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
is important to prevent config drift
* listen to the linter!
Other than the Puppet community module "quality", the same probably applies
any config management tooling; I'm just talking about Puppet because I've
I would consider it (much) more important to understand the tools you are
than to change tooling to be fashionable.
Also here's some notes I took last year on running Ruby things on OpenBSD:
Pupistry as mentioned in that post is great if you want to use Puppet but
want to run a Puppet master server
On 29 December 2017 at 22:31, Ingo Schwarze <***@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.