(inline)
On Thu, May 15, 2014 at 11:45:21AM -0700, Ramin K wrote:
> 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/
(I think I had this exact conversation when discussing profiles at work.)
This is usually where I say: If you have site-specific things you should
modularize those and add the relevant include statements and chaining to the
profile, with the data in hiera.
For us that includes a site level in hiera so that hosts at different sites get
different puppetmasters (server not ca_server), ntp servers, resolvers, and so
on. This helps us use the mnemonic that anything in node yaml indicates either
an oddity or an error. This will also let us quickly include a module if we
need it somewhere else.
Of course, your mileage may vary, mine sure has at times.
> 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.
--
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/20140515191436.GA19133%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
