Ansible ディベロッパー部 2020.02 のセッション資料
国内NW機器ベンダーがAnsible対応した話Ansible ディベロッパー部 2020.02
View Slide
1名前 ：中山 真一 （ @naka_shin1 ）所属 ：セイコーソリューションズ株式会社職種 ：ソフトウェアエンジニア業務内容 ：担当NW機器の設計・開発・評価・組み込みNW機器のSW開発（比較的上位レイヤ）・Webアプリの開発興味ある技術 ：Ansible、API(Netconf,REST,等々)、Telemetry、運用自動化1自己紹介ペット：フクロモモンガその他：二児の父
2担当製品についてAnsible Webinar 公開しています（オンデマンド）2自己紹介
3Ansible ディベロッパー部 と 私の関係● 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対応を決めた理由開発背景9API 種別 Orchestrator 個人的な所感Ansible ツール Ansible TowerAWX・自動化を最近導入し始めたユーザ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.htmlConnection 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)httpapiclientnetconfclientnetconfserver(SSH)
16ネットワーク機器としてどう対応するかnetwork_cli 対応（開発）のイメージ開発課題16● Connection Plugin が決まるとそれに伴って対応する内容が決まってくる・開発アイテムは主に Vendor Module と Vendor PluginSSHサーバ(CLIシェル)network_cli接続処理ベンダー差分の吸収処理実作業処理(ベンダー毎)SSH接続SSH切断xxx_commandxxx_configCLIコマンド実行結果vendor毎のpluginConnection PluginVendor PluginVendor Moduleネットワーク機器
17ネットワーク機器としてどう対応するか対応（開発）するファイル開発課題17● Ansible パッケージ（2.9.4）ansiblemodulesnetworkterminalpluginscliconfactionModule Plugindocs_fragmentsmodule_utilsxxx：既存フォルダ：追加ファイル：追加フォルダnetworkxxxsite-packagesxxx.py__init__.pyxxx.py__init__.pyxxx_command.pyxxx_config.pyxxx_facts.pyxxx.py xxx.py xxx.pyxxx はモジュールの識別子※ios, vyos, junos 等既に存在するモジュールを修正する、モジュールを追加するという場合はここだけでいいはずです
18ネットワーク機器としてどう対応するかnetwork_cli の処理理解開発課題18● 処理概要SSHサーバ(CLIシェル)network_cliSSH接続SSH切断xxx_commandxxx_configCLIコマンド実行結果vendor毎のpluginConnection PluginVendor PluginVendor Moduleネットワーク機器Ansible Night in Tokyo 2019.07 の資料を参照下さい「network_cliプラグインとPlaybookで指定できる文字の話」1. Playbookから情報取得・ansible_network_os→ 使用するvendor pluginの判別・使用モジュール2. SSH接続 → プロンプト待ち※vendor plugin3. 初期コマンドの実行※vendor plugin4. コマンド実行(Playbookで指定)※管理者権限に移行する場合vendor plugin5. 実行結果のエラーチェック※vendor plugin6. 実行結果を返す※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.4config file = /etc/ansible/ansible.cfgconfigured 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/ansibleexecutable location = /home/nakayama/.pyenv/versions/3.7.4/bin/ansiblepython 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.pdfAnsibleモジュールをどう考えるか
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-engineAnsibleのバージョンアップに追従していくことRelease ( Ansible Ver ) Major Version の Release1st 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ご清聴ありがとうございました。
nakashin1
yu4u
yujisoftware
soracom
zakiyama
oracle4engineer
moritama1515
k9i
daihiraoka
techtekt
yuya4
htsuruo
okazuki
chriscoyier
paulrobertlloyd
marcelosomers
tanoku
reverentgeek
yeseniaperezcruz
shpigford
akosma
wjessup
cassininazir