Perhaps I am overlooking something. How would you construct the hierarchy
so you could set apache::keepalive for this profile?
class profile::apache_phpfpm {
include ::apache
}
You could do global variables, but you couldn't one set the hierarchy to
> the profile level? Thus you isolate variables in preference to the
> profile, rather than a global mismash. Stick with parametrization for now
> if this works, refactor later after getting it working, as you'll have a
> functional base state.
>
>
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
>>
>>
> I am not sure about this... Personally, I get scared of having too many
> sub-classes beyond install.pp, config.pp, service.pp, etc. It might make
> those files verbose, but then it is easier to contain and debug.
> Afterwards, parts into separate pieces, if this helps.
>
> Is cron a separate class? Personally, I put my bottom level modules into
> their product role, which may require cron functionality. I avoid crafting
> classes based on their functionality, as this would be the same as having a
> class called package that accepts an array packages to be installed. It
> gets hard to identify what is involved in installing a product or
> scheduling cleanup tasks for the same product; the code to implement a
> particular product gets scattered across many files, rather than
> self-contained in one module.
>
>
I am not sure I understand what you're suggesting here. The point of the
create_resources calls at the very bottom is so we can attach backup jobs,
cron jobs, firewall rules to the profile. You seem to be suggesting we
should assign these at the role level. Is that correct? I see valid reasons
for doing it either way but experience may dictate one is better then the
other.
Yes, apache, php, cron, duplicity, and firewall are all separate classes.
> 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/d499acf3-d7d7-401f-8692-4d9c44b02e6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
