(inline) On Wed, May 14, 2014 at 10:22:02PM -0700, mjuszc...@gmail.com 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]puppet-users+unsubscr...@googlegroups.com. > 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:puppet-users+unsubscr...@googlegroups.com > 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 puppet-users+unsubscr...@googlegroups.com. 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.
