Ask Your Question
0

Merging Hiera files From mulitiple Environments

asked 2017-01-03 13:43:48 -0600

jason gravatar image

Hello,

I would like to merge a few puppet environments in to 2 : "production", "development". The environments/ modules /sites aspects of this merge are fine, but i am having difficulty with the Hiera data.

We have hiera data that applies to an entire environment and i am looking for an alternate way of doing. ex: envs: test, preprod, prod desired envs: prod, test How does one merge the hiera data from preprod into the prod heira yaml file and still have it only apply to the pre prod servers?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

answered 2017-01-04 04:16:30 -0600

deric gravatar image

I'm not sure if it's good idea to bypass the environment isolation. It might lead to strange behavior. Anyway, it could be done by updating your hiera.yaml file on the puppet master (puppetserver).

---
:hierarchy:
    - "env/%{::environment}"
    - "env/%{::shared_environment}"
    - "common"
:merge_behavior: deeper

Where environment is set by Puppet and ::shared_environment would be a custom fact set to preprod (in case of production env). Then you'll have hierarchy like this:

hieradata/
  production/
     production_specific_config.yaml
  preprod/

with environment specific settings. Also it might be good idea to use merge_behavior: deeper (deep_merge gem) in order to avoid copying whole configurations between environments.

edit flag offensive delete link more
0

answered 2017-01-04 11:58:14 -0600

DarylW gravatar image

I would recommend something similar to deric's answer .. If you don't have any data isolation issues (same key for eyaml, no problem with secrets across envs) you can just have all of your data collocated, and let hiera resolve the correct value for your env.

We have multiple different 'sets' of data we manage with hiera. We have separate AWS VPC's that we deploy to that each have their own set of configuration, but we also have dev/test/prod configuration (which we would still possibly want to test in any of the VPCs). All of that is just managed using hiera and custom facts. So if I want to test out the 'test' set of configuration in my development VPC, I can create my instances using the 'test' fact, but it infers which VPC I'm in for getting the actual 'network environment' specific information.

All of our data exists in a single hierarchy, which is in all environments, but the data chosen varies as it naturally must in some cases (different sets of IP's for services, different scaling information, etc..)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2017-01-03 13:43:48 -0600

Seen: 70 times

Last updated: Jan 04