Hello,
This sounds like a different direction than you're thinking, but it might
help to keep things manageable - and it's kinda cool! Take a look at R10K
[1] and Control Repos [2]. The gist is that each tenant would have it's
own control repo, then R10K can deploy each control repo as a dynamic
puppet environment, prefixed by the tenant's name. The nice thing here is
that the control repo contains all the tenant's nodes, data, modules and
environments in a fairly manageable way...especially if you like to track
changes or want to test things with puppet-rspec and CI tools before going
live.
A Git branch in the control repo is deployed as a puppet environment, so
the "master" branch in [2] is labeled "production" and is the default
environment for puppet. Using r10k's tenant prefix capability [3], each
tenant's environments will be unique within a single puppet master -
[1] https://github.com/puppetlabs/r10k
[2] https://github.com/puppetlabs/control-repo
[3]
https://github.com/puppetlabs/r10k/blob/master/doc/dynamic-environments/configuration.mkd#prefix
The Puppet Master's environments directory
(/etc/puppetlabs/code/environments) with two tenants (group1 and group2)
might look like this:
-- group1_production/
--data/ <- where hiera data lives
--manfiests/<- where site.pp and node manifests live
--site-modules/ <- where role and profile modules live
--modules/ <- where r10k deploys puppet modules
--hiera.yaml<- environment data hierarchy
--Puppetfile<- file to define what modules r10k deploys (sourced
from Puppet Forge or Git Repos)
--environment.conf <- puppet environment config, e.g. modulepath
-- group1_test/
--data/
--manfiests/
--site-modules/
--modules/
--hiera.yaml
--Puppetfile
--environment.conf
-- group2_production/
--data/
--manfiests/
--site-modules/
--modules/
--hiera.yaml
--Puppetfile
--environment.conf
If you can get fancy with CI/CD tools, you can use a webhook from the git
control repos to spur R10K to deploy a branch/environment to the puppet
master.
On Wednesday, March 27, 2019 at 9:13:54 AM UTC-4, zxcvb...@gmail.com wrote:
>
> My employer has a multi-tenant puppet installation with a fairly odd
> layout. The files a laid out like this:
>
> /manifests/group1/application1/server.pp
> /manifests/group1/application1/node.pp
> /manifests/group1/application2/server.pp
> /manifests/group1/application2/node.pp
> ...
> /manifests/groupX/applicationY/server.pp
> /manifests/groupX/applicationY/node.pp
>
> Where server.pp is always called server.pp, and always defines class
> "server" and three inherited classes dev_server, qa_server, and
> prod_server. These include all the puppet directives to install groupX's
> applicationY server in either the dev, qa, or prod environment.
>
> The node.pp always has three node stanzas which include either dev_server,
> qa_server, or prod_server.
>
> The guy who set it up never used puppet before and had a real knack for
> putting things in non-standard places, so I'd like to clean it up and do
> things "the puppet way". However I've not done a multi-tenant setup before
> so could use some advice, or some "this is how we do it and works for us"
> ideas.
>
> My thoughts at the moment are to consolidate all of the node.pp files into
> a single file under manifests, then set up a second modules directory
> (maybe called nodeclasses?) and then groupX/applicationY will become the
> groupX::applicationY class which is included in the node definition in
> node.pp.
>
>
--
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/c9ea2f56-ce05-41f6-a62f-c4e4592fec3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.