マルチベンダー・ネットワーク自動化：NAPALMとPythonでCLIの煩わしさから解放されよう

Table of Contents

マルチベンダーCLIの悪夢

単一ベンダーのネットワーク管理だけでも十分に大変です。しかし現実には、ほとんどの本番環境のラックはCisco IOS、Juniper Junos、Arista EOSが混在した「ベスト・オブ・ブリード」構成になっています。これは通常、基本的なVLAN変更を行うだけでも、ベンダーごとに3つの異なるチートシートを手元に置いておく必要があることを意味します。各ベンダーには独自の構文、コミット方法、そしてインターフェースの状態を確認するといった単純なタスクでさえ、それぞれ異なる煩雑な出力形式が存在します。

前四半期、私のチームは監査中のポート状態を確認するためだけに、showコマンドからテキストをパースする作業に毎週15時間近くを費やしていました。それは退屈でミスが起きやすい作業でした。これを解決するために、私たちはワークフローにNAPALMを導入しました。このモデルに移行して以来、設定の一貫性は飛躍的に向上しました。今では、インフラを「個別に手動設定された一点もの（スノーフレーク）」としてではなく、バージョニングされたコードとして扱っています。

コアコンセプト：なぜNAPALMなのか？

NAPALMは「Network Automation and Programmability Abstraction Layer with Multivendor support」の略称です。ネットワークハードウェアのための「万能翻訳機」だと考えてください。Cisco CatalystとJuniper MXのために別々のスクリプトを書く代わりに、1つのPythonスクリプトを書くだけで済みます。NAPALMがデバイスへの接続や、リクエストを各ベンダー固有の言語に翻訳するといった面倒な処理をすべて引き受けてくれます。

1. 抽象化レイヤー

NAPALMの最大の利点は「Getters」です。デバイスの稼働時間（uptime）やシリアル番号を確認したい場合は、get_facts()を呼び出すだけです。対象がCisco ISRでもAristaのスイッチでも関係ありません。NAPALMは常に標準化されたPythonの辞書形式を返します。これにより、大量のテキストの中からMACアドレスを見つけ出すためだけに、200行もの複雑な正規表現（Regex）を書く手間から解放されます。

2. 設定管理

NAPALMは単にデータを読み取るだけではありません。デバイスの実際の状態も管理します。主に2つのメソッドをサポートしています。小さなスニペットを追加するためのMerge（マージ）と、設定を既知の正常なテンプレートで上書きするためのReplace（リプレース）です。さらに重要なのは、セーフティネットとして機能するcompare_config()機能です。これは、コミットする前に何が変更されるかを正確に示してくれます。もし変更によって接続が切れてしまった場合でも、rollback()機能を使えば数秒でデバイスを前の状態に戻すことができます。

ハンズオン：環境構築

導入は非常に簡単です。Python 3.6以降と、使用するハードウェアに対応した特定のドライバライブラリが必要です。依存関係をクリーンに保つために、仮想環境（venv）の使用をお勧めします。

# ワークスペースのセットアップ
python3 -m venv napalm-env
source napalm-env/bin/activate

# ライブラリのインストール
pip install napalm

スクリプトを実行する前に、ハードウェアのAPIが準備できているか確認してください。Cisco IOSの場合はSSHが有効であることを確認します。AristaデバイスはeAPIの有効化が必要で、Juniper機器はNETCONFをオンにする必要があります。

接続とデータ取得

Ciscoルーターから基本情報を取得するスクリプトを見てみましょう。ドライバを定義した後のロジックがいかにシンプルであるかに注目してください。

from napalm import get_network_driver
import json

# 'ios'、'junos'、または 'eos' を指定
driver = get_network_driver('ios')
device = driver(hostname='10.1.1.50', username='admin', password='secure_password')

print("接続を開始します...")
device.open()

# 標準化されたメソッドを使用してデータを取得
facts = device.get_facts()

# 結果を出力
print(json.dumps(facts, indent=4))

device.close()

'ios'を'junos'に入れ替えてIPアドレスを更新しても、get_facts()メソッドは同じデータ構造を返します。ハードウェアのブランドに関係なく、自動化ロジックは同一のままです。

設定変更の自動化

本当の価値は、変更を流し込むときに発揮されます。この例では、Merge戦略を使用してインターフェースの説明（description）を更新します。これは通常、フルリプレースよりも日常的な運用において安全な方法です。

from napalm import get_network_driver

driver = get_network_driver('ios')
device = driver('10.1.1.50', 'admin', 'secure_password')
device.open()

print("設定をステージング中...")
device.load_merge_candidate(config='interface GigabitEthernet1\n description Link_to_Core')

# 'diff' はこれから何が起こるかを表示します
diff = device.compare_config()

if diff:
    print("保留中の変更:\n" + diff)
    
    confirm = input("これらの変更をコミットしますか？ (y/n): ")
    if confirm.lower() == 'y':
        device.commit_config()
        print("完了しました。")
    else:
        device.discard_config()
else:
    print("変更は検出されませんでした。")

device.close()

本番環境において、このdiff出力は命綱となります。深夜の緊急電話につながるような、いわゆる「タイプミス」を防ぐことができます。

ロールバックというセーフティネット

どんなに完璧な計画を立てても、ミスは起こります。私が本番環境でNAPALMを信頼している理由の一つは、rollback()関数にあります。コミットが完了した後に監視システムが遅延のスパイクを検知し始めた場合、即座に元に戻すことができます。

try:
    # ここで事後確認スクリプトを実行
    validate_ospf_neighbor_count()
except Exception as e:
    print(f"アラート: {e}。前の状態にロールバックします！")
    device.rollback()

Cisco IOSの場合、NAPALMは設定をアーカイブすることでこれをシミュレートすることに注意してください。Juniperでは、OSに組み込まれたネイティブのrollbackアーキテクチャを使用します。

本番環境から得た教訓

半年間、毎日使用してきた中で、スクリプトをより堅牢にするためのいくつかの方法を見つけました。

パスワードのハードコーディングをやめる: os.environやHashiCorp Vaultのようなツールを使用してください。Gitの履歴にネットワークの認証情報を含めてはいけません。
タイムアウトの調整: 古いCisco ISR 4000などでの大規模な設定変更は時間がかかることがあります。予期せぬ切断を防ぐために、ドライバのtimeoutパラメータを60秒または90秒に増やしてください。
監査ログを残す: compare_config()の出力を常に中央ファイルにログとして記録しましょう。「いつ、誰が、何を変更したか」を正確に把握するのに役立ちます。
状態の検証: コミットを信用するだけでは不十分です。get_bgp_neighbors()などを実行して、変更後にルーティングテーブルが消失していないことを確認してください。

次のステップへ

手動のCLI作業からPythonによる自動化へ移行するのは、最初は険しい道のりに感じるかもしれません。しかし、それによって得られる一貫性は、学習の苦労に見合う価値があります。ベンダーごとの癖を抽象化することで、コマンドの構文を暗記するのではなく、ハイレベルなネットワーク設計に集中できるようになります。小規模なオフィスを管理している場合でも、広大なデータセンターを管理している場合でも、設定管理の統合は現代のインフラ構築において不可欠なステップです。