Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
developing_ansible_network_module
Search
naka-shin1
February 12, 2020
Technology
3
1.8k
developing_ansible_network_module
Ansible ディベロッパー部 2020.02 のセッション資料
naka-shin1
February 12, 2020
Tweet
Share
More Decks by naka-shin1
See All by naka-shin1
OverviewOfAnsibleFest2022_and_OnsiteReport
nakashin1
0
990
Supporting_AnsibleCollections
nakashin1
0
750
module-developing_and_operation
nakashin1
1
2.9k
network_cli_and_playbook
nakashin1
2
3.8k
Other Decks in Technology
See All in Technology
Apple/Google/Amazonの決済システムの違いを踏まえた定期購読課金システムの構築 / abema-billing-system
cyberagentdevelopers
PRO
1
210
プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 / Building an authentication platform using Authlete and AWS
kakehashi
1
150
「 SharePoint 難しい」ってよく聞くけど、そんなに言うなら8歳の息子に試してもらった
taichinakamura
1
590
とあるユーザー企業におけるリスクベースで考えるセキュリティ業務のお話し
4su_para
3
320
Figma Dev Modeで進化するデザインとエンジニアリングの協働 / figma-with-engineering
cyberagentdevelopers
PRO
1
430
クライアントサイドでよく使われる Debounce処理 をサーバサイドで3回実装した話
yoshiori
1
150
生成AIとAWS CDKで実現! 自社ブログレビューの効率化
ymae
2
320
【技術書典17】OpenFOAM(自宅で極める流体解析)2次元円柱まわりの流れ
kamakiri1225
0
210
【LT】ソフトウェア産業は進化しているのか? -Javaの想い出とともに- #jjug_ccc
takabow
0
170
初心者に Vue.js を 教えるには
tsukuha
5
390
visionOSでの空間表現実装とImmersive Video表示について / ai-immersive-visionos
cyberagentdevelopers
PRO
1
100
現地でMeet Upをやる場合の注意点〜反省点を添えて〜
shotashiratori
0
500
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Typedesign – Prime Four
hannesfritz
39
2.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Agile that works and the tools we love
rasmusluckow
327
21k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
41
2.1k
Rails Girls Zürich Keynote
gr2m
93
13k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Scaling GitHub
holman
458
140k
Transcript
国内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様からのアドバイス を共有したい • 発表内容が直撃する人は少ないかもしれません、、、が 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対応を決めた理由 開発背景 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実践ガイド 第3版
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 • モジュールは何を用意すればよいか ・基本は以下の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.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 • ここまで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-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 ご清聴ありがとうございました。