てくなべ (tekunabe)

ansible / network automation / 学習メモ

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 リファレンス の見方になれていないため「あのプロパティはどこで拾えるんだろう？」などを調べるのが少し時間かかりました。 今回でいうと、選択中の文字列の取得や、エディタとして設定されている改行コードです。

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

ネットワーク自動化ツールの選定ポイント（Ansible、Netmiko、NAPALM、Nornir）

automation network

はじめに

近年、ネットワーク機器への作業を自動化するOSS のツールやライブラリが増えてきています。この記事では、こんな観点でツールを検討するのが良いのでは、という自分の案をまとめてみます。

例示するツールとしては、Python で実装されている Ansible、Netmiko、NAPALM、Nornir を取り上げています。標準で利用できる機能を想定しています。

※ 2019/01/08 時点のバージョン、Ansible 2.7.5、Netmiko 2.3.0、NAPALM 2.3.3、Nornir 2.0.0 を対象


■ 検討ポイント

[1] 対象プラットフォームに対応しているか

まず気になるのが、そのツールが操作対象のプラットフォーム（Cisco IOS、Juniper Junos、Arista EOS など）に対応しているか、ということだと思います。

各ツールの対応状況が分かるリンクを掲載します。

Ansible の対応数は中くらい

https://docs.ansible.com/ansible/latest/modules/list_of_network_modules.html

Netmiko は多め

https://github.com/ktbyers/netmiko#supports

NAPALM は少なめ

https://napalm.readthedocs.io/en/latest/support/index.html

Nornir は他に依存

実際の接続部分に netmiko、NAPALM のどちらを選択するかに依存します。


[2] コードを書くか、書かないか

仕組みを作る人、使う人、メンテナンスする人のスキルセットなどによって、コード（プログラム）を書くか書かないかという方針も変わってくると思います。

コードを書くという場合は、netmiko、NAPALM、Nornir といった、Python ライブラリとして提供されてものが利用できます（Ansible も Python API あり）。

一方で、コードを書かないという場合は、 Ansible のような YAML で構成を定義していくタイプが候補に挙げられます。


[3] シンプルか、高機能か

シンプルなツールは、それに特化して覚えることが少ないですが、自前で処理を作る部分が多くなります。 高機能なツールは逆に、覚えることが多いですが、自前処理は少なります。

Python ライブラリでは、シンプルな順に netmiko、NAPARLM、Nornir ではないかと思います。


[4] すでに利用しているツールがあるか

例えば、すでにサーバーチームが Ansible を利用している、といった状況であれば、相乗りで導入しやすくなるのではないでしょうか。 他にも、既存のスクリプトがあるのであれば、同じツールを利用すると統一感がとれます。


[5] どのくらい操作を抽象化したいか

TeraTerm マクロのように show run 等のコマンドをそのまま実行するタイプに対して、get_config のような関数を介してコマンドを実行することをここでは抽象化と呼びます。抽象化は、コマンドやベンダー意識しなくてよい（程度はものによります）、パラメータ化しやすいといったメリットがあります。

Ansible

コマンドそのまま実行する、ios_commmand や ios_config のようなモジュールのほかに、ios_system のような、コマンドを抽象化したモジュールもあります。プラットフォームによって、まちまちです。

Netmiko

コマンドそのまま実行するタイプです。抽象化したい場合は、テンプレート化などで対応する必要があります。

NAPALM

get_config や get_interfaces などのコマンドを抽象化した関数があります。コマンドそのまま実行することもできます。

Nornir

実際の接続部分に Netmiko、NAPALM のどちらを選択するかに依存します。


[6] インベントリ・変数管理機能が必要か

ツールによっては操作対象の機器をグループ定義して管理したり、それらが利用する変数を定義したりする機能が、あらかじめ備わっているものがあります。

Ansible

接続対象を管理する Inventory や、ホストやグループ単位で変数を管理する仕組みがあります。

netmiko

特に接続対象や変数を管理する仕組みはありません。

NAPALM

特に接続対象や変数を管理する仕組みはありません。

Nornir

接続対象を管理する Inventoryや、ホストやグループ単位で変数を管理する仕組みがあります。


■ まとめ

ポイント Ansible Netmiko NAPALM Nornir
[1] 対応プラットフォーム数 中 多い 少ない 接続部分に依存
[2] コード？ YAML Python Python Python
[3] シンプル/高機能 高機能 シンプル 高機能 高機能
[4] すでに利用しているか - - - -
[5] 抽象化レベル ◬ × 〇 接続部分に依存
[6] インベントリ・変数管理機能 〇 × × 〇

どんな観点でネットワーク自動化のツールを検討するのという案をまとめました。考え方や状況によって選び方は変わってくると思います。参考になれば幸いです。

なにかご意見ございましたら @akira66592 までご連絡いただければと思います。

参考

www.slideshare.net tekunabe.hatenablog.jp tekunabe.hatenablog.jp