CML2を使いこなす。（その11：Node Definitionsの設定）

# はじめに
`CML2`にはCisco機器のOSイメージ以外に、`Alpine`や`Ubuntu`等のサーバ用イメージも標準で付属されていますが、`Windows`のマシンイメージや`RHEL`系のマシンイメージは付属されておりません。

標準で付属しているマシンイメージでは足りない場合に、独自のカスタムイメージを導入する方法を紹介しようと思います。

- 【前】[CML2を使いこなす。（その10：ホストマシンへのSSH接続）](https://qiita.com/sakai00kou/items/47d49b525b1014052aef)
- 【次】[CML2を使いこなす。（その12：カスタムイメージの導入）](https://qiita.com/sakai00kou/items/343d3e5782c164367dde)

# カスタムイメージについて
`CML2`では`KVM`等のディスクイメージとして使われる`qcow`、`qcow2`のファイル形式に対応しています。

最近はISOのディスクイメージだけではなく、クラウド用のイメージとして`qcow2`の形式で公開されているOSも多いことから、`qcow2`形式で公開されている最新のOSを`CML2`に導入したり、独自で作成したKVMのイメージを使ったりすることができるようになっています。

# カスタムイメージ登録方法
カスタムイメージを登録するためにはカスタムイメージのアップロード、カスタムイメージ用の設定情報の作成とカスタムイメージの情報登録が必要となります。

カスタムイメージ用の設定情報（`Node Definitions`）とカスタムイメージの登録情報（`Image Definitions`）は内部的には`yaml`のファイル形式で設定されており、`Node Definitions`については前もって準備しておけばファイルをインポートすることも可能です。

|内容|ファイル形式|
|:--|:--|
|カスタムイメージ|qcow,qcow2|
|Node Definitions|yaml（インポート可）|
|Image Definitions|yaml（インポート不可）|

今回は以下で公開されている`CentOS`のクラウドイメージを登録してみます。

【CentOS8クラウドイメージ 】
https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.4.2105-20210603.0.x86_64.qcow2

## Node Definitions設定の構成
`Node Definitions`を登録するといっても設定項目がたくさんあり、初見では何をどのように登録すればよいか分かりづらいため、デフォルトで登録されている`Ubuntu`の設定を見ながら読み解いていこうと思います。

尚、以下項目は`CML2`の管理画面から`TOOLS`→`Node and Image Definitions`→`Ubuntu`より確認できます。

各項目の詳細は以下公式ドキュメントを参照。

- [Creating A New Node Definition](https://developer.cisco.com/docs/modeling-labs/#!creating-a-new-node-definition)

### General

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|ID|ubuntu|内部ID。**画面表示名ではない**|
|Description|Ubuntu Cloud Init Platform|Node Definitionsに表示されるコメント|
|Nature|server|ノード種別|
|Available image definitions|UBUNTU 20.04 - 24 FEB 2021|紐付けられているImage Definitions名|

一番最初の項目になるので、`ID`が画面表示される際の名前と思いきや、**画面表示名ではありません**。

どうやら`CML2`ホストの`/var/lib/libvirt/image/node-definitions/`配下に作成される`Node Definitions`のYamlファイル名として使われるようです。

`Nature`は特にどれを選んでも動作に影響は無いようですが、どのような種別のノードなのかを判断するために指定するようです。

### User Interface

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|Visible|有効|ADD NODESでの表示項目を減らす？|
|Description (Markdown)|※下記参照|ADD NODESで表示されるコメント|
|Prefix|ubuntu-|Workbench上のノードプレフィックス|
|Icon|server|画面上アイコンの種類|
|Label|Ubuntu|**Node Definitionsに表示される表示名**|

`Visible`は`Workbench`画面の`ADD NODES`で表示される項目数の表示有無の設定のようですが、設定の違いが分かりませんでした・・・

`Description (Markdown)`は以下`ADD NODES`でカーソルをノードに合わせたときに表示されるコメントになり、マークダウン形式で記載することができます。

![capture_16082021_071555.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569912/72647cb8-0600-2f3e-403f-7d518d84f3e8.jpeg)


`Prefix`は`Workbench`上にノードを配置した際に表示されるノード名を示しており、ハイフンの後ろにノードの番号が付与されます。

`Label`は**Node Definitions画面で表示される表示名**となるため、ユーザが見たときに分かりやすい名前にするのが良いでしょう。

### Linux Native Simulation

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|Domain Driver|KVM|仮想化ドライバ|
|Simulation Driver|server|シミュレーションドライバ|
|Disk Driver|VirtIO|ディスクドライバ|
|Memory|2048MiB|メモリサイズ|
|CPUs|1|CPU数|
|CPU Limit|- (100%)|最大CPU使用率|
|Network Driver|VirtIO|ネットワークドライバ|
|Data Disk Size|0GiB|データ用ディスクサイズ|
|Boot Disk Size|64GiB|ブート用ディスクサイズ|
|Video Model|No Video Adapter|ビデオカード設定|
|Video Memory|-|ビデオメモリサイズ|

`KVM`等で仮想マシンを作成する際にも設定する各種ドライバ設定となります。

`Simulation Driver`はドライバ種別を指定するようですが、サーバ用途なら`server`を選択しておけば問題ないかと思われます。

CPUやメモリは使うイメージに合わせて設定、ディスクサイズは1ディスクで問題なければ`Data Disk Size`には入力せず、`Boot Disk Size`のみサイズを入力するようにします。

`CPU Limit`は`Ubuntu`では値無しとなっていますが、ユーザが登録する場合は20～100%の範囲で設定しないと登録できないようなので、100%（制限なし）とします。

### Interfaces

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|Has a Loopback Interface|無効|ループバックインタフェースの要否|
|Number of serial ports|1|シリアルポート番号|
|Default number of physical interfaces|1||
|インタフェース名|ens3～ens10|使用可能なインタフェース数|

`Has a Loopback Interface`はループバックインタフェースが必要な場合に有効にする設定となりますが、Cisco系ノードの設定時のみ必要となる設定のため、Cisco系ノード以外では無効にしておきます。

`Number of serial ports`はシリアルポート数の指定となり、指定数分シリアルポートが作成されます。

`Default number of physical interfaces`はデフォルトで作成されるインタフェース数となりますが、`Workbench`上で「**インタフェース名**」で指定した数分、接続＆設定することができるため、サーバ系では数にあまり意味が無いようです。

Cisco系ノードの場合は未接続ポートのコンフィグが生成されないため、`show running-config`等で出力されるコンフィグを減らすことができます。

`インタフェース名`は`Workbench`で別の機器とポート接続する際に表示されるポート数とポートの表示名となります。

以下のように画面上で表示される名前とポート数を示すだけのようなので、実際のインタフェース名と合わせる必要はありません。

![capture_15082021_175234.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569912/aad6257b-0b43-63b2-6de1-05e89ebee767.jpeg)

### Boot

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|Timeout|180 seconds|タイムアウト時間|
|Boot文字列1|Cloud-init target|ブート完了と見なす文字列|
|Boot文字列2|Welcome to Ubuntu|ブート完了と見なす文字列|
|Boot文字列3|running 'modules final' at|ブート完了と見なす文字列|

`CML2`では`Boot`が正常に完了したかを確認するために、コンソールに表示される文字列をOR条件でチェックしており、指定した文字列が表示されたらブートシーケンスが完了したと判断しています。

また、上記文字列が確認できなかった場合は`Timeout`秒数分経過した後、正常に起動完了したとみなします。

上記の場合、**Boot文字列1～Boot文字列3**のいずれかがコンソール上に表示された場合、もしくは`Timeout`秒数分経過したら正常に起動したとみなし、`Workbench`上のノードステータスを**起動中**に遷移させます。

尚、起動完了を判断するための**Boot文字列**は設定しなくても問題ありませんが、`Timeout`は必須項目となっているため、仮想マシンの起動時間を考慮して適当な値を設定します。

### pyATS (optional)

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|Enable pyATS|有効|pyATSの有効化|
|Use in Testbed|有効|テストベッドでの使用有無|
|Operating System|linux|OS種別|
|Series|-|シリーズ名|
|Model|-|モデル名|
|Username|-|ログインユーザ名|
|Password|-|パスワード|
|Config extract command|-||

本項目は`pyATS`を使用する場合に設定するログイン情報や実行コマンドを設定する項目となり、`pyATS`を使用しないなら不要となるものとなります。

`pyATS`は使ったことが無いため詳細は割愛しますが、正常性確認を自動化するツールとなるようです。

### Property Inheritance

**Image Definition**

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|RAM|有効|Image Definitionsの値の継承|
|CPUs|有効|Image Definitionsの値の継承|
|CPU Limit|有効|Image Definitionsの値の継承|
|Boot Disk Size|有効|Image Definitionsの値の継承|
|Data Disk Size|有効|Image Definitionsの値の継承|

**Per-node**

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|RAM|有効|ノード個別の値の継承|
|CPUs|有効|ノード個別の値の継承|
|CPU Limit|有効|ノード個別の値の継承|
|Boot Disk Size|有効|ノード個別の値の継承|
|Data Disk Size|有効|ノード個別の値の継承|

各種リソース情報について、何を継承するかを示す項目となります。

`CML2`では最初に`Workbench`に配置されたノードに個別定義しているリソース情報が無いかを確認し、次に`Image Definitions`で定義された値をチェック、最後に`Node Definitions`で定義された値を使用する仕様となっています。

`Cisco`系では1つの`Node Definitions`に複数の`Image Definitions`が結びついている定義があるため、各バージョンでリソースの使用量を使い分けたい場合に有用です。

### Configuration

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|Configuration Generator|-|**Build Initial Bootstrap Configurations**をクリックしたときに生成されるコンフィグを使用するかどうか。

ラボの「**DESIGN**」にある「**BUILD INITIAL BOOTSTRAP CONFIGURATIONS**」を選択したときに既定のコンフィグを使用するかの設定。

以下スクリーンショットの通り、特定のノードタイプしか選べませんが、タイプを指定して「**BUILD INITIAL BOOTSTRAP CONFIGURATIONS**」を選択することである程度基本的な設定がされたコンフィグ（例えばユーザ、パスワード設定等）を読み込ませることができます。

![capture_18082021_074009.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569912/9bc58bd0-ddf9-a6af-7d3b-4f7a6c19255a.jpeg)

### Provisioning

|項目名|Ubuntuでの設定例|説明|
|:--|:--|:--|
|Enable provisioning|有効|初回起動時のプロビジョニングを有効にするか|
|Media Type|ISO|メディアタイプ|
|Configuration Disk Volume Name|cidata|Media Typeで指定したボリュームのボリューム名|
|Name|meta-data|ファイル名|
|Editable|無効||
|Content|※下記参照|ファイルの内容|
|Name|user-data|ファイル名|
|Editable|有効||
|Content|※下記参照|ファイルの内容|

```yaml:meta-dataの内容
instance-id: ubuntu
local-hostname: ubuntu
```

```yaml:user-dataの内容
#cloud-config
hostname: inserthostname_here
manage_etc_hosts: True
system_info:
  default_user:
    name: cisco
password: cisco
chpasswd: { expire: False }
ssh_pwauth: True
ssh_authorized_keys:
   - your-ssh-pubkey-line-goes-here
```

初回起動時に実行する自動構成機能を使うかの設定。

`Ubuntu`の場合はISO形式のボリュームを読み込み、`cloud-init`を実行するような設定が定義されています。

# おわりに
長くなったので、今回は`Node Definitions`の説明までとします。

次回は実際に`CentOS`のカスタムイメージを登録してみようと思います。