| Here's how I'm setting hostnames in ec2:
Disclaimer: I don't care about mucking with DNS; nor do I care about rebooting EC2 instances. I don't reboot ec2 instances, I just destroy and spin up new ones. This is also assuming that these instances were bootstrapped/ec2 server created with the -N flag to set the node_name in the chef-server. I'm approaching this from the perspective that node_name is king and so long as it's set properly, that's all I care about.
I know this is valid only for the duration the host is up and probably would reset back to the wonky i-123124324 aws dhcp name.
--
Ryan C. Creasey
Principal Systems Engineer
Gamespy Technology
On Apr 5, 2011, at 1:34 PM, Daniel DeLeo wrote:
On Tuesday, April 5, 2011 at 1:24 PM, Rob Guttman wrote:
+1. Sean's reasons are our reasons. We don't actually care about the hostnames, per se. Any descriptive 'alias' attribute (which is what I'm implementing now instead of hostnames) can save a lookup for monitoring and comparable.
- Rob On Tue, Apr 5, 2011 at 2:21 PM, Sean OMeara <
">
> wrote:
2 cents:
The reason I favor descriptive host naming conventions are because
they show up all over in logs, metrics consoles, alerts, etc.
I'd much rather click on something semantically useful when checking
to see if my database is indeed swapping, and getting an alert saying
"host i-ec45e683 is down" while I'm out to dinner doesn't tell me if I
need to go running for a laptop or not.
-s
Yeah, the thing to keep in mind is that meaningful hostnames and meaningful hostnames with autoincrementing integer suffixes aren't the same thing. You can keep the meaningful part and append a randomish suffix (EC2 instance ID, whatever). It'll look nice in your logs and pages, but you won't need to run an autoincrementing integer service to keep your hostnames in order.
--
Dan DeLeo
|