この記事は、Software Design 2018年12月号 の 特集1「[超速]入門 Ansible」内の「第3章:Ansibleでネットワーク作業も自動化」（以下、基本編）の続きです。
- 作者: 中島倫明,横地晃,齊藤秀喜,楠正憲,三廻部大,鷲北賢,くつなりょうすけ,安藤幸央,結城浩,武内覚,宮原徹,平林純,職業「戸倉彩」,速水祐,樽石将人,清水琢也,山田泰宏,田代勝也,eban,中村壮一,上田隆一,谷口岳,mattn,すずきひろのぶ,小飼弾,青田直大,やまねひでき,あわしろいくや,中島雅弘,法林浩之,関治之,後藤大地,杉山貴章,Software Design編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2018/11/16
- メディア: 雑誌
- この商品を含むブログを見る
誌面スペースの関係で掲載できなかった、少し応用的な内容をブログとして投稿します。サンプル 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 スイッチに対して異なる値を埋め込んだコマンドを実行できます。
[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」で定義します。
syslog_server: 10.10.0.1
syslog_server: 10.20.0.1
ここまでの準備により変数「syslog_server」の値は、グループ「east」に所属する対象ノードへのタスク実行時には「10.10.0.1」に、「west」に所属する機器へのタスク実行時には「10.20.0.1」になります。
■ Playbook の作成
最後に、ログ送信先 Syslog サーバーのIPアドレスを設定する Playbook を作成します。
- 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 の再利用性が向上します。
