THanks and great post by the way!
I think we are pretty much on the same thinking behind. You don't add the
"package" resource directly but using create_resources from hiera is
almost the same thing. THe only difference is that your way is more
flexible as you can add / remove packages just changing data and not code.
But if you know beforehand what are the requires and you think they'll be
static in the long term I prefer that to be on the code side so my hiera
data looks small compact relevant and tidy.
My problem is with the file resources and templates. if if you have a
decent amount of different applications you'll end up with a super profile
class. It'll contain all different type of files and templates and too many
sub profile modules. Some companies have more than 200 different
applications type with an average of 2 to 4 config files to be deployed by
app. I know some of them could be moved to "rpms" but is normal to have at
least 1 config file managed by templates. DO you think it is good to have a
profile class with say 300 400 files from different applications?
That's where I prefer to use a different pattern and that is one profile
class per application: ie:
profile_webapp
profile_alpha_app
profile_gamma_app
etc...
And sometimes when needed use the repo->config->install->service pattern.
Do you see any cons on that approach?
Thanks!
Juan
1. profiles::php with create_resources around a Package resource that
pulls in php-apc, php-mcrypt, php-gd, and all the other usual suspects
based on Hiera data. When was the last time anyone needed just one PHP
module? Also not a terrible place to set apc.ini and other config files.
2. profile::myrole and yeah I add the resource directly particularly if
it'll never ever conflict with another module. Also a good place to pull
in very simple modules. I'm not a fan of breaking things up into more
specific subclasses within a profile::class.
On Monday, February 10, 2014 6:48:55 AM UTC, Ramin K wrote:
>
> On 2/9/2014 4:47 AM, JuanBrein wrote:
> >
> >
> > I've been using puppet on different companies and implementing the roles
> > / profile pattern on some of them.
> >
> > In theory the patter works very well but in practice I usually face
> > challenges that I sort out implementing my own designs / solutions. I
> > would like to know how you guys deal with that in case you do.
> >
> > **Say you have a typical LAMP stack and you have to deploy a web app so
> > my classes would look something like this (super simplified version):
> >
> > *Modules:*
> >
> > class apache { //puppetlabs class }
> > class mysql { //puppetlabs class }
> > etc./.
> >
> > *Profile*:
> >
> > class profile::webapp {
> >
> > class 'apache'
> > class 'mysql'
> >
> > $name = hiera('webapp::name')
> > apache::vhost {$webapp::name:}
> >
> > }
> >
> > *Roles:*
> >
> > class role::prod_web {
> > include 'base'
> > include 'profile::webapp'
> > }
> >
> > Now some of the questions I face:
> >
> > 1- Say thate for whatever reason the profile::webap requires a specific
> > package... ie php-apc that is not covered by the apache module. The
> > roles / profile states that you should always reference modules. Would
> > you guys create a new class just to include a resource? What I usually
> > end up doing is to add that package into the profile for the sake of
> > simplicity.
> >
> > 2- Sometimes modules from puppetlabs or other contributors lacks of some
> > functionality. Say for example you need to deploy a file under
> > /etc/sysconfig. I wouldn't place that file under the profile class as
> > that is used for multiple profiles definitions. However creating a new
> > module for just a single file seams like too much of an overhead. What I
> > usually do is I split up the profile module into multiple profile
> > modules and use the repo -> install -> config -> service pattern. That
> > allows me to create a file / template where to place my specific
> > resources for that profile and still consume data from hiera to
> > customize the behaviour.
> >
> > 3- The problem with point 2 is that you might end up with too many
> > profile classes and some of them might include a simple reference to a
> > module. That is not much of a problem to me as I prefer to have my files
> > attached to the right profile module rather than having multiple files
> > on a single profile module... or multiple modules with just a couple of
> > files.
> >
> > Cheers!
> > Juan Breinlinger
>
>
> 1. profiles::php with create_resources around a Package resource that
> pulls in php-apc, php-mcrypt, php-gd, and all the other usual suspects
> based on Hiera data. When was the last time anyone needed just one PHP
> module? Also not a terrible place to set apc.ini and other config files.
>
> 2. profile::myrole and yeah I add the resource directly particularly if
> it'll never ever conflict with another module. Also a good place to pull
> in very simple modules. I'm not a fan of breaking things up into more
> specific subclasses within a profile::class.
>
> 3. See #2
>
> I recently took a crack at writing some examples of profile uses
> as
> well as philosophizing on good profile classes. Probably needs another
> hour of editing, but might be helpful in its current state.
>
> https://ask.puppetlabs.com/question/5235/what-goes-in-the-profile-part-of-roleprofile/
>
>
> Ramin
>
--
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/b8ad138c-e10e-454e-8151-3239ce1e37b1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
