Re: [Puppet Users] Re: Thoughts on roles/profiles class paradigm
On 1/22/2014 7:35 PM, Nathan Nobbe wrote:
I read Craig's article numerous times and have recently published an
article http://quickshiftin.com/blog/2014/01/composition-in-puppet/ on
my thoughts. To summarize, I feel the big lesson from the article is
composition is needed to define reusable grouped module declarations
(aka /roles/). Whether or not you like the notion of the 2-layered
approach (roles /and/ profiles) is something else and a bit extra IMO.
That said I'm only managing tens of servers rather than hundreds or
thousands so far, but for me one layer to represent 'roles' has worked
great.
What it amounts to for me is a simple guideline - leverage inheritance
(or the hiera hierarchy) as much as possible and introduce composition
on a need-to basis. Composition is necessary though, unless all your
systems are identical.
Thanks again Craig for the article. Neat to find you on the google group!
-nathan
If I had the 20-30 hours to write a Puppet Conf presentation it would
be called The profile is the most important part of role/profile. :-)
In a simple system with a webserver and database, profiles don't appear
to add much. However in a complex system where an Apache server could be
a proxy, app server, ssl terminator, or other function the added layer
is very necessary. In my system I have 25+ roles half of which use
profile::apache to get vastly different configs. In each case
profile::apache provides the entry point for the data Hiera provides
based on Role.
Profile classes are where you get to be opinionated about your config.
In my sample profile::apache class below my Apache module can remain
generic and shareable while profile::apache pulls in things like
collectd, logstash, etc that are specific to how *I* think any server
with Apache should be installed.
You might also check out Craig's later presentation on role profile
which provides a clearer picture than his earlier blog post.
http://www.slideshare.net/PuppetLabs/roles-talk
Ramin
class profile::apache {
include ::apache
include profile::logstash
include profile::sslcerts
collectd::plugin { 'apache': }
logrotate::simple { 'apache':}
$mymods = hiera('apache::a2mods', {})
create_resources('apache::a2mod', $mymods)
$myvhosts = hiera('apache::vhosts', {})
create_resources('apache::vhost', $myvhosts)
Sslcerts::Cert|| - Class['apache::service']
}
--
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/52E188C8.5020807%40badapple.net.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Thoughts on roles/profiles class paradigm
On Wednesday, January 9, 2013 2:34:30 PM UTC-7, Wolf Noble wrote: Hi Gang, My colleagues and I are contemplating refactoring our modules to take advantage of the roles/profiles paradigm suggested by Craig Dunn in his blog post found here: http://www.craigdunn.org/2012/05/239/ Before we jump feet-first into adopting this paradigm, I thought it a good idea to reach out and see what everyone else thinks about this. We're currently struggling with some problems that this paradigm seems to solve quite nicely; but I'm not convinced it's the best abstraction / organization paradigm out there. If you've not read it, I think It's worth the few minutes it takes to read. Thanks Craig, for writing it. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. I read Craig's article numerous times and have recently published an articlehttp://quickshiftin.com/blog/2014/01/composition-in-puppet/on my thoughts. To summarize, I feel the big lesson from the article is composition is needed to define reusable grouped module declarations (aka *roles*). Whether or not you like the notion of the 2-layered approach (roles *and* profiles) is something else and a bit extra IMO. That said I'm only managing tens of servers rather than hundreds or thousands so far, but for me one layer to represent 'roles' has worked great. What it amounts to for me is a simple guideline - leverage inheritance (or the hiera hierarchy) as much as possible and introduce composition on a need-to basis. Composition is necessary though, unless all your systems are identical. Thanks again Craig for the article. Neat to find you on the google group! -nathan -- 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/c2c138f4-a703-43c9-8110-0522697063bc%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Thoughts on roles/profiles class paradigm
I was in a position to build a puppet environment from scratch. After lots of studying and trying different suggestions the profile/role paradigm is proving flexible enough to meet any challenge we have faced thus far. We apply a role to nodes that should be identical (typically clusters of nodes) and the same role gets applied to dev/test/prod clusters. This solved two problems. 1) It works nicely for integrating with the release process where clusters are tested as a platform. We can make changes to applications, middleware and the OS in the role. Dashboard reports then show what will change on dev/test/prod. The changes are then applied following the schedule of the release process. 2) Applying only roles to nodes keeps the dashboard clean if using it as an ENC. The only classes found on the dashboard are roles. No one has to guess what a server is used for because the single applied role to the cluster makes it obvious. In all honesty though we do apply roles to node groups. So if a node finds itself in multiple groups it will have multiple roles. But the roles are always mutually exclusive or the underlying classes are written to handle the potential for resource conflicts. The final big advantage I see is having terminology and a proven pattern to communicate ideas between team members. Once we settled on the profile/role pattern we quit going in circles on how to implement and solutions to perceived problems became clear and in some cases solved themselves. All and all very satisfied with the pattern so far. Those are my thoughts. Hope they are helpful. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/jEyW_0N7YxEJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
