Ask Your Question

How do you deal with dynamic hiera parameters?

asked 2015-11-24 04:27:34 -0500

poysama gravatar image

I am making a module for a rails application. Problem is, every rails app has multiple .yml files aside from the standard database.yml. I wanted to handle configuration with Hiera dynamically. The idea is to accept any configuration and populate it with the passed data. I imagine my module would look like this.

### Given a configuration file for rails named app.yml which contains whatever dynamic content

# init.pp
class rails ( 
  $configs = {},
) {
  create_resources('rails::config', $configs, {})

define rails::config (
### how do i define this part to accept dynamic vars?

) {

### a sample hiera.yml would be like
    'dynamic_key': 'dynamic_value'
      - 'dynamic_value_as_hash1
      - 'dynamic_value_as_hash2

How do you let a defined type accept a bunch of dynamic parameters? Also, I was thinking that since these data are very specific to an application, maybe I could just create a separate hierarchy for the app so I can define defaults. That way, it doesn't have to be dynamic. Sample hiera.yml would look like

    - "%{::environment}/%{::fqdn}"
    - "%{::environment}/%{::environment}"
    - "%{::environment}/app/%{app}"
    - global/common
    :datadir: '/etc/puppetlabs/puppet/environments'
edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2015-11-24 19:10:10 -0500

ramindk gravatar image

updated 2015-12-01 13:20:32 -0500

We do something similar to this, my advice is

You must use Ruby 1.9.3 or better on your master. Ruby 1.9.3 preserves hash insertion order unlike earlier versions. When order is preserved you won't need to sort the hash everytime to keep the file from changing between Puppet runs. Unless you want to write really complicated templates that sort the top level key, then walk the rest of the structure and sort at each level, just use Ruby 1.9.3+. The Ruby version on the agents doesn't matter because templates are evaluated on the master.

Your developers will want their config in these files as well. I recommend standard config files in the project src and use Puppet write to /etc/someapp/conf files. The Rails app load both and merge with the the Puppet managed files the final say. Doing it this way allows defaults to live in the project and Puppet to manged secrets and the differences between environments.

Bite the bullet and write huge yaml files per environment. Duplication is easier than trying to programmatically deal with every case. We do some tricks with yaml aliases that are based on $::environment to pull in defaults and then merge them via hiera_hash, but it's easy to screwup. Completely bullet proof once it works in our experience.

hiera-eyaml, start now. It'll make your life easier.

Placeholders in the project yaml files.

  # edits here, only affect dev instances.
  host: localhost
  user: rails

The hash.yml.erb we use to dump data into yaml files.


    obj = @options

    arr = obj.sort
    out = "---\n"
    arr.sort.each do |element|
      entry = {element[0] => element[1]}
      out += entry.to_yaml.split(/\n/)[1..-1].join("\n") + "\n"

edit flag offensive delete link more

answered 2015-11-24 16:34:31 -0500

lavaman gravatar image

To have a defined type use such data, you would need to have code that reads in the data from hiera, then runs create_resources on it. The data defines the the resources you would like to create, as described here:

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

1 follower


Asked: 2015-11-24 04:27:34 -0500

Seen: 345 times

Last updated: Dec 01 '15