I work with Matt and am filling in for him since I posed this question to 
him originally.

Our confusion really lies around how you layout profiles for a 
multi-function box. For example, suppose you have a role, "CMS App Server" 
that will host various CMS like Wordpress, Drupal, and others. They are all 
built on top of the same technologies, Apache, PHP, and MySQL. I don't 
believe you can build a separate profile for each CMS b/c they will 
conflict (at least within Puppet). Each will require a certain set of php 
modules and settings, apache modules and settings, etc. So do you build a 
single profile like profile::wordpress_drupal_cms3_cm4 or do you build a 
profile::apachefpm profile? The later seems more logical to me however you 
lose the ability to define profile specific hiera variables b/c 
profile::apachefpm is generic.


On Thursday, May 15, 2014 1:22:02 AM UTC-4, mjus...@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 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/457a1f16-7d8f-4bad-9d93-1f666127fb89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to