Recommended/Suggested R10k Deployment Strategy
28 views
Skip to first unread message
dsdwcal
Jul 27, 2016, 10:14:26 AM7/27/16
to Puppet Users
So relatively recently we have deployed and set up R10k to manage our environments and modules. In terms of suggested practices, I am curios what others are currently doing to manage their production/dev environments. It seems logical to me to change the production puppetfile's moduledir to manage the /etc/puppet/modules directory, and have all other environments manage their own environments moduledirectory (/etc/puppet/environments/<environment>... That way the lookup hierarchy for modules will first look in the specific environment. If them module is not found, the production version of the module will be deployed. Is this recommended/ are there better ways of doing this?
Rob Nelson
Jul 27, 2016, 10:16:46 AM7/27/16
to puppet...@googlegroups.com
I don't do any central modules, but everything in an environment modulepath. That way there's no confusion about what module may be loaded. It also keeps the configuration as simple as can be, no environment is special in any way.
On Wed, Jul 27, 2016 at 10:06 AM, dsdwcal <gamerg...@gmail.com> wrote:
So relatively recently we have deployed and set up R10k to manage our environments and modules. In terms of suggested practices, I am curios what others are currently doing to manage their production/dev environments. It seems logical to me to change the production puppetfile's moduledir to manage the /etc/puppet/modules directory, and have all other environments manage their own environments moduledirectory (/etc/puppet/environments/<environment>... That way the lookup hierarchy for modules will first look in the specific environment. If them module is not found, the production version of the module will be deployed. Is this recommended/ are there better ways of doing this?
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ea3009d7-09b9-4797-9087-3c012a0d9e49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
dsdwcal
Jul 27, 2016, 11:18:38 AM7/27/16
to Puppet Users
Hmm ok thanks for the speedy reply!
In implementing R10k, we've recently transitioned from a monolithic module repo to individual module repos. As such, our /etc/puppet/modules folder used to be managed by a single git repo that was periodically pulled down and synced with master. It seems sensible to me that since production would essentially include a majority of these modules, one would want the production Puppetfile managing /etc/puppet/modules and all other environments managing their own environments modulepath (/etc/puppet/environments/<environment>/modules). In my mind this saves space by avoiding copying production modules in multiple environments, and when you want to test a tweak to a module you can do so easily in a dev environment.
That being said, I'm curious about how others have it set up. If the production Puppetfile is managing the modules in /etc/puppet/environments/production, then what would be in the main module directory at /etc/puppet/modules? It seems like in our current setup that directory would be essentially empty if the production Puppetfile was pointed to manage the /etc/puppet/environments/production/modules directory... or am I missing something?
In implementing R10k, we've recently transitioned from a monolithic module repo to individual module repos. As such, our /etc/puppet/modules folder used to be managed by a single git repo that was periodically pulled down and synced with master. It seems sensible to me that since production would essentially include a majority of these modules, one would want the production Puppetfile managing /etc/puppet/modules and all other environments managing their own environments modulepath (/etc/puppet/environments/<environment>/modules). In my mind this saves space by avoiding copying production modules in multiple environments, and when you want to test a tweak to a module you can do so easily in a dev environment.
That being said, I'm curious about how others have it set up. If the production Puppetfile is managing the modules in /etc/puppet/environments/production, then what would be in the main module directory at /etc/puppet/modules? It seems like in our current setup that directory would be essentially empty if the production Puppetfile was pointed to manage the /etc/puppet/environments/production/modules directory... or am I missing something?
Christopher Wood
Jul 27, 2016, 11:57:09 AM7/27/16
to puppet...@googlegroups.com
On Wed, Jul 27, 2016 at 08:18:37AM -0700, dsdwcal wrote:
> Hmm ok thanks for the speedy reply!
>
> In implementing R10k, we've recently transitioned from a monolithic module
> repo to individual module repos. As such, our /etc/puppet/modules folder
> used to be managed by a single git repo that was periodically pulled down
> and synced with master. It seems sensible to me that since production
> would essentially include a majority of these modules, one would want the
> production Puppetfile managing /etc/puppet/modules and all other
> environments managing their own environments modulepath
> (/etc/puppet/environments/<environment>/modules). In my mind this saves
> space by avoiding copying production modules in multiple environments, and
> when you want to test a tweak to a module you can do so easily in a dev
> environment.
You can also get this by having a common environment and using a basemodulepath. Modules specified in the different environments will override any of the same name in the basemodulepath. One downside here is that people go off in their own directions _anyway_ without spending the additional effort in getting their changes back in common. The upside is obviously that you can diff what different configs are required by different departments based on the git hashes used.
> Hmm ok thanks for the speedy reply!
>
> In implementing R10k, we've recently transitioned from a monolithic module
> repo to individual module repos. As such, our /etc/puppet/modules folder
> used to be managed by a single git repo that was periodically pulled down
> and synced with master. It seems sensible to me that since production
> would essentially include a majority of these modules, one would want the
> production Puppetfile managing /etc/puppet/modules and all other
> environments managing their own environments modulepath
> (/etc/puppet/environments/<environment>/modules). In my mind this saves
> space by avoiding copying production modules in multiple environments, and
> when you want to test a tweak to a module you can do so easily in a dev
> environment.
> That being said, I'm curious about how others have it set up. If the
> production Puppetfile is managing the modules in
> /etc/puppet/environments/production, then what would be in the main module
> directory at /etc/puppet/modules? It seems like in our current setup that
> directory would be essentially empty if the production Puppetfile was
> pointed to manage the /etc/puppet/environments/production/modules
> directory... or am I missing something?
[root@puppetmaster2 ~]# ls /etc/puppetlabs/code/modules | wc -l
0
[root@puppetmaster2 ~]# for i in `ls -d /etc/puppetlabs/code/environments/*/modules`; do ls $i | wc -l; done
132
50
13
72
32
31
18
52
56
0
26
24
52
47
23
56
The majority of those are individual departments' versions of production. The first one is the common environment. Some stuff there hasn't been touched since I broke things out into the r10k setup but it's still used in production. Definitely good candidates for not being in each environment.
> On Wednesday, July 27, 2016 at 10:16:46 AM UTC-4, Rob Nelson wrote:
>
> I don't do any central modules, but everything in an environment
> modulepath. That way there's no confusion about what module may be
> loaded. It also keeps the configuration as simple as can be, no
> environment is special in any way.
> Rob Nelson
> On Wed, Jul 27, 2016 at 10:06 AM, dsdwcal <[2]gamerg...@gmail.com>
> wrote:
>
> So relatively recently we have deployed and set up R10k to manage our
> environments and modules. In terms of suggested practices, I am curios
> what others are currently doing to manage their production/dev
> environments. It seems logical to me to change the production
> puppetfile's moduledir to manage the /etc/puppet/modules directory,
> and have all other environments manage their own environments
> moduledirectory (/etc/puppet/environments/<environment>... That way
> the lookup hierarchy for modules will first look in the specific
> environment. If them module is not found, the production version of
> the module will be deployed. Is this recommended/ are there better
> ways of doing this?
>
> --
> 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 [3]puppet-users...@googlegroups.com.
>
> So relatively recently we have deployed and set up R10k to manage our
> environments and modules. In terms of suggested practices, I am curios
> what others are currently doing to manage their production/dev
> environments. It seems logical to me to change the production
> puppetfile's moduledir to manage the /etc/puppet/modules directory,
> and have all other environments manage their own environments
> moduledirectory (/etc/puppet/environments/<environment>... That way
> the lookup hierarchy for modules will first look in the specific
> environment. If them module is not found, the production version of
> the module will be deployed. Is this recommended/ are there better
> ways of doing this?
>
> --
> 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
> To view this discussion on the web visit
> [4]https://groups.google.com/d/msgid/puppet-users/ea3009d7-09b9-4797-9087-3c012a0d9e49%40googlegroups.com.
> For more options, visit [5]https://groups.google.com/d/optout.
>
> --
> 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 [6]puppet-users...@googlegroups.com.
> --
> 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
> To view this discussion on the web visit
> [7]https://groups.google.com/d/msgid/puppet-users/708647b8-c215-4b90-8045-d0a1776874d0%40googlegroups.com.
> For more options, visit [8]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. javascript:
> 2. javascript:
> 3. javascript:
> 4. https://groups.google.com/d/msgid/puppet-users/ea3009d7-09b9-4797-9087-3c012a0d9e49%40googlegroups.com?utm_medium=email&utm_source=footer
> 5. https://groups.google.com/d/optout
> 6. mailto:puppet-users...@googlegroups.com
> 7. https://groups.google.com/d/msgid/puppet-users/708647b8-c215-4b90-8045-d0a1776874d0%40googlegroups.com?utm_medium=email&utm_source=footer
> 8. https://groups.google.com/d/optout
Reply all
Reply to author
Forward
0 new messages