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, [email protected] 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 [email protected]. 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.
