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様からのアドバイス を共有したい● 発表内容が直撃する人は少ないかもしれません、、、が1社でも増えれば嬉しいユーザがその後ろにたくさんいるはず!発表の動機
5本日の内容● なぜAnsible対応したのか● リリースまでの道のり・どこを目指すか・ネットワーク機器としてどう対応するか・会社としてどう対応するか● これからどう対応していくか
Ansible ディベロッパー部 2020.02なぜAnsible対応したのか
7なぜAnsible対応したのか担当製品ネットワーク運用の現場で使われる製品CLI / GUIネットワーク運用環境の変化に対応しよう手動オペレーション 運用の自動化API Orchestrator開発背景運用自動化への対応
8なぜAnsible対応したのかどうやってネットワーク運用の自動化に対応しよう開発背景8当時(2017~2018)の選択肢(API)● Ansible● REST● Netconf現在(2020.02)だと 上の3つに加えて以下も入るかもしれません● 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実践ガイド 第3版 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● モジュールは何を用意すればよいか・基本は以下の3点セットかなと- xxx_facts : 設定情報、コンフィグ等の収集- xxx_command : CLIコマンド(主にshow系)の実行- xxx_config : CLIコマンド(主に設定系)の実行・この3つ以外を作るシチュエーション、モチベーション- 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● ここまで2回バージョンアップしてきました※左側は弊社のモジュールリリース日、右側は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ご清聴ありがとうございました。