【Ansible応用講座 第7回】ネットワーク機器の自動化。Cisco/Juniperスイッチの設定管理とバックアップ戦略

「サーバーはコード化した。でも、スイッチは手動ですか？」

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、Windows Serverの自動化について解説しました。

さて、サーバーの構築はAnsibleで爆速になりました。
しかし、そのサーバーを繋ぐ「ネットワーク機器（スイッチ、ルーター、ファイアウォール）」はどうでしょうか？
「VLANの設定変更依頼？ あー、ネットワーク担当のAさんがExcelの台帳を見ながら、TeraTermマクロで来週やるって」
…これでは、ビジネスのスピード感が台無しです。

本記事では、AlmaLinux 9 をコントロールノードとし、ターゲットとなるネットワーク機器（Cisco IOS / Juniper Junos）に対して、設定変更やConfigバックアップを自動化する手順を徹底解説します。

---

第1章：ネットワーク自動化の壁とAnsibleの仕組み

サーバー管理とネットワーク管理には、決定的な違いがあります。

1. エージェントレスの真価

LinuxサーバーならPythonスクリプトを送り込んで実行できますが、ネットワーク機器（スイッチやルーター）は独自のOSで動いており、Pythonをインストールしたりファイルを転送したりすることができません。
そこでAnsibleは、「ローカル（コントロールノード上）でモジュールを実行し、SSH経由でCLIコマンドを送信して、結果をパースする」という方式をとります。

2. network_cli 接続プラグイン

この通信方式を実現するのが ansible_connection: network_cli です。
通常のSSH接続（sftp使用）とは異なり、対話的なシェル操作を自動化するように振る舞います。

3. コレクションの導入

ネットワーク機器向けの機能は、各ベンダーが提供する「コレクション」として配布されています。
まずはこれらをインストールします。

# Cisco IOS用
ansible-galaxy collection install cisco.ios

# Juniper Junos用
ansible-galaxy collection install junipernetworks.junos

# 汎用ネットワークモジュール（念のため）
ansible-galaxy collection install ansible.netcommon

---

第2章：インベントリと接続設定

ネットワーク機器への接続には、OS種類の指定など固有のパラメータが必要です。
group_vars を使って定義します。

inventory.yml

all:
  children:
    switches:
      children:
        cisco_switches:
          hosts:
            switch01.example.com:
        juniper_switches:
          hosts:
            switch02.example.com:

group_vars/cisco_switches.yml

ansible_connection: network_cli
ansible_network_os: cisco.ios.ios
ansible_user: admin
ansible_ssh_pass: "CiscoPass123!"
# 特権モード(enable)への昇格設定
ansible_become: yes
ansible_become_method: enable
ansible_become_pass: "EnablePass123!"

group_vars/juniper_switches.yml

ansible_connection: network_cli
ansible_network_os: junipernetworks.junos.junos
ansible_user: admin
ansible_ssh_pass: "JuniperPass123!"

---

第3章：Cisco IOSスイッチの操作 (cisco.ios)

まずは世界で最も普及している Cisco IOS の操作から始めます。

1. 情報収集 (Facts)

cisco.ios.ios_facts モジュールを使うと、機器のバージョンやシリアル番号、インターフェース情報などを構造化データ（JSON）として取得できます。

- name: Gather Facts
  cisco.ios.ios_facts:
    gather_subset: all
  register: switch_facts

- name: Debug Facts
  debug:
    var: switch_facts

これで「バージョンごとの在庫管理」などが自動化できます。

2. 設定変更 (ios_config)

ios_config モジュールは、コンフィグモードに入って設定を変更します。
VLANを作成する例です。

- name: Create VLAN 100
  cisco.ios.ios_config:
    lines:
      - name VLAN_Marketing
    parents: vlan 100
    # 実行前に差分があるか確認し、なければ実行しない（冪等性）

3. Configバックアップ (ios_config backup)

これが最も実用的な機能です。
設定変更をする前に、現在の running-config を自動でバックアップしてくれます。

- name: Save running-config with backup
  cisco.ios.ios_config:
    backup: yes
    backup_options:
      filename: "backup_{{ inventory_hostname }}_{{ ansible_date_time.iso8601 }}.cfg"
      dir_path: ./backups/

定期実行（Cron + Ansible）すれば、Git管理されたコンフィグ自動バックアップシステムの完成です。

---

第4章：Juniper Junosスイッチの操作 (junipernetworks.junos)

JuniperなどのモダンなOSは、「設定を変更して、コミット（Commit）して初めて反映される」という仕組みを持っています。
Ansibleもこれに対応しています。

設定変更とコミット (junos_config)

- name: Configure Interface
  junipernetworks.junos.junos_config:
    lines:
      - set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.1/24
    comment: "Configured by Ansible"
    confirm: 5  # "commit confirmed 5" と同等！

プロの技： confirm オプションを指定すると、「設定反映後、一定時間内に確定操作がなければ自動ロールバック」されます。
これは、遠隔作業で設定ミスによりSSH接続が切れてしまった場合の命綱になります。

---

第5章：【実践】マルチベンダー対応Playbook

「CiscoとJuniperが混在している環境で、一括でSNMPサーバーの設定を入れたい」
そんな時は、group_vars と変数を活用して、ベンダーの差異を吸収します。

Playbook (setup_snmp.yml)

---
- name: Setup SNMP Server
  hosts: switches
  gather_facts: no
  vars:
    snmp_community: "public_ro"

  tasks:
    # Cisco用タスク
    - name: Configure SNMP (Cisco)
      cisco.ios.ios_config:
        lines:
          - snmp-server community {{ snmp_community }} RO
      when: ansible_network_os == 'cisco.ios.ios'

    # Juniper用タスク
    - name: Configure SNMP (Juniper)
      junipernetworks.junos.junos_config:
        lines:
          - set snmp community {{ snmp_community }} authorization read-only
      when: ansible_network_os == 'junipernetworks.junos.junos'

ansible_network_os 変数（インベントリで定義済み）を使って条件分岐することで、1つのPlaybookで複数ベンダーに対応できます。

---

第6章：冪等性と「Config差分」の扱い

ネットワーク自動化で最も難しいのが「冪等性の担保」です。
ios_config モジュールは優秀で、「現在の設定と投入する設定を比較し、差分がある時だけコマンドを実行する」ように動きます。

Check Mode (Dry Run) の活用

本番適用前に「何が変わるか」を確認することは必須です。

ansible-playbook setup_snmp.yml --check --diff

--diff オプションをつけると、実際に投入されるコマンドや、コンフィグのBefore/Afterが表示されます。
これを見て、意図しない設定変更（全ポートシャットダウンなど！）が含まれていないかを確認します。

---

第7章：トラブルシューティング

ネットワーク特有のエラーと対策です。

Q1. “Connection timed out” で接続できない

原因: SSHが許可されていない、またはACLでブロックされている。
対策: 手動SSHで接続できるか確認してください。また、コントロールノードのIPが機器のACLで許可されているか確認してください。

Q2. “operation requires privilege escalation”

原因: Cisco機器で特権モード（Enable）に入っていない。
対策: インベントリ変数で ansible_become: yes と ansible_become_method: enable を設定してください。

Q3. タイムアウトエラー (Timeout)

原因: show tech-support のような大量の出力を返すコマンドを実行すると、Ansibleのデフォルトタイムアウト（10秒〜30秒）を超えてしまう。
対策: ansible.cfg または変数でタイムアウト値を延ばします。

ansible_command_timeout: 60  # 60秒に延長

---

まとめ：ネットワークも「インフラ」の一部である

お疲れ様でした！
これで、サーバーもネットワークも、すべてAnsibleで統合管理できるようになりました。

今回の重要ポイント：

• ネットワーク機器は network_cli で接続し、エージェントレスで操作する。
• ベンダーごとにコレクション（cisco.ios, junipernetworks.junos）を使い分ける。
• ios_config の backup: yes は、お手軽かつ最強のバックアップ手段。
• --check --diff で、変更内容を事前確認する癖をつける。

「ネットワークは手動、サーバーは自動」という分断された運用は、ミスの温床です。
Ansibleで全てをコード化し、インフラ全体を一貫したポリシーで管理しましょう。

さて、ここまで来ると、Ansibleの実行環境自体も複雑になってきます。
Pythonのバージョン、ライブラリの依存関係、コレクションのバージョン…。
チームメンバー全員が同じ環境でAnsibleを実行するにはどうすればいいでしょうか？

次回、応用講座 最終回となる第8回は「新時代の実行環境。Ansible Builder/RunnerによるExecution Environment (EE)」です。
Ansibleの実行環境そのものをコンテナ化（Execution Environment）し、どこでも同じ環境でPlaybookを実行できる最新技術について解説します。
Ansibleの未来へ、最後のステップです。お楽しみに！