Puppet users - May 2012 - Is it possible to set up multi-level puppet nodes?

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.

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 <hli713@gmail.com> 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.

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.

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 <s.ship...@auckland.ac.nz>
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.