Sysadmin Toolbox

第2回 Perlによるテストの自動化

この記事を読むのに必要な時間:およそ 6.5 分

管理者の重要な仕事のひとつに,テストがあります。新しいシステムのテスト,H/W, OSやソフトウェアなどの移行にともなうテスト,過去に発生したミスの再発防止テストなどいろいろなテストありますが,目的はシステムが要件通りに稼働し続けることの保証です。今回は,テストの自動化を取り上げます。

テストの自動化

安定したシステムにテストは欠かせませんが,みなさんの環境ではどのようにテストをしているでしょうか。手順がExcelに並べられているだけだったりしませんか。ミスが起きたら,再度同じミスをしないためのテストをしていますか。ミスが起きない,もしくはミスがあってもできるだけ迅速に検知できることをテストで保証できているでしょうか。

以前ファイアーウォールの移行作業をしたのですが,製品のベンダが異なるためACLの記法も異なり,設計思想も異なっていため,簡単にはACLを移行することができませんでした。ACLも1,000のオーダーに達していたため,作業中に発生するミスを考えると,ちまちま手作業で移行することも無理でした。導入にあたってはベンダによるサポートがありましたが,彼らの方法論は「ExcelにACLをコピーして,手作業で書換える」という,ユーザとしては受け入れ難いものでした。

さて,この移行作業をどうテストすればよいでしょうか。手作業にはミスがつきものですから,ACLは自動で変換したいところです。また,変換したACLに間違いがないかを事前に検証したいですね。ACLは内部のサブネットごとに異っていたので,各サブネットから移行前と移行後で同じACLが適用されていることを,事前に検証したいところです。

いろいろあったものの,最終的にはPerlによる変換スクリプトと独自のテストスクリプトを作成し,ほぼ上記の目的は達成し,移行することができました。これは,前述したモジュールがなければまず無理な作業でした。現場ではさまざまな要件がでてきますが,困ったときでもなんとかそれを可能にしてくれるPerlのモジュールが,Perlを管理者にとってかけがえのない言語にしていると思わせる一件でした。

本題に戻ってテストの自動化です。人為的ミスという言葉がありますが,人間はミスをするものですから人為的ミスを前提にテストしなければいけません。なくすことは無理であっても,人為的ミスが入り込む余地をテストで極力減らす必要があります。それなのに,そのためのテストが手動であってはいけません。ですから,テストは自動化するべきです。

なぜPerlなのか

以前は,Perlならだいたいのホストにインストールされていると言われたものでしたが,いまやRuby,Pythonといった言語もデフォルトでインストールされていることは珍しくありません。では,管理者がPerlを使うメリットとはなんでしょう。

Perlの最大の強みのひとつは,その膨大な数のモジュールであると言われます。PerlのモジュールはCPANと呼ばれるリポジトリで公開されており,執筆時点で6,000人以上の開発者が12,000を超えるモジュールを公開しています。これらのモジュールには,管理者のために管理者によって作成されたモジュールもたくさん含まれています。「怠惰」は管理者の美徳のひとつですから,すでに公開されている既存の資産を利用しない手はありません。

CPANで公開されているモジュールを再利用するメリットはそれだけではありません。こうしたモジュールは不特定多数によってさまざまな環境で使われますので,ある程度の品質を期待できます。少なくとも,外の世界と隔絶され,誰にもレビューされることのない環境で書かれたプログラムよりは品質が高いと期待できます。品質の高いモジュールを使えば,全体のコードの品質があがるというわけではありませんが,同じ程度にダメなプログラムなら,壊れた独自のライブラリによって書かれたプログラムより,CPANのモジュールを使って使っているプログラムの面倒を見る方がまだましです(往々にして,管理者によって書かれたプログラムは,ドキュメントなし,コメントなし,書いた本人はいない,ということが多いですから)。

CPANモジュールの使いかた

CPANで公開されているモジュールは,cpanというCPANのパッケージ管理システムでインストールすることができます。ただし,Mac OS XをのぞくUnix-like OSのディストリビューションでは,それぞれのパッケージ管理システムでCPANのモジュールを管理できますし,ディストリビューション固有のサポートも受けられますので,ディストリビューションのパッケージ管理システムから利用するのがお勧めです。例えば,Gentoo/Linuxではg-cpanというコマンドで,Portageに存在しないモジュールでも自動的にebuildを作成して,Portageからインストールしたかのように管理できます。詳しくは,お使いのディストリビューションのマニュアルを参照してください。

インストールしたモジュールのマニュアルはperldocコマンドで参照できます。Foo::Barというモジュールならperldoc Foo::Barで参照できます。モジュールのソースコードもperldoc -m Foo::Barといったように,コマンド1つで見ることができます。

モジュール紹介

管理者にとって便利なモジュールをいくつか紹介します。

Net::Ping, Net::Ping::External
ホストの到達性をテストするモジュールです。ICMPだけでなく,TCPやUDPを使うテストも可能です。
Net::DNS, Net::LDAP, Net::SMTP, Mail::POP3Client, libwww-perl
それぞれ,各種アプリケーション層のプロトコルを利用するためのモジュールです。
Net::DHCP, Net::BGP, Net::SNMP
L2/L3機器を監視したり,保持しているデータを処理するのに便利なモジュールです。
Net::IP, Net::Netmask, NetAddr::IP, Net::MAC::Vendor
IPアドレスの処理や操作には欠かせないモジュールです。
Net::Telnet, Net::SSH, Net::SSH::Expect, Net::SSH::Perl
実際にコンソールにアクセスしなければできない操作をPerlから実行するのに便利なモジュールです。
Net::Pcap, Net::Packet
より低レベルのネットワーク通信にアクセスを提供するモジュールです。
Nmap::Parser, Nagios::Object, POE::Filter::Snort
管理者におなじみのツールにPerlでアクセスできるモジュールです。

いかがでしょう。少しの想像力とこうした強力なモジュールがあれば,大体のことは自動化することができます。

著者プロフィール

Tomoyuki Sakurai

流しのsysadmin。Aさん曰く「厳しい人。怒られそうで恐い。でも,おそらくいい人で頼りがいのある人」。Bさん曰く「厳しい。けど優しい。けど甘くはない」。

OpenBSD Support Japan Inc
URLhttp://www.openbsd-support.com/

コメント

コメントの記入