<\/p>\n\r\nclass ntp {\r\n file{\"\/etc\/ntpd.conf\":\r\n source => [\"puppet:\/\/\/ntp\/ntpd.conf.${environment}\", \r\n \"puppet:\/\/\/ntp\/ntpd.conf\"]\r\n }\r\n}\r\n\r\nnode dev1 {\r\n include ntp\r\n}\r\n<\/pre>\n<\/code><\/p>\n
If you put the ntp module in both production and development, the right one will be chosen depending on the nodes environment setting. The file ntp.conf will also be served from the right modules files directory. You could now safely make changes to the development one without affecting the rest of the machines.<\/p>\n
The major drawback here is that if you have say 30 modules, you need to duplicate the lot into development if you wish to use them there, this is not great at all as it quickly becomes a maintenance nightmare. If you made a change to ntp module in development, you need to remember to go and do the same change in all your other environments. In cases where you give each sysadmin or developer their own environment this rapidly becomes unmaintainable.<\/p>\n
The modulepath option has a trick up it’s sleeve though, you can specify several search paths just like the normal Unix PATH environment variable, we can rework our config like this.<\/p>\n
<\/p>\n\r\n[puppetmasterd]\r\n modulepath = \/etc\/puppet\/manifests\/common\/modules\r\n\r\n[development]\r\n modulepath = \/etc\/...\/development\/modules:\/etc\/...\/common\/modules\r\n\r\n[production]\r\n modulepath = \/etc\/...\/production\/modules:\/etc\/...\/common\/modules\r\n\r\n[johndoe]\r\n modulepath = \/etc\/...\/johndoe\/modules:\/etc\/...\/common\/modules\r\n<\/pre>\n<\/code><\/p>\n
Here we’ve added a few more environments, even one for a developer called John Doe. The big thing we did though is create \/etc\/puppet\/manifests\/common\/modules<\/em> as a 2nd search path. <\/p>\n<\/p>\n\r\nproduction\r\n`-- modules\r\ndevelopment\r\n`-- modules\r\ncommon\r\n`-- modules\r\n `-- ntp\r\n `-- manifests\r\n `-- init.pp\r\n<\/pre>\n<\/code><\/p>\n
The idea here is that you’d strive to keep all your modules in the common directory as their stable location but if you wished to do development on your ntp<\/em> module that you wish to test, you just copy the ntp module into either development<\/em> or johndoe<\/em> directories, with that done only machines in those environments will get the new code.<\/p>\nThis works especially well if you use version control, I use SVN and treat common<\/em> as my trunk<\/em>, whenever I need to work on a module I simply branch it into development<\/em>, do my work there and when ready to release I merge my changes back to common<\/em> and get rid of the branched copy so all environments gets the same version.<\/p>\nWith this you can easily come up with a simple release testing strategy, do the weeks code in development and test locally, then put the changes you wish to release to production into your QA environment and do tests. Finally when you’re ready merge all the changes into common and just get rid of the development and QA copies, all environments are now running the same code ready for the next cycle.<\/p>\n
This gives you the ability to create branches, do testing, isolate developers from each other – just put their desktops in individual environments – and lots of other nifty things but in the end you have only one copy of the code for your stable released versions.<\/p>\n
I hope you find this useful, I’ll reiterate that this is a simple setup, you should use this information and come up with a solution that will work well for your use case and teams.<\/p>\n","protected":false},"excerpt":{"rendered":"
Puppet supports putting nodes in environments, this maps cleanly to your development, qa and production life cycles and it’s a way to hand out different code to different nodes. Before reading this post you should probably read the Puppet Wiki page first for background. I’ll present here a simple layout that is both a powerful […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","footnotes":""},"categories":[7],"tags":[121,21],"_links":{"self":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/1038"}],"collection":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/comments?post=1038"}],"version-history":[{"count":31,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/1038\/revisions"}],"predecessor-version":[{"id":1063,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/1038\/revisions\/1063"}],"wp:attachment":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/media?parent=1038"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/categories?post=1038"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/tags?post=1038"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}