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,056
  • 12
  • 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
  • 197,159
  • 92
  • 443
  • 809
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
  • 7,057
  • 23
  • 35