[Ansible] グループ変数を活用したネットワーク機器への Syslog サーバー追加

---

この記事は、Software Design 2018年12月号 の 特集1「[超速]入門 Ansible」内の「第3章:Ansibleでネットワーク作業も自動化」（以下、基本編）の続きです。

ソフトウェアデザイン 2018年12月号

誌面スペースの関係で掲載できなかった、少し応用的な内容をブログとして投稿します。サンプル Playbook などの一式は、以下のリポジトリの extra ブランチにアップしてあります。

https://github.com/akira6592/sd2018-ansible-nw/tree/extra

また、 エーピーコミュニケーションズ Advent Calendar 2018 の1日目の記事も兼ねています。

---

応用編: グループと変数の活用

基本編では Playbook の中に直接コマンドを指定し、各 L3 スイッチに対して同じコマンドを実行しました。応用編ではもう少し凝った設定変更の例を見ていきましょう。

基本編の想定環境に、東日本と西日本のそれぞれの機器用に Syslog サーバーが追加設置されたとします。

そこで、各 L3 スイッチのログ送信先として、自身の所属するエリア用の Syslog サーバーの IP アドレスを設定（logging host コマンド）する例を見ていきましょう。

ファイルの構成は以下の通りです。

• ファイル構成

.                        # 作業用ディレクトリ
|-- group_vars           # グループ変数ファイル格納ディレクトリ
|  |-- east.yml          # グループ「east」用変数定義ファイル（追加）
|  |-- ios.yml           # グループ「ios」用変数定義ファイル
|  └-- west.yml          # グループ「west」用変数定義ファイル（追加）
|-- 03_set_logging.yml   # ログ送信先Syslogサーバー設定用Playbook（追加）
└-- inventory.ini        # インベントリーファイル（変更）

■ インベントリーファイルの作成

基本編で利用したインベントリーファイルにもうひと工夫加えます。

前述の通り、東日本の機器用と西日本の機器用の Syslog サーバーが1台ずつ追加されたため、2つのサーバーのIPアドレスは異なります。東日本用と、西日本用に1つずつ Playbook を作成してもよいのですが、ここはインベントリーファイルの機能を活用してスマートに設計してみましょう。

具体的にはまず、各 L3 スイッチを拠点グループ「tokyo」と「osaka」にそれぞれ所属させます。さらに「tokyo」「osaka」グループをそれぞれエリアグループ「east」「west」に所属させます。

後述する各エリアグループ用の変数定義ファイルを組み合わせることで、各 L3 スイッチでエリア用の変数を利用できます。これにより、ひとつの Playbook で各 L3 スイッチに対して異なる値を埋め込んだコマンドを実行できます。

• inventory

[ios] 
TOKYO-L3SW01 ansible_host=10.10.10.254
OSAKA-L3SW01 ansible_host=10.20.20.254

[tokyo]            # 拠点グループ「tokyo」
TOKYO-L3SW01

[osaka]            # 拠点グループ「osaka」
OSAKA-L3SW01

[east:children]    # エリアグループ「east」の配下に拠点グループ「tokyo」をネスト 
tokyo

[west:children]    # エリアグループ「west」の配下に拠点グループ「osaka」をネスト 
osaka

今回は対象ノードが少ないため、グループにする意味をそれほど感じられないかもしれませんが、グループにしておくことで拠点や対象ノードが増えても効率よく管理できます。

なお、グループの関係については ansible-inventory コマンドで視覚的に確認できます。

$ ansible-inventory -i inventory --graph
@all:
  |--@east:
  |  |--@tokyo:
  |  |  |--TOKYO-L3SW01
  |--@ios:
  |  |--OSAKA-L3SW01
  |  |--TOKYO-L3SW01
  |--@ungrouped:
  |--@west:
  |  |--@osaka:
  |  |  |--OSAKA-L3SW01

■ 変数定義ファイルの作成

基本編で作成した「ios.yml」に加えて、各エリア用の「east.yml」と「west.yml」を新たに作成します。これらのファイルには、各エリア用の Syslog サーバーのIPアドレレスを変数「syslog_server」で定義します。

• group_vars/east.yml

syslog_server: 10.10.0.1

• group_vars/west.yml

syslog_server: 10.20.0.1

ここまでの準備により変数「syslog_server」の値は、グループ「east」に所属する対象ノードへのタスク実行時には「10.10.0.1」に、「west」に所属する機器へのタスク実行時には「10.20.0.1」になります。

■ Playbook の作成

最後に、ログ送信先 Syslog サーバーのIPアドレスを設定する Playbook を作成します。

• 03_set_logging.yml

- hosts: ios                      # (a) ヘッダーセクション
  gather_facts: no
  
  tasks:
    - name: set syslog server     # (b) SyslogサーバーIPアドレス設定タスク
      ios_logging:
        dest: host
        name: "{{ syslog_server }}"
      notify:
        - save

  handlers:                       # (c) ハンドラーセクション
    - name: save
      ios_config:
        save_when: always

この Playbook について解説します。

(a) ヘッダーセクション

基本編で作成した2つの Playbook と同様に、グループ「ios」を対象とし、ファクト収集は無効にしていています。

(b) Syslog サーバー IP アドレス設定タスク

ios_logging モジュールを利用しています。ios_logging モジュールは、Cisco IOSのネットワーク機器に対して、ロギング関連の設定をするモジュールです。コマンドとしては logging host などにあたります。

dest オプションにはログの送信先タイプを指定します。 ここでは Syslog サーバーへ送信するため「host」を指定します。この場合、name オプションに Syslog サーバーのホスト名またはIPアドレスを指定します。

notify ディレクティブで、このタスクで設定変更が発生した場合に呼び出すハンドラー「save」を指定しています。

(c) ハンドラーセクション

ios_config モジュールの save_when オプションに「always」を指定しています。これにより、このタスク実行時に常に「runnging-config」を「startup-config」にコピーします。

なお、このタスクは前述の「(b) SyslogサーバーIPアドレス設定タスク」の notify 経由で実行されます。そのため、結果的には「(b) Syslog サーバー IP アドレス設定タスク」で設定変更が発生したら「runnging-config」を「startup-config」にコピーするという動作になります。

■ 実行と確認

それでは Playbook を実行します。利用するコマンドや書式は基本編で作成した Playbook の実行のときと同じです。

$ ansible-playbook -i inventory.ini 03_set_logging.yml

PLAY [ios] *****************************************************************

TASK [set syslog server] ***************************************************
changed: [OSAKA-L3SW01]
changed: [TOKYO-L3SW01]

RUNNING HANDLER [save] *****************************************************
changed: [OSAKA-L3SW01]
changed: [TOKYO-L3SW01]

PLAY RECAP *****************************************************************
OSAKA-L3SW01               : ok=2    changed=2    unreachable=0    failed=0
TOKYO-L3SW01               : ok=2    changed=2    unreachable=0    failed=0

各L3スイッチへのSyslogサーバーIPアドレス設定タスクのステータスが「changed」となり、設定変更されたことが分かります。それに伴い、ハンドラー経由でタスク「save」も呼び出されています。

念の為、ここでは各 L3 スイッチ側で設定が投入、保存されたことを確認します。

• 東京拠点側

TOKYO-L3SW01# show running-config | inc logging
logging host 10.10.0.1
TOKYO-L3SW01# show startup-config | inc logging
logging host 10.10.0.1

• 大阪拠点側

OSAKA-L3SW01# show running-config | inc logging
logging host 10.20.0.1
OSAKA-L3SW01# show startup-config | inc logging
logging host 10.20.0.1

これで、正常に2台の L3 スイッチに異なる Syslog サーバーのIPアドレスを指定した logging host コマンドが投入されたことを確認できました。

まとめ

このように、一部のパラメータのみが異なる作業を抽象化し、Playbook と 変数（パラメータ）を分けることでメンテナンス性と Playbook の再利用性が向上します。