[chef] Re: Re: Hostname Naming Strategies

[Adam Jacob < >]

On Thu, Aug 5, 2010 at 1:08 PM, John Merrells 
<
 >
 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:

# "i-17734b7c.example.com" => ec2.public_hostname
# "couchdb-prod-i17734b7c.example.com" => ec2.public_hostname

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: