Ask Your Question
2

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

asked 2013-02-23 10:33:15 -0500

Stefan gravatar image

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 ... (more)

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted
0

answered 2013-03-20 16:03:01 -0500

Stefan gravatar image

updated 2013-03-20 16:04:35 -0500

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)

edit flag offensive delete link more
1

answered 2013-02-25 08:48:18 -0500

llowder gravatar image

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)

edit flag offensive delete link more

Comments

+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)

Stefan gravatar imageStefan ( 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)

Stefan gravatar imageStefan ( 2013-03-20 15:28:20 -0500 )edit
0

answered 2013-02-26 13:54:44 -0500

Ancillas gravatar image

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".

edit flag offensive delete link more

Comments

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)

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

Your Answer

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

Add Answer

Question Tools

2 followers

Stats

Asked: 2013-02-23 10:33:15 -0500

Seen: 198 times

Last updated: Mar 20 '13