Looking for recommendations on double DTAP environments

[Walter Heck]

Hi all,

I'm working on an environment and encounter the same issue I have encountered a couple of times before. This'll be a bit of a long one, so brace yourselves ;)

Situation:

We have a large managed hosting enterprise organisation where we're implementing puppet.The tooling team develops and maintains a set of puppet modules for usage by the infracoders. The infracoders write hiera databases and do classification which needs to move through a normal DTAP workflow. We'll refer to these as puppet environments.

The customers though maintain their servers also in DTAP: some of the webservers are in testing, others are in production. From a puppet perspective though, these machines are all in production. So far so good, so what's the challenges? We'll refer to these as customer environments

Challenges:

* different module versions on different customer environments. When a new version of the apache module becomes available from the tooling team, the infracoders might not want to use it straight on production

* if there needs to be a change on a server in the customer environment Acceptance, do we go through puppet DTAP for Customer environments DT also? That depends on wether this customer wants that change in their D and T environments

* if there needs to be a change across all servers, how does this flow through puppet DTAP and customer DTAP?

* rights: some admins can only have rights to change things on the customer DTA, but not P. They need to go through a senior engineer for that.

Solution:

We've so far settled on this:

* having 4 hiera git repo's per customer, where their D systems live in the D hiera repository. main reasons are:

** we want to have different puppet module versions per DTAP stage in a customer environment

** junior offshore admins cannot edit or even see systems/configs in the customer environment production

** a system that is a live system for a customer has the puppet environment set to production, regardless of wether the customer runs it in their DTA or P environment. The infracoders move hiera/puppet code through puppet environments DT and A within for instance the T hiera git repo.

How do others solve this problem? Insights more then welcome :)

cheers,

Walter

[Garrett Honeycutt]

Hi Walter,

I'm using r10k with the Hiera data in the same repo as your Puppetfile.
This allows for arbitrary environments and for each environment to have
its own copy of the code which is likely at different versions. Using
gitlab to prevent pushing to named environments such as production. This
way you can create an environment to test some specific new
functionality or a fix and then request that it be merged into a more
regulated environment. You can make use of gitlab groups and permissions
to enforce who can merge into which branch (environment). Add git hooks
for more granularity if needed or in lieu of the whole gitlab setup.

Making use of hiera-eyaml to encrypt sensitive data. We want more junior
and off-shore people to see the keys, so that they understand how
systems are configured and eyaml ensures that they do not see the actual
data. If your code is truly data driven and the data is in Hiera and you
hide that from people, there is no way they will be able to understand
how the model is created.

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658