てくなべ (tekunabe)

ansible / network automation / 学習メモ

JANOG43 レポートその3【ハッカソン編】スタッフ兼参加者として

event janog

はじめに

f:id:akira6592:20190201174616p:plain:w400
ハッカソン風景

2019/01/23-25 に山梨県甲府市のコラニー文化ホール（山梨県立県民文化ホール）で開催された JANOG43 Meeting in Yamanashi に参加してきました。（ハッカソンは1/22）

本ブログでは、3回に分けてレポートします。

JANOG ハッカソンとは、ネットワーク運用における自動化や可視化などをテーマにして、チーム（または一人）で仕組みを作るイベントです。今回は、スタッフ兼参加者として関わらせていだきました。

本記事では、スタッフと参加者の両面での準備や当日の様子などをまとめます。

なお、Day2 の JANOG43 ハッカソン Wrap-up & Winnerでも、当日の様子やアンケートが公開されていますので是非ご覧下さい。



■ 経緯と準備

スタッフか参加者か

2018/09/19に、JANOGのメーリングリストに「[janog:14433] JANOG43 ハッカソン 開催のお知らせ & スタッフ応募 のお知らせ」というタイトルで案内がありました。 JANOG42 での初開催に引き続き2回目の開催です。JANOG42 では参加できなかったため、今回は何かしらの形で関りたいと思いました。

この時は、丸一日も集中力が持たないと思って、参加者ではなくスタッフとして応募しました。

スタッフミーティング・役割分担

計2回オンラインでのミーティングで役割分担や状況の共有、当日の流れの確認などを行いました。

一例ですが、役割としては以下のようなものがありました。

  • 応募者連絡窓口
  • 仮想環境準備
  • 会場ファシリティー
  • 当日司会
  • 優勝チーム投票＆集計 → 私はこれを担当
  • 懇親会手配

準備の期間は一度もリアルで集まることはなかったのですが、オンラインミーティングの映像と、スタッフ向けのSlackで実写アイコンが推奨されていたため、当日に戸惑うことはあまりありませんでした。

テーマ案の書き込み

私が書き込んだのは以下の3つです。私自身がやるぞ、というわけではなく、参加者のアイディアのきっかけになればと思っていました。

  • パラメーターシートの自動生成
    • コンフィグかshowコマンドの結果を収集、パースしてテンプレートに埋め込み、パラメーターシート（markdown程度？）を生成する
    • Python / Ansible など
  • 障害発生時の情報収集の自動化
    • 障害発生を何かしらで検知、トリガーにして、障害調査に必要なshowコマンド結果を自動実行、収集する
    • Python / Ansible など
  • 障害発生時の自動復旧
    • 障害発生を何かしらで検知、トリガーにして、障害復旧に必要なコマンドを自動実行する（難しそう）
    • Python / Ansible など
  • 設定変更の事前検証の自動化
    • 設定変更しようとする内容が、意図した通りになるかをBafishで検証してOK/NGを返す。余裕があれば投入までパイプラインのようなもに
    • Batfish / Python / Ansible など

ほかにも、参加者などからさまざまなテーマが書き込まれました。実際になにをやるかは当日に最終決定するので、この時点では案出しと興味の表明程度です。



■ ハッカソン当日（Day0: 2019/01/22）

スタッフの朝はちょっと早い

f:id:akira6592:20190201170958p:plain:w400
「OUT」の文字は外から見ると逆に

会場となる山梨県立図書館に、スタッフは 9:00 集合。あまりちょうどいい特急がなく、早めの到着です。図書館は外から見ても伝わる素敵感でした。

会場の準備

f:id:akira6592:20190201171125p:plain:w400
チーム数が決まっていないなかで配置

2Fの多目的ホールが会場です。ここでスタッフは机やいす、電源タップなどの準備をしていきます。 10:00 に近づくと続々と参加者が到着しました。

チームとテーマ決め

開始のあいさつや、環境の説明が終わると、あらかじめ書かれたテーマ案について簡単に説明する時間が設けられました。これを聞いた後に、実際にチームを組んでいきます。

なお、最終的には以下の8つのチームになりました。

  • id1: トラッフィックコントロール最適化
  • id2: 「Linux標準教科書」のNotebook化
  • id3: NW構成管理とトラフィック経路の世代管理/ ルータ状態の記録・保存および管理、経路の見える化
  • id4: ルータの正常性確認の自動化
  • id5: ansible＋githubフローでテスト自動化
  • id6: データ収集・オペレーション自動化によるNW運用の改善
  • id7: Telemetryを用いた障害検知と復旧の自動化
  • id8: NW flowとDNS 名前解決を合わせたデータ分析

私たちのチームは

f:id:akira6592:20190201171528p:plain:w400
チーム＆テーマ相談中
大変ありがたいことに、親和性の高いテーマ案のチームが集まって、一緒にやろうとお誘いをいただいたて「Telemetryを用いた障害検知と復旧の自動化」に取り組むことにしました。なので、スタッフ兼参加者となりました。

OSPFによる冗長構成されたネットワークで、通常経路中ルーターのインターフェースに異常があった時に、自動でコスト変更をして経路を迂回させ、事後経路の情報を通知する、というものです。

利用ツールや技術は以下です。

  • 仮想ネットワーク機器（IOS XRv、vEOS）
    • XRv は Telemetry に対応したバージョンを持ち込みデプロイ
  • Telemetry
  • Prometheus
  • Ansible
  • Grafana
  • skack

ラボ環境

今回は、JPNIC様にご協力いただいて、IOS XRv、vSRX、cEOS、Ubuntu、CentOSが、数台ずつの環境となりました。もちチーム独自で準備した環境を利用してもOKです。

レッツ作業

各チームがテーマに沿ってモノを作り上げる作業をしていきます。

f:id:akira6592:20190201171626p:plain:w400
構成

私たちのチームでも構成を図にして、ルーター設定、Telemetry関連、Ansible関連のように役割分担をしていきます。 だいたい1つの役割につき1コンテナ(docker)を利用し、docker-compose でまとめる、といった構成です。軽いVMの代わりとしてコンテナを使いましたが、役割を分けつつ、最後は一つの成果物にしたいハッカソンのチームには相性が良いと思いました。

f:id:akira6592:20190201172259p:plain:w400
作業中

私は、Ansible の Playbook を Web API で実行させる仕組みのところを担当しました。 API といえば、Ansible Tower や AWX が持っている機能です。ですが、あえて最近知ってまだ試せていなかった ansible-runner-serviceに挑戦しました。 localhost を対象とした Playbook を実行することはできたのですが、インベントリを作成する方法が分からずかなり苦戦しました。

時間が途中でなくなってきたので、結局 flask で簡易的な Web API もどきを書いてしのぎました・・。

（後日談）

なお後日、YAML で定義すればよいことが分かりました。



発表と投票

17:00 で作業終了。この時間までに各チームで発表資料を作り、ここからは発表と投票の時間です。

f:id:akira6592:20190201173405p:plain:w400
発表中1

f:id:akira6592:20190201173255p:plain:w400
発表中2

投票は Slack 上で行いました。各チームの発表を聞いて、自分がいいなとおもったら、いいねのする形式です。

f:id:akira6592:20190201173047p:plain:w400
いいねのリアクションとして投票（画面は抜粋）

見事優勝したのは「NW flowとDNS 名前解決を合わせたデータ分析」をテーマにしたチームです。おめでとうございました！

優勝チームは Day2 の JANOG43 ハッカソン Wrap-up & Winner の枠でプレゼンする権利が与えられます。



■ Wrap-up & Winner

f:id:akira6592:20190201171918p:plain:w400
Wrap-up & Winner

Day2 の JANOG43 ハッカソン Wrap-up & Winner で、ハッカソンの概要、当日の様子、アンケート結果、優勝チームのプレゼンが行われました。

資料

アーカイブ配信 （2019/02/28 12:59 まで）



■ まとめ・感想

JANOG ハッカソンのスタッフ兼参加者としてあれこれをまとめました。

普通に使われる Ansible

ツールとしては、8チーム中5チームがネットワーク機器の操作に Ansible を利用していたのが印象的でした。

反省

みなさん技術力がとても高く圧倒されました。特に私が足りないと思ったの、Telemetry や監視ツールの知識です。

また、参加者として作業に集中しすぎてしまいました。スタッフとしてももっと他チームの様子も見たりすればよかったと思いました。（Ansibleの質問は少しだけ答えられましたが・・）

時間がいくらあっても足りない

前回のハッカソンは半日開催でしたが、短いという声が多く、今回は一日開催となりました。 ですが、一日でも足りず、チーム内で「なにを諦めて、どこを落としどころにするか」を決めるというタスクが自然発生します。 おそれくこれはいくら時間があっても足りない話な気がしています。

ハッカソン参加への不安を解消するには

テーマを決めるうえで大きなポイントは以下の2つです。

  • 当日に何を実現したいか（What）
  • 何を使うか（How: プログラム言語やツール）

What のほうがより重要だと感じています。もし、How のほうが強いのであれば、その How が活用されそうな他のチームを探して一緒にやるのが良いと思います。

How の面では、今回や過去のJANOGでも参考になるプログラムがありました。どんなツールで何ができるの？どう使うの？のヒントになると思います。

さいごに

とても楽しく、良い思い出になりました。ありがとうございました。

f:id:akira6592:20190201173549p:plain:w500
お疲れ様でした！

写真は JANOG43 スタッフの伊藤さんが撮影されたものも利用させていただきました。ありがとうございました。

JANOG43 レポートその2【登壇編】自動化の行き着く先は?

event janog network automation

はじめに

f:id:akira6592:20190131170832p:plain:w300
自動化の行き着く先は?

2019/01/23-25 に山梨県甲府市のコラニー文化ホール（山梨県立県民文化ホール）で開催された JANOG43 Meeting in Yamanashi に参加してきました。（ハッカソンは1/22）

本ブログでは、3回に分けてレポートします。

その2である本記事では、「自動化の行き着く先は?」に登壇するまでの経緯や準備、当日の様子などををまとめます。


■ 経緯と準備

答えがなく、悩ましい話題

JANOG43 のプログラム公開後、登壇者である後藤さんからお誘いいただき、後から追加で入れさせていただきました。プログラム委員の方々調整ありがとうございました。

普段扱っている Ansible などのツールの話ではないため、正直どのような観点でお話するか悩みました。後藤さんからのドラフトのスライドを拝見すると、運用の価値や運用自動化の目的についての問いかけがいくつかありました。

そのため、プログラム後半の参加者含めたディスカッションのきっかけとなるような、一つの意見を述べるかたちにしました。ただ、言語化は難しかったです。読むと当たり前のように感じる言葉でも、実際自分で書くとなるなかなかですね・・。

f:id:akira6592:20190131165702p:plain:w300
考え中の意味不明なメモ

■ 発表

www.janog.gr.jp

アーカイブ配信 （2019/02/28 12:59 まで）

資料

togetter まとめ


■ ディスカッション

f:id:akira6592:20190201103157p:plain:w300
プログラム後半はディスカッション
ツイートをピックアップさせていただきます。ツイートありがとうございました。

togetter まとめ


■ 野良BoF

後藤さんの主催で、当日の午後に「運用自動化時代の運用者のあり方とは？」という野良BoFが開催されました。野良BoFとは、JANOG43ミーティング実行委員会が管理、選考を[通常BoF]とは異なり、主催者で管理、運営するタイプのBoFです。「自動化の行き着く先は?」の続き的な位置づけのものなので、私も参加させていただきました。

プログラム本編では出てこなかった、物理作業のつらみの話もありました。

togetter まとめ


■ まとめ・感想

今回は、自動化の仕組みを作る側と使う側に分かれるとうまくいかず、運用者自体が自動化を作ったほうがよい、という意見が多かったように感じます。

今になって少し疑問になってきたのですが、そもそも分けるとかチームとは何でしょうか。お財布の分け方でしょうか、それとも単純にリーダーとメンバーの体制の単位でしょうか。もしかしたら、仮に作る側のリーダーと使う側のリーダーが同じでも、お財布（予算）が同じだと、また論調が異なってくるものでしょうか。

着地点のない話題ですが、何かしらのヒントや考えるきっかけになったのであれば幸いです。 参加者のみなさま、お誘いいただいた後藤さん、スタッフみなさま、本当にありがとうございました。

JANOG43 レポートその1【参加編】

event janog

はじめに

f:id:akira6592:20190130131715j:plain:w400
開会宣言
2019/01/23-25 に山梨県甲府市のコラニー文化ホール（山梨県立県民文化ホール）で開催された JANOG43 Meeting in Yamanashi に参加してきました。（ハッカソンは1/22）

本ブログでは、3回に分けてレポートします。

その1である本記事では、参加した本会議の各プログラムの一覧と、いくつかピックアップして感じたことなどをまとめます。



■ 参加したプログラム一覧

「★」は本記事ピックアップ対象のプログラムです。

Day1

Day2

Day3



■ ネットワーク運用を楽にするチュートリアル

www.janog.gr.jp

(プログラム説明ページから引用)

本セッションでは、ネットワーク運用者の負担を軽減するツールの例や開発のヒントを紹介することで、JANOGのみなさんがすぐにでも業務改善にチャレンジしていただけるようになることを目的としています。 そしてネットワークの業務改善のノウハウやアイディアを貯めていただき、次回JANOGハッカソンに挑戦していただけることを期待しています！

発表者

アーカイブ配信（2019/02/28 12:59 まで）

資料

本プログラムは概要編と実践編の2部構成でした。

概要編

自動化にも難易度やリスクによっていろいろ

f:id:akira6592:20190130120659j:plain:w550
リスク・難易度別の業務改善例

概要編では自動化が求められる背景（スピードやスケール）や、自動化を小さく始めていきましょう、といったお話でした。

特に印象に残っているのは、P11 の「ネットワーク運用業務改善の一例」です。自動化とひとことでいっても、難易度やリスクが低いものもあれば、高いものがある、ということを示されていました。

まずは作業の整理、それから参照・通知系、設定系・・、と難易度とリスクが高くなっていきます。いきなり難しくてリスクの高いところを目指すのではなく、ステップを踏んで自動化をすすめて行きましょうと話をするときに、こういった基準があると良いと感じました。

実践編

WebAPI は怖くないし便利

f:id:akira6592:20190130115859j:plain:w550
WebAPIは便利

実践編では、WebAPIとは何か、具体的なツールやコードが紹介されていました。 WebAPIは、おためしとして郵便番号検索API、実践サンプルとして LibreNMS のAPIが紹介されていました。

LibreNMS は初耳でした。ネットワーク機器のコンフィグ収集するツールであるRANCID や、oxidized などとも統合できるようです。

togetter まとめ



■ 自動化の行き着く先は?

www.janog.gr.jp

発表者

  • 後藤 芳和さん (株式会社リコー)
  • 横地 晃 (株式会社エーピーコミュニケーションズ)

アーカイブ配信（2019/02/28 12:59 まで）

資料

リコーの後藤さんと私が登壇したプログラムです。詳細は、レポートその2 登壇編でお伝えする予定です。

togetter まとめ



■ LINEのネットワークをゼロから再設計した話

www.janog.gr.jp

（2019/02/28 12:59 までアーカイブ配信あり）

発表者

  • 小林 正幸さん (LINE株式会社)

アーカイブ配信（2019/02/28 12:59 まで）

資料

JANOG 39 で共有したインフラの課題解決や、新しい技術へのチャレンジとしてネットワークアーキテクチャを刷新したお話。技術的に圧倒されるものが目白押しでした。

f:id:akira6592:20190130155613j:plain:w550
CLOS Network 構築には ZTPとAnsibleを利用

シンプルな設計とはなにか

技術的な面で圧倒されたことはもちろんなのですが、特に設計思想がしっかりされている点が印象的でした。（資料 P4）例えば、シンプルなネットワークとはとは何かをきちんと定義していることです。

  • 使用するプロトコルが最小
  • そのプロトコルがオープンであること
  • ネットワーク機器がステートレスであること

シンプルという言葉でまとめてしまうだけだと、認識の齟齬が出てしまったり、目指しているところがぶれてしまったりしそうです。ですが、このようにきちんと言葉の定義をしておくことで、本当に良い設計ができるのだと感じました。

togetter



■ ストレスフリーなオペレーション環境を目指して

「初心者歓迎! Light Lighting Talk大会」の中のひとつ。 www.janog.gr.jp

発表者

資料

人の感情という軸の発見

もし私が同じ内容で発表するとしたら、タイトルに「自動化」を付けてしまうと思います。 つい自動化や効率化のように、機器やツール、作業の方に注目してしまうためです。 ストレス/ストレスフリーといった、人の感情という軸を私自身は持ってなかったので、新たな気付きになりました。

また、この日のどこかのプログラムできいた「自動化という言葉で考えると見えないこともある」という言葉を思い出しました。


■ IDCフロンティア ネットワーク運用システムの課題と挑戦

www.janog.gr.jp

（2019/02/28 12:59 までアーカイブ配信あり）

発表者

  • 見崎 徳仁さん (株式会社IDCフロンティア)

アーカイブ配信（2019/02/28 12:59 まで）

資料

IDCフロンティアさんがネットワーク運用面で抱えていた課題に対して、どう取り組んできたかというご紹介でした。 大きく分けて、トラフィックの可視化、ネットワーク作業の自動化です。

f:id:akira6592:20190130142730j:plain:w550
自動化に利用したツール

設定を消すための工夫

後半のネットワーク自動化の取り組みの中で、設定を削除するときの工夫のお話がありました。(資料 P31) Ansible Playbook で利用する Jinja2 テンプレートの中で、定義ありの時は通常のコマンド、定義なしの時は no コマンドを生成するように工夫されていました。 宣言的ではなく、手続きベースの自動化場合、こういうった工夫が必要になります。

この点については、大変興味深いのでまた別の記事で深掘りしてみたいと思います。

（2019/02/18 追記） 「ネットワーク設定自動化に利用するインプット形式の分類（範囲、処理形式、表現形式別） - てくなべ (tekunabe)」という記事でネットワーク設定自動化に利用するインプット形式の分類についてまとめました。この分類では「[3] 部分宣言的パラメーター」に該当します。

コンフィグのシンタックスチェッカーとしてのコンテナNOS

パイプラインの中に、コンフィグのシンタックスをチェックするためにコンテナのネットワークOSを利用されている点も興味深かったです。自動化の仕組みも人が作るのでバグは発生し得ます。予期せぬコンフィグが生成されたことに設定投入前に検出することで、安全にする工夫なのだと思います。

また、質疑応答の時間で以下の質問をさせていただきました。（動画 37:25頃から）ありがとうございました。

    1. インベントリはどのような形でマージリクエストを出しているのでしょうか。既存のインベントリファイルを編集してマージリクエストするかたちか、対象ホスト名のみを指定したパラメータ的なものか。
      1. 前者の、イベントリファイルを編集してマージリクエストするかたち。シンプルな作りにすることを優先させた。

togetter



■ 懇親会

f:id:akira6592:20190201101236p:plain:w350
アンダーレイネットワーク

Day2の夜にはベルクラシック甲府にて、懇親会が開催れました。この写真の以外にももう1フロアあったというから驚きです。合計676名が参加されたそうです。

f:id:akira6592:20190201102710p:plain:w350
カラフル

色々な方をごあいさつさせていただくなかで、このブログを見たという方もいらっしゃってとても嬉しく思いました。いつもありがとうございます。



■ まとめ

特に印象的だったプログラムをいくつかとりあげました。 他にも、プログラムがたくさんありました。2019/02/28 12:59 まではアーカイブ配信（対象のもののみ）もされているので、気になるものがありましたらチェックしてみてはいかがでしょうか。（Streaming Supporters各社みなさまありがとうございます。）

www.janog.gr.jp

おまけ: JANOGミーティング 全国大会

本会議の会場であるコラニー文化ホール（山梨県立県民文化ホール）には「JANOGミーティング 全国大会」という催事案内の掲示がありました。全国大会は、規模感が伝わりやすい良い言葉だと思いました。実際、ここ3回は参加者1,000人を超えていますし、開催場所も様々です。稟議書に書くときに使わせて頂きたいと思います。

f:id:akira6592:20190130132833p:plain:w300
規模感が伝わる「全国大会」

「Ansibleもくもく会 2019.01 ネットワーク編 in 富士通」にメンターとして参加しました

ansible

はじめに

2019/01/ に Ansible のハンズオンイベント「Ansibleもくもく会 2019.01 ネットワーク編 in 富士通」が、 富士通ソリューションスクエア PLYで開催されました。

ansible-users.connpass.com

本イベントに、メンターとして参加させていただいたので簡単ににレポートいたします。

■ Ansible もくもく会とは？

Ansible もくもく会とは、Ansible ユーザー会の主催で1ヶ月に1回くらいの頻度で開催されるハンズオンイベントです。 サーバー編、ネットワーク編があります。 イベントの開催情報は、connpass の Ansible ユーザー会 グループのメンバーになると通知されます。 また、 slack の ansiblejp というワークスペースでも情報をキャッチできます。(Joinはこちらから)

自分で用意するのは Wi-Fi 接続できる PC と SSH クライアントくらいです。ハンズオンに必要なAnsibleをインストールしたサーバー、自動化対象のサーバー、ネットワーク機器は、すべてレッドハットさんから提供されます。 参加者ひとりひとりに1セットずつ割り当てられるので、環境は非常に恵まれています。

使用する linklightというコンテンツも用意されていて、日本語版もあります。


■ メンターとは？

もくもく会では、参加者がハンズオンをもくもくしている過程で、つまずいたり疑問に思ったことがあったときに書き込めるオンラインのメモ帳が用意されます。 その質問に対して、一緒に悩んだり、もし答えられれば答えるといった役割を持つのがメンターです。もちろん、口頭でやりとりもします。 もくもく会の参加の枠として、一般参加枠より倍率が低くて当選しやすい「メンター枠」が用意されているのがメリットです。

私も過去数回担当させていただきました。


■ 当日の様子

富士通ソリューションスクエア PLY という素敵な会場で、もくもくやっていきました。

www.fujitsu.com

今回はネットワーク編でした。ネットワーク編は今回で3回目でしたが、今回初めて Networking-v2 という新しいハンズオンコースでコンテンツ、環境での開催でした。


寄せられた質問の例

雰囲気をお伝えするため、参加者から寄せられた質問をいくつか要約して抜粋します。（実施はもっと細かく具体的にやりとりしています）

  • [Q] Exercise 1.2 の Step 1 の「factsの取得を制限したい場合」とは？

    • [A] 制限する目的はコントロールノードのメモリの節約と、情報収集時にかかるターゲットノードへの負荷の軽減。
    • [A] ios_facts モジュールでは、デフォルトでハードウェアやインターフェースに関するfactsを収集するが、 gather_subset オプションで変更できる。

  • [Q] Exercise 1.2 の Step 4 で [WARNING]: Unable to parse /home/student/lab_inventory/hosts as an inventory source (略) のようなエラーが表示されてしまう。

    • [A] 指定したインベントリファイルが見つからないようです。ansible-playbook コマンドを実行する際のディレクトリをご確認ください。

勇気をもって質問しちゃいましょう

「こんな簡単なこと質問しちゃってもいいのかな？」という内容でも思い切って書いて持ったほうが良いです。結構他の人も同じところでつまずいていたりしますので。


■ 成果共有LT枠 もおすすめ！

もくもくタイムが終わったら、成果共有LTの時間です。成果共有LTといっても 特に資料はつくる必要はなく口頭で、

  • どこまでできたか
  • わかったかこと
  • つまずいたところ

などを数分発表するだけ OK です。

この役割の人向けに、申し込み時に「成果共有LT枠」が用意されています。やはり一般参加枠より倍率が低く参加しやすいです。その割にはお手軽なので、とてもオススメです。


■ まとめ

これまでは、恵比寿のレッドハットさんのセミナルームで開催されるてきたのですが、前回は弊社、今回は富士通さんの会場ということで、他の会場での開催の流れができてきました。

今後も定期的に開催されると思いますので、Ansible ユーザー会 グループや、ansiblejp slack をチェックの上、ご参加されてみてはいかがでしょうか。

ネットワークのテスト自動化に利用できそうなツールまとめ

Batfish ansible automation network python napalm

はじめに

サーバーのテスト自動化といえば、 Serverspec や Testinfra 、infrataster などが有名ですが、ネットワークのテスト自動化については、みんなが口をそろえて名前を出すものがないような印象です。一方で、リスクの観点から設定変更の自動化より先にテストや状態確認の自動化からはじめたいというケースもあるのではないでしょうか。

この記事では、どんなツールや組み合わせがネットワークのテストの自動化に使えそうかをまとめます。

ざっくりとした内容となっていますが、もし誤りや不足などありましたら @akira6592 までご連絡いただけると幸いです。

一覧

名前 タイプ 実機接続 主なテスト内容 言語
NetTester フレームワーク 要 物理ネットワークの受入テスト Ruby
pyATS フレームワーク 要 疎通や show コマンド実行結果の妥当性 Python
Ansible + TextFSM + assert モジュール フレームワーク 要 show コマンド実行結果の妥当性 (内部はPython)
Ansible + napalm_validate モジュール フレームワーク 要 show コマンド / traceroute 実行結果の妥当性 (内部はPython)
netmiko + TextFSM ライブラリ 要 show コマンド実行結果の妥当性 Python
NAPALM + napalm_validate ライブラリ 要 show コマンド / traceroute 実行結果の妥当性 Python
batfish エンジン + ライブラリ 不要 コンフィグや、経路、ACLの妥当性 Java (pythonクライアント pybatfish あり)


■ フレームワーク系

NetTester

OpenFlow を利用したネットワーク自動テストツールです。複数機器を接続した状態で障害試験などができます。

pyATS

疎通や show コマンド実行結果の妥当性を検証できるテストフレームワークです。

Ansible + TextFSM + assert モジュール

Ansible のネットワークモジュールで show コマンドを実行し、TextFSMというパーサーを parse_cli_textfsm フィルター経由で呼んでパースし、その結果を assert モジュール で妥当性を判定する組み合わせです。

Ansible + napalm_validate モジュール

Ansible のサードパーティの ansible-napalm モジュール群があります。 その中に、想定する状態を YAML で定義して、実際の結果と比較 napalm_validate というモジュールがあります。この仕組みを利用して、妥当性を判定する組み合わせです。


■ ライブラリ 系

netmiko + TextFSM

ネットワーク自動化 Python ライブラリ netmiko と、TextFSM というパーサーを利用して、Python の assert メソッドで妥当性を確認する組み合わせです。 unittest や pytest など、ユニットテストツールと組み合わせも面白いかもしれません。

NAPALM + napalm validate

ネットワーク自動化 Python ライブラリ　NAPALM の validate 機能です。 想定する状態を YAML で定義して、実際の結果と比較します。napalm というコマンドラインツールから呼び出すこともできます。

batfish

ネットワーク機器のコンフィグの様々な検証ができる ツールです。 実機に接続する必要がなく、コンフィグファイルがあれば検証できるのが特徴です。 エンジン本体は Java で書かれていますが、Python クライアントである pybatfish から扱うことができます。


■ まとめ

ネットワークのテスト自動化にどんなツールや組み合わせが使えそうかをまとめました。ご参考になれば幸いです。

[Ansible] Junos の設定投入後に commit せずに candidate config を取得する

ansible junos automation network

■ はじめに

Ansible は、Juniper Junos のネットワーク機器に対応していて、情報の取得や設定変更ができます。

Junos は設定投入後に commit することによって、実際の動作に反映されます。設定変更の流れの中で、commit 前の candidate config を確認したいこともあるのではないでしょうか。そこでこの記事では、Junos の設定変更後に commit せずに candidate config を取得する方法をご紹介します。

Junos はJuniper のラボサービス vLabs を利用させていただきました。(vmx 17.4R1-S2.2)

実現できるのは Galaxy モジュール

Junos 対応モジュールには、大きく分けて Ansible に標準で組み込まれているモジュールと、Ansible Galaxy 経由で提供されている Galaxy モジュールの 2 種類あります。

commit せずに candidate config を取得といったことができるのは、Galaxy モジュールのほうです。ここでは、juniper_junos_config モジュールを利用します。


■ 環境の準備

必要 Python パッケージのインストール

Galaxy モジュール を利用するためには junos-eznc(PyEZ) をインストールする必要があります。私の環境では、 jxmlease もインストール必要がありましたので合わせてインストールします。

pip install コマンドでインストールします。

$ pip install junos-eznc jxmlease

(参考) インストールしていないと、あとで Playbook 実行時に以下のようなエラーになります。

fatal: [vmx]: FAILED! => {"changed": false, "msg": "junos-eznc (aka PyEZ) >= 2.1.7 is required for this module. However, junos-eznc does not appear to be currently installed. See https://github.com/Juniper/py-junos-eznc#installation for details on installing junos-eznc."}

Galaxy モジュール のインストール

aansible-galaxy install Juniper.junos コマンドで対象の Galaxy モジュールをインストールします。

$ ansible-galaxy install Juniper.junos
- downloading role 'junos', owned by Juniper
- downloading role from https://github.com/Juniper/ansible-junos-stdlib/archive/2.1.0.tar.gz
- extracting Juniper.junos to /home/vagrant/.ansible/roles/Juniper.junos
- Juniper.junos (2.1.0) was installed successfully


■ Playbook の作成と実行

インベントリファイル

対象ホストの定義です。今回は1台を vlabs というグループで囲っています。

  • inventory
[vlabs]
vmx ansible_host=172.16.0.1

Playbook

投入したいコマンドを指定した Playbook を作成します。 コミットしないという commit: no と、candidate config を取得する retrieve: candidate オプションがポイントです。

  • junos_get_candidate.yml
- hosts: vlabs
  gather_facts: no
  roles:
    - Juniper.junos     # ロールの読み込み

  tasks:
    - name: set config and get candidate config
      juniper_junos_config:
        lines:                     # 投入コマンド
          - set system ntp server 10.0.0.123
        load: merge
        format: set                # set 形式で扱う
        commit: no                 # コミットしない
        retrieve: candidate        # candidate config 取得
        host: "{{ ansible_host }}" # 対象ホスト
      register: res
    
    - name: save file            # ファイルへの保存タスク
      copy:
        content: "{{ res.config }}"    # 改行入りコンフィグの文字列を指定
        dest: "{{ inventory_hostname }}_changed_candidate_config.txt" 

  vars:  # 説明簡略化のため、Playbook 内に変数定義
    ansible_connection: netconf
    ansible_port: 35000                # 環境の都合上指定、デフォルトは netconf の場合 830
    ansible_user: testuser
    ansible_password: testpass9999

host オプションのデフォルトは {{ inventory_hostname }} です。そのため今回のインベントリファイルでいうと、vmx になりますが、これは便宜上付けた名前であり名前解決できないので、{{ ansible_host }} (今回の場合 172.16.0.1) を指定しています。

なお、Junos 側に ntp server の設定が何もない状態からはじめることを想定しています。

実行と確認

playbook の実行

今回は、安全のため Playbook 側に チェックモード相当の commit: no を指定をしていいます。そのため、 ansible-playbook コマンドとしては --check オプションは不要ですが、ここでは意図を明確にするために --check をつけて実行しています。

$ ansible-playbook -i inventory junos_commit.yml --check
PLAY [vlabs] ****************************************************************

TASK [set config and get candidate config] **********************************
changed: [vmx]

TASK [save file] ************************************************************
ok: [vmx]

PLAY RECAP ******************************************************************
vmx                        : ok=2    changed=1    unreachable=0    failed=0

changed になりますが、あくまでコミットはしません。

取得した candidate config の確認

candidate config がファイルとして保存され、set system server 10.0.0.123 コマンドに相当するコンフィグが あること を確認します。

set version 17.4R1-S2.2
(...略...)
set system ntp server 10.0.0.123            # ある（想定通り）
set chassis fpc 0 pic 0 number-of-ports 8
set chassis fpc 0 lite-mode
set interfaces fxp0 unit 0 fami

Junos 側の確認

Junos 機器側には、set system server 10.0.0.123 コマンドに相当するコンフィグが ないこと （commitしていいないため）を確認します。

jcluser@vMX-0> show configuration system ntp
　　　　　　          # ない（想定通り）
jcluser@vMX-0>


■ まとめ

Ansibleで、Junos の設定投入後に commit せずに candidate config を取得する方法をご紹介しました。

投入しようとしている部分的なコンフィグが、文法エラーなどによってはじかれてしまうのではないか、という不安を解消するには、机上チェックではなかなか難しいです。

実機に投入後、commit せずに canndidate config を取得すれば、その不安を解消できると思います。また、candidate config には想定する作業後の全行のコンフィグが含まれています。これを例えば、さらに Batfish に読み込ませて、実機反映前に事前検証するといった用途が考えられます。

参考にしていただければ幸いです。

Visual Studio Code の拡張をはじめて作ったときの流れ

vscode TypeScript

■ はじめに

Visual Studio Code の拡張をはじめて作りました。（自分向け） marketplace.visualstudio.com

この記事では、経緯や作る過程などをまとめます。


■ 経緯

このブログもそうなのですが、Markdown を書くことがよくあります。1つ個人的な悩みがあるのが表の書き方です。どうも横に長くなりがちなので苦手です。

|Header 1|Header 2|Header 3|
|:------|:------|:------|
|Column 1-1|Column 1-2|Column 1-3|
|Column 2-1|Column 2-2|Column 2-3|

以下のような HTML を書いていたこともあり、表の見た目の再現性よりも縦長に書くほうが慣れていました。

<table>
  <tr>
    <th>Header 1</th>
    <th>Header 2</th>
    <th>Header 3</th>
  </tr>
  <tr>
    <td>Column 1-1</td>
    <td>Column 1-2</td>
    <td>Column 1-3</td>
  </tr>
  <tr>
    <td>Column 2-1</td>
    <td>Column 2-2</td>
    <td>Column 2-3</td>
  </tr>

そこで、以下のようにネストしたリストを書くと表の形式に変換できたらいいなと思いました。

- 
  - Header 1
  - Header 2
  - Header 3
- 
  - Column 1-1
  - Column 1-2
  - Column 1-3
- 
  - Column 2-1
  - Column 2-2
  - Column 2-3

VS Code を普段使っていますが、既存の Markdown 関係の拡張機能を調べてみても該当の機能を持つものがなかったので、作ることにしました。 もしかしたら既存であったかもしれませんが、 VSCode の拡張はいままで作ったことがなかったので勉強のためにもやることにしました。


■ 開発から公開までの全体の流れを知る

こちらを参考の記事をにさせていただきました。

yoshinorin.net


■ 開発〜公開

Hello World で雰囲気をつかむ

https://code.visualstudio.com/api/get-started/your-first-extension

このページに、Hello World を表示させるだけの簡単なチュートリアルがあります。 こちらを元にして少し修正してみたりして、雰囲気をつかみました。

サンプル一式のリポジトリは、Microsoft/vscode-extension-samples です。

実装

API リファレンスや、既存の拡張機能のソースを読んだりしながら、やりたいことを実装していきました。 TypeScript 自身が初めてだったのですが、VS Code で開発するとデバッグがしやすかったです。

Markdown のリストを読み込む部分は、おそらく VS Code 自身が持っている機能を利用したかったのですが、やり方が分からなかったので、ちょっとしたパース処理を書くことにしました。

テストコード

Hello World のチュートリアルで生成するプロジェクトに、簡単なテストコードも含まれていました。そのテストコードを参考にして書いていきました。 Mocha というテストフレームワークを使っているようです。

リリース準備

拡張機能の名前やバージョン番号、作成者などの情報を package.json というファイル名のマニフェストファイルに書いていきます。 Marketplace 上の説明ページなどにも利用されます。 各項目の説明は Extension Manifest に書かれています。 マニフェストファイルもやはり、既存の拡張機能のものをお手本にさせていただきました。

リリース

Publishing Extension というページに従いました。


■ 感想とまとめ

いつかなにか作ってみたいなと思っていたのですが、ようやく重い腰をあげることができまいした。やってみると思ったよりは簡単にできました。 ただ、まだまだ API リファレンス の見方になれていないため「あのプロパティはどこで拾えるんだろう？」などを調べるのが少し時間かかりました。 今回でいうと、選択中の文字列の取得や、エディタとして設定されている改行コードです。

モノや環境としてはまだまだ改善点があったり、引き続きちょっとずつ取り組んでみたいと思います。