国内NW機器ベンダーがAnsible対応した話 Ansible ディベロッパー部 2020.02

1 名前 ：中山 真一 （ @naka_shin1 ） 所属 ：セイコーソリューションズ株式会社 職種 ：ソフトウェアエンジニア 業務内容 ：担当NW機器の設計・開発・評価 ・組み込みNW機器のSW開発（比較的上位レイヤ） ・Webアプリの開発 興味ある技術 ：Ansible、API(Netconf,REST,等々)、Telemetry、運用自動化 1 自己紹介 ペット：フクロモモンガ その他：二児の父

2 担当製品について Ansible Webinar 公開しています（オンデマンド） 2 自己紹介

3 Ansible ディベロッパー部 と 私の関係 ● Ansible自身（network vendor module）の開発者 という立場 ● 国内NW機器ベンダーがAnsible対応した話 ↓ 国内にある NW機器ベンダーという立場の開発者 が AnsibleというOSSに 対応した話 自己紹介

4 ● 国内ネットワーク機器ベンダーのAnsible対応を加速させたい → モジュール増はAnsibleのできる事が広がる事に (more powerful) ● 自社の経験 ＋ ノウハウ ＋ Red Hat様からのアドバイス を共有したい ● 発表内容が直撃する人は少ないかもしれません、、、が １社でも増えれば嬉しいユーザがその後ろにたくさんいるはず！ 発表の動機

5 本日の内容 ● なぜAnsible対応したのか ● リリースまでの道のり ・どこを目指すか ・ネットワーク機器としてどう対応するか ・会社としてどう対応するか ● これからどう対応していくか

Ansible ディベロッパー部 2020.02 なぜAnsible対応したのか

7 なぜAnsible対応したのか 担当製品 ネットワーク運用の 現場で使われる製品 CLI / GUI ネットワーク運用環境の変化に対応しよう 手動オペレーション 運用の自動化 API Orchestrator 開発背景 運用自動化への対応

8 なぜAnsible対応したのか どうやってネットワーク運用の自動化に対応しよう 開発背景 8 当時（2017～2018）の選択肢（API） ● Ansible ● REST ● Netconf 現在（2020.02）だと 上の３つに加えて以下も入るかもしれません ● RESTCONF ● gRPC ネットワーク機器が運用自動化に対応するとは ＝ APIやツールに対応する事 ＝ Orchestrator からアクセスできる事

9 なぜAnsible対応したのか Ansible対応を決めた理由 開発背景 9 API 種別 Orchestrator 個人的な所感 Ansible ツール Ansible Tower AWX ・自動化を最近導入し始めたユーザ REST プロトコル サーバ監視ツール 内製ツール ・サーバ監視/管理ツールでネットワークも、の場合 ・内製ツール文化の場合 Netconf プロトコル NSO（cisco） 内製ツール ・規模の大きいネットワーク運用環境の場合 ● 社内では汎用性の高い機能追加となるよう、プロトコルに対応すべきという声も多かった → JANOGでAnsibleが取り扱われていた事は後押しになりました（管理手法としてデファクトになりつつあると） ● 最終的には チャレンジしてみよう、という事で Ansible に → プロトコル対応ではなく、ツール対応、しかもOSS という部分がチャレンジでもあり、リスクでもあり

10 なぜAnsible対応したのか Ansible対応を決めた理由 開発背景 10 私がやりたかったから ボトムアップじゃー

Ansible ディベロッパー部 2020.02 リリースまでの道のり ・どこを目指すか ・ネットワーク機器としてどう対応するか ・会社としてどう対応するか

12 どこを目指すか リリースとは 最初に 12 ● 初期リリースにあたって、どう対応するかをまずは決めました ・https://www.redhat.com/ja/explore/ansible/getting-started/ansible-module モジュールの大分類 ・個人としても（会社としても）初めてトライする部分が多いので、 スモールスタートの意識で 今回対応したのは この部分です

13 ネットワーク機器としてどう対応するか Ansibleとネットワーク機器をどう繋ぐか 開発課題 13 ● コネクションプラグインの確認 ・https://docs.ansible.com/ansible/latest/plugins/connection.html ・Ansible実践ガイド 第３版 P254「ネットワークモジュール用のコネクションプラグイン」 Connection Plugin

14 ネットワーク機器としてどう対応するか Ansibleとネットワーク機器をどう繋ぐか 開発課題 14 ● どのコネクションプラグインで Ansible と連携できるかを考える ・弊社の場合は network_cli 一択でした ・「SSHでCLIアクセスしてコマンド実行する」という一番メジャーな接続方法 ネットワーク機器の場合、一番多い接続方法となっています https://docs.ansible.com/ansible/latest/network/user_guide/platform_index.html Connection Plugin Protocol 自社製品の対応 network_cli SSHv2 〇 netconf NETCONF × httpapi HTTPS × network_cliに 対応した話をします

15 ネットワーク機器としてどう対応するか Ansibleとネットワーク機器をどう繋ぐか 開発課題 15 ● network_cli があるから対応しやすかった（非常に助かった） ・netconf や httpapi の場合、ネットワーク機器側にサーバ実装が必要となる → netconf : netconfのサーバ → httpapi : Webサーバ(ブラウザ用ではなくAPI用) ● ネットワーク機器側に特別な対応が不要 「エージェントレス」の恩恵かなと Webサーバ (HTTPS) httpapi client netconf client netconf server (SSH)

16 ネットワーク機器としてどう対応するか network_cli 対応（開発）のイメージ 開発課題 16 ● Connection Plugin が決まるとそれに伴って対応する内容が決まってくる ・開発アイテムは主に Vendor Module と Vendor Plugin SSHサーバ (CLIシェル) network_cli 接続処理 ベンダー差分の 吸収処理 実作業処理 (ベンダー毎) SSH接続 SSH切断 xxx_command xxx_config CLIコマンド 実行結果 vendor毎の plugin Connection Plugin Vendor Plugin Vendor Module ネットワーク機器

17 ネットワーク機器としてどう対応するか 対応（開発）するファイル 開発課題 17 ● Ansible パッケージ（2.9.4） ansible modules network terminal plugins cliconf action Module Plugin docs_fragments module_utils xxx ：既存フォルダ ：追加ファイル ：追加フォルダ network xxx site-packages xxx.py __init__.py xxx.py __init__.py xxx_command.py xxx_config.py xxx_facts.py xxx.py xxx.py xxx.py xxx はモジュールの識別子 ※ios, vyos, junos 等 既に存在するモジュールを修正する、モジュールを追加する という場合はここだけでいいはずです

18 ネットワーク機器としてどう対応するか network_cli の処理理解 開発課題 18 ● 処理概要 SSHサーバ (CLIシェル) network_cli SSH接続 SSH切断 xxx_command xxx_config CLIコマンド 実行結果 vendor毎の plugin Connection Plugin Vendor Plugin Vendor Module ネットワーク機器 Ansible Night in Tokyo 2019.07 の資料を参照下さい 「network_cliプラグインとPlaybookで指定できる文字の話」 1. Playbookから情報取得 ・ansible_network_os → 使用するvendor pluginの判別 ・使用モジュール 2. SSH接続 → プロンプト待ち ※vendor plugin 3. 初期コマンドの実行 ※vendor plugin 4. コマンド実行(Playbookで指定) ※管理者権限に移行する場合 vendor plugin 5. 実行結果のエラーチェック ※vendor plugin 6. 実行結果を返す ※vendor module ・ok / failed / changed … ・stdout(stdout_lines)

19 ネットワーク機器としてどう対応するか 開発全体で苦労した点・悩んだ点 開発課題 19 ● 正規表現 （Regular expression） ・network_cli を使う場合、様々な場面で登場します - プロンプト定義、エラー定義、xxx_facts で CLIコマンドから要素を抽出する場合 などなど （例）プロンプト定義 (弊社製品の場合) - ※ 正規表現の可視化サイトなど使いながら対応していました （上記は https://www.debuggex.com/ を利用） (^|¥r|¥n)¥([0-9]{1,3}¥)(¥[[0-9:]{8}¥])?[a-zA-Z0-9][a-zA-Z0-9-_.]{0,63}(?:[>#])[ ]$ (0)NS-2250>

20 ネットワーク機器としてどう対応するか Pluginの開発で苦労した点・悩んだ点 開発課題 20 ● terminalプラグイン (TerminalModule) ・CLIコマンドの入出力について、ベンダー差分を吸収する部分 - プロンプト定義 [ terminal_stdout_re ] - エラー定義 [ terminal_stderr_re ] → ここで定義したエラー文をCLIの入出力で検出するとエラーとしている ① 製品のエラー出力を洗い出す - 特定のフォーマットで定義されていると思(ry その結果から正規表現を定義する（エラー種類が多いと大変かも） ② どこまで定義すべきか - 文法エラー、権限エラー、設定時コマンド実行後のエラー(パラメータチェック) を定義 ※ping等は迷ったが、他のベンダーに同様の定義がなかったので対応せず（ 100% loss でもokで返る） - ログイン時の実行コマンド定義（terminal length 0 等） [ on_open_shell() ] - 管理者モードに遷移する際のコマンド定義（enable 等) [ on_become(), on_unbecome() ]

21 ネットワーク機器としてどう対応するか Moduleの開発で苦労した点・悩んだ点 開発課題 21 ● モジュールは何を用意すればよいか ・基本は以下の３点セットかなと - xxx_facts : 設定情報、コンフィグ等の収集 - xxx_command : CLIコマンド(主にshow系)の実行 - xxx_config : CLIコマンド(主に設定系)の実行 ・この３つ以外を作るシチュエーション、モチベーション - CLIをなるべく意識しなくても設定できるように - 特定の機能を使う場合、CLIとしては複数行設定が必要なとき - 何か独自の機能を実現したいとき Ansibleと連携して効果が出るシチュエーションは どういう場合なのか、については リリース後に分かる場合もあります 個人的にはスモールスタートでいいと思います

22 ネットワーク機器としてどう対応するか Moduleの開発で苦労した点・悩んだ点 開発課題 22 ● xxx_config の対応 ・自社のCLI仕様と闘いながら、どう冪等性を実現するか ・自社CLI仕様との闘い ① running-config と startup-config のフォーマット差分 - CLIとしての使いやすさ＝人間への分かりやすさ （自動化には優しくない） ② CLI仕様 - 設定が表示されるもの、されないもの、初期状態(default config) - 設定済みのconfigを投入した際に、エラーになるもの、ならないもの ※running-config に表示されていないけど投入したらエラーになる、、とか (0)NS-2250# show config running ............................ # echo "SYSTEM configuration..." # set timezone Tokyo (0)NS-2250# show config startup === show external startup1 === # echo "SYSTEM configuration..." # set timezone Tokyo

23 ネットワーク機器としてどう対応するか ファイルの提供方法 開発課題 23 ● どうお客様環境で使えるようにするか ・OSS ではないので、ansible.com からDLはできない → 直接提供 ● どういう形で提供するか ・環境は様々（OS、ディストリビューション、Pythonの仮想環境(xxxenvとか)） ・ユーザになるべく使いやすい形で（導入時の障壁とならないように） → インストーラを用意して必要なファイル（ディレクトリ）のみ配布 - ansible --version の 実行結果(ansible python module locacion) にインストール ansible 2.9.4 config file = /etc/ansible/ansible.cfg configured module search path = ['/home/nakayama/.ansible/plugins/modules’, ‘/usr/share/ansible/plugins/modules’] ansible python module location = /home/nakayama/.pyenv/versions/3.7.4/lib/python3.7/site-packages/ansible executable location = /home/nakayama/.pyenv/versions/3.7.4/bin/ansible python version = 3.7.4 (default, Oct 24 2019, 21:24:39) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]

24 会社としてどう対応するか 課題 24 ● 開発したパッケージ（xxx_modules_for_ansible）の考え方 ・単独で販売するソフトウェアではない ・あくまで 対応製品 の価値をあげる為のツール ● 公開方法 ・Ansibleのライセンスは GPLv3 です ・GPLv3、開発内容について 社内の知財部門と確認して公開方法を決めました ・その際 IPAの公開している「GNU GPL v3逐条解説書（第1版）」が非常に参考になりました - https://www.ipa.go.jp/osc/license1.html - https://www.ipa.go.jp/files/000028320.pdf Ansibleモジュールをどう考えるか

25 会社としてどう対応するか 所感 25 ● 問い合わせ対応 やや増 ・製品知識 ＋ Ansible についての知識が必要に ・自社モジュール以外の Ansibleについての一般的な質問も当然頂く - Ansibleの一般的な知識をチームで習得する必要がある ● 「Ansible」が共通言語となり、これまでの対応領域が増えた印象 ・自社製品の使い方がAnsibleと連携して少し変わった（増えた） ・対応しました！ だけではなく、 Ansibleと連携した場合の使い方（ユースケース）をきちんと考える必要がある ● Ansible用のコンテンツが必要 ・モジュール説明、Playbook集、ユースケース紹介、など 対応してみて10か月・・・

Ansible ディベロッパー部 2020.02 これからどう対応していくか

27 これからどう対応するか 課題 27 ● ここまで２回バージョンアップしてきました ※左側は弊社のモジュールリリース日、右側はAnsibleの Major Version リリース日 （泣） ※2.10のリリースは本日時点でまだ未定 （ https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_10.html ） ● Release Note にあまり出てこない内部的な差分もあります ● ユーザのAnsible利用ポリシー(同一Verの利用期間、Verup判断)、導入タイミング は様々 その為 ベンダーとしては少なくとも Major Version には対応すべきと考えています - https://access.redhat.com/support/policy/updates/ansible-engine Ansibleのバージョンアップに追従していくこと Release ( Ansible Ver ) Major Version の Release 1st 2019-04-12 ( 初期リリース, 動作確認 Ansible 2.7.7 ) 2019-05-17 (2.8.0) 2nd 2019-10-30 ( 機能追加リリース, 動作確認 Ansible 2.8.4 ) 2019-11-01 (2.9.0) 3rd 2020-??-?? ( ？, Ansibleの2.9対応? ) 2020-??-?? (2.10.0) 夏位？

28 これからどう対応するか 課題 28 ● OSS化 ・国内ベンダー初？ コミュニティモジュールを目指したい Ansibleのバージョンアップに追従していく為に ここ！ https://www.redhat.com/ja/explore/ansible/getting-started/ansible-module

29 これからどう対応するか 課題 29 ● メリット ・ansible.com にアップできる ・ソースの品質は上がる傾向に（PR等） ・知名度、認知度、ユーザの使いやすさ向上（入手性・情報） と、 現在のベンダー配布よりはプラスになると考えています ● 基本的な考え方 ・メンテナンスはアップした会社 - Issue対応、PR対応等 - Ansible Verup対応（NW機器での動作確認） OSS化

30 これからどう対応するか 課題 30 ● 直近のTODO ・社内の体制づくり - CI/CD環境の構築（ソースの修正 → 評価 というサイクルが定期的に発生する為） - Ansibleをサポートできるメンバの育成 ・ソースのブラッシュアップ - 静的ソースチェック(Sanity Test) ・社内ルールの確認・整備 - QAとテスト自動化の議論 - GitHub, Ansible の Code of Conduct (規約) の会社としての確認 OSS化

31 最後に 31 ● Ansibleをもっとパワフルに！ ・対応するネットワーク機器が増えるとAnsibleの魅力もアップ ・国内ネットワーク機器ベンダの対応がもっと増えると嬉しい、お役に立てればと ● 対応する事でいい事あります！ ・従来の使い方＋「Ansibleで運用の自動化」という付加価値を製品に ・対応しているベンダー、Ansibleを扱う会社との連携 ● 個人的に ・まずは公式ドキュメントをしっかり確認（ Developer Guide ） ・Software Design 2020.2月号（Ansible問題解決マップ Ansibleモジュールの開発・テストをする）分かりやすい ・Ansible利用者側としてのスキルを伸ばしたい（個人目標）、OSS化したい

Ansible ディベロッパー部 2020.02 ご清聴ありがとうございました。