On Monday, July 20, 2015 at 9:45:12 PM UTC-5, Fabien Delpierre wrote: > > Peter, Felix, > Thank you for your answers! > > I guess my improperly worded question was about figuring out whether > Puppet has a concept similar to what Chef calls a wrapper cookbook. > >
I know nothing more about "wrapper cookbooks" than I can deduce from their name and your code, but they sound like they may have some similarity with the Puppet pattern called "Roles & Profiles", conceived by Craig Dunn. You can find a lot of information about it around the web, but here's the original description: http://www.craigdunn.org/2012/05/239/. As for your original problem, I'm inclined to agree with you that it's wrong to put your site-specific nginx config file in a general-purpose nginx module. The need to modify a module itself to customize it for your site violates its modularity, and it will bite you as soon as soon as your site requires two unrelated nginx servers. On the other hand, the nginx module should manage the standard nginx configuration files, because it needs to ensure that the correct relationships are maintained between that file and other nginx components (its Package, the nginx Service, etc.), and because other code shouldn't need to know details of how nginx config files are structured. The trick, then, is that you want the nginx module to manage the file to have whatever content (and other properties) you need it to have, without making that content itself belong to the module. This is separation of data from code, which is a well established best practice for designing Puppet modules and manifest sets. The typical approach to this problem involves giving one or more of the classes of the nginx module class parameters by which you can provide the necessary data (the appropriate 'content' or 'source' for the managed file, for instance). You then provide the data via automated data binding through Hiera. Under some circumstances, you may be able to split configuration between files managed by the general-purpose module, and files managed by site-specific classes. This generally happens when the file to be managed supports an 'include'-like directive to incorporate the contents of other files into itself by reference, or when the component being managed automatically reads all files from a given directory. Under these circumstances it is often to your advantage to wrap the native resources involved in a defined type provided by the GP module. That way all the needed relationships and internal plumbing can be handled by the defined type, and the user just needs to provide the site-specific details. 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/3df6a923-b91c-4766-95ea-666873f99ad7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
