ネットワークテクノロジー課の渡部です。
NW自動化開発課のマネージャーを務める傍ら、プレイングマネージャーという形でエンジニアとしても活動しています。
本ブログでは、様々なNW自動化にまつわるトピックをご紹介していくのですが、まず第一弾としてRobot Framework関連の記事を拡充していくことを予定しています。
第一弾をRobot Frameworkとした最も大きな理由は、我々のチームではPythonと同等に近いチームのコア言語となっているため、皆様にご紹介したいKnowledgeが既に蓄積されているからです。
本記事では、なぜRobot Frameworkがチームのコア言語として利用されているかをご説明させて頂きます。
Robot FrameworkとはOSSとして公開されているTest Automation Frameworkです。
近年ではTestに留まらずRPAのFrameworkとしても利用されていますが、基本的にはTest Frameworkとしての特徴が色濃く出ているFrameworkとなっています。
Robot Frameworkの主要な機能は下記の３つです。
上述の機能は試験や作業においては非常に重要であり、これらが自動で実行できるRobot Frameworkはとても有用なツールであると言えます。
しかし、Robot Frameworkも万能ではなく、本格的に利用するには以下のコストが発生します。
あえてコストと述べましたが、これらの学習コストが小さいのもRobot Frameworkの特徴です。Robot言語は簡潔でわかりやすいものであり、Driverを作成する必要があるといってもPythonで記載できるためPythonベースのチームにおける習熟はそこまで高いものではありません。
また、NW自動化開発のLibraryはPythonであることが多いため、NW自動化開発チームにとってRobot Frameworkは習熟のしやすいOSSであるといえます。
前章で述べた通り、技術要素としてNW自動化開発チームとRobot Frameworkの相性は良いのですが、最も相性が良いポイントは技術要素ではなく、業務の特性にあります。
Robot Frameworkは元々Test Frameworkであるため、最も得意な分野は試験となります。
試験というものは言い換えると「特定の前提条件において、特定の結果が得られることを確認する」というものでしかありません。
この特定の条件と特定の結果が定義できれば、試験という工程である必要はありませんので、ユースケースに制限はありません。
つまり、試験の工程以外でもTest FrameworkであるはずのRobot Frameworkの恩恵を受けられるということになります。
手動でのNW検証・運用を想像してみましょう。
いわゆるNWエンジニアが日常的に行っている業務です。
それらの業務は抽象的には「Commandを発行して、目的通りの動作をしているか状態を確認する」という作業に集約されます。
例えば、BGPで経路の交換ができることを確認する検証を想像してみてください。
その場合、実施される作業はとなり、すなわち、Configの投入と確認の繰り返しとなります。
NWの状態が正常であるということを確認する運用作業の場合には、
のような形で、コマンドの発行と確認の繰り返しとなるためほぼ同等となります。
場合によっては、検証や作業の過程においてSNMPやSyslogサーバーに必要に応じて情報を取得して確認をしたり、パケットキャプチャを取得するケースもありますが、広義の意味では「Commandを発行して、目的通りの動作をしているか状態を確認する」という作業に過ぎません。
上記を踏まえるとこれらの作業を自動で実施するためには、
といった機能が必須になります。
また、一般的にNWを構成する装置のメーカーは１つに留まらないことや、装置や周辺機器によってはCLI over SSHだけでなくREST APIやGUIなど様々な形式のインターフェースが存在しているため、インターフェースの形式に問わず上記の機能を実現する必要があります。
Robot Frameworkのアーキテクチャと主要機能によって、上記の問題を全て解決することが可能です。
Robot Framework自身で解決できない場合も、必要な機能を拡張することで対応が可能です。
Robot FrameworkはAssertionという機能を有しており、対象の値が指定した条件を満たしているかを判定することが可能です。
例えば、変数Xの数値が5であること、のような判定をさせることができます。一般的なプログラミングにおけるIF文の条件式と似ています。
IF文は判定を手段とした制御を目的とした文ですが、Assertionは判定自体を目的とする処理となっており、条件を満たしていればSuccessとし、満たしていなければFailと扱います。
つまり、この作業を実行した後にこういう結果返されるべきである、という記述をすることで確認（試験）することを可能にします。
また、Assertionとは別の機能となりますが、Robot FrameworkはPythonのErrorをCatchすることも可能です。
Robot Frameworkでは上記のAssertionの結果だけでなく、実行途中にError Objectを検知するとそれをErrorと判断し、Failと扱います。このFailの扱いはAssertionでFailと扱った時と同等の動作をするため、Assertionを記載しなくてもErrorを検出した段階でFailとなるという仕様になっています。
Robot Frameworkは自動実行した試験の結果をHTML形式のlogとしてReportingすることが可能です。
Reporting機能は特別な実装をする必要がなく、Robot言語でシナリオを記述することだけで自動で生成されます。
生成されたlog.htmlではSuccess/Failが一目でわかるようになっており、試験の数や成功失敗の統計等も見やすくまとめられています。
試験の結果は膨大になることがよくありますが、階層ごとにSummarizeされており、非常に見やすい階層構造になっています。DrillDownすることで詳細まで確認することが可能なので、必要に応じて詳細な確認をすることが可能です。
さらに、Failしている場合には自動的にFailしている場所だけが展開されて表示されるため、切り分けのときには必要な情報だけをすぐに確認することが可能です。
Robot Frameworkは一部のDriver(Keyword)が提供されていますが、基本的には利用者が自由にDriverを実装するという思想に基づいています。DriverはPythonで実装することができ、Pythonの関数をKeywordとして直接呼び出すことができます。引数等の概念もPythonを踏襲しているため、Python開発者であればすぐにDriverの開発が可能です。PythonDriver開発に関連するAPIやデコレーター等も充実しており、簡単にDriverを開発・組み込みすることが可能です。
NWを自動化する際には様々なインターフェースを利用するのですが、Netmikoやncclient、Seleniumと呼ばれる有用なPython Libraryを利用することで様々なインターフェースの操作が可能です。Python LibraryはRobot Frameworkから呼び出されるDriverでも利用できるため、PythonをDriverとして利用し、Robot FrameworkからそれらのLibraryを利用できることは大きなメリットとなります。
検証や作業等はRobot Frameworkにおいてはシナリオに相当するものとなり、Robot言語を用いて記述することができます。
シナリオを用いて自動化をするにあたり、下記のようなケースが一般的に発生することがあります。
これらの制御はRobot Frameworkに具備している機能で実現可能であり、簡単に制御することが可能です。
Pythonで実装することも可能ですが、既に存在する機能を利用しない手はありません。
自動化の開発において装置の制御も重要な分野ではありますが、シナリオの制御はより重要であり、シナリオの制御の小回りが効くかどうかは開発工数や品質に大きく影響してきます。
本記事ではRobot Frameworkの利点やNWの自動化との親和性を紹介しました。
Robot Frameworkのユースケースは無限大であり、近年ではRPAツールとしての利用も増えてきています。
開発も継続的に行われており、機能追加やCommunity活動も活発なため、今後も発展が見込まれるOSSだといえます。
有用な反面、非常に機能が多いOSSであるため、それらを認識してうまく使いこなすかによって開発効率の良し悪しが左右されてしまう側面もあります。
本ブログでは、我々のチームが今まで経験してきた中で培ってきた便利な機能やベストプラクティス等を公開していく予定ですので、皆様のRobot Frameworkライフが少しでも豊かになるお手伝いができるように頑張りますので、応援よろしくお願いします！