For my case we already know what datacenter the servers are in, so I use a combination of attributes and data bags.
If the data is not changing between datacenters then I just use attributes.
I create data bags for each datacenter that holds the specific values I need that cannot be default attributes.
Then during the chef run each node knows which specific data bag it needs to look at.
So for example maybe I will have an databag that is named ‘production’ and within it an item named ‘datacenter1’, etc…
From: “Michael Herman” email@example.com
Sent: Wednesday, May 8, 2013 7:31am
To: "firstname.lastname@example.org" email@example.com
Subject: [chef] Re: How do you manage multiple data centers
We take a slightly different tack, we create an infrastructure environment and place data centre specific services in that environment, such as DNS, mail gateways and local repositories.
Each application environment (dev/qa’s/production) then includes a reference naming its infrastructure environment, any service that then relies on a infrastructure service just performs a search against that infrastructure environment.
This allows new application environments to be configured without having to populate site specific data, or updating multiple entries in each application environment… similar to data bags containing site specific data, but also managing the services via chef. There are times when I think it can be cumbersome, but generally works well for us.
On Wednesday, May 8, 2013, Sascha Bates wrote:
I’m about to embark on the multiple part of my multi-datacenter automation project and am wondering how people are accomplishing this now?
I currently have environments that mimic code promotion: dev/test/prod whatever.
My production environment is only used to pin cookbook versions and that’s how I ensure promotion is controlled, by bumping the version in my environment.
Now that I’m approaching a situation where I need to make some design decisions, I’m wondering how people are managing data that vary by location and how they feel about what they’re doing. I’m aware of most of the ways to do something like this: environments, roles, data bags, whatevs, so I’m not in need suggestions on what I should do, but am looking for how you like what YOU’RE doing.