Puppet users - Jul 2012 - Pros and Cons of a Decentralized Puppet Architecture

We have around 300 RHEL servers that are currently connecting to a 
Puppetmaster server. However, we have noticed some performance bottlenecks 
and it is the point of failure in our system. I am fairly new to puppet in 
general and I am considering creating a decentralized puppet architecture 
instead of having Puppet clients connect to the Puppetmaster server. Aside 
from what I would suspect to happen such as performance gain and lack of 
signing and exchanging SSL certs for new machines, what are other pros and 
cons to setting up a decentralized architecture?

Note:  The reason behind the question is its always a good thing to reduce 
server count around here

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/fA3wU_H2l1cJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 12-07-17 09:11 AM, JMeterX wrote:
> We have around 300 RHEL servers that are currently connecting to a
> Puppetmaster server. However, we have noticed some performance
> bottlenecks and it is the point of failure in our system. I am fairly
> new to puppet in general and I am considering creating a decentralized
> puppet architecture instead of having Puppet clients connect to the
> Puppetmaster server. Aside from what I would suspect to happen such as
> performance gain and lack of signing and exchanging SSL certs for new
> machines, what are other pros and cons to setting up a decentralized
> architecture?
here''s an incomplete list that comes from the top of my head.

pros:

 * you move the single point of failure security-wise to a repository
from which your nodes pull the manifests, which is probably easier to
secure (less moving parts).
 * the setup scales much better than with a centralised puppet master.
the performance that you''ll need to be verifying is wheter too much
nodes pull the manifests simultaneously. everything else is done by each
node.

cons:

 * passing resources and files from one node to another (e.g. collecting
resources) is tougher. you pretty much have to reinvent a method of
doing it.
 * you really have to trust users with root access on each node since
manifests are pulled directly on the server (and can thus be modified
locally).

-- 
Gabriel Filion

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- Original Message -----
> From: "Gabriel Filion" <lelutin@gmail.com>
> To: puppet-users@googlegroups.com
> Sent: Wednesday, July 18, 2012 12:48:00 AM
> Subject: Re: [Puppet Users] Pros and Cons of a Decentralized Puppet
Architecture
> 
> On 12-07-17 09:11 AM, JMeterX wrote:
> > We have around 300 RHEL servers that are currently connecting to a
> > Puppetmaster server. However, we have noticed some performance
> > bottlenecks and it is the point of failure in our system. I am
> > fairly
> > new to puppet in general and I am considering creating a
> > decentralized
> > puppet architecture instead of having Puppet clients connect to the
> > Puppetmaster server. Aside from what I would suspect to happen such
> > as
> > performance gain and lack of signing and exchanging SSL certs for
> > new
> > machines, what are other pros and cons to setting up a
> > decentralized
> > architecture?
> 
> here''s an incomplete list that comes from the top of my head.
> 
> pros:
> 
>  * you move the single point of failure security-wise to a repository
> from which your nodes pull the manifests, which is probably easier to
> secure (less moving parts).
not really the case, you still have a single place where manifests live
that nodes pull the manifests from using git or whatever, thats still
a single point of attack.

the key exchange problem is generally harder since now you need to figure
out how to get git (or whatever) credentials on the node, often that means
a ssh private key and you need to either manage a per node public key on
the git server or share among your ndoes the same one thats tightly controlled
via say git-shell and force commands.

worse now you have all the code on all the nodes unless you invest heavily
into a setup that can output build artefacts of just the data relevant to 
that node this is in most circumstances very undesirable.
>  * the setup scales much better than with a centralised puppet
>  master. the performance that you''ll need to be verifying is
wheter too much
> nodes pull the manifests simultaneously. everything else is done by
> each node.
> 
> cons:
> 
>  * passing resources and files from one node to another (e.g.
>  collecting resources) is tougher. you pretty much have to reinvent a
method of
> doing it.
exported resources work, puppetdb will mostly work even in a masterless 
environment, the ''mostly'' bit is being worked on.
>  * you really have to trust users with root access on each node since
> manifests are pulled directly on the server (and can thus be modified
> locally).
if they have root they can just amend the machine direct in ways you dont
manage, the problem of the code on the node is its much easier to determine
how to work around puppet and do things that wont be managed etc since its
all clear - similarly easy if u get your hands on a compiled catalog though.

Bigger problem is any kind of secrets, keys, certs etc for different hosts
that you might have in your code is shared.

A big con is also that ''apply'' is very much a 2nd class
citizen, there''s a
number of things it cant do - write classes.txt, resources.txt etc, pluginsync
is broken etc.  Some of these are slated for improvement in puppet 3 but mostly
its a pain.    

That said, I run masterless now and have been much happier since, warts and all.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.