Hello Jesse & Matt.
This might be a dumb question, but can you build a system manually with the
various CMSes? Are there a cross-set of technologies (Apache, PHP, MySQL)
that will work on all CMSes in your organization? I would think in terms
in how you would build these systems manually w/o puppet in some organized
way, then see how this can fit into puppet. If you can build some
reference platform that can host some or all of these, then you have your
basic profile for that wonder-web-box system.
Complexity might come in when you start separating, such as putting php in
it's own module and apache in another, then sequencing them in profile.
You can use augues to scissor php specific configurations. This is what I
do for a nginx + php-fm configuration.
class profile::webserver { class { "nginx": } -> class { "php": } }
On Friday, May 16, 2014 8:55:35 AM UTC-7, Jesse Cotton wrote:
>
> 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/b5e35060-be8e-4dcb-9755-159c20e1fc9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
