Upgrade to Pro — share decks privately, control downloads, hide ads and more …

developing_ansible_network_module

naka-shin1
February 12, 2020

 developing_ansible_network_module

Ansible ディベロッパー部 2020.02 のセッション資料

naka-shin1

February 12, 2020
Tweet

More Decks by naka-shin1

Other Decks in Technology

Transcript

  1. 1 名前 :中山 真一 ( @naka_shin1 ) 所属 :セイコーソリューションズ株式会社 職種

    :ソフトウェアエンジニア 業務内容 :担当NW機器の設計・開発・評価 ・組み込みNW機器のSW開発(比較的上位レイヤ) ・Webアプリの開発 興味ある技術 :Ansible、API(Netconf,REST,等々)、Telemetry、運用自動化 1 自己紹介 ペット:フクロモモンガ その他:二児の父
  2. 3 Ansible ディベロッパー部 と 私の関係 • Ansible自身(network vendor module)の開発者 という立場

    • 国内NW機器ベンダーがAnsible対応した話 ↓ 国内にある NW機器ベンダーという立場の開発者 が AnsibleというOSSに 対応した話 自己紹介
  3. 4 • 国内ネットワーク機器ベンダーのAnsible対応を加速させたい → モジュール増はAnsibleのできる事が広がる事に (more powerful) • 自社の経験 +

    ノウハウ + Red Hat様からのアドバイス を共有したい • 発表内容が直撃する人は少ないかもしれません、、、が 1社でも増えれば嬉しいユーザがその後ろにたくさんいるはず! 発表の動機
  4. 8 なぜAnsible対応したのか どうやってネットワーク運用の自動化に対応しよう 開発背景 8 当時(2017~2018)の選択肢(API) • Ansible • REST

    • Netconf 現在(2020.02)だと 上の3つに加えて以下も入るかもしれません • RESTCONF • gRPC ネットワーク機器が運用自動化に対応するとは = APIやツールに対応する事 = Orchestrator からアクセスできる事
  5. 9 なぜAnsible対応したのか Ansible対応を決めた理由 開発背景 9 API 種別 Orchestrator 個人的な所感 Ansible

    ツール Ansible Tower AWX ・自動化を最近導入し始めたユーザ REST プロトコル サーバ監視ツール 内製ツール ・サーバ監視/管理ツールでネットワークも、の場合 ・内製ツール文化の場合 Netconf プロトコル NSO(cisco) 内製ツール ・規模の大きいネットワーク運用環境の場合 • 社内では汎用性の高い機能追加となるよう、プロトコルに対応すべきという声も多かった → JANOGでAnsibleが取り扱われていた事は後押しになりました(管理手法としてデファクトになりつつあると) • 最終的には チャレンジしてみよう、という事で Ansible に → プロトコル対応ではなく、ツール対応、しかもOSS という部分がチャレンジでもあり、リスクでもあり
  6. 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に 対応した話をします
  7. 15 ネットワーク機器としてどう対応するか Ansibleとネットワーク機器をどう繋ぐか 開発課題 15 • network_cli があるから対応しやすかった(非常に助かった) ・netconf や

    httpapi の場合、ネットワーク機器側にサーバ実装が必要となる → netconf : netconfのサーバ → httpapi : Webサーバ(ブラウザ用ではなくAPI用) • ネットワーク機器側に特別な対応が不要 「エージェントレス」の恩恵かなと Webサーバ (HTTPS) httpapi client netconf client netconf server (SSH)
  8. 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 ネットワーク機器
  9. 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 等 既に存在するモジュールを修正する、モジュールを追加する という場合はここだけでいいはずです
  10. 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)
  11. 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>
  12. 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() ]
  13. 21 ネットワーク機器としてどう対応するか Moduleの開発で苦労した点・悩んだ点 開発課題 21 • モジュールは何を用意すればよいか ・基本は以下の3点セットかなと - xxx_facts

    : 設定情報、コンフィグ等の収集 - xxx_command : CLIコマンド(主にshow系)の実行 - xxx_config : CLIコマンド(主に設定系)の実行 ・この3つ以外を作るシチュエーション、モチベーション - CLIをなるべく意識しなくても設定できるように - 特定の機能を使う場合、CLIとしては複数行設定が必要なとき - 何か独自の機能を実現したいとき Ansibleと連携して効果が出るシチュエーションは どういう場合なのか、については リリース後に分かる場合もあります 個人的にはスモールスタートでいいと思います
  14. 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
  15. 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)]
  16. 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モジュールをどう考えるか
  17. 25 会社としてどう対応するか 所感 25 • 問い合わせ対応 やや増 ・製品知識 + Ansible

    についての知識が必要に ・自社モジュール以外の Ansibleについての一般的な質問も当然頂く - Ansibleの一般的な知識をチームで習得する必要がある • 「Ansible」が共通言語となり、これまでの対応領域が増えた印象 ・自社製品の使い方がAnsibleと連携して少し変わった(増えた) ・対応しました! だけではなく、 Ansibleと連携した場合の使い方(ユースケース)をきちんと考える必要がある • Ansible用のコンテンツが必要 ・モジュール説明、Playbook集、ユースケース紹介、など 対応してみて10か月・・・
  18. 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) 夏位?
  19. 29 これからどう対応するか 課題 29 • メリット ・ansible.com にアップできる ・ソースの品質は上がる傾向に(PR等) ・知名度、認知度、ユーザの使いやすさ向上(入手性・情報)

    と、 現在のベンダー配布よりはプラスになると考えています • 基本的な考え方 ・メンテナンスはアップした会社 - Issue対応、PR対応等 - Ansible Verup対応(NW機器での動作確認) OSS化
  20. 30 これからどう対応するか 課題 30 • 直近のTODO ・社内の体制づくり - CI/CD環境の構築(ソースの修正 →

    評価 というサイクルが定期的に発生する為) - Ansibleをサポートできるメンバの育成 ・ソースのブラッシュアップ - 静的ソースチェック(Sanity Test) ・社内ルールの確認・整備 - QAとテスト自動化の議論 - GitHub, Ansible の Code of Conduct (規約) の会社としての確認 OSS化
  21. 31 最後に 31 • Ansibleをもっとパワフルに! ・対応するネットワーク機器が増えるとAnsibleの魅力もアップ ・国内ネットワーク機器ベンダの対応がもっと増えると嬉しい、お役に立てればと • 対応する事でいい事あります! ・従来の使い方+「Ansibleで運用の自動化」という付加価値を製品に

    ・対応しているベンダー、Ansibleを扱う会社との連携 • 個人的に ・まずは公式ドキュメントをしっかり確認( Developer Guide ) ・Software Design 2020.2月号(Ansible問題解決マップ Ansibleモジュールの開発・テストをする)分かりやすい ・Ansible利用者側としてのスキルを伸ばしたい(個人目標)、OSS化したい