Out of curiosity, what exactly are all the components you are trying to
install, e.g. CMSes? Drupal? WordPress? Joomla? Is that database going to
be on the same system?
Note, segue here before I divulge a solution, perhaps sacrilegious, is that
the role/profile might not be the best design pattern for, as it seems to
be a top-down with functional decomposition, rather than a bottom-up
approach (e.g. starting with apache, app-engine child class, then cms
child class, each one inheriting properties and actions of the parent).
There are other OOP design patterns (yet to be documented) that could work
for Puppet. Still, here's a way to maybe get this to work with
roles/profiles:
You could write maybe a fat_php module (not profile), but has parameters to
turn on/off the features you want through parametrization. Thus you can
have this fat_php module support all the requirements to install everything
under the sun, then a profile will toggle them on and off through
parameters. Thus, a package's ensure attribute can be set to "present"
depending on what CMS the profile will build.
The role would call whatever profile CMSes that are needed for that role,
so it can call two or more CMS profiles. Each one will toggle various
options, such as a package's ensure to "present", appropriate to the that
CMS. When the catalog is compiled, and 2+ CMSes were enabled, packages
will only be installed once. If any custom code should have some way to
avoid collisions, if it has already been invoked previously, so you need to
be careful to ensure it is idempotent, especially for exec { command: }.
When you advanced the code base to use Hiera, you can just use class
includes, to have pure idempotence, and avoid specifying parameters through
class { param=value }, which might cause some unexpected, ala honey badger
("don't give a shit"), results when classes might try to get installed
twice or out of order between profiles included in the roles.
Similarly, you can have a fat MySQL module which has the needed schema and
account configurations needed to make it work with whatever CMS. These
sets of configurations and actions are toggled on/off, and which will be
set by the profile (or hiera config related to the profile).
On Saturday, May 17, 2014 5:39:05 AM UTC-7, Jesse Cotton wrote:
>
> Yes it is feasible :) So really the server is just a PHP app server. What
> makes it useable for all of the CMSs is that the correct set of apache and
> php modules are installed, and it has the correct firewall rules, cron jobs
> and backup jobs configured. With this in mind, my inclination is to build a
> cms_app_server profile but that seems more like a role then a profile.
>
--
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/a4b895df-02b6-4014-bbce-176d93c3ee07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
