意味のあるホスト名と意味のないホスト名の選択[終了]

さまざまなハードウェア、ソフトウェア、オペレーティングシステム、仮想/専用など、さまざまなサーバーのパペット管理クラスターの環境を想定します。

意味のあるホスト名（mysqlmaster01..99、mysqlslave001..999、vpnprimary、vpnbackupなど）を選択しますか、または本や映画のキャラクターなどの意味のないホスト名を選択しますか？

意味のあるホスト名で見られる問題は、通常、名前が単一のサービスを表し、サーバーに複数の目的がある場合、それが本当に面倒になることです（特にサーバーの役割が頻繁に変更される場合）。

サービス名をIPアドレスにマッピングし、そのマッピングを維持して、DNSが行うべきことをしていませんか？

両方のアプローチの長所と短所は何ですか？また、選択したアプローチで取り組む必要がある実際の問題は何ですか？

むかしむかし、命名スキームを決定する機会がありました。だから私は巡回して、結局これらの名前を日常的に使用しなければならなかった人々である開発者に、機能的な名前（つまり、エンコードされた形式で、マシンの目的）またはニーモニック名（つまり、マシンの目的に関する暗黙のコンテンツを含まない、既存の人間の命名スキームから抽出された名前）。

38人の開発者のうち、37人がニーモニック名を好みました。1つの優先機能名のみ。だから私はすべて川にちなんでそれらに名前を付けました（可能な名前の非常に大きなプールがあり、それらの多くは短く、覚えやすく、入力しやすいです）。

人間の脳は、名前に意味を付けるために非常にうまく設計されています。覚えやすい名前を提供すると、人々はそれらの名前が何に使われているのかをすぐに覚えて使用します。一般的な背景（川、元素、星、郡、飲み物など）から描かれた名前を使用すると、会社のホスト名を見つけたときにすぐに認識できるようになります。そうしないと、「すべてのメールが終わった」などのステートメントbetelgeuseが少し混乱する可能性があります）。

反対に、私の開発者は、以前の仕事で彼らが何でpr1ms001あったかを正確に思い出すのに本当に苦労したと感じました。

ただし、内部DNSでCNAMEを使用してニーモニック名マッピングへの機能名を提供したことを追加する必要があります。そのため、PRサイトの最初のクラスターのメインメールサーバーpr1ms001がそれが現在であったことを知らせてくださいorwell。また、マシンごとに多くの機能名を持つことができるため、作業中の機能に関連する機能名を常に使用している限り、pr1imap001その機能を移動した場合でも、常にIMAPサーバーを指すようになります。からorwellまでrhine。また、hudson死亡した場合、運用機能に影響を与えることなく交換品の名前を変更できるため、「hudson新旧を意味しますhudsonか？」混乱。

これは主にサーバーがあるかどうかにダウンしていますpetsかlivestock。

ペットには個人名が付けられます。それらは互いに異なっており、それらの違いを気にかけます。病気になったら、私たちは通常、それを健康に戻すように看護しようとします。従来、サーバーはペットでした。

家畜は数字を取得します。それらはほとんど同一であり、どのような違いがありますか、私たちは気にせず、通常最小化しようとします。人が病気になったら、それを置いて別のものを手に入れます。完全に仮想化されたサーバー、特にAWSなどのIaaSサーバーは家畜です。

ほとんどの複雑な環境では、混在しています。たとえば、Webバックエンドはほぼ確実に家畜です。さらに必要な場合は、標準構成でさらにいくつかを起動します。必要ない場合は、いくつかをオフにします。データベースサーバーは、一部の構成ではペットです。それぞれに多くの特別な設定があります。仮想化の代わりにベアメタルで実行することもできます。

もちろん、どちらの環境でも、SERVICESという名前を付けて、それらに直接対処できます。これは、どのような場合でもベストプラクティスです。開発者は、サービスの実際のホスト名を知っている必要はありません。ホスト名は、純粋に操作可能な詳細である必要があります。次に、ホスト名で運用スタッフに役立つ情報をエンコードすることを考えます。たとえば、サーバーがどのデータセンターにあるかを示すと便利です。

これは前にここで説明しました...

私の推奨事項は、機能名とニーモニック名の組み合わせです...

アプリケーションを作成していて、アドレス指定する必要がある場合は、ccts-logserver1全体を通してその名前を使用しますが、CNAMEまたはエイリアスにします。実際のホスト名は、果物や野菜、ギリシャ神話、またはサインフェルドのキャラクターなど、何でもかまいませんが、実際の機能的な名前を関連付ける必要があるときに、ある程度の柔軟性を提供しますが、人々が覚えられるものを保持します。

mangoDBサーバーが失敗する例を考えてみてください...しかし、他の何かに置き換えられますpeach。おそらく、既存のプロセスとアプリケーションを確認する必要がありますcmt-prod-db1。システムを交換し、名前の競合なしにシステムを構築し、アプリケーション（および開発者）を満足させることができます。

私が働いている場所では、複数の都市、複数の企業、複数のサイトを管理しています。ニーモニック名は機能しません。代わりに、サーバーを説明する短縮形を使用します。異なるドメインに複数のオフィス（または複数のドメインに単一のオフィス、同じドメインに複数のオフィス、または上記すべて）を持つクライアントがあるため、このケースではうまく機能します。

私たちにとって、情報には会社/ドメイン、都市、機能、番号が含まれます。したがって、会社のドメインコントローラーの場合、シカ​​ゴのサイプレスは次のようになります。

CYPRCHDOM001（会話ではこれをサイプレスのメインDOMと呼びます）

CYPRCHSQL001はSQLサーバー、CYPRCHMGM001はその管理（ウイルス対策、バックアップなど）、CYPRCHAPP001は混合アプリケーションサーバーになります。覚えやすく、分類しやすく、教えやすい。

ホスト名の唯一の要件は、ネットワーク上で一意であることです。

意味は、サーバー機能だけである必要はありません。物理デバイスを扱う必要がある場合、ロケーションは非常に役立ちます。デバイスが仮想か物理かを知ることも役立ちます。ネットワークデバイス、Linuxサーバー、またはWindowsボックスの違いを認識できると、ログインに使用するツールを判断する際に非常に便利です。

これを処理する方法は、次のようにこの情報をデバイス名に入れてみることです。

LまたはT -ライブやテストのPまたはV -物理または仮想SまたはN -サーバーまたはネットワーク（私たちはすべてのLinuxサーバを持っていない）のシーケンシャル番号は一意性を保証するためにISO 3166-1の3文字の国コードは、デバイスを示します位置しています。

次に、DNSのCNAMESを使用して、さまざまなサービス名をホスト名にマッピングします。

私はこれについて複雑な気持ちを持っています。確かに、特定のデバイスがどこにあるかを調べる必要がある時間を節約できます。一方、ジェムストーンを使用していた以前のシステムと比較すると、特定のサーバーがホスト名を提示されたときの動作を覚えるのははるかに困難です。宝石は何の意味も意味しませんでしたが、それぞれの人が独自のつながりを作ることができるため、覚えやすいものでした。

唯一のアドバイスは、あるシステムから別のシステムに移行したときに最大の混乱が生じたため、1つのスキーマで解決することだと思います。