Ansible Network Module

はじめに

これは、NetOpsCoding Advent Calendar 2016 の 2016年12月15日 の記事です。

この記事では、Ansible の Network Module について書かせていただこうと思います。

Ansible とネットワーク対応

サーバの構成管理ツールとして Chef や Puppet と比較して語られることが多かった Ansible ですが、「simple IT Automation」のツールを標榜しています。Ansibleのトップページでも、デカデカと

AUTOMATION FOR EVERYONE

と書かれています。

みましたか？
NetOps Codingのみなさん、Automation ですよ、A u t o m a t i o n。

がぜん興味がわいてきましたよね？

そして、今年2016年の2月に、Ansibleの開発元であるRedHatからプレスリリースがあったのを覚えていますか？

「Red Hat、Ansibleの新機能によってネットワークでもDevOpsを実現」
https://www.redhat.com/ja/about/press-releases/rhjapan-red-hat-brings-devops-network-new-ansible-capabilities

"Red Hat Brings DevOps to the Network with New Ansible Capabilities"
https://www.ansible.com/press/red-hat-brings-devops-to-the-network-with-new-ansible-capabilities

もう、NetOps Coding な人々が手を出さない理由はないでしょう。

と、ここまで書きましたが、実際に Ansible Network Moudle でどんなことができるのを解説した記事などをあまり見かけませんし、多くは語られていない気がしています。

そこで、Ansible の Network Module について調べてみたことを共有させていただこうと思います。正直なところ、すべての実装と機材を試してみることは厳しいので、実際に動くかは「？」なところもありますが、ここでは Ansible の Manual などの Document と、実際のコードを覗いてみて判ったことなどを書かせていただきます。

なお、この記事では Ansible の Network Module についての解説に徹して、Ansibleの使用方法などについては、良い解説書や記事などが既に多くありますので、ここでは触れずに、既に御存知とのことで話をすすめます。

Network Module 対応ベンダ

冒頭の記事で紹介した2016年2月のプレスリリースの段階では、次の5社のネットワーク機材ベンダとフレームワークをサポートしていました。

• Arista Networks – Arista EOS
• Cisco Systems – Cisco Application Centric Infrastructure (ACI); Cisco IOS-XE®; Cisco IOS-XR®; and Cisco NX-OS
• Cumulus Networks – Cumulus Linux
• OpenSwitch.net – OpenSwitch
• Juniper Networks – Junos OS

2月のプレスリリースの後、5月末にリリースされたAnsibleのバージョン2.1では、これらのベンダのネットワーク機材をコントロールするモジュールが、Ansibleのcoreモジュールに統合されました。

そして、この記事の書かれた2016年12月時点のAnsibleバージョン2.2のコードでは、core の network module の下には、さらに次の10社のベンダとオープン・ソース・ソフトウエアが加わっています。

• A10 Networks
• Citrix Systems
• Dell − dellos6/dellos9/dellos10
• Exoscale
• F5 Networks
• Solraris/illumos
• Pluribus Netowrks - netvisor
• Palo Alto Netowrks - panos
• Nokia - sros
• VyOS (Open Source Software)

ここで、「おー、たくさん対応しているじゃん！」とぬか喜びしないようにしましょう。
これらのモジュールのうち、どうみてもネットワーク機材と呼べないクラウドサービスのモジュールや、まだモジュールが1つしか登録されていない「俺はまだ本気を出していないだけ」なものありますので。

Network Module の分類

Ansible は、公式ドキュメントが充実していると言われています。基本的な使い方などの解説も充実していますが、Module Indexにはモジュールの使い方が詳しく載っています。この中でも、Ansibleでネットワーク機材を触ろうという奇特なNetOpsCodingな方々は、Network Modulesに目をとおしましょう。Ansible の Network Module の対応ベンダごとにモジュールがまとめられています。

Ansible のモジュールは、core と extras のモジュールの二つに大きく分類されます。coreモジュールは、Ansibleのコアチームがメンテナンスしており、優先順位が高く ansible の本体と一緒にリリースされています。extrasモジュールは、コミュニティがメンテナンスしているコア以外のモジュールになりますが、ソースコードの管理としては（2016年12月現在） Ansible の本体と同じレポジトリで管理されています。

Networkモジュールでは、2016年2月にリリースされた がcoreモジュールの扱いになっていますが、それ以外のモジュールは extras の扱いになっています。

Ansible のモジュールは、

[os]_[function] 

のように、OS名と機能を繋げて命名をされています。たとえば、VyOS で、その設定を取得する facts という機能のモジュールであれば、vyos_facts のようなモジュール名になります。

公式ドキュメントから、ベンダ（OS）とその対応する機能をまとめたのが次の表になります。この表では、縦にベンダ（OS）で、機能毎に対応した Ansible のバージョンが記述してあります。また、赤い色の部分が、core のモジュールになります。

註：上記の表には記載しませんでしたが、template モジュールは、バージョン2.2で deprecated になっており config にとってかわられています。

上記の表から読み取れることは次のようなことです。

• OS毎に共通する機能は、config、command、fact （黄色の部分）
• A10 Networks や F5 Networks などのロードバランサ、Cumulus LinuxのようなLinuxベースのスイッチなどは、モジュールの名称などが大きく異なっている。
• 対応するモジュール数としては、通常は 3モジュール〜4モジュール
• 対応するモジュール数もっとも多いのは、Cisco NX-OS であり、58モジュールが登録されれている。
  　（NX-OSですが、非常にアグレッシブな2名のコミッタがいらっしゃるらしい）

つまり、Ansible の Network Module を理解するためには、それぞれの

• config
• command
• facts

を押さえれば良いことがわかります。

利用上の注意

ネットワーク・モジュールを利用する際の注意点は、ローカルモジュールであること、追加のライブラリのインストールを要求されるものが多々あることです。

詳しく利用例を載せようと思ったのですが、申し訳ありません、時間切れです。（後ほど追記します）

まとめ

Ansible は、「システムの前提も小さく、学習コストも低く導入の敷居が容易であること」が長所としてあげられますが、その反面の欠点として、「制御構造が貧弱だったり、抽象化がされていない」ということが言われます。

たとえば、unix のサーバにおけるパッケージ管理を行うモジュールとして、全体に共通する package のような抽象的な機能が存在するのではなく、OSやdistributionのパッケージシステムごとに別々のモジュールが用意されています。つまり、Ubuntu であれば apt モジュールを、CentOS であれば yum モジュールを、FreeBSD なら pkg を利用することになります。

そもそも OSやdistributionごとにパッケージの名称などは異なるのですから、このような点を抽象化・共通化するのは困難です。Ansible では、これらの抽象化しきれない実装依存な箇所の処理を Ansible の利用者に委ねる、という割り切ったポリシになっています。この割り切りは一貫しており、ネットワーク機材の対応においても、その特徴は表れています。つまり、全てのネットワーク機材の場合に抽象化された config、command といったモジュールで賄うことはせず、機材ベンダやそのOSごとに別々のモジュールを用意しています。

Ansible では過度な抽象化を行なわず、Ansible というフレームワーク内で現実的な手順書を記述することで Automation を実現することをめざしています。そのため、

Better than Shell script

と呼ばれることもありますが、Network Module の場合は、

Better than Expect

そう呼んで良いかと思います。