Machine Naming Conventions

[Benjamin VanEvery]

Hi,

I'm looking for some ideas on machine naming conventions. We'd like to get a place where machine names mean very little and serve primarily as a unique key to query in a machine inventory database, which would give back information about machine roles and cluster membership.

I'd really appreciate learning about other people's best practices (or failed practices) in this arena!

Thanks a bunch! 

Sincerely,

Ben

[Ranjib Dey]

machine ids? or uuids.

http://man7.org/linux/man-pages/man5/machine-id.5.html

--
You received this message because you are subscribed to the Google Groups "devops-toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devops-toolcha...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Will Thames]

If you don't care what the names are, then you might as well just pick something that guarantees uniqueness - eg. hex representation of IP address (assuming your hosts don't share IP addresses).

AWS does it slightly differently with e.g. ip-10-1-2-3 which will also work but does mean inconsistent length hostnames e.g. if you also had ip-192-168-100-233 - a problem an eight hex digit host name would solve.

At 3am, sshing to an eight hex digit hostname could lead to typos (having said that, most common naming schemes have a good chance of typos - e.g. a single character being difference between dev and prod). To ensure a good chance of distance between hostnames and thus reduce risk that a typoed host exists, you could always use a substring of the sha checksum of the ip address!

In general, picking a naming convention is going to be a trivial problem compared with ensuring that you can extract meaningful host information from the inventory database at 3am - get me the production database server on the West Coast serving the FooBar application.

--

[Jonathan Hitchcock]

Slightly easier than remembering a string of digits is remembering a pronounceable rendition of those digits:  http://shorl.com/koremutake

[Brian Pitts]

Although RFC 1178 was written at a very different time, I'm still a fan of "use theme names".

http://tools.ietf.org/search/rfc1178

[Brad Knowles]

On Feb 12, 2014, at 9:08 AM, Brian Pitts <br...@polibyte.com> wrote:

> Although RFC 1178 was written at a very different time, I'm still a fan of "use theme names".
>
> http://tools.ietf.org/search/rfc1178

That works fine for small groups of machines, but for example when you've got more than seven machines, you can't name them all after the seven dwarves. Any theme naming scheme is going to have a limit to how many nodes it can sustain.

Once you reach that limit, then what? Heck, in my experience, theme naming starts becoming more hassle than its worth well before the theme is completely exhausted.


I like theme naming for small groups of machines, but you have to decide at what point you're going to start using something that is more practical.

--
Brad Knowles <br...@shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

[Joseph Holsten]

I like that pronounceable digit representation!

We tried using opaque host names for a while, but switched back to role-based names after we found our pagerduty alerts were suddenly impossible to understand.

We ended up with three main styles of domain names:

{service}-{index}.{env}.{geo}.{base-domain}, eg

app-216.stg.sfo.corp.net

This style is used for virtualized node FQDNs

{service(-{subservice})}-{index}.{env}.{geo}.{base-domain}, eg

app-db-216.stg.sfo.corp.net

{service(-{subservice})}-{index}.{env}.{geo}.{base-domain}, eg

app-db-216.stg.sfo.corp.net, 

This style is used for most b

{service(-{subservice})}-{index}-r{rack}.{env}.{geo}.{base-domain}, eg

datanode-216-r347.stg.sfo.corp.net

This style is used for physical servers,

--

http://josephholsten.com

[Frederic Vassard]

In the past we have used the machine physical location as its hostname. This works pretty well and allows for the machine to be re purposed easily. However, this requires a good and very accessible single source of truth for those 3 am scenarios...

Cheers,
--Fred.

[Joseph Holsten]

Shoot, misfired while typing on my phone. I'll send our full scheme when I get to a real keyboard. 

--

http://josephholsten.com

[Brian Pitts]

On 02/12/2014 09:36 AM, Brad Knowles wrote:
> On Feb 12, 2014, at 9:08 AM, Brian Pitts <br...@polibyte.com> wrote:
>
>> Although RFC 1178 was written at a very different time, I'm still a fan of "use theme names".
>>
>> http://tools.ietf.org/search/rfc1178
>
> That works fine for small groups of machines, but for example when you've got more than seven machines, you can't name them all after the seven dwarves. Any theme naming scheme is going to have a limit to how many nodes it can sustain.
>
> Once you reach that limit, then what? Heck, in my experience, theme naming starts becoming more hassle than its worth well before the theme is completely exhausted.
>
>
> I like theme naming for small groups of machines, but you have to decide at what point you're going to start using something that is more practical.

You'll eventually exhaust a single theme. However, it scales much
farther than 7. For example, elastisearch draws from a list of 3000
Marvell character names when creating a cluster.

--
All the best,
Brian Pitts

[Steve Conover]

We do this:

- First letter = machine class. a = application-class host, b = large slow disks, c = ssd/flash, etc. Have a minimal # of machine classes.

- Two letters that describe the zone with respect to firewalls, e.g. dz = dmz

- A monotonically increasing number

- We ensure the above combination is unique across dc's

Example:

adz23

app-class machine

in the dmz

#23 (specifically, this would be the 23rd app-class host in the dmz we've ever provisioned, globally)

[Aaron Bull Schaefer]

On Tue, Feb 11, 2014 at 7:02 PM, Benjamin VanEvery <vane...@gmail.com> wrote:
> I'd really appreciate learning about other people's best practices (or
> failed practices) in this arena!

I wrote a detailed article [1] regarding a scheme that should work
well for small to medium deployments. Like you mentioned, I recommend
not having the machine's name directly reflect its purpose. Once you
get to a certain scale, this breaks down and location based names
probably make more sense, but this should get you past thousands of
machines.

[1] http://www.mnxsolutions.com/devops/a-proper-server-naming-scheme.html

--
Aaron Bull Schaefer
http://elasticdog.com/

[Nathan Valentine]

I have a feeling this could turn into bikeshedding but I'll chime in anyway. ;) 

I really like Joseph's model. Very similar to what I've always done when I was in a work role to set these conventions or when I was setting up a multi-node personal project. 

And to ensure bikeshedding, for the love of $diety, 0-index and no lead padding on the index! Names like app007 make me stabby for so many reasons.

--

---
Nathan Valentine, Puppet Labs Professional Services

Have you seen? : http://ask.puppetlabs.com , http://puppetlabs.com/learn

Join us at PuppetConf 2014, September 23-24 in San Francisco - http://bit.ly/pupconf14

[Bryant Durrell]

I'm probably part of the choir but I love the dashes. Concatenation leads to illegibility and we're not limited to 80 column screens any more.

-- 

Bryant Durrell

[Scott Zahn]

It might be slight bikeshedding, but I like seeing how other people do this kind of thing.  I personally agree with Joseph's naming model as well, probably because my naming model is almost identical with Joseph's. :) It has worked well for me with servers in multiple EC2 regions.

I'm totally curious, why does zero padding make you stabby?

[raul mazda]

On 12 February 2014 08:37, Nathan Valentine <nat...@puppetlabs.com> wrote:

And to ensure bikeshedding, for the love of $diety, 0-index and no lead padding on the index! Names like app007 make me stabby for so many reasons.

string sort is the best sort.

.laz 

[Jonathan Hitchcock]

A list of 3000 is no less exhaustible than a list of 7.

Machines are cattle, not pets!

[Joseph Holsten]

One more time!

We tried using opaque host names for a while, but switched back to role-based names after we found our pagerduty alerts were suddenly impossible to understand.

We ended up with three and a half styles of domain names:

{service}-{index}.{env}.{geo}.{base-domain}, eg
app-216.stg.sfo.corp.net

This style is used for virtualized node FQDNs, where the service maps to a chef role, the env to a chef/app environment, and geo to a datacenter or cloud region. The index is an opaque, unique identifier. At the moment we're using 3 digit decimal, but fully intend to switch to hex.

{service(-{subservice})}-{index}.{env}.{geo}.{base-domain}, eg
app-db-216.stg.sfo.corp.net

This style is used for support services (like the cache, queue, db, or elasticsearch) required for running service app. Implies that security groups should only allow access from other nodes that start with app-*.

{service(-{subservice})}.{env}.{geo}.{base-domain}, eg
app-db.stg.sfo.corp.net

This style is used for load balancer VIPs, CNAMES, and round-robin DNS pools. It is intended to be a logical/semantic name for clients who need to access the service. Developers found hardcoding indexed hostnames are beaten until morale has improved.

{service(-{subservice})}-{index}-r{rack}.{env}.{geo}.{base-domain}, eg
datanode-216-r347.stg.sfo.corp.net

This style is used for physical servers, and the rack index is shared with our datacenter provider's rack indexing. That way when we absolutely need a physical person walk to a physical location and press a physical button, it's straightforward.

We also have this naming script integrated with our provisioning tools, we can build a "unipony" app dev instance in our default datacenter with a single command:
$ mkbox unipony
Which builds a t1.micro with a node name of something like unipony-639.dev.dfw.corp.net and bootstraps with a chef runlist of ['role[unipony]']. More complicated usage is like the following:
$ mkbox unipony prod sfo hs1.8xlarge

--
http://josephholsten.com

[Isaac Finnegan]

That sounds reasonable, but why was it hard to add data to the pager duty alert about what the hosts function was?

[Aaron Bull Schaefer]

On Wed, Feb 12, 2014 at 11:45 AM, Jonathan Hitchcock
<jonathan....@gmail.com> wrote:
> Machines are cattle, not pets!

I agree with this if you're working in an IaaS environment, but not so
much if you're managing your own bare metal.

[Abe Hassan]

Just to be clear: the physical machines are pets, and I take care of them because it's silly to throw them out over a bad stick of RAM. But the logical server, everything installed on that machine, is still treated like cattle...

[Joseph Holsten]

We're just using pagerduty's default nagios integration. And while the detail view had the right metadata, I started getting rather angry when I'd get a phone call at 3am saying the load was critical on server ZERO EY ONE DEE DASH THREE FIVE BEE EFF. You can imagine how much my devs liked it when we started putting them on-call for their apps.