はじめに
ホスト名の付け方には、視認性や区別のしやすさ向上等の目的で、様々な工夫をされているかと思います。
自動化を前提と場合に、何か考慮するべき点があるか考えてみたのまとめます。
多く分けて以下の 2点です。
なお、ペットより家畜的に扱い、あまりホスト名を付ける意味さえない場合もあると思います。この記事である程度ペットのように扱う、ネットワーク機器のホスト名を想定しています。
■ 1. 機械的に読み込みやすくしておく
自動化するためには様々なデータを、人だけでなく、機械にやさしい状態にしておく必要があります。
そのためには、ホスト名の規則や文字種を決めておき、機械が読み込みやすくしておきます。
変数名やファイル名にも利用できる文字種にする
ホスト名を変数名やディクショナリのキーとして利用したり、ファイル名の一部にホスト名を埋め込むことがあります。 そのため、Ansible に限らず各処理系の「変数名やファイル名にも利用できる文字種にする」というのは一定の基準になります。
ファイル名として、避けるべき代表例は / です。ディレクトリの区切りとみなされるためです。特にこのような記号類には要注意です。
デリミタを予め決めておく
ここでいうデリミタとは、RT_01 の _ のように、意味のある単位に区切る文字のことです。
多くの場合は、- や _ といった記号になるでしょう。このようなデリミタは予め決めておくのが良いです。
決めておけば機械的に処理する際に、シンプルな正規表現（またはより単純なパターンマッチ）でグルーピングや区別などがしやすくなります。
デリミタを何にするか
デリミタを - にするか _ にするかは流儀が分かれるかもしれません。
システム（名前解決など）によって利用できる記号が限られてたり、非推奨とされる記号があったりする場合は、それに従うのが良いでしょう。
全体としては _ より - のほうが制約を受けにくい印象があります。
なお、Ansible としては _ のほうが好まれる傾向があります。ホスト名と直接は関係ありませんが、具体的には以下の理由です。
- 変数名に
-が使えない - Ansible 2.8 では、
-が含まれるグループ名を不正とみなし、設定次第では_に置換する仕様変更があった
グループ名のデリミタを _ にするのであれば、ホスト名も _ にするのが自然だろうという考え方もできます。また、気休めレベルですが、どこかで - がマイナスという演算子と判断されて、意図しない挙動することを防ぐ目的もあります。
他にも、1号機、2号機を示す、#1 、#2 の # も別の記号に置き換えたほうが安全で扱いやすいように思います。
（記事投稿後、Ansible の事情に偏りすぎていたので論調を変えました）
数値部分は固定長
RT1、RT2・・・RT9 の次が RT10 のように、数値部分の桁数がガタつくのは機械的に処理しにくくなりがちです。 各桁に意味持たせたり、ゼロパディングしたりして固定長にしておきます。
文字部分もできれば固定長
できれば、文字部分も固定長がよいでしょう。たとえば国名であれば、ISO 3166-1 という3文字で表記する規格があります。他にも、地域名、機器区分、機種名などの意味を持つ文字列がホスト名に含まれる。これらも固定長にできればすると扱いやすくなります。
機器区分を省略して固定長にする方法としては、Switch を SW、Firewall を FW のようにする方法などがあります。
ただし、無理に固定長にこだわりすぎて、直感的に分かりにくくなってしまうのは避けたいところです。 難しい場合は、平易な表現とデリミタを組み合わせると良いと思います。
ケースセンシティブ（大文字小文字を区別）に備える
手作業でホスト名を確認する際、大文字小文字はあまり意識しないかもしれません。
たとえば、実際のコンフィグが hostname rt01 だった場合、手作業の手順書にある「ログイン先が RT01 であること」という項目は OK になるのではないでしょうか。
また、rt01、RT02 のようにホストによって大文字小文字が統一されてなくても、あまり不都合はなかったかもしれません。
ところが、自動化する場合は大文字小文字を区別される場面がが多いです。この認識のギャップがバグのもとになりえます。
コンフィグ上も資料上も、予め大文字小文字を区別して管理するのが良いでしょう。
■ 2. 機械的に生成しやすくしておく
自動化によってスケールしやすくなると、ホスト名自体も自動生成したくなるのではないでしょうか。
モノの名前だけでなく数値を組み合わせる
Moon、Jupiter、Mercury のようなモノの名前だけに頼ってホスト名を付けると、辞書（定義）が必要になって限界が来やすいです。
また、次のホスト名を決めずらい面もあります。 上記の場合、太陽に近い順といった定義をすればメンテナンスが煩雑になりがちになります。
それよりも、シンプルで明確な、数値を組み合わせるのが良いと思います。 数値であれば、基本的に数値を単純にカウントアップするだけです。
このあたりは、手作業の運用と勘所は同じかもしれません。
おわりに
この手のテーマは、地味ですがとても重要に思います。
一方で、ある種の設計要素の面もあるため、なかなか表に出て来ます。
みなさんがどのようにされているのか興味深く思います。
