てくなべ (tekunabe)

ansible / network / automation

[Ansible] 「つまずき Ansible 【Part11】トラブルシューティング手法を試す

はじめに

2020/08/01 に、YouTube Live で「つまずき Ansible 【Part11】トラブルシューティング手法を試す」という配信をしました。 実際に作業しながらエラーと戦って進めるシリーズです。

tekunabe.connpass.com

今回は、July Tech Festa 2020Cloud Operator Days Tokyo 2020@saito_hidekiさんから発表があった、以下の資料を参考にながら、トラブルシューティングの手法をいつくつか試しました。

www.slideshare.net

やったことや、わかったことをふりかえります。

動画

www.youtube.com


■ やったこと

log_path によるログ保存

設定名は DEFAULT_LOG_PATH

ansible.cfg の場合は以下の設定。相対パスでもOKの模様。

[defaults]
log_path=ansible.log

環境変数での設定の場合は ANSIBLE_LOG_PATH

コマンド実行時の一時的に有効にする場合は、以下のよいうに指定する。

$ ANSIBLE_LOG_PATH=ansible1.log ansible-playbook -i inventory.ini ios_show.yml

ANSIBLE_DEBUG によるデバッグ

設定名は DEFAULT_DEBUG

環境変数での設定の場合は、ANSIBLE_DEBUG。大量のログが表紙されるので、一時的な設定にするのが吉。

$ ANSIBLE_DEBUG ansible-playbook -i inventory.ini ios_show.yml 

前述の log_path 指定したファイルにも出力される。

--step によるステップ実行

ansible-playbook コマンドの --step オプションで、各タスクの実行前に一時停止できる。

n でスキップ、y で実行(次のタスクでまた止まる)、c で継続(この後は止まらない)

# ansible-playbook -i inventory.ini ios_show.yml --step

PLAY [ios] ***************************************************************************************************************************
Perform task: TASK: 1. show version (N)o/(y)es/(c)ontinue: y

Perform task: TASK: 1. show version (N)o/(y)es/(c)ontinue: ***************************************************************************

TASK [1. show version] ***************************************************************************************************************
ok: [rt01]
ok: [rt02]
Perform task: TASK: 2. show ip route (N)o/(y)es/(c)ontinue: c

Perform task: TASK: 2. show ip route (N)o/(y)es/(c)ontinue: **************************************************************************

TASK [2. show ip route] **************************************************************************************************************
ok: [rt02]
ok: [rt01]

TASK [3. show ip route] **************************************************************************************************************
ok: [rt01]
ok: [rt02]

PLAY RECAP ***************************************************************************************************************************
rt01                       : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
rt02                       : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

--start-at-task による、開始タスクの指定

ansible-playbook コマンドの --start-at-task オプションで、どのタスクから始めるかを指定できる。

ansible-playbook -i inventory.ini ios_show.yml --start-at-task "2. show ip route"

としたときに、以下のように 2. show ip route という名前のタスク移行が実行される。

    - name: 2. show ip route
      ios_command:
        commands:
          - show ip route

新たにわかったこと

試した限り、同じ名前のタスクが合った場合は、上にあるタスクから実行される模様。

また、--start-at-task "2. show ip*" のようなワイルドカード指定もできた。 "2. show ip" ではマッチしない。

Playbook Debugger によるデバッグ

以前の配信でも利用した便利な Playbook Debugger

たとえば、以下のように Play レベルで debugger: always を指定すると、各タスクの各ホスト実行後にデバッガーが起動する。

---
- hosts: ios
  gather_facts: false
  debugger: always
  
  tasks:
    - name: 1. show version
      ios_command:
        commands:
          - show version

    - name: 2. show ip route
      ios_command:
        commands:
          - show ip route

    - name: 3. show ip route
      ios_command:
        commands:
          - show ip route

変数の値を途中で確認したり

[rt02] TASK: 1. show version (debug)> p task_vars["ansible_user"]
'admin'

書き換えたりもできる。

[rt02] TASK: 1. show version (debug)> task_vars["ansible_user"]="hogehoge"
[rt02] TASK: 1. show version (debug)> u

再実行は r

[rt02] TASK: 1. show version (debug)> r

新たにわかったこと

前述の --step の機能を包含していると思っていがそうではなかった。

  • --step
    • タスクの実行前に止まる
    • タスク単位(ホスト単位ではなく)で止まる
  • Playbook Debugger
    • タスクの実行後に止まる
    • ホスト単位で止まる

ANSIBLE_KEEP_REMOTE_FILES による、Pythonファイルの保存

Ansible がマネージドノードに送って実行する Python ファイルは、通常は実行後に削除されるが、それを残すことに酔ってデバッグの材料になる。

設定名は DEFAULT_KEEP_REMOTE_FILES

環境変数での設定の場合は ANSIBLE_KEEP_REMOTE_FILES

# ANSIBLE_KEEP_REMOTE_FILES=True ansible -i inventory.ini sv -m shell -a "hostname"
awx | CHANGED | rc=0 >>
centos7

ターゲットノードでファイルが残る。

[root@centos7 ~]# cd .ansible/tmp/ansible-tmp-1596282623.326226-90936-50539150331503/
[root@centos7 ansible-tmp-1596282623.326226-90936-50539150331503]# ll
合計 124
-rwx------. 1 root root 124866  8月  1 20:50 AnsiballZ_command.py

実行もできる。

[root@centos7 ansible-tmp-1596282623.326226-90936-50539150331503]#./AnsiballZ_command.py 

{"changed": true, "end": "2020-08-01 20:52:07.803865", "stdout": "centos7", "cmd": ["hostname"], "rc": 0, "start": "2020-08-01 20:52:07.801926", "stderr": "", "delta": "0:00:00.001939", "invocation": {"module_args": {"creates": null, "executable": null, "_uses_shell": false, "strip_empty_ends": true, "_raw_params": "hostname", "removes": null, "argv": null, "warn": true, "chdir": null, "stdin_add_newline": true, "stdin": null}}}


Part3 にむけて

以下のネタを検討中です。気が向いたものをやります。

  • connection: local ななにか
  • Ansible Toewr / AWX をコマンドがら操作する
  • ansible.cfg
  • Jinja2、フィルター
  • Windows

無償版 ESXi への vCenter(VCSA 7.0)の デプロイが Stage1 の 80% から進まない

はじめに

タイトルオチですがまとめておきます。 この手の作業は初めてだったのですが、多くの人が通り道のようですね・・。

環境

  • ESXi 7.0.0b
  • VMware vCenter Server Appliance 7.0

現象

vCenter Server Appliance 7.0 を GUI でデプロイしおうとしたところ、 Stage 1 の 80% から進まず止まってしまいました。

f:id:akira6592:20200731205250p:plain
進まない

調べて出会ったのがこちらの記事です。(助かりました)

技術メモメモ: vCSA (vCenter Server Appliance) 6.7のインストールが80%で止まる件

インストール先のESXiは無償ライセンスで運用しており、それが原因のようだ。試しに60日間の機能無制限の評価ライセンスでESXiを構築して同様にvCSAをインストールしてみたところ、問題なくインストールすることができた。

対策

ちょうど VMUG Advantage に入ったばかりで、各種ライセンスを1年間利用できる状態だったので「VMware vSphere 7 (ESXi)」のライセンスキーを取得して、ESXiに投入しました。

f:id:akira6592:20200731210601p:plain
投入前(無償版ライセンス)

f:id:akira6592:20200731210013p:plain
投入後

投入後、勝手にデプロイが進んでいきました。

f:id:akira6592:20200731210105p:plain
この後も順調でした

f:id:akira6592:20200731210742p:plain
デプロイと基本設定後

[Ansible] 「AnsibleでA10 Thunder のADC機能を設定しよう!(基礎編)」に参加させていただきました

はじめに

2020/07/28 に A10ネットワークス株式会社さん主催の「【リモート勉強会】第2回:AnsibleでA10 Thunder のADC機能を設定しよう!(基礎編)」に参加させていただきました。

www.a10networks.co.jp

第1回が好評だっため、同じ内容で再度開催されたとのことです。実際私も第1回に参加した人からのススメもあって今回参加しました。

資料や、環境、Q&Aの体制が整っていて、実際にハンズオンができてとても有意義な勉強会でした。

この記事では、この勉強会通して学んだことのうち、特に知れてかったポイントなどをまとめます。


使用テキスト

使用されたテキストはこちらです。

github.com

LB としての基本的な設定を少しずつ Playbook を使って設定していく流れです。

Playbook のサンプルや解説はもちろん、実行ログや Thnder 側での確認手順なども詳細に書かれて、操作に迷うところはありませんでした。


基本は Collection モジュールを使用する

Ansible 本体にも、a10_*モジュールがありますが、これらは基本的に利用されないようです。

これまでもいくつかサンプルを見て察しがついていたのですが、代わりに以下の collection を利用するのが良いようです。


環境

README.mdにもあるように、各種 PATH が設定されていました。

[root@ansible playbook]# ansible-config dump --only-changed
DEFAULT_ACTION_PLUGIN_PATH(env: ANSIBLE_ACTION_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_axapi/plugins/action']
DEFAULT_CLICONF_PLUGIN_PATH(env: ANSIBLE_CLICONF_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_cli/plugins/cliconf']
DEFAULT_TERMINAL_PLUGIN_PATH(env: ANSIBLE_TERMINAL_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_cli/plugins/terminal']


a10.acos_axapi のモジュールの ansible_host オプションなどは省略可能

テキストでは、以下のように ansible_hostansible_username といった接続に関わるオプションが各タスクごとに指定されていました、(引用元

  - name: Configure virtual server
    a10_slb_virtual_server:
      ansible_host: "{{ ansible_host }}"
      ansible_port: "{{ ansible_port }}"
      ansible_username: "{{ ansible_username }}"
      ansible_password: "{{ ansible_password }}"
      name: "vip1"
      ip_address: "10.0.1.100"
      port_list:
        - port_number: "80"
          protocol: "http"
          service_group: "sg1"
          pool: "p1"
      state: present

タスクごとに指定するのは、冗長だと思って楽にできる方法ががあるか質問したところ、実はインベントリファイルの変数設定さえあれば、タスク側は指定不要とご回答いただきました。 テキストではわかりやすさのため指定しているとのこと。

つまり上記の例では、以下のように書けます。

  - name: Configure virtual server
    a10_slb_virtual_server:
      name: "vip1"
      ip_address: "10.0.1.100"
      port_list:
        - port_number: "80"
          protocol: "http"
          service_group: "sg1"
          pool: "p1"
      state: present

あとで、この README.md を確認したらちゃんと書いてありました。

If you want to use an Inventory file to perform respective configurations through a playbook, you don't need to specify ansible_host, ansible_username, ansible_password and ansible_port in the playbook.


a10_write_memory は毎回 changed になる

running-configstartup-config に保存する a10_write_memory というモジュールがあります。

このモジュールは実行のたびに毎回 changed になります。設定の「定義」ではなく、write memory という「操作」なので、そうなのだろうなと思います。

一方で、他の設定定義系のモジュールの多くは冪等性があるようです。そのため、もし、設定変更時のみ write memory したい場合は、handlers を組みわせることになると思います。


部分宣言的な定義

Virtual-Serverを構成するPlaybookの作成のところで、以下のような説明がありました。

既存のport_list設定(port 80 http)を残す場合は、必ずPlaybookに記述する必要があります。 記述がない場合は、既存のport設定が消えて新規の(Playbook内に記述された)port設定のみが設定される形になります。

つまりもともと port 80 http がある状態で、以下のように port 443 https のみの port_list にした場合、 port 80 http が消えて port 443 https のみになるということです。

      port_list:
        - port_number: "443"
          protocol: "https"
          service_group: "sg1"
          pool: "p1"
          template_client_ssl: "ssl1"

このような挙動を取るものを、私は勝手に部分宣言的な定義と呼んでいます。

Network Resource Module でいう state: overriddenstate: replace のような動きですね。

注意が必要な一方で、あるべき姿を宣言する形(引き算を考えなくていい)便利だと思います。


構造化データの取得には state: noop

各モジュールの state オプションは presentabsent の他にも noop という値も指定できます。 get_type オプションを併せて使うと、構造化データで結果を取得できるそう。

参考

tenko.hatenablog.jp


a10.acos_cli.acos_command モジュールは設定変更もできる

(これはテキストには出てこず、Q&Aのやりとりをきっかけに調べました)

私がこれまで見てきた *_command モジュールは、主に show コマンド用です。例えば、 ios_command モジュールで、configure terminal してなにか設定変更系コマンドを指定しても正常に実行できません。

一方で、a10.acos_cli.acos_command モジュールでは、設定変更もできるようです。

例えば、以下のような例がモジュール内のドキュメントに記載されています。

    - name: Run multiple sequential commands on ACOS device
      a10.acos_cli.acos_command:
        commands:
          - command: configure
          - command: slb template http test1
          - command: write memory
          - command: end

ただ、実際は、a10.acos_cli.acos_config モジュールのほうが、設定変更に特化した機能が多いため、a10.acos_cli.acos_config のほうが設定変更に適していると思います。


a10.acos_cli.acos_command モジュールは内部で show running-config を実行する

(こちらもテキストには出てこず、Q&Aのやりとりをきっかけに調べました)

前述のように、設定変更もできることに起因するようですが、a10.acos_cli.acos_command モジュールは内部で show running-config を実行するようです。

事前事後のコンフィグの差分を確認し、差分があれば chenged にする、という処理がありました、

これだけ聞くと、あぁそうなのか、という感じですが、気にしないといけないのは権限です。

show running-config を実行するには、enable する必要があります。ということは、相応の設定が必要になります。 enable パスワードが空なのであれば、空であるという指定 ansible_become_password="" が必要です。場合によっては。ansible_become_method=enable も併せて必要になるケースもあるようです。

試せていませんが、使用しているユーザーが特権ユーザーであれば become 系は不要なのかなと予想しています。


おわりに

親切なテキストと、十分な環境、的確な回答をいただける Q&A が揃っていて、とても安心して作業できました。 もしまた開催されたらおすすめできる内容でした。

ありがとうございました。

おまけ

おかげさまで時間内にすべて終わりました。最後は HTTPSのVirtual-Serverの構成 です。

記念の動作確認 GIF です。LB で SSL を終端しつつラウンドロビンしています。(Firefox の Ctrl+F5 (スーパーリロード) しています)

f:id:akira6592:20200728205155g:plain
ラウンドロビンしている様子

Intel NUC 上の ESXi 7.0 に BUFFALO の USB NIC を認識させる

はじめに

先日、第10世代 Intel NUC を購入して ESXi 7.0b をインストールしました。

f:id:akira6592:20200724140643p:plain:w400
ESXi 7.0b

物理 NIC を追加したくなったため調べたところ、以下の記事を見つけました。

tech-mmmm.blogspot.com

この記事で紹介されているチップセット「AX88179」と同じらしい「BUFFALO 有線LANアダプター LUA4-U3-AGTE-BK ブラック Giga USB3.0対応」がたまたま家に転がっていたため、試しました。

ほとんど前述の記事の手順と同じです。とても参考になりました。私の環境の場合は、ESXi 7.0 なので、ドライバのファイル名(後述)だけ違います。

接続

USB NIC を NUC の余っている USB 3.0 のポートに接続します。

接続直後の確認

ESXi に SSH でログインして、lsusb コマンドで、接続直後の状態を確認します。

[root@localhost:~] lsusb
Bus 001 Device 001: ID 0e0f:8003 VMware, Inc. Root Hub
Bus 002 Device 001: ID 0e0f:8003 VMware, Inc. Root Hub
Bus 001 Device 002: ID 8087:0026 Intel Corp.
Bus 001 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
[root@localhost:~]

ASIX Electronics Corp. AX88179 Gigabit Ethernet が追加されました。 ただし、まだドライバをインストールしていないため、ESXi 上の 物理NIC としては認識されていない状態です。

ドライバのダウンロードとインストール

こちらのサイトからドライバをダウンロードします。

ESXi 7.0 を利用しているので、ドライバファイルは ESXi700-VMKUSB-NIC-FLING-34491022-component-15873236.zip を選択します。

f:id:akira6592:20200724140143p:plain
ESXi 7.0 向けのドライバを選択

ダウンロードしたドライバファイルを、データストアブラウザや SCP などで ESXi へコピーします。

その後、esxcli software vib install -d ドライバのzipファイル名 でドライバをインストールします。

[root@localhost:~] esxcli software vib install -d /vmfs/volumes/datastore1/ESXi700-VMKUSB-NIC-FLING-34491022-component-15873236.zip
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMW_bootbank_vmkusb-nic-fling_0.1-4vmw.700.1.0.34491022
   VIBs Removed:
   VIBs Skipped:

ESXi の再起動を要求されているので、再起動します。

確認

正しく認識されたか ESXi の web にログインして確認します。

vusb0 という物理NIC が追加されました。

f:id:akira6592:20200724140420p:plain
vusb0 が追加された

f:id:akira6592:20200724140539p:plain
vusb0 の詳細

おわりに

たまたま家に転がっていた NIC でできてよかったです。

長期的に利用したわけではないので安定面はまだ不明ですが、とりあえずは認識しました。

f:id:akira6592:20200724141053p:plain
リンクアップもしてます

ネットワーク自動化の勉強って何やればよい?

はじめに

なんとなく興味を持って、業務としても携わっているネットワーク自動化ですが、なにをべんきょうすればよいの?と聞かれたときのために自分なりの方法をまとめておきます。

(ここにあげげたことをすべて私がマスターしているわけではありません・・)


関連情報にアンテナをはる

新しい情報はだいたい海外からくるので、海外の情報をメインにアンテナをはる。

Blog

slack


ネットワークの基礎を身につける

業務をシステム化するのには業務を知る必要があるように、ネットワーク自動化するためにはネットワークの基礎を知る必要がある。


ネットワークの設計、構築、運用業務を知る

業務をシステム化するのには業務を知る必要があるように、ネットワーク自動化するためにはネットワークの業務を知る必要がある。

  • 設計、構築、運用でどのような作業があるかを知る
  • 作業の特性も知っておく(頻度が多い/少ない作業、リスクが低い/高いなどの区別)

参考書籍

まだ読めていませんが、運用業務を知るにはこの書籍が参考になりそうです。


プログラミングの基礎を身につける

Ansible のようなツールのみを使う場合は、プログラミング言語の知識はほとんど不要だが、動作を詳しく知ったり、カスタマイズする場合には必要。

  • 言語は Python がおすすめ
    • ネットワーク自動化のライブラリ(netmiko/NAPALMなど)がいくつかあるため。
  • 参考書を読んで分かった気にならない
  • 実際に読んで見る、書いてみる、動かしてみる。

参考書籍

Python はたくさん書籍が出版されていますが、以前私が Python の資格を受験するときはこの書籍を読みました。ボリュームが程よくてよかったです。

Pythonチュートリアル 第3版

Pythonチュートリアル 第3版

  • 作者:Guido van Rossum
  • 発売日: 2016/03/24
  • メディア: 単行本(ソフトカバー)


インターフェースやフォーマットについて理解する

どのようなツールやライブラリを利用するにしても、各種インターフェースやフォーマットを意識する必要がある。

  • CLIGUI 特徴、メリット、デメリットを知る
  • データフォーマット(JSON/YAML/XMLなど)を知る
  • REST API を知る
  • YANG、NETCONF、RESTCONF を知る

参考書籍・サイト

www.oreilly.com

Cisco が提供している無料の学習サイト developer.cisco.com


Ansible などの自動化ツールの基礎を身につける

簡単なことを簡単にすませるには自動化ツールが有効。

Cisco が提供している無料の学習サイト(再掲) developer.cisco.com


資格をとってみる

2020年2月から始まった Cisco Certified DevNet Associate。自動化やプログラマビリティを扱う。Cisco 依存は多くない。 www.cisco.com

tekunabe.hatenablog.jp

参考書籍

本記事執筆時は未発売ですが、公式はこちら。


ネットワーク自動化ライブラリで小さなモノを作る

自動化ツールが対応していないネットワークOSに対しては、コードで開所する必要がある

  • netmiko、NAPALM、nornir などのライブラリで、情報取得系、設定系それぞれ作ってみる

CLIの延長ではない世界に触れる

[Ansible] 記号類をURLエンコードする urlencode()

はじめに

@ などをURLエンコード%40%20)したいと思い、Ansible の Filter のページ を参照しましたが、それらしいフィルターはありませでした。 ならばと思って、Jinja2 のドキュメントを見ると urlencode() というフィルターがありました。

この記事では簡単なサンプルで紹介します。

  • 検証環境
    • Ansible 2.9.9
    • Jinja2 2.11.2

サンプル

---
- hosts: localhost
  gather_facts: false

  tasks:
    - name: debug 
      debug:
        msg: "{{ item | urlencode() }}"
      loop:
        - kingyo@example.com
        - Hello World

実行

$ ansible-playbook -i locahost, urlencode.yml 

PLAY [localhost] ****************************************************************************************************

TASK [debug] ********************************************************************************************************
ok: [localhost] => (item=kingyo@example.com) => {
    "msg": "kingyo%40example.com"
}
ok: [localhost] => (item=Hello World) => {
    "msg": "Hello%20World"
}

PLAY RECAP **********************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

@%40 に、$20 にURLエンコードされて表示されました。

おわりに

Ansible ドキュメントで目的のフィルターが見つからないときは、Jinja2のドキュメントを確認するのが吉です。

自動化に適したプログラマブルなホスト名を考える

はじめに

ホスト名の付け方には、視認性や区別のしやすさ向上等の目的で、様々な工夫をされているかと思います。

自動化を前提と場合に、何か考慮するべき点があるか考えてみたのまとめます。

多く分けて以下の 2点です。

  1. 機械的に読み込みやすくしておく
  2. 機械的に生成しやすくしておく

なお、ペットより家畜的に扱い、あまりホスト名を付ける意味さえない場合もあると思います。この記事である程度ペットのように扱う、ネットワーク機器のホスト名を想定しています。


■ 1. 機械的に読み込みやすくしておく

自動化するためには様々なデータを、人だけでなく、機械にやさしい状態にしておく必要があります。

そのためには、ホスト名の規則や文字種を決めておき、機械が読み込みやすくしておきます。

変数名やファイル名にも利用できる文字種にする

ホスト名を変数名やディクショナリのキーとして利用したり、ファイル名の一部にホスト名を埋め込むことがあります。 そのため、Ansible に限らず各処理系の「変数名やファイル名にも利用できる文字種にする」というのは一定の基準になります。

ファイル名として、避けるべき代表例は / です。ディレクトリの区切りとみなされるためです。特にこのような記号類には要注意です。

デリミタを予め決めておく

ここでいうデリミタとは、RT_01_ のように、意味のある単位に区切る文字のことです。 多くの場合は、-_ といった記号になるでしょう。このようなデリミタは予め決めておくのが良いです。

決めておけば機械的に処理する際に、シンプルな正規表現(またはより単純なパターンマッチ)でグルーピングや区別などがしやすくなります。

デリミタを何にするか

デリミタを - にするか _ にするかは流儀が分かれるかもしれません。

システム(名前解決など)によって利用できる記号が限られてたり、非推奨とされる記号があったりする場合は、それに従うのが良いでしょう。 全体としては _ より - のほうが制約を受けにくい印象があります。

なお、Ansible としては _ のほうが好まれる傾向があります。ホスト名と直接は関係ありませんが、具体的には以下の理由です。

グループ名のデリミタを _ にするのであれば、ホスト名も _ にするのが自然だろうという考え方もできます。また、気休めレベルですが、どこかで - がマイナスという演算子と判断されて、意図しない挙動することを防ぐ目的もあります。

他にも、1号機、2号機を示す、#1#2# も別の記号に置き換えたほうが安全で扱いやすいように思います。

(記事投稿後、Ansible の事情に偏りすぎていたので論調を変えました)

数値部分は固定長

RT1、RT2・・・RT9 の次が RT10 のように、数値部分の桁数がガタつくのは機械的に処理しにくくなりがちです。 各桁に意味持たせたり、ゼロパディングしたりして固定長にしておきます。

文字部分もできれば固定長

できれば、文字部分も固定長がよいでしょう。たとえば国名であれば、ISO 3166-1 という3文字で表記する規格があります。他にも、地域名、機器区分、機種名などの意味を持つ文字列がホスト名に含まれる。これらも固定長にできればすると扱いやすくなります。

機器区分を省略して固定長にする方法としては、Switch を SWFirewallFW のようにする方法などがあります。

ただし、無理に固定長にこだわりすぎて、直感的に分かりにくくなってしまうのは避けたいところです。 難しい場合は、平易な表現とデリミタを組み合わせると良いと思います。

ケースセンシティブ(大文字小文字を区別)に備える

手作業でホスト名を確認する際、大文字小文字はあまり意識しないかもしれません。 たとえば、実際のコンフィグが hostname rt01 だった場合、手作業の手順書にある「ログイン先が RT01 であること」という項目は OK になるのではないでしょうか。 また、rt01RT02 のようにホストによって大文字小文字が統一されてなくても、あまり不都合はなかったかもしれません。

ところが、自動化する場合は大文字小文字を区別される場面がが多いです。この認識のギャップがバグのもとになりえます。

コンフィグ上も資料上も、予め大文字小文字を区別して管理するのが良いでしょう。


■ 2. 機械的に生成しやすくしておく

自動化によってスケールしやすくなると、ホスト名自体も自動生成したくなるのではないでしょうか。

モノの名前だけでなく数値を組み合わせる

MoonJupiterMercury のようなモノの名前だけに頼ってホスト名を付けると、辞書(定義)が必要になって限界が来やすいです。

また、次のホスト名を決めずらい面もあります。 上記の場合、太陽に近い順といった定義をすればメンテナンスが煩雑になりがちになります。

それよりも、シンプルで明確な、数値を組み合わせるのが良いと思います。 数値であれば、基本的に数値を単純にカウントアップするだけです。

このあたりは、手作業の運用と勘所は同じかもしれません。


おわりに

この手のテーマは、地味ですがとても重要に思います。

一方で、ある種の設計要素の面もあるため、なかなか表に出て来ます。

みなさんがどのようにされているのか興味深く思います。