Ansibleとは何か

ネットワークエンジニアが手作業で設定変更を行う場合、 一般的には次のような作業を繰り返します。

1. 対象機器へSSHでログインする
2. 現在の設定を確認する
3. コンフィグレーションモードへ入る
4. 必要な設定を入力する
5. 設定結果を確認する
6. 設定を保存する
7. 次の機器へログインする

2台程度であれば手作業でも対応できます。 しかし、20台、50台、100台と対象が増えると、 同じコマンドを何度も入力することになります。

Ansibleでは、こうした作業内容を Playbook に記述し、対象機器を Inventory で管理します。

なぜネットワーク設定にAnsibleを使うのか

手動作業とAnsibleを比較する

Ansibleによる設定投入の全体像

ネットワーク機器をAnsibleで操作する場合、 基本的にはAnsibleを実行する Control Node から対象機器へ接続します。

Cisco IOSをSSH経由で操作する例では、 Ansibleの ansible.netcommon.network_cli 接続を利用し、 Cisco IOS用Collectionのモジュールを使って処理します。

つまり、Ansibleが単純にキーボード入力を再現しているのではなく、 対象OSに対応したモジュールを使って処理を定義します。

Inventory・Playbook・Moduleを理解する

Ansibleを学ぶときは、 最初に次の4つを区別すると理解しやすくなります。

検証環境を準備する

今回は、LinuxまたはWSL上のAnsible Control Nodeから、 SSHでCisco IOS系の検証機器へ接続する想定にします。

1．Ansibleを確認する

ansible --version

2．必要なCollectionを確認・導入する

ansible-galaxy collection list

ansible-galaxy collection install ansible.netcommon
ansible-galaxy collection install cisco.ios

Cisco IOS向けの cisco.ios.ios_config などは、Cisco IOS用Collectionに含まれています。

3．最初に手動SSHを確認する

ssh ansible@192.168.10.11

Ansibleで接続できない場合、 Ansibleの設定だけでなく、SSH、IP到達性、認証、 Enable権限なども確認する必要があります。

Inventoryを作成する

最初に、Ansibleが操作する機器をInventoryへ登録します。

ここでは inventory.yml を作成します。

---
all:
  children:
    cisco_switches:
      hosts:
        sw01:
          ansible_host: 192.168.10.11
        sw02:
          ansible_host: 192.168.10.12

      vars:
        ansible_connection: ansible.netcommon.network_cli
        ansible_network_os: cisco.ios.ios
        ansible_user: ansible
        ansible_become: true
        ansible_become_method: enable

各項目の意味

Inventoryを確認する

ansible-inventory -i inventory.yml --graph

イメージとして、次のように対象機器を確認できます。

@all:
  |--@ungrouped:
  |--@cisco_switches:
  |  |--sw01
  |  |--sw02

Playbookを作成する

次に、SW01とSW02の GigabitEthernet1/0/1 へdescriptionを設定するPlaybookを作ります。

ファイル名を interface_description.yml とします。

---
- name: Configure interface description
  hosts: cisco_switches
  gather_facts: false

  tasks:
    - name: Configure GigabitEthernet1/0/1
      cisco.ios.ios_config:
        parents:
          - interface GigabitEthernet1/0/1
        lines:
          - description Uplink-to-Core
        backup: true

Playbookを分解して理解する

hosts

hosts: cisco_switches

Inventoryで定義した cisco_switches グループを対象にします。

gather_facts

gather_facts: false

今回は通常のサーバー向けFacts収集を使用しないため、 falseとしています。

cisco.ios.ios_config

cisco.ios.ios_config:

Cisco IOSのコンフィグレーションを管理するためのモジュールです。

parents

parents:
  - interface GigabitEthernet1/0/1

どの設定階層の下へコマンドを投入するかを指定します。

lines

lines:
  - description Uplink-to-Core

インターフェース配下へ存在させたい設定を定義します。

backup

backup: true

設定変更前のrunning-configをバックアップするために使用します。

Playbookを実行する

InventoryとPlaybookを作成したら、 ansible-playbook で実行します。

ansible-playbook \
  -i inventory.yml \
  interface_description.yml

正常に変更された場合、出力は次のようなイメージになります。

PLAY [Configure interface description] ****************

TASK [Configure GigabitEthernet1/0/1] *****************
changed: [sw01]
changed: [sw02]

PLAY RECAP *********************************************
sw01 : ok=1 changed=1 unreachable=0 failed=0
sw02 : ok=1 changed=1 unreachable=0 failed=0

changedの意味

changed=1 は、Ansibleの処理によって対象機器の状態に変更が発生したことを示します。

設定後は機器側でも確認します。

show running-config interface GigabitEthernet1/0/1

設定例：

interface GigabitEthernet1/0/1
 description Uplink-to-Core

複数機器へ異なる設定を投入する

自動化では、全機器へ完全に同じ設定を入れるだけではありません。

たとえば、機器ごとにインターフェースdescriptionを変える場合は、 Variableを利用できます。

Inventoryへ変数を持たせる

---
all:
  children:
    cisco_switches:
      hosts:
        sw01:
          ansible_host: 192.168.10.11
          uplink_description: Uplink-to-Core01

        sw02:
          ansible_host: 192.168.10.12
          uplink_description: Uplink-to-Core02

      vars:
        ansible_connection: ansible.netcommon.network_cli
        ansible_network_os: cisco.ios.ios
        ansible_user: ansible
        ansible_become: true
        ansible_become_method: enable

Playbookから変数を参照する

---
- name: Configure uplink descriptions
  hosts: cisco_switches
  gather_facts: false

  tasks:
    - name: Configure description
      cisco.ios.ios_config:
        parents:
          - interface GigabitEthernet1/0/1
        lines:
          - "description {{ uplink_description }}"
        backup: true

同じPlaybookを利用しながら、 機器ごとに値を変更できるようになりました。

実務では、IPアドレス、VLAN、NTPサーバー、 Syslogサーバーなどもデータとして分離して管理できます。

冪等性を理解する

Ansibleを理解するうえで重要な言葉が 冪等性（Idempotency） です。

たとえば、すでに次の設定が存在するとします。

interface GigabitEthernet1/0/1
 description Uplink-to-Core

Playbookでも同じ状態を要求している場合、 再実行時には変更が不要と判断されることが期待されます。

sw01 : ok=1 changed=0 unreachable=0 failed=0

なぜ冪等性が重要なのか

• Playbookを繰り返し実行しやすくなる
• 不要な設定変更を減らせる
• 現在状態と期待状態の差を意識できる
• 自動化処理の再現性を高められる

本番投入を安全にする方法

Ansibleで設定できるようになった後に、 さらに重要になるのが 安全に実行する設計 です。

1．対象機器を制限する

最初から全台へ投入せず、 --limit を使って対象を限定する方法があります。

ansible-playbook \
  -i inventory.yml \
  interface_description.yml \
  --limit sw01

まずSW01だけで確認し、問題がなければ対象を広げるという使い方ができます。

2．変更前にバックアップする

- name: Backup configuration
  cisco.ios.ios_config:
    backup: true

「自動化だからバックアップ不要」ではありません。 むしろ短時間で多数の機器を変更できるため、 バックアップと切り戻しの設計が重要になります。

3．差分を確認する

モジュールや処理内容が対応している場合は、 Ansibleのdiff機能を使って変更内容を確認できます。

ansible-playbook \
  -i inventory.yml \
  interface_description.yml \
  --check \
  --diff

4．設定保存の扱いを決める

running-configをstartup-configへ保存する必要がある場合は、 保存方法もPlaybookで設計します。

- name: Configure interface
  cisco.ios.ios_config:
    parents:
      - interface GigabitEthernet1/0/1
    lines:
      - description Uplink-to-Core
    backup: true
    save_when: changed

「設定投入」と「保存」を分けるのか、 同じPlaybookで実施するのかは、 運用ルールや切り戻し方針に合わせて決めます。

5．投入後の確認も自動化する

設定を入れて終了するのではなく、 必要に応じて状態確認もPlaybookへ組み込みます。

- name: Check interface configuration
  cisco.ios.ios_command:
    commands:
      - show running-config interface GigabitEthernet1/0/1
      - show interfaces GigabitEthernet1/0/1 status
  register: result

- name: Show result
  ansible.builtin.debug:
    var: result.stdout_lines

Ansibleによる設定投入でよくある失敗

設計・運用上の判断基準

Ansibleを業務へ導入するときは、 Playbookを書く技術だけでは不十分です。

「どこまで自動化するか」を設計する必要があります。

自動化に向いている作業

• NTPサーバーの統一
• Syslog送信先の追加・変更
• SNMP設定の展開
• インターフェースdescriptionの統一
• 共通ACLの展開
• 設定バックアップ
• showコマンドによる状態確認
• 設定差分の検出

慎重に扱うべき作業

• 管理用IPアドレスの変更
• SSH経路そのものに影響する設定
• ルーティングプロトコルの大規模変更
• 全社WANの経路変更
• 機器再起動を伴う変更
• 遠隔拠点で切り戻し手段がない変更

顧客・上司へAnsible導入を説明する方法

顧客にAnsibleを説明するとき、 「YAMLでネットワーク機器を操作できます」 だけでは価値が伝わりにくいでしょう。

技術ではなく、 業務上の効果 に変換して説明します。

説明例

技術をビジネス価値へ変換する

Ansibleでよく使う英語表現

公式ドキュメントを検索するときの例

Ansible Cisco IOS configuration
Ansible ios_config example
Ansible network_cli Cisco IOS
Ansible network automation inventory
Ansible ios_config backup
Ansible Vault network credentials

製品名とエラー内容を英語で組み合わせて検索できると、 公式ドキュメントやIssueへ到達しやすくなります。

自分の言葉で説明する課題

実務で使うならここまで考える

学習環境では、 「Playbookを書いて設定できた」 ところまででも十分な成果です。

しかし、実務でネットワーク自動化を担当するなら、 次の段階まで考えられると価値が高まります。

1. 設定値をコードから分離する Inventory、group_vars、host_varsなどを使い、 共通処理と機器固有データを分けます。
2. 認証情報を安全に管理する SSH鍵やAnsible Vaultなどを利用し、 パスワードを平文で管理しないようにします。
3. GitでPlaybookを管理する 誰が、いつ、どの設定ロジックを変更したのかを追跡できるようにします。
4. レビュー工程を作る 本番投入前にPlaybookと差分を別担当者が確認できるようにします。
5. 投入後の検証まで自動化する showコマンドやAPIを利用して、 設定だけでなく状態まで確認します。

参考：公式ドキュメント

• Ansible Network Getting Started
• cisco.ios.ios_config module
• Cisco IOS Platform Options
• ansible.netcommon.network_cli