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.
