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