はじめに

こんにちは, IT基盤部ネットワークグループ(NOC)のnagiです.

NOCでは, データセンタ, オフィス, 横浜スタジアムなどの数十拠点のネットワークを運用しています. 個々の拠点の規模感は大小様々ではありますが, すべてを合わせると管理するべきネットワーク機器の台数は膨大になります.

これらの機器のconfigは, RANCID¹を用いた日次バックアップによって管理されていました. RANCIDは, 機器からconfigを丸々取得し保存することができますが, 生のconfigをそのまま保存するため, ツールでの活用は面倒なものでした. そこでより保守性を高めつつ, 自動化を推進するための第一ステップとして, config管理ツール"“nwcli"“を内製しました. nwcliを開発したことで, 機器configをより扱いやすいデータ構造のYAMLで管理することができるようになりました. また機器の設定監視や設定一括投入も可能になりました.

本記事では, nwcli開発の背景, 構成, 運用例について紹介します.

開発背景

機器のconfig管理に関しては, 以下の課題がありました.

背景も変更者も分からない謎設定が残っている

例えば, 日々の定常オペレーションの一つにポート設定の変更があります. 原則すべてのポートにはdot1x認証が施されています. しかし, 認証方法が異なる機器(検証機やPOS端末など)の接続の際には, 都度申請を利用者に起票してもらい, NOCが必要な設定を投入しています. 設定変更依頼には, 一時利用も多く含まれています. 利用終了時の切り戻しを忘れると, 意図が分からない設定が留置されてしまいます.

新規拠点構築時の設定漏れ/不要設定留置

新規の拠点ネットワーク構築時は, 手作業で真心をこめて手順書を作成するため, どうしても設定漏れ等が発生しがちです. また手順書を作る際, 0からではなく既存機器の設定をコピーしてから編集することもよくあります. そのとき不要な設定がそのまま引き継がれてしまう場合があります.

複数機器に対して設定を一括投入する手段がない

現在NOC内には複数機器に対して設定を一括投入する手段がありません(個々でスクリプトを作成する場合はありますが…). 機器キッティング時や, SyslogやRadiusサーバの設定変更時には, 大きく工数が取られてしまう状態です.

構成

システム構成

まず簡易的な構成図を以下に示します.

nwcliはAnsibleをラップしたツールとなっています. AnsibleはPython製の構成管理ツールです. サーバでの利用例が目立ちますが, ネットワーク機器でも利用可能です. AnsibleのPlaybookに必要設定を記述しGit管理することで, 変更の履歴を手軽に追従できるようにします. またAnsibleでは複数機器に対して並列接続をし, 設定を一括投入することが可能です. CI/CDにはGithub Actionsを用いています.

nwcliはCLIツールと踏み台サーバに常駐するデーモンの2つで構成されています. CLIツール内部のLinterでPlaybookの検査を実施し, 問題がなければデーモン側でAnsible実行とAnalyzerによる実行結果解析²を実施します. このとき実行ブランチが開発ブランチの場合は, check mode(dryrun)でAnsibleを実行します. masterにマージされるタイミングで設定の本適用が走ります.

解析結果は, リポジトリにコミットされます. 解析結果をファイルに出力することで, プルリク上でレビューを可能にします. また該当ブランチのプルリクに対してコメントも投下します.

Linter

Playbookに誤りがないかを検査するLinterでは, 設定の不整合や機器configの誤りをチェックします. 設定の不整合とは, 例えばLAGのメンバーインタフェース間での設定差異などです. 誤りチェックにはCUE³を用います.

CUEは, Schema定義言語で, データのバリデーションや変換が可能です. 予め必要なフィールドをCUEで定義し, 実際のPlaybookの設定(=YAML)と突き合わせることで誤りを検知します.

以下はInterface定義の一部を抜粋したものになります.

#Interface: {
    index: string
    description?: {
        edge: *false | true
        neighbor: {
            name: string
        }
        if !edge {
            neighbor: {
                port: string
                port_prefix: string
            }
        }
    }
    speed?: 10 | 100 | 1000
    switchport?: {
        mode: "access" | "trunk"
        if mode == "access" {
            vlan: int
        }
        if mode == "trunk" {
            native_vlan: *0 | int
            allowed_vlans?: [...int]
        }

Analyzer

ログ解析では2つの情報を抽出します.

• Playbookに未実装なコマンド (未実装コマンド)
• 機器で実行されるコマンド (実行コマンド)

未実装コマンドは, 機器のconfigには存在するがPlaybook内の設定には存在しないコマンドです. つまり変更の追従ができていない設定となり, 機器側の設定を消すかPlaybookに追加するかの対応が必要となってきます. 未実装コマンドの導出方法ですが, 特に難しいことはしておらず, 機器configと実行結果に含まれるコマンドをひたすら比較する力技で実装しています.

実行コマンドは名前の通りで, Playbookを適用することで新規に投入されるコマンドになります.

Ansibleではタスクの実行結果で変更があった場合は, changedフラグが立ちますが, そちらの情報は利用せずAnalyzerの解析結果で変更有無を判断します. フラグ情報を利用しない理由は, 一部モジュールで実際にconfigが変更されていないのに, changedフラグが立つことがあるためです. 例えばconfigの保存モジュールがそれに該当します.

Playbook構成

Playbookの構成についても簡単に紹介します. 基本的には拠点毎に分割してPlaybookを作成しており, 拠点Playbookから拠点Roleを呼び出しています. 拠点Roleでは, ホストごとに独立した変数ファイルを持ち, そこに機器設定を記述しています. 以下は本構成を図示したものです.

|- playbooks
|   |- site1.yml
|   |- site2.yml
|- roles
|   |- site1
|      |- vars
|         |- host1.yml
|         |- host2.yml
|      |- tasks
|         |- main.yml

またRolesには拠点Roleだけではなく, 機器の共通設定をまとめたテンプレートRoleもあります. テンプレートRoleは, Cisco IOS Switch, Juniper SRXなどの機器の種類で分けています. テンプレートRoleは, 拠点Role内のホスト変数(roles/site1/vars/host1.ymlなど)に記述することで読み込まれるように, Playbookを実装しています.

template_role: "_cisco_ios/_template_c2960"
interfaces:
  GigaEthernet1/0/1:

運用

実際の運用例についても紹介します.

現在nwcliを日次でGithub Actionsのworkflow(scheduleトリガー)で実行しています 定期実行はcheck modeで実行され, 全拠点機器に対して実施されます. この定期実行により, 現在の機器configとPlaybookの実装に差分がないかを確認しています. 差分があった場合は, プルリクが自動起票されます. プルリクが起票された場合は, 心当たりがある担当者が修正し差分を排除します. このプルリクが閉じられるまで, NOCメンバーは退勤することができません⁴.

まとめ

今回は, NOC内で開発したconfig管理ツールnwcliについて紹介しました.

以下3点の課題がありましたが, いずれもAnsibleとGithubの活用により解決ができました.

• ✅ 背景も変更者も分からない謎な設定が残っている.
  • Gitの履歴, YAMLでのコメントで管理可能
  • 定期差分確認により設定の除去漏れを防止
• ✅ 新規拠点構築時の設定漏れ/不要設定留置
  • テンプレートRoleを作成し共通設定を一元管理
• ✅ 複数機器に対して設定を一括投入する手段がない
  • Ansibleで並列接続をし一括投入可能

運用がスタートしたばかりで, まだまだ改善の余地はありますが, 今後も開発を続けていきます. 大きなアップデートがあればまた記事にしたいと思います. 長々とした記事でしたが, ここまで読んでいただきありがとうございました.