FAQ
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.

Search Discussions

  • Gabriel Filion at Jul 17, 2012 at 11:48 pm

    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.
  • R.I.Pienaar at Jul 17, 2012 at 11:59 pm

    ----- 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 17, '12 at 1:12p
activeJul 17, '12 at 11:59p
posts3
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase