0

There seem to be two different ways to distribute puppet manifests:

  1. Centralized:

    This involves running a central puppet master server which is periodically queried by puppet agents for changes.

  2. Decentralized:

    In this case there is no central puppet master server and manifests are distributed to the nodes some other way, for example via Git. Then a node runs puppet apply to apply the changes.

I would like to know what are the main differences between the two approaches and if any puppet feature depends on a particular approach.

grekasius
  • 2,046
  • 11
  • 15
  • possible duplicate of [Pros and Cons of a Decentralized Puppet Architecture](http://serverfault.com/questions/408261/pros-and-cons-of-a-decentralized-puppet-architecture) – ewwhite Jul 26 '14 at 12:35
  • I don't know, that duplicate question/answer isn't that great either. A lot changed since then. Setting up a Puppetmaster is pretty easy for a professional. I wouldn't want to miss the advantage of centralized reporting (via Puppetdb). I think this question is pretty much opinion based. – faker Jul 26 '14 at 13:59

2 Answers2

1

It depends.

I use Puppet Enterprise, so out of the box, it's pretty well-equipped to handle the geographically-dispersed environment I manage. For me, I also leverage mcollective, which provides other benefits.

See what works for you. Everyone does this differently. I wouldn't use a Git approach unless you had a specific constraint. E.g. do it the Puppet way unless you have a reason not to.

ewwhite
  • 194,921
  • 91
  • 434
  • 799
1

I'm not 100% sure about others but stuff like exported resources definitely depend on having a puppet master with puppet DB.

I doubt there will be stuff that you can do with a decentralized architecture and not with a centralized one.

Florin Asăvoaie
  • 6,932
  • 22
  • 35