On Monday, May 19, 2014 1:42:08 PM UTC-5, Jesse Cotton wrote:
>
> 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.
>
That is what your data hierarchy is for. Hiera does not limit you to only
global and per-node data. You can define as many hierarchy levels as you
need, each grouping your nodes in its own way (though it usually makes the
most sense for the groups at each level to be subsets of the groups at the
next lower level).
And the foregoing is based on using only the built-in YAML back end. Hiera
supports pluggable back ends, usable together or separately. A custom back
end can employ whatever lookup or computation you want to serve whichever
data you choose.
>
>
>
>> 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)
> }
>
>
Either you're missing something or I am. I see nothing in that class that
would inherently preclude it being composed. In particular, the two class
declarations it contains both use 'include', not the resource-like class
declaration syntax. If there is a barrier to composition it would be
related to composition with another class that declares some of the same
resources. That problem has a solution, however: factor out the
multiply-declared resources into their own class or classes, which the
then-composable classes declare instead of declaring the resources directly.
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/2aaf1788-6e2e-4695-8f0f-8b8f813773fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
