Use something like a mac address and map them logically (i.e use chef envs/roles/tags). This forces you to stop remembering hostnames and setup automation to ssh/run commands. If you try to encode information into hostnames you head into the deep end pretty quickly and it's probably going to change in six months anyway.
I believe that's why the information is all encoded with CNAMES. That way you can change purposes easily without ever touching the original A record, which refers to the hardware (not its function)
Using a deterministic ID for machines is definitely the way to go.
We actually studied this for a while and MAC address is a pretty universal ID that works virtually anywhere. We use the smallest physical non-zero MAC address in case of multiple NICs. We considered using chassis or baseboard serial numbers but it gets too vendor specific.
I'm not following. The whole purpose of naming is to make it easy. I don't want to remember 000a43dbac72.example.com, it's easier to remember "pine" and "oak" and trust me, after working in the environment a while, everyone knows what every keyword is.
Wow, that's interesting. Had a similar thought not too long ago about applying a naming scheme to identifiers in code. Not like this or Hungarian Notation, but more like a controlled vocabulary variables with the same meaning use the same name across your codebase. So no more using "price" here and "amount" there. That would directly address the second hard thing.
I personally believe that servers should not have names, as naming them just creates the incentive to try to fix broken infra instead of just killing and respawning. I've considered using some kind of short UUID for hostnames instead.
That's taking the "pets" vs "cattle" meme a bit literally. Memorable hostnames can be given to both pets and cattle.
However, I personally question the wisdom of giving a network intruder a roadmap to your internal network via easily predicted DNS names, but that's probably just me being paranoid.
We used something very similar to this where I work (Crittercism). I designed most of it.
I used five-part DNS CNAMEs exactly how they're specified in the article (a bit shocking, actually) except that mine switch the "group name" (prod, staging, CI, etc.) and the geography, with the rationale that "groups" can span several geographic areas (example: a multi-regional production environment), so they're logically the "containers" of geographic regions.
Example: rtr01.us-west-2.prod.crittercism.com, NOT rtr01.prod.us-west-2.crittercism.com
Do you manage 12 machines in a closet, 200 EC2 instances, or 1,500 systems in 5 datacenters?
Do you have more than one datacenter in a given city? in a given campus? in a given building?
Do you build systems that serve a single purpose such as a database, or do you run multiple daemons on a single system? How do you take docker/containerization into account?
How often are your sysadmins logging into these systems? Once a week (spell out "production"), or 20 times a day (abbreviate it as "prod")?
Are your systems all owned and operated by you? Do you manage systems for multiple clients in the same datacenter?
Does your team consist entirely of your college roommates you started your company with? Or are you a team of 20 spread out across different time zones and different countries? Will your funny/memorable names be offensive?
This all seems like an exercise in trying to build the The Server Naming Tower of Babel Bikeshed.
Yeah, but most of those are good ideas for a moderately large business that's not managing other people's servers. Especially mnemonic names. Would you rather reference ruby.web or W1L1Z (which is often the kind of cap that people come up with by default).
Presumably you'll need to iterate over hosts anyway, so why not move directly towards your automation tools' (ansible, chef, puppet, etc) host inventory and not fuss with DNS...
Even when you pick a naming scheme, it'll eventually cause grief if you get big enough.
Name your machines XXYYN[N] where XX is the building name, YY is the rack name and NN is the position in the rack? You'll eventually have more than 676 buildings, 676 racks, or 99 machines in a rack. Multiple people will have written regexes to split that into building, rack, position and they will break when you grow one of the fields.
My naming system is pretty similar. Infrastructure consists of a handful of big beefy machines that then each host anywhere from 4 to 12 single purpose guest vms.
For the beefy host machines, I just go with core-a, core-b, core-c etc plus a geo tag. So: 'core-a.de.domain.local', 'core-b.de.domain.local' etc.
For the vms, they get functional names like 'n0-dbc1.de.domain.local' (for node0, database cluster 1) or 'git.de.domain.local' etc.
Only the last two digits of each guest vms mac address (or addresses if it has multiple eth interfaces) changes. The rest is tied to the underlying host machine. So e.g. 00:50:56:01:01:06 means a mac for a guest on 'core-a', 00:50:56:02:02:03 means a mac for a guest on 'core-b' etc.
All internal non-publicly routable IPs use our domain and the '.local' TLD (with bind serving our internal network). All external, publicly routable IPs use our domain and the .net TLD. Finally, our frontend website IPs use our domain and the .com TLD.
The above wont scale well beyond one or two hundred vms per data centre location but if we ever need more than that, it will be a nice problem to have :)
standard width of 3 characters maybe? makes visual scanning of a list of names easy to do to spot name/purpose, environtment, geo, etc. you don't have to keep moving your eyes left or right with each row.
When this came up before I liked the comment from an ex-dropbox employee on how dropbox found positional hostnames to be a the best solution:
https://news.ycombinator.com/item?id=6540044 (top comment by gmjosack)
I worked in the field of infrastructure documentation for a while, applying configuration management principles to it.
Naming is very important and often done poorly. The positional scheme you link to works very well.
You need to label things, and bear in mind that you might be asking some outsourced third party "pair of hands" who has no knowleged of your environment to reboot a box - you want to be sure it's the right one!
Active equipment like servers often have naming conventions around function etc, but consider what happens if someone remotely renames the server and its physical label is ot updated...
For passive equipment, e.g. patch panels, we recommended a suffix indicating U position (being consistent about whether U's coount from the bottom, and which edge defines the U position). Most places start with U1 as the bottom U position, and equipment that might take up Us 1&2 is defined as being in U1 (bottom edge). Alternatives OK, but be clear and consistent.
Many organisations are not definitive on location ids, down to city, name of building within the city, even the names of rooms within a building - multipe names often used!
I use pokémon names to name computers. I just pick the last 9 bits from the computer MAC address, add 1, and check which pokémon have this number in the national pokedex. This scheme can be adapted depending of the network. Perhaps you could use the names of legendary pokémons to name servers and more important computers. It's easy to find images, ASCII art and perhaps even toys to put in the computers to help identification. And even if your network gains 40 new computers each year, the number of existent pokémons grows more than this and you won't be without names. :-)
I suppose it makes sense to get rigorous and logical about hostnames from an admin point of view, but I do miss the romance and personal expression of naming machines after.. well, scifi entities, fairy-tale dwarves, whatever.
One of the many things I like about my ISP is that they apparently feel the same:
traceroute to 192.9.9.100 (192.9.9.100), 30 hops max, 60 byte packets
1 X.X.X.X (X.X.X.X) 7.057 ms 8.826 ms 8.859 ms
2 c.gormless.thn.aa.net.uk (90.155.53.53) 26.691 ms 28.136 ms 27.243 ms
3 c.aimless.thn.aa.net.uk (90.155.53.43) 29.673 ms 30.793 ms 30.273 ms
I used to go the multiple subdomain approach until I discovered some wildcard SSL certificates do not support more than one level of subdomains. Therefore, I now do something like staging-nyc.example.com
In what world is `tst` a better part of a hostname than `testing`? All this article seems discuss is a naming scheme for lazy people who don't want to type long and descriptive hostnames.
[+] [-] siliconc0w|11 years ago|reply
[+] [-] jmtulloss|11 years ago|reply
[+] [-] brugidou|11 years ago|reply
We actually studied this for a while and MAC address is a pretty universal ID that works virtually anywhere. We use the smallest physical non-zero MAC address in case of multiple NICs. We considered using chassis or baseboard serial numbers but it gets too vendor specific.
[+] [-] worklogin|11 years ago|reply
[+] [-] davidw|11 years ago|reply
[+] [-] tambourine_man|11 years ago|reply
It's one of the two hard problems, you know. Help is always appreciated.
http://martinfowler.com/bliki/TwoHardThings.html
[+] [-] chrisweekly|11 years ago|reply
[+] [-] tootie|11 years ago|reply
[+] [-] PieSquared|11 years ago|reply
[+] [-] kbar13|11 years ago|reply
I personally believe that servers should not have names, as naming them just creates the incentive to try to fix broken infra instead of just killing and respawning. I've considered using some kind of short UUID for hostnames instead.
[+] [-] bryanlarsen|11 years ago|reply
Assuming you meant "short ID", how is that any different than the OP's suggestion of randomly choosing from a list of meaningless names?
[+] [-] peterwwillis|11 years ago|reply
"Sure Frank. What's its host tag name?"
"AF84n3Dd2PM."
[+] [-] awalton|11 years ago|reply
However, I personally question the wisdom of giving a network intruder a roadmap to your internal network via easily predicted DNS names, but that's probably just me being paranoid.
[+] [-] eldavido|11 years ago|reply
I used five-part DNS CNAMEs exactly how they're specified in the article (a bit shocking, actually) except that mine switch the "group name" (prod, staging, CI, etc.) and the geography, with the rationale that "groups" can span several geographic areas (example: a multi-regional production environment), so they're logically the "containers" of geographic regions.
Example: rtr01.us-west-2.prod.crittercism.com, NOT rtr01.prod.us-west-2.crittercism.com
Great article.
[+] [-] Asparagirl|11 years ago|reply
[+] [-] 15thandwhatever|11 years ago|reply
Do you manage 12 machines in a closet, 200 EC2 instances, or 1,500 systems in 5 datacenters?
Do you have more than one datacenter in a given city? in a given campus? in a given building?
Do you build systems that serve a single purpose such as a database, or do you run multiple daemons on a single system? How do you take docker/containerization into account?
How often are your sysadmins logging into these systems? Once a week (spell out "production"), or 20 times a day (abbreviate it as "prod")?
Are your systems all owned and operated by you? Do you manage systems for multiple clients in the same datacenter?
Does your team consist entirely of your college roommates you started your company with? Or are you a team of 20 spread out across different time zones and different countries? Will your funny/memorable names be offensive?
This all seems like an exercise in trying to build the The Server Naming Tower of Babel Bikeshed.
[+] [-] romaniv|11 years ago|reply
[+] [-] thezilch|11 years ago|reply
/etc/ansible/{dev,test,stage,prod}-hosts
[+] [-] e_proxus|11 years ago|reply
[+] [-] oddevan|11 years ago|reply
I use Pokemon. What do you use?
[+] [-] ChikkaChiChi|11 years ago|reply
Machete, Vega, Jack, Oscar, Angel, Tattoo, Tigre, Carlos, Vic, Reynaldo, Guerrero, etc...
[+] [-] sciurus|11 years ago|reply
https://groups.google.com/d/topic/devops-toolchain/UZzAcEL7K...
[+] [-] Zolomon|11 years ago|reply
On the other hand, choosing a name for what is running on that server makes it just one step easier for an attacker?
[+] [-] rachelbythebay|11 years ago|reply
Name your machines XXYYN[N] where XX is the building name, YY is the rack name and NN is the position in the rack? You'll eventually have more than 676 buildings, 676 racks, or 99 machines in a rack. Multiple people will have written regexes to split that into building, rack, position and they will break when you grow one of the fields.
[+] [-] corford|11 years ago|reply
For the beefy host machines, I just go with core-a, core-b, core-c etc plus a geo tag. So: 'core-a.de.domain.local', 'core-b.de.domain.local' etc.
For the vms, they get functional names like 'n0-dbc1.de.domain.local' (for node0, database cluster 1) or 'git.de.domain.local' etc.
Only the last two digits of each guest vms mac address (or addresses if it has multiple eth interfaces) changes. The rest is tied to the underlying host machine. So e.g. 00:50:56:01:01:06 means a mac for a guest on 'core-a', 00:50:56:02:02:03 means a mac for a guest on 'core-b' etc.
All internal non-publicly routable IPs use our domain and the '.local' TLD (with bind serving our internal network). All external, publicly routable IPs use our domain and the .net TLD. Finally, our frontend website IPs use our domain and the .com TLD.
The above wont scale well beyond one or two hundred vms per data centre location but if we ever need more than that, it will be a nice problem to have :)
[+] [-] btgeekboy|11 years ago|reply
[+] [-] TomasEkeli|11 years ago|reply
[+] [-] jnazario|11 years ago|reply
[+] [-] edwhitesell|11 years ago|reply
[+] [-] teddyh|11 years ago|reply
I usually suggest that people read RFC 1178, Choosing a Name for Your Computer: http://tools.ietf.org/html/rfc1178
At least then they will avoid the usual pitfalls worked out over the many years in which networked computers has existed.
[+] [-] jasonkolb|11 years ago|reply
[+] [-] Flenser|11 years ago|reply
[+] [-] robaato|11 years ago|reply
Naming is very important and often done poorly. The positional scheme you link to works very well.
You need to label things, and bear in mind that you might be asking some outsourced third party "pair of hands" who has no knowleged of your environment to reboot a box - you want to be sure it's the right one!
Active equipment like servers often have naming conventions around function etc, but consider what happens if someone remotely renames the server and its physical label is ot updated...
For passive equipment, e.g. patch panels, we recommended a suffix indicating U position (being consistent about whether U's coount from the bottom, and which edge defines the U position). Most places start with U1 as the bottom U position, and equipment that might take up Us 1&2 is defined as being in U1 (bottom edge). Alternatives OK, but be clear and consistent.
Many organisations are not definitive on location ids, down to city, name of building within the city, even the names of rooms within a building - multipe names often used!
Examples might be:
LON-DOCK1-DC1-AA02-PP-U41
LON-DOCK1-DC1-AB02-SW-U23
Sometimes:
SVR-LON-DOCK1-DC1-AB03-U01
(without U suffix is fine for such kit often)
Lots of fun in this area!
[+] [-] thiagoharry|11 years ago|reply
[+] [-] ttctciyf|11 years ago|reply
One of the many things I like about my ISP is that they apparently feel the same:
[+] [-] johne20|11 years ago|reply
[+] [-] flyt|11 years ago|reply
[+] [-] Fizzadar|11 years ago|reply