On 5/14/2014 10:22 PM, 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
o Base Components
+ SSSD
+ Sudo
+ NTP
o 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?
As always John's response earlier in the thread was spot on.
Determining role rather than roles is the basis of your problem.
The way I design role/profile today is to think in terms of creating a
data schema that describes my system. Then I assemble roles, profiles,
and modules to consume that schema. That schema is realized in the
hiera.yaml. A simple flexible hiera.yaml might look like:
:hierarchy:
- hosts/%{clientcert}
- env/%{environment}/%{role}
- role/%{role}
- env/%{environment}
- common
I believe that role (or some unique fact, enc lookup, whatever) is the
right place to insert function specific data because it is unique to
that group of servers. Some resources like sourcing firewall rules based
on multiple profiles are more likely to lead to conflicts particularly
if there are overlapping functionality. Some resources like vhosts are
unlikely to collide though load order might be unexpected.
As a side note attempting to do role/profile without Hiera, ENC,
Foreman, or some sort of external data source is doomed to fail in my
opinion.
I'd also like to disagree slightly with Christopher who also posted in
this thread. Your profile:: classes are the perfect place for all sorts
of site specific nonsense including resources. In fact if you're not
sufficiently embarrassed of your profile classes you're probably not
taking full advantage of that abstraction layer. I wrote about how I
use/abuse them here,
https://ask.puppetlabs.com/question/5235/what-goes-in-the-profile-part-of-roleprofile/
Ramin
--
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/53750B41.40806%40badapple.net.
For more options, visit https://groups.google.com/d/optout.
