こうした状況は、中規模以上のインフラを担当するエンジニアによく見られる。サーバー台数が増えてからAnsibleを導入したものの、ルーターやスイッチはメーカーごとのCLIに縛られ、構成管理の輪に入れられていない。設定変更のたびに担当者が機器に直接ログインし、コマンドを打って確認する作業が残る。
この記事では、Ansibleのネットワーク自動化機能を使い、LinuxサーバーとCiscoルーターを同じPlaybookで管理する設計を解説する。ansible.netcommonコレクションとios_command・ios_configモジュールの仕組みから、サーバーとネットワーク機器を統合するsite.ymlの設計まで扱う。RHEL 9系～Rocky Linux 9系のコントロールノードを想定環境として説明する。
この記事のポイント
・AnsibleはSSH経由でネットワーク機器の設定読み書きができる
・ios_commandで設定確認、ios_configで変更を適用するのが基本パターン
・インベントリのansible_network_os変数で機器の種別を指定する
・site.ymlのimport_playbookでサーバーとネットワーク機器のPlaybookを統合する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜAnsibleでネットワーク機器も管理できるのか
Ansibleが広く普及した理由の一つは「管理対象にエージェントを入れなくてよい」設計にある。SSH接続さえできれば、対象ホスト側にPythonが無くても操作可能なケースが多い。ネットワーク機器（ルーター・スイッチ・ファイアウォール）はまさにこの条件に合致する。CiscoのIOS/IOS-XEやNX-OS、JuniperのJunOS、AristaのEOSはいずれも独自OSで動いており、LinuxのPythonは動作しない。しかしSSHによるCLI操作は受け付けるため、Ansibleはその「SSH経由でCLIコマンドを送り込む」アプローチをnetwork_cliという接続方式として実装した。これにより、サーバー管理と同じPlaybook記法でネットワーク機器を扱えるようになっている。
重要な違いは「モジュールの実行場所」だ。Linuxサーバーを管理するときは、コントロールノードがSSHで接続→Pythonモジュールを転送→対象ホスト上でモジュールを実行という流れになる。ネットワーク機器の場合はモジュールがコントロールノード側で動作し、その結果としてCLIコマンドを生成して機器へ送信する。処理の主体は常にコントロールノードにある点が、サーバー管理との根本的な違いだ。
ansible.netcommonと各ベンダーコレクションの関係
Ansibleのネットワーク自動化はansible.netcommonコレクションを基盤とし、その上にベンダー固有のコレクションが乗る二層構造になっている。・ansible.netcommon：network_cli・netconf・httpapiなどの接続プラグイン群。全ベンダーの共通基盤
・cisco.ios：Cisco IOS/IOS-XE向けモジュール（ios_command、ios_config、ios_vlansなど）
・cisco.nxos：Cisco NX-OS（Nexus系）向けモジュール群
・juniper.junos：Juniper JunOS向けモジュール群
・arista.eos：Arista EOS向けモジュール群
コレクションは
ansible-galaxy collection install でインストールする。# ansible.netcommonとcisco.iosをインストール ansible-galaxy collection install ansible.netcommon ansible-galaxy collection install cisco.ios # インストール済みコレクションの確認 ansible-galaxy collection list | grep -E 'netcommon|cisco'
Collection Version ------------------ ------- ansible.netcommon 6.1.3 cisco.ios 8.0.0
requirements.yml に記述する方法が、チーム開発での標準的な手順だ。# requirements.yml --- collections: - name: ansible.netcommon - name: cisco.ios - name: cisco.nxos # インストール実行 ansible-galaxy collection install -r requirements.yml
インベントリでネットワーク機器を定義する方法
Linuxサーバーと同様に、ネットワーク機器もインベントリファイルに記述する。異なるのは接続に必要な変数の指定だ。1. インベントリの基本構成
# inventory/hosts [web_servers] web01 ansible_host=192.168.10.11 web02 ansible_host=192.168.10.12 [network_devices] router01 ansible_host=192.168.10.1 [network_devices:vars] ansible_connection=ansible.netcommon.network_cli ansible_network_os=cisco.ios.ios ansible_user=admin ansible_become=yes ansible_become_method=enable
・ansible_connection：「ansible.netcommon.network_cli」を指定する。これがSSH経由のCLI接続を意味する
・ansible_network_os：機器のOSを示す。Cisco IOSなら「cisco.ios.ios」、JunOSなら「juniper.junos.junos」
・ansible_become_method：特権モード（Ciscoでいう
enable コマンド）への昇格方法を指定するパスワード類（
ansible_password・ansible_become_password）は平文でインベントリに書かない。Ansible Vaultで暗号化した変数ファイル（group_vars/network_devices/vault.yml）に分離するのが設計上の基本だ。2. 複数ベンダーが混在する場合のgroup_vars設計
現場ではCiscoとJuniperが混在するケースも多い。group_varsでベンダーごとにグループを分け、
ansible_network_os を切り替える設計にすると管理しやすい。# group_vars ディレクトリ構成 group_vars/ cisco_ios/ vars.yml # ansible_network_os: cisco.ios.ios vault.yml # ansible_password: （vault暗号化済み） juniper/ vars.yml # ansible_network_os: juniper.junos.junos vault.yml # ansible_password: （vault暗号化済み）
ios_commandで現在の設定を確認する方法
ios_command モジュールは、Cisco IOS機器にshowコマンドを送り、出力を変数として取得するモジュールだ。機器の現状確認や設定収集の自動化に使う。# playbooks/gather_network_info.yml --- - name: ネットワーク機器の設定情報を収集する hosts: network_devices gather_facts: false # ネットワーク機器にはsetupモジュールを使わない tasks: - name: インターフェース状態を取得 cisco.ios.ios_command: commands: - show interfaces brief - show ip route register: network_output - name: 収集した情報を表示 ansible.builtin.debug: var: network_output.stdout_lines
TASK [収集した情報を表示] ************************************ ok: [router01] => { "network_output.stdout_lines": [ [ "Interface IP-Address OK? Method Status Protocol", "GigabitEth0/0 192.168.10.1 YES manual up up " ], [ "Codes: L - local, C - connected ...", "Gateway of last resort is not set" ] ] }
gather_facts: false は必須の指定だ。ネットワーク機器はLinuxのsetupモジュールが使えないため、この行を省略するとPlaybook実行の冒頭でエラーが発生する。ネットワーク機器のfacts収集が必要な場合は、別途 cisco.ios.ios_facts モジュールを明示的に呼び出す。ios_configで設定を変更・適用する方法
ios_config モジュールは、機器のコンフィグに設定行を追加・変更する。Ciscoの設定モード（configure terminal）に相当する操作をPlaybookで表現できる。# playbooks/configure_interface.yml --- - name: ルーターのインターフェース設定を適用する hosts: network_devices gather_facts: false tasks: - name: Loopback0インターフェースを設定する cisco.ios.ios_config: lines: - description Ansible Managed - ip address 10.0.0.1 255.255.255.0 - no shutdown parents: interface Loopback0 save_when: modified # 変更があった場合のみ write memory を実行
parents パラメーターはCiscoの階層設定を表現する。「interface Loopback0」の配下に lines の設定行を適用するという意味だ。save_when: modified を指定すると変更が発生した場合のみ write memory が実行されるため、実行のたびに不要な書き込みが走るのを防げる。べき等性を維持するための注意点
ios_configは既存の設定行と送信する行を比較し、差分がある場合だけ変更を適用する設計だ。ただしコマンドの表記が機器のrunning-configと完全一致しないとべき等性が崩れる点に注意が必要だ。
たとえばCisco IOSは
no ip domain-lookup を内部的に no ip domain lookup（ハイフンなし）と保存することがある。送信した行とrunning-configの表記が異なると毎回「差分あり」と判断され、余分な変更が走り続ける。解消策は事前に show running-config の出力を確認し、機器が採用している表記に合わせてPlaybookを書くことだ。より確実にべき等性を保ちたい場合は、network_resource_modules（ios_vlans・ios_interfacesなど）を使うアプローチがある。これらのモジュールは
state: merged や state: replaced のパラメーターで宣言的に設定の最終状態を定義できるため、表記ゆれの影響を受けにくい。site.ymlでサーバーとネットワーク機器のPlaybookを統合する設計
Ansibleの構成管理を真に活かすのは、サーバーとネットワーク機器の設定を1回の実行で揃えられる状態にしたときだ。site.yml で import_playbook を使い、役割ごとのPlaybookを束ねる設計を採用する。# site.yml（プロジェクトのエントリーポイント） --- - name: ネットワーク機器の基本設定を適用する import_playbook: playbooks/network_baseline.yml - name: Webサーバーの構成管理を適用する import_playbook: playbooks/web_servers.yml - name: DBサーバーの構成管理を適用する import_playbook: playbooks/db_servers.yml
import_playbook は静的インポートなので、ansible-playbook site.yml --list-tasks でタスク一覧を事前確認できる。ネットワーク機器とサーバーを別々に実行したい場合は --tags を組み合わせる設計にするとよい。サーバーとネットワーク機器で異なる3つの設計上の違い
統合設計を行う前に、両者の動作の違いを押さえておく必要がある。
・gather_facts：サーバーはtrueがデフォルト。ネットワーク機器はfalseを明示する（必須）
・接続プラグイン：サーバーはansible.builtin.ssh、ネットワーク機器はnetwork_cli
・モジュール実行場所：サーバーは対象ホスト側、ネットワーク機器はコントロールノード側
これらをgroup_varsで自動的に切り替える構成にしておけば、Playbookのタスク記述に両者の差はほとんど出なくなる。Ansibleを業務でどこまで活用できるかを体系的に整理したい方は、Ansible実践講座でサーバーからネットワーク機器まで網羅した自動化の全体像を学べる。
トラブルシュート：ネットワーク接続でよくあるエラー
1. 「Unable to connect to port 22」エラー
コントロールノードからネットワーク機器のSSHポートに到達できていない状態だ。Firewallのルールやネットワーク経路を確認し、コントロールノードから直接SSHで接続できるかを検証する。Linux ポート確認の全コマンドを使って接続性を事前に確認しておくと、原因の切り分けが早い。
2. 「timeout value 10 seconds reached」エラー
設定量が多いshowコマンドや、ページャー（--More--）が挟まるコマンドで発生しやすい。ansible.cfgの
[persistent_connection] セクションで command_timeout を伸ばすことで対処できる。# ansible.cfg [persistent_connection] command_timeout = 60 connect_timeout = 30
terminal length 0 を設定することでも解消できる。ios_configにその設定を含めておくか、接続後に自動的にページャーを無効化するよう terminal_initial_prompt の設定で対応する。3. 「SCP/SFTP is not supported」エラー
ネットワーク機器へのファイル転送は通常のSFTPが使えないことがある。configファイルを転送する場合は、templateモジュールでコントロールノード側にファイルを生成し、ios_configの
src パラメーターで渡す設計に切り替えると解消する。本記事のまとめ
AnsibleのネットワークモジュールでLinuxサーバーとネットワーク機器を統合管理するポイントをまとめる。| やりたいこと | 使うモジュール・変数 |
|---|---|
| Ciscoルーターにshowコマンドを送る | cisco.ios.ios_command |
| インターフェースや設定行を変更する | cisco.ios.ios_config |
| SSH接続方式を指定する | ansible_connection: ansible.netcommon.network_cli |
| 機器のOS種別を指定する | ansible_network_os: cisco.ios.ios |
| facts収集を無効化する | gather_facts: false |
| サーバーとネットワーク機器を一括実行 | import_playbook でsite.yml統合 |
| 宣言的な設定管理でべき等性を保つ | cisco.ios.ios_vlans などのresource module |
Ansibleのネットワーク自動化はansible.netcommonとベンダーコレクションの組み合わせで成り立っている。インベントリに
ansible_connection と ansible_network_os を正しく定義し、gather_facts: false を忘れなければ、Linuxサーバーと同じPlaybook記法でネットワーク機器の設定管理が始められる。サーバーと機器を同じsite.ymlで統合することで、インフラ全体を一貫したコードで管理できる状態になる。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AnsibleをはじめとするLinuxインフラ自動化の実践的なカリキュラムを提供しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：Ansibleのgitモジュールでアプリケーションデプロイを自動化する方法｜ブランチ指定と環境ごとの展開設計
- この記事の属するカテゴリ：Ansibleへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます