キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
告知

 Mar.topbanner.JPG

 AMATopBanner2021.4.JPG

 

NSO サービスモデルの開発環境について

  • NSO
102
閲覧回数
0
いいね!
0
コメント

背景/前提

NSOサービスモデルを開発するにあたり、ある程度の規模・人数での開発になると開発環境を整えることが重要になってきます。我々のチームでも、日々より良い形でのサービスモデル開発のための環境整備を実施しており、現状でのナレッジを本記事にてご紹介させていただきます。より良い手法等がありましたら是非コメント等でご連絡いただければ幸いです。

 

開発環境

実機利用および複数人での開発を想定しているため、Mac上での開発ではなくRemoteでのUbuntuを想定しています。イメージとしては下記の環境を想定しています。Mac Localでの開発も行っておりますが、実機との接続を考慮すると下記のモデルになるケースが多いです。

 

screenshot 2021-02-23 13.43.10.jpg

 

IDE

サービスモデルを開発するにあたり構成されるファイルは、以下のように多岐に渡ります。

 

  • YANG
  • Python/Java
  • XML

XMLについてはNSO自身がexportするXMLをCopy&Pasteするだけですので問題はありませんが、YANGや特にPython/Javaは一般的なプログラミングの要素となりますので、テキストエディタでの開発では限界があります。そのため、NSOのサービスモデル開発にはIDEを利用することが推奨されます。IDEには様々な種類がありますが、本記事ではVisualStudio Codeでの利用方法について記載致します。

 

Visual Studio CodeのPluginについて

VisualStudio Codeには様々なPluginが存在するのですが、下記のPluginがNSOのサービスモデル開発では有用です。筆者の環境はpythonでの開発を実施しているため、Javaについては割愛しております。

python

Pythonコードのsyntax highlightやインテリセンス(構文補完)などを実施するPluginです。NSOではpythonを利用して開発しているため、必須のPluginとなります。NSOではmaapi等のNSO特有のPython Libraryも利用するため、適切な設定をすることでNSOのPython Libraryのmethod等もインテリセンスが有効になるため、開発効率が上昇します。

 

screenshot 2021-02-23 13.48.16.jpg

Remote-SSH

遠隔の開発環境にログインして、ファイルの編集およびターミナルの実行を可能にするPluginです。接続にはSSHの鍵認証を実施するため、事前に開発端末で公開鍵を作成したうえでNSOが動作するサーバーの上に公開鍵を配置する必要があります。(ssh-copy-id等を利用すると簡単に済みます)。また、NSOのインストール環境(System or Local)によるのですが、権限の問題があるためRemoteでログインする際の権限はsuper userにしておくことが望ましいです。

 

このPluginを利用することで、複数人が同一のNSO環境にログインした上であたかもローカルで操作しているような操作性で開発ができるようになります。

 

1点注意点として、VS codeの仕様となりますがRemote SSHでログインしているプロファイルではpython plugin等はRemote SSH環境ごとにインストールする必要がありますので、pythonのインテリセンスが動作しない時等はログインしているRemote SSH環境にpython pluginがインストールされているかを確認する必要があります。

Yangster/YANG syntax highlither

YANGの構造を理解して補完やinclude/submoduleの関連性等を表示したり、syntax highlightを実施してくれます。YANGは慣れれば読みやすい言語なのですが、慣れないうちはこのようなヘルパーを利用して開発することをおすすめします。

git lens

下記のGitにも関連するのですが、行ごとのcommit履歴を表示できたり、gitに関連する様々な機能が利用できるためサービスモデルの開発でも有用となります。

Git

サービスモデルには複数のファイルが含まれており、かつ様々な追加および変更が適用されます。そのため、一般的な開発物と同様にGitでの管理がversion管理やリリース管理の観点で望ましいです。しかし、サービスモデルにはバイナリファイルが含まれていることもあり、適切な形でのGit管理を行うことが重要となっています。

 

NSOサービスモデルでは下記のファイルがGitに含まれることが望ましいです。基本的にはテキストファイルで管理されているものはすべてGitに配下に存在していることが望ましいです。

 

  • YANG
  • python
  • template xml
  • metadata xml
  • Makefile

反対に、コンパイルの時に作成されるfxsファイルのようなバイナリファイルはgitの外で管理されるべきです。したがって、.gitignoreは一例となりますが、下記のように記載することが除外が可能です。

 

load-dir/*.fxs
.DS_Store
.idea/
*.pyc

git initはサービスモデルをncs-make-packageで作成された際にできあがるディレクトリの直下で実行することで、python/src/temlpates/testなどが含まれるためinitはディレクトリ直下で実行されるのが一般的かと思われます。

 

少し考え方を帰るとNEDもサービスモデルの一部としてversion管理とすると言う考え方もありますので、このあたりについては優先すべき管理事項を何とするかを起点として、使いやすいGit管理の方法を採用すべきだと思います。

CI

サービスモデルを継続的に開発するにあたり、CIの考え方は非常に重要になります。適切なCI環境および文化を取り入れることで機能追加や改修のスピードを向上することが可能です。NSOのCIはその他の開発のCIよりも難易度が高いと言えると考えています。その理由として、理想的なNSOの試験は装置の実機を用意することであり、CIではない通常の総合試験のような形では実機での試験を実施することが多いです。しかし、CIの環境で全ての装置の実機を用意することは費用面だけでなく様々な要因により現実的ではありません。そのため、CI環境には以下のようなパターンが考えられます。

 

  • 実機を用意する(理想)
  • netsimを利用する
  • 仮想ルーター等を利用する
  • スタブのようなものを開発する

これらの環境については各々の環境によって最適な形が違うため、本記事では特に言及せずに、試験Frameworkについて記載致します。

 

NSOにおける自動試験は下記のサイクルで実施されることが一般的だと考えられます。

 

  1. 試験環境を用意する(NSO,Network,Config)
  2. 試験項目を実施する(RESTCONF/REST API etc)
  3. 試験結果が正しいか確認する(Response body/実機Config)

これらを実施するために、試験のFrameworkを利用する形になるのですが、世の中には様々な試験Frameworkが存在しています。我々のチームではRobot Frameworkを利用しており、開発したNEDやサービスモデルのレグレッション試験、サービスモデルの新規機能の試験等はRobot Frameworkを用いて試験を自動化しております。

Robot Framework: https://robotframework.org/

 

Robot Frameworkは以下の特長があります。

 

  1. 試験コード(Robotファイル)が可読性が高く、柔軟に試験コードが記載できる
  2. プラグインが開発可能なため、NSO + αのようなマルチレイヤー試験が実施可能
  3. プラグインが開発可能なため、試験環境の準備のようなScriptも実施可能
  4. 試験結果のレポーティング機能が優れている

下記にサンプルの試験レポート結果を記載致します。とても見やすくまとまるため、非常に優れています。

 

 

screenshot 2021-02-23 13.38.39.jpg

 

NSOのCIについては上述したとおり環境の用意等の様々な課題がありますが、Robot Frameworkでの試験の自動化を起点とし、よりよりCI環境を検討していく予定です。