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
1k
Supporting_AnsibleCollections
nakashin1
0
750
module-developing_and_operation
nakashin1
1
3k
network_cli_and_playbook
nakashin1
2
3.9k
Other Decks in Technology
See All in Technology
AWS Media Services 最新サービスアップデート 2024
eijikominami
0
200
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.6k
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
7
760
Can We Measure Developer Productivity?
ewolff
1
150
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
370
BLADE: An Attempt to Automate Penetration Testing Using Autonomous AI Agents
bbrbbq
0
300
Amazon Personalizeのレコメンドシステム構築、実際何するの?〜大体10分で具体的なイメージをつかむ〜
kniino
1
100
SREによる隣接領域への越境とその先の信頼性
shonansurvivors
2
520
スクラム成熟度セルフチェックツールを作って得た学びとその活用法
coincheck_recruit
1
140
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
120
Featured
See All Featured
Facilitating Awesome Meetings
lara
50
6.1k
Documentation Writing (for coders)
carmenintech
65
4.4k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
A better future with KSS
kneath
238
17k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
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 ご清聴ありがとうございました。