5 ms·
I know servers are supposed to be "cattle" but I can't get away from the feeling that having at least a part of the name being somewhat sentimental is a nice th
by hnarn 5y ago
I know servers are supposed to be "cattle" but I can't get away from the feeling that having at least a part of the name being somewhat sentimental is a nice thing. The default naming scheme for many containers, for example, will combine an adjective and a noun to create a unique name. I myself wrote a pretty silly script once that randomly returned the name of a British or German naval warship. It seems to me that "formalized" naming doesn't have to be exclusive with sentimentality, you can just add it at the end, like:
geotag-srvtype[#]-prod-[pokemon_name_or_whatever]
That way, if your environment is completely fluid, it becomes obvious when a node has re-deployed, and if it's not, you can just re-use the old name when re-deploying instead of generating a new one.
You can of course include hash-looking things in hostnames as well, but I'm a strong believer that hashes are for computers, not for humans to read (most of the time).
- tomjen3 5y agoYou totally should name the container classes after battleships. Then you can truthfull say you deleted/sunk the Bismark. Anyway I think there is nothing wrong with naming classes of things after known things - so you are deploying two more Victor class frontend servers or Dreadnaught monitoring services. The trouble becomes when you care about Dreadnaught-oux3z and treat it as not disposable.
- DonHopkins 5y agoYou could name your servers after cuts of beef, beef recipes, and hamburgers, like the WOPR Computer and Big Mac: https://www.youtube.com/watch?v=iRsycWRQrc8 https://www.youtube.com/watch?v=iRsycWRQrc8 https://en.wikipedia.org/wiki/Big_Mac_(supercomputer) https://en.wikipedia.org/wiki/Big_Mac_(supercomputer)
- GekkePrutser 5y agoNot everyone buys into the cattle not pets thing. It's mainly a thing related to auto deployment strategies. Which are great for the cloud with its quick auto scaling capabilities. The ideal vision there is that you shouldn't even have the ability to log in to a server. But there are other usecases where a known environment you can poke around in is more useful IMO. As an example, in cloud environments not much time is spent investigating issues. When something fails the solution is often to just wipe and redeploy. I prefer fully understanding the problem and having the tools to troubleshoot. Especially because in my work the servers still have different roles.