はじめに
ネットワーク機器の設定変更を自動化するあたって考慮するポイントの1つは、設定情報のインプットをどのような形式にするかです。
たとえば、機器が解釈できるコマンドを直接インプットする方法もあれば、パラメータシートのように人にも解釈しやすいものをインプットしてコマンドを生成する方法もあります。また、宣言的にインプットする方法もあれば、手続き的にインプットする方法もあります。 この記事では、設定情報のインプットを「範囲」「処理形式」「表現形式」の3つの観点で分類して、それぞれの特徴をまとめます。
なお、ネットワーク機器に CLI でコマンドを投入していく形式を想定しています。
■ 分類方法（3つの観点：範囲/処理形式/表現形式）
設定情報のイインプット形式を3つの観点で分類します。それぞれの観点について説明します。
・範囲（全体/部分）
どの範囲の設定内容か、という観点です。
全体
ネットワーク機器の設定全体を指定する形式です。
Cisco IOS のコンフィグであれば、show run で表示されるコンフィグの形式を指します。
version 16.8 service timestamps debug datetime msec service timestamps log datetime msec platform qfp utilization monitor load 80 no platform punt-keepalive disable-kernel-core platform console virtual ! hostname csr1000v (...略...) wsma agent exec ! wsma agent config ! wsma agent filesys ! wsma agent notify ! ! end
部分的
部分的に設定を指定する形式です。
ntp server 10.0.0.1 ntp server 10.0.0.2
・処理式形（宣言的/手続き的）
どのように設定内容を処理させるか、という観点です。
宣言的
「こういう設定状態であってほしい」と宣言型で指定して処理する形式です。指定する側にとっては、今の状態がどうなっているかはあまり意識しません。
たとえば、参照先 NTP サーバーの設定が、10.0.0.1、10.0.0.2、10.0.0.3、の3つがある状態から、
- ntp_servers: - 10.0.0.1 - 10.0.0.2
や
ntp server 10.0.0.1 ntp server 10.0.0.2
のような指定をすると、10.0.0.1、10.0.0.2、の2つになることを期待します。既存の設定にあった 10.0.0.3 が消えることがポイントです。
手続き的
このコマンドを実行（手続き）してほしい、という指定する形式です。 ネットワーク機器が解釈できるコマンドそのもので、手作業でコピペする時と同じイメージです。 手続きそのものですので、指定する側にとっては、今の状態がどうなっているかを強く意識する必要があります。
たとえば、参照先 NTP サーバーの設定が、10.0.0.1、10.0.0.2、10.0.0.3、の3つがある状態から、
ntp server 10.0.0.1 ntp server 10.0.0.2
のような指定をすると、10.0.0.1、10.0.0.2、10.0.0.3、の3つのままなることを期待します。no ntp server 10.0.0.3 を指定していないため、10.0.0.3 が残ったままになることがポイントです。
また、依存関係のある設定を正しい順序で追加したり、設定を削除する場合の no コマンドをあらかじめ準備する必要があります。
これら準備は、人が考えたり、パターン化したうで自動で生成する仕組みを作りこみます。
・表現式形（パラメーター/コンフィグ）
どのように設定内容を表現するか、という観点です。
パラメーター
YAML や JASON、Excel などで設定をパラメーターとして表現する形式です。これらのパラメーターは、コンフィグに変換してからネットワーク機器に投入します。 たとえば、YAML でパラメーターを表現すると以下のようになります。
- ntp_servers: - 10.0.0.1 - 10.0.0.2
コンフィグ
ネットワーク機器が解釈できるコンフィグそのものによって、設定を表現する形式です。
ntp server 10.0.0.1 ntp server 10.0.0.2
■ 各パターンの特徴
前述した 3つの観点で分類して、本記事での名称を以下に示します。
| No | 範囲 | 処理形式 | 表現形式 | 名称 | イメージ |
|---|---|---|---|---|---|
| 1 | 全体 | 宣言 | パラメーター | 全体宣言的パラメーター | 機器単位のパラメーターシート |
| 2 | 全体 | 宣言 | コンフィグ | 全体宣言的コンフィグ | 想定事後コンフィグ |
| - | 全体 | 手続き | パラメーター | 全体手続き的パラメーター | なし |
| - | 全体 | 手続き | コンフィグ | 全体宣言的コンフィグ | なし |
| 3 | 部分 | 宣言 | パラメーター | 部分宣言的パラメーター | 作業依頼単位のパラメーター |
| - | 部分 | 宣言 | コンフィグ | 部分宣言的コンフィグ | なし |
| - | 部分 | 手続き | パラメーター | 部分手続き的パラメーター | なし |
| 4 | 部分 | 手続き | コンフィグ | 部分手続き的コンフィグ | 作業用投入コンフィグ |
現時点で具体的なイメージが湧いたものに番号を付けました。
1~4 のインプット形式について、ぞれぞれ以下の点について説明します。
- インプット前に必要な準備（もちろんこれ自体もサブシステムしても可）
- 自動化システム内で処理すること
- コンフィグが正しく入ったか確認する方法
- ここでは状態（
show ip route結果など）ではなく、コンフィグそのものの確認 - この確認が必要かどうかはここでは取り上げません
- ここでは状態（
・[1] 全体宣言的パラメーター
機器全体の設定を定義した、パラメーターシートのようなイメージです。
- YAMLで指定する例
system: hostname: rt101 ntp_servers: - 10.0.0.1 - 10.0.0.2 interfaces: - name: GigabitEthernet0/0/1 description: to rt102 ipv4_address: 10.0.101.254/24 - name: GigabitEthernet0/0/2 description: to rt202 ipv4_address: 10.0.102.254/24 # (...略...)
インプット前に必要な準備
自動化システム内で処理すること
- パラメーターから投入コマンドの生成
noコマンドや、設定間の依存性に要注意- 生成したコンフィグを投入
コンフィグが正しく入ったか確認する方法
- インプットから生成したコンフィグと事後のコンフィグが一致していること
・[2] 全体宣言的コンフィグ
「全体としてこのコンフィグの状態にしてほしい」と指定します。git でコンフィグ全体を管理していて「こうなってほしい」というコンフィグに変更してコミットするのもこのパターンです。
version 16.8 service timestamps debug datetime msec service timestamps log datetime msec platform qfp utilization monitor load 80 no platform punt-keepalive disable-kernel-core platform console virtual ! hostname csr1000v (...略...) ntp server 10.0.0.1 ntp server 10.0.0.2 (...略...) wsma agent exec ! wsma agent config ! wsma agent filesys ! wsma agent notify ! ! end
インプット前に必要な準備
- ゴールとなる、あるべき姿のコンフィグ
自動化システム内で処理すること
- 現在のコンフィグと、指定した全体的宣言コンフィグの差分を生成
- または、コンフィグをアトミックに切り替えられる機器であれば不要
noコマンドや、設定間の依存性に要注意- 生成したコンフィグを投入
- コンフィグをアトミックに切り替えられる機器であれば、切り替え
コンフィグが正しく入ったか確認する方法
- インプットのコンフィグと事後のコンフィグが一致していること
・[3] 部分宣言的パラメーター
部分的な設定を「こうあってほしい」という表現でパラメータで表現するパターンです。機器全体の現状の設定を知らず、各部署から設定変更依頼がパラメーターでくる場合もこのパターンです。
- yaml で指定する例
- ntp_servers: - 10.0.0.1 - 10.0.0.2
インプット前に必要な準備
- 統一されたフォーマットの設定パラメーター
自動化システム内で処理すること
- パラメーターから投入コマンドの生成
noコマンドや、設定間の依存性に要注意
コンフィグが正しく入ったか確認する方法
- インプットから生成したコンフィグが処理され、追加、変更、削除後に宣言した通りの設定になること
- 例（追加）
- 事前設定状態: A, B
- 宣言パラメーター: A, B, C
- 処理: 投入コマンドとして差分「C」を生成して投入
- 事後設定状態： A, B, C
- 確認:
- 宣言パラメーター「A, B, C」と事後設定状態「A, B, C」が一致すること
- 差分「C」が事後設定状態「A, B, C」に含まれること
・[4] 部分手続き的コンフィグ
手順化した作業用投入コンフィグのイメージです。手作業するときに、コピペ用に準備するようなものと同じようなものです。
ntp server 10.0.0.1 ntp server 10.0.0.2
インプット前に必要な準備
- 設定、削除、依存性に考慮して手順化したコンフィグを生成
自動化システム内で処理すること
- 生成したコンフィグを投入
コンフィグが正しく入ったか確認する方法
- 事前状態に手続きコンフィグをマージ（追加、変更、削除）した結果と、事後設定状態が同じこと
- マージのロジックはプログラム側で独自実装する必要がある
- 例（追加）
- 事前設定状態: A, B
- 手続きコンフィグ: C
- 処理: 手続きコンフィグ通り「C」を投入
- 事後設定状態： A, B, C
- 確認:
- 事前設定状態「A, B」と手続きコンフィグ「C」をマージした結果と、事後設定状態「A, B, C」が同じであること
- 手続きコンフィグ「C」が事後設定状態「A, B, C」に含まれること
■ まとめ
ネットワーク設定自動化に必要な設定情報のインプットをどのような形式を、範囲、処理形式、表現形式によって分類しました。
それぞれ、あらかじめ準備することが異なりますので、どのような形式のインプットかを意識して設計すると良いと思います。
