On Monday, May 19, 2014 10:18:11 AM UTC-4, jcbollinger wrote:
>
>
>
> On Friday, May 16, 2014 10:55:35 AM UTC-5, 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.
>>
>>
>
> You can declare the same class multiple times, provided that you use the
> 'include' function or its cousins to do so. That is a tremendously useful
> technique for managing configurations where multiple facilities share
> requirements on some of the same core resources. Using 'include' instead
> of resource-like class declarations means you must feed data to your
> classes via hiera instead of via your manifests, but separating your data
> from your manifests is good practice anyway. That's what Christopher Wood
> was pointing you toward, and it is good advice.
>
>
We're aware of most of this and agree with most of this. However when you
always call include, you lose the ability to say a particular hiera
variable is attached to the profile. For example
If you define:
class profile::apache_phpfpm {
include ::apache
}
with the following in hiera:
apache::keepalive = 1
keepalive = 1 applies anywhere apache is included
vs
class profile::apache_phpfpm (
$keepalive = 1
) {
class { ::apache:
keepalive => $keepalive
}
}
profile::apache_phpfpm::keepalive = 1
So with the later you can build a somewhat self-contained profile. With the
former you have to set variables "globally" or on a node.
> It is thus possible to find and/or write composable classes and modules
> for managing the components you want. As David Schmitt observes,
> composability is not automatic, but I don't see why your particular case of
> an apache-based PHP app server with firewall rules and a specific
> collection of PHP and apache modules should present any special problem.
>
> Thus, the answer to your question is "neither." You build a drupal
> profile, and a wordpress profile, etc., and you use them all together.
>
>
So below is an example for Drupal. It could literally be cloned for
Wordpress and Joomla. Unfortunately, b/c of the class declarations, it is
not composable.
class profile::drupal (
$apache_listen = ['80'],
$apache_name_virtual_hosts = ['*:80'],
$apache_modules = ['fastcgi'],
$apache_fastcgi_servers = {
'www' => {
host => '127.0.0.1:9000',
faux_path => '/var/www/php.fcgi',
alias => '/php.fcgi',
file_type => 'application/x-httpd-php'
}
},
$phpfpm_pools = {
'www' => {
listen => '127.0.0.1:9000',
user => 'apache',
pm_max_requests => 500,
catch_workers_output => 'no',
php_admin_value => {},
php_value => {}
}
},
$php_modules = [],
$firewall_rules = {},
$backup_jobs = {},
$cron_jobs = {}
) {
include ::apache
::apache::listen { $apache_listen: }
::apache::namevirtualhost { $apache_name_virtual_hosts: }
::apache::mod { $apache_modules: }
create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
include ::php::fpm::daemon
create_resources(::php::fpm::conf, $phpfpm_pools)
::php::module { $php_modules: } ~> Service['php-fpm']
# So the apache user is created before
# php-fpm starts
Class['::apache'] -> Class['::php::fpm::daemon']
create_resources(firewall, $firewall_rules)
create_resources(::duplicity::job, $backup_jobs)
create_resources(::cron::job, $cron_jobs)
}
>
> John
>
>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/6a4218c6-fb00-4434-aa56-56de3fb33eff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
