3.6 directory environments, r10k, and hieradata

[Wolf Noble]

Hi Guys,

I have a few questions about 3.6 directory environments, which we're looking to adopt. 

Currently the most pressing surrounds the integration of r10k and hiera…

I believe I want to store hieradata inside the r10k repos, so that each r10k repo (I'm planning on using these to segregate different internal product stacks so that product owners can put sensitive data in their own hiera hierarchy, without the members of other products having access to the sensitive data) 

It seems that if I want some tiers of my hierarchy to be accessible to all, the only path open to me is to have a hierarchy inside each r10k repo, and symlink the branches of that hierarchy to relevant locations inside the global hierarchy.

While I suspect this _will work_ it doesn't quite sound like the most elegant solution.  

Does anyone have any input on a more elegant way that they'd be willing to share?

[Pete Brown]

I have my hiera data in a separate repository with the same branches
as my environment repositories.
I have r10k setup to check out my hiera repo and two environment trees.
My first idea was to use a submodule but I am not sure r10k would
handle that properly.
You could use a separate module for the global hiera settings and get
r10k to manage that as well.

It wouldn't be too tricky to build a hiera tree that does lookups into
your two hiera trees as long as they share a parent directory.

I am also about to publish my puppet management module to puppet forge
which might give you some inspiration.
It can manage an r10k setup with multiple repositories.
The docs are a bit sparse st the moment but it may help.
https://github.com/abstractitptyltd/abstractit-puppet

It would also be pretty easy to change my module to check out multiple
hiera trees.

Hope that helps.

Pete.

> --
> 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/CAC1UU3eAPaMPsM3XF9kdwwXb%2BD5cH8mG2ZxHKCakv4rS0NCj-w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Rich Burroughs]

I wonder if you could use hiera-gpg or eyaml to deal with this. Keep the Hiera data in one repo, but have the sensitive data encrypted so the other groups can't read it but the Puppet master can.

We use hiera-gpg where I work. With it you should be able to have the people working with the files encrypt them with their group member's keys and also the Puppet master's. Split the different groups into different files, so people could only read the files they need to. You'd also gain the benefit of having the sensitive stuff encrypted in the repo.

It seems like it could work but I'm not positive.

Rich

--

[Pete Brown]

It would probably work with both of those.
hiera-eyaml would make it easier because you don't need to encrypt the
whole file and it still lets you use a separate data directory.

Pete.

> https://groups.google.com/d/msgid/puppet-users/CAPGcbtDeubhsOHthcWh4JOAYdHdnferLgLZSAj6u3iTfRZ4m2g%40mail.gmail.com.