FAQ
Hi,

I am new in puppet, and I just wonder whether it is possible to create
multiple levels of puppet masters. Can puppet work this way?

First-level(master): root-master
Second-level(masters): master1, master2
Third-level nodes(as agents): agent1, agent2, agent3, agent4

All master nodes in the second-level are agents of root-master, and
each of third-level nodes is an agent of an second-level master node.

Thanks very much.

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

Search Discussions

  • Scott Merrill at May 26, 2012 at 11:14 pm
    I'm setting up this kind of configuration now. Yes, it can be done.

    Use a DNS alias (or hardware load balancer) for your second level
    Puppet Masters.

    I'm also using a DNS CNAME for my top-level Puppet Master, so that I
    can (later) consider some fault tolerance here. My top-level Master is
    my global Certificate Authority, so I'm using "puppetca" as the cname.
    My second level masters have "ca = false" in their config.

    All third level clients (my nodes) are clients of my second-level
    masters, and specify a config parameter of "ca_server = puppetca".
    On May 26, 2012, at 6:59 PM, LI wrote:

    Hi,

    I am new in puppet, and I just wonder whether it is possible to create
    multiple levels of puppet masters. Can puppet work this way?

    First-level(master): root-master
    Second-level(masters): master1, master2
    Third-level nodes(as agents): agent1, agent2, agent3, agent4

    All master nodes in the second-level are agents of root-master, and
    each of third-level nodes is an agent of an second-level master node.

    Thanks very much.

    --
    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.
    --
    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.
  • Steve Shipway at May 28, 2012 at 1:59 am
    I have set ours up like this.

    One top-level puppet server, hosting the CA, Filebucket, and Dashboard. This uses mod_balancer and mod_proxy to route to...

    Three backend puppet masters, handling the production environment manifests

    One backend puppet server, handling the dev and test environment manifests

    In addition, we have our departmental Subversion server, which synchs the puppet configuration to the three backend servers every 15min.

    To make changes, we do this in the test environment, then check it in to subversion and migrate to production, which causes a subsequent synch out to all 3 backend servers within 15min.

    We can theoretically have any number of backend production servers now, and the load on the frontend is relatively low. The CA must be on a single server, and we also put thefilebucket here to save on storage and make the dashboard work better -- though we could always put the filebucket onto a completely separate server if we so wished. The CA could likewise be farmed out but since its load is negligible theres no point in doing so. The dashboard could also be on a separate server but again it has low CPU requirements.

    We use DNS to point to the top-level server. Should we wish to have a remote puppet server (to save on bandwidth) then we can set one up with the same synchronisation, but not add it to the balancer group. Maybe make it use a local filebucket, but it can still use the central CA.

    This setup also allows us to have one dashboard, but still allow separate departments to run their own puppet environment behind the one DNS CNAME if they so wish.

    Most of the config info was taken from the Puppet book, though it misses out a key configuration item - you need to specify which env var and HTTP header carries the SSL auth information on the backend, unless you keep the CA on the same host.

    Steve


    Steve Shipway
    University of Auckland ITS
    UNIX Systems Design Lead
    s.shipway@auckland.ac.nz
    Ph: +64 9 373 7599 ext 86487

    --
    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.
  • LI at May 29, 2012 at 12:37 am
    Thanks so much for the enlightenment on this, Steve/Scott. Initially,
    I was pondering whether it was possible to make the root-master
    trigger the changes on the second-level puppet-masters and then down
    to third-level puppet agents. It seems that it is not possible.
    Otherwise, the subversion server can connect to the root-master only
    instead of syncing all second-level puppet-masters. If I get it wrong,
    please let me know. I have only less than 2-weeks of puppet learning.
    So, each comment/reply is helpful.

    Thanks again for your excellent detailed writings.





    On May 27, 9:59 pm, Steve Shipway wrote:
    I have set ours up like this.

    One top-level puppet server, hosting the CA, Filebucket, and Dashboard.  This uses mod_balancer and mod_proxy to route to...

    Three backend puppet masters, handling the production environment manifests

    One backend puppet server, handling the dev and test environment manifests

    In addition, we have our departmental Subversion server, which synchs the puppet configuration to the three backend servers every 15min.

    To make changes, we do this in the test environment, then check it in to subversion and migrate to production, which causes a subsequent synch out to all 3 backend servers within 15min.

    We can theoretically have any number of backend production servers now, and the load on the frontend is relatively low.  The CA must be on a single server, and we also put thefilebucket here to save on storage and make the dashboard work better -- though we could always put the filebucket onto a completely separate server if we so wished.  The CA could likewise be farmed out but since its load is negligible theres no point in doing so.  The dashboard could also be on a separate server but again it has low CPU requirements.

    We use DNS to point to the top-level server.  Should we wish to have a remote puppet server (to save on bandwidth) then we can set one up with the same synchronisation, but not add it to the balancer group.  Maybe make it use a local filebucket, but it can still use the central CA.

    This setup also allows us to have one dashboard, but still allow separate departments to run their own puppet environment behind the one DNS CNAME if they so wish.

    Most of the config info was taken from the Puppet book, though it misses out a key configuration item - you need to specify which env var and HTTP header carries the SSL auth information on the backend, unless you keep the CA on the same host.

    Steve

    Steve Shipway
    University of Auckland ITS
    UNIX Systems Design Lead
    s.ship...@auckland.ac.nz
    Ph: +64 9 373 7599 ext 86487
    --
    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
postedMay 26, '12 at 10:59p
activeMay 29, '12 at 12:37a
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase