Much of what I would suggest depends on the exact setup of your servers. Here are a few generic suggestions:
You already want to use hiera. That's great, but like any tool, if you do not use it properly, you can booger it all up. I started using puppet before hiera and I can personally vouch for how great it is to pull all the per-server data out of the main "code" base. Hiera is built into puppet-master, so no worries there. I cannot speak about mcollective as I do not use it (small buncha servers) Use the hierarchy and priority to organize your servers by functional groups. In my location, I started with a generic server (dev), then got a QA server, and a production server from that. Production servers split into internal and external (dmz). I hope this helps you get started. Try not to do it all at once. Take it in smaller steps. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) ----- Original Message ----- From: "Paul Archer" <geek65...@gmail.com> To: puppet-users@googlegroups.com Sent: Friday, August 23, 2013 12:03:41 PM Subject: [Puppet Users] Best practices for infrastructure I'm new to puppet, fixin' to (in Texas parlance) setup a largish installation, and want to make sure I get things right the first time. I have a colo plus several satellite locations, with many more on the way. I'll be using open-source Puppet, as we have way too many nodes to manage (potentially 275+ at each site) to afford PE. I'm thinking about setting up a master in the colo with a slaved master at each site, following this document: http://docs.puppetlabs.com/guides/scaling_multiple_masters.html Each master will run passenger/apache. I'll have puppetDB running on the primary master at the colo (with an eye to moving it to a separate server if needed). I'll probably use Subversion (but maybe git) for synchronization of data among masters. I'd like to use mcollective and hiera, so those will probably get setup on the primary master. (Do I need them on each master?) One of our sites is a lab, so I'll be doing testing there.I'll need to setup some kind of dev/test/prod environment system. I'll be testing both dashboard and foreman, although I need to do automated bare-metal installs, so foreman will probably win out there. Each site also has around 100 nodes that break and get swapped out frequently, so (depending on what foreman can do for me in the installation process) I might need to be relatively lax about certificates to avoid revoking and regenerating them constantly. (We're talking 2-3 nodes a week getting pulled, worked on, and replaced or reimaged.) So that's where I am right now. Any thoughts, suggestions, tips, how-tos would be greatly appreciated. Paul -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users . For more options, visit https://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
