(inline) On Wed, May 14, 2014 at 10:22:02PM -0700, [email protected] wrote: > Hi all, > We use the roles/profiles/components model originally suggested by Craig > Dunn fairly heavily. In our case: > > * The role is a business name, like "Application X App Server" > * The profile is the technical name, like "Base Components" or > "Webserver" > * The components are either wrapper classes around modules or modules > themselves, like "PHP" or "Apache". > > For the most part, this works well. We can have, for example: > > * MyFace Application Server > > * Base Components > > * SSSD > * Sudo > * NTP > > * PHP Webserver > > * PHP > * Apache > * PHP-FPM > * Memcache > > However, we're running into trouble how to handle the situation > where you're running a box with multiple functions... for example, > WordPress and Drupal. In that case, how do you handle configuration > conflicts? On the surface, it seems like we would create a more generic > profile like "PHP Webserver" (like I did in the above example). If I do > this, however, I lose the ability to define profile specific variables > such as firewall rules, cron jobs, etc. > Any thoughts on this? > Best, > Matt
You might be interested in this thing, it helped me a great deal: https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/ Other tips: -only includes and chaining in roles/profiles (no resources) -never use resource style declarations for classes anywhere -all data in hiera -make lots of use of include directories in configurations -examples: /etc/httpd/conf.d, /etc/profile.d My further rhubarbing: Sounds like you'd end up with three roles to start: wordpress server drupal server wordpress+drupal server A bit of thinking about how to break out commonalities into other hiera levels and you're there. Later on, perhaps try combining those into a single "phpttpd" role where hiera flags set which php configuration bits are installed into the aforementioned include directories, with suitable chaining freeing you from too much explicit notify/subscribe. Which model you use depends on how you use the servers and whether it's easier for your admins to think of them all as generic servers with pseudo-random features per host, or hosts with one specific function. I've preferred the first for most of my stuff, but another department prefers the second style given their operational constraints. > -- > 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 [1][email protected]. > To view this discussion on the web visit > > [2]https://groups.google.com/d/msgid/puppet-users/c1157f75-5a08-4e13-8739-abef8bd23cf4%40googlegroups.com. > For more options, visit [3]https://groups.google.com/d/optout. > > References > > Visible links > 1. mailto:[email protected] > 2. > https://groups.google.com/d/msgid/puppet-users/c1157f75-5a08-4e13-8739-abef8bd23cf4%40googlegroups.com?utm_medium=email&utm_source=footer > 3. https://groups.google.com/d/optout -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140515135819.GA16761%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
