On Thu, Aug 5, 2010 at 1:08 PM, John Merrells john@merrells.com wrote:
But we're wondering what the best way is to manage that counter. Is that something you all delegate to the opscode server?
And how do you deal with host names when you scale up/down capacity?
I'd be curious how others do this too. I couldn't decide whether to set up the DNS from Chef,
or the Chef nodes from the DNS. In the end I went with a single text file that maps dns names
onto servers, and then I have a bit of code that configures the dns entries, creates the servers,
and then adds the Chef runlists for the nodes.
We use Dynect for our DNS, and we're on EC2. We have the instance-id
as a piece of unique-ness, so we use that for the node_name. We also
have a data structure that looks like this:
{
"dynect": {
"zone": "example.com",
"domain": "example.com",
"ec2": {
"env": "prod",
"type": "couchdb"
},
}
}
That gets populated by roles. The base role sets the zone and domain,
and the ec2 env and type attributes get assigned by the production and
couchdb role, respectively.
When that system boots, it makes API calls to Dynect ensuring the
following records exist:
If the IP address changes, the records get automatically updated.
The code is here:
http://github.com/opscode/cookbooks/blob/master/dynect/recipes/ec2.rb
And you can use it yourself with:
knife cookbook site vendor dynect
Adam
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com