# How to manage data at a service level (not node level)?

I have an application where each installation spans across multiple nodes (normally three hosts: the master instance, a second instance and the database instance). To setup each instance I have a single class which accepts multiple parameters:

• some parameters are specific to one installation/cluster (the name of the installation, is it for development, QA, or production)
• some parameters are node specific (like: is the server the master of that installation? Is the database installed on this host)

I currently do not use hiera to retrieve the parameter values and I specify all parameters at node level. But this means ...

edit retag close merge delete

Sort by » oldest newest most voted

I did a variation of Lee's idea. I want to keep my hierarchy as simple as possible so my default hierarchy goes like this

:hierarchy:
- operatingsystem/%{operatingsystem}
- domain/%{domain}
- common


In my hieradata directory I also have the files

/etc/puppet/data/my_application/clusterA.yaml
/etc/puppet/data/my_application/clusterB.yaml


The above files are generally not parsed when doing a normal hiera lookup as they do not appear in the hiearchy. Inside the my_application class however I am now able to do

class my_application($cluster) { shared_option = hiera('shared_option', undef, "myapplication/${cluster}")
}


At a node level I just have ...

more

I had a similar situation, involving multiple Apache and Tomcat clusters.

What I wound up doing was to create a couple of custom facts, paired with naming conventions.

One I called "node_id". This fact would look at the hostname and then return a value that would identify which cluster the node was in (team1_app_a, team2_web_b etc).

The second one was "cluster_type". This was also hostname based and would return a value that would identify which type of cluster (team1_app, team2_web, team1_database, etc).

I then set my hiera hierarchy up like:

:hierarchy:
- "%{node_id}"
- "%{cluster_type}"
- common


This allows me to set things ...

more

+1 for the idea but I have a few "old" severs that do not follow any naming convention and getting the "cluster_type" just by looking at any other fact is ...(more)

( 2013-02-26 17:21:53 -0500 )edit

By looking at the source I found out that the hiera function supports a third parameter to specify an alternate hierarchy. So I can have a yaml file for each ...(more)

( 2013-03-20 15:28:20 -0500 )edit

I use puppet environments as my clusters, and have hiera setup like this.

:hierarchy:
- "%{hostname}"
- "%{environment}"
- "%{location}"  # Things like DNS change based on region
- common


Now, if you have a class called "application1", and you apply that class to a server in the "cluster1" environment, you'll be able to reference variables in hiera like "application1::parameter1", which will then be pulled from "cluster1.yaml".

more

do you mean real puppet environments, or is this a custom fact of your own? Puppet environments does not sound practical because I have roughly a hundred different "clusters" (it ...(more)

( 2013-02-26 17:12:22 -0500 )edit