Le 16/11/2016 à 09:34:50+0100, Craig Dunn a écrit
>
>
>
> Firstly, the idea behind roles and profiles is that profiles are used to
> define
> logical "technology stacks" composing of your component modules. That is to
> say, that profiles are the layer where you declare how your component modules
> are implemented to model the technology unit you are trying to manage. Roles
> are a way to represent a more "business logic" view of Puppet and are
> generally
> just wraps one or more profiles that make up that business logic, eg: a
> "application server" is all you should care about at a business logic level,
> the technology stacks (profiles) that are included to make up the role of an
> application server may include "webserver", "security", "base", "tomcat"....
> Ironically the value of roles is their simplicity, by keeping them
> essentially
> dumb and limiting their responsibility to just including profiles it provides
> a
> nice layer of separation between business logic representation and
> implementation details.
>
> With the above in mind, I think having hiera data populate role classes blurs
> that line and you end up with implementation details in both roles and
> profiles
> and it starts not making sense to have that further layer of abstraction.
>
> Going further, the best environments I have seen only need to populate profile
> class with hiera data in the most extreme of edge cases. Good component
> modules should be able to get all the data they need by using data bindings
> and
> a well thought out hiera hierarchy should prove sufficient for ensuring that
> things get configured correctly, and often your profiles will generally just
> "include ::class" and let data bindings do the rest - obviously this isn't
> always the case, sometimes you need to do specific implementation around
> component modules, such as component modules which expose a defined resource
> type but have no "create_resources" style of dynamically creating the
> resources
> that it provides, which is what profiles serve to do, and in some cases it
> might make sense to populate profile data from hiera to achieve this.
This is exaclty what I try to do. Event I sometime use create_resources (or
now loop). But I don't see how I can do for a data needed by two profile
like a share password. Or if I take your sample "webserver", "security", "base",
"tomcat". If I installed tomcat in some place ('/opt/tomcat') how the
module who manage the war going to kown where to put the war ?
>
> So in summary; If you have a lot of data in hiera for your roles/profiles,
> you
> might want to look at why this is and see if having a more suitable hierarchy
> and relying on native data binding lookups from the component modules isn't an
> option... If you genuinely need data populated at this level, then it's part
> of the implementation of your technology stack, therefore should be at the
> profile level, not the role level.
>
Ok got it.
> I highly recommend you read this post by Gary Larizza ... http://
> garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
thanks....google already give me that link.
> Disclaimer: all of this is just opinions, but they're well tested opinions ;)
Every opinions are good for me.
Thanks again.
Regards.
--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
France
xmpp: [email protected]
Heure local/Local time:
mer 16 nov 2016 10:09:08 CET
--
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/20161116091809.GA28733%40pcjas.obspm.fr.
For more options, visit https://groups.google.com/d/optout.
