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. 国内NW機器ベンダーがAnsible対応した話
    Ansible ディベロッパー部 2020.02

    View Slide

  2. 1
    名前 :中山 真一 ( @naka_shin1 )
    所属 :セイコーソリューションズ株式会社
    職種 :ソフトウェアエンジニア
    業務内容 :担当NW機器の設計・開発・評価
    ・組み込みNW機器のSW開発(比較的上位レイヤ)
    ・Webアプリの開発
    興味ある技術 :Ansible、API(Netconf,REST,等々)、Telemetry、運用自動化
    1
    自己紹介
    ペット:フクロモモンガ
    その他:二児の父

    View Slide

  3. 2
    担当製品について
    Ansible Webinar 公開しています(オンデマンド)
    2
    自己紹介

    View Slide

  4. 3
    Ansible ディベロッパー部 と 私の関係
    ● Ansible自身(network vendor module)の開発者 という立場
    ● 国内NW機器ベンダーがAnsible対応した話

    国内にある NW機器ベンダーという立場の開発者 が
    AnsibleというOSSに 対応した話
    自己紹介

    View Slide

  5. 4
    ● 国内ネットワーク機器ベンダーのAnsible対応を加速させたい
    → モジュール増はAnsibleのできる事が広がる事に (more powerful)
    ● 自社の経験 + ノウハウ + Red Hat様からのアドバイス を共有したい
    ● 発表内容が直撃する人は少ないかもしれません、、、が
    1社でも増えれば嬉しいユーザがその後ろにたくさんいるはず!
    発表の動機

    View Slide

  6. 5
    本日の内容
    ● なぜAnsible対応したのか
    ● リリースまでの道のり
    ・どこを目指すか
    ・ネットワーク機器としてどう対応するか
    ・会社としてどう対応するか
    ● これからどう対応していくか

    View Slide

  7. Ansible ディベロッパー部 2020.02
    なぜAnsible対応したのか

    View Slide

  8. 7
    なぜAnsible対応したのか
    担当製品
    ネットワーク運用の
    現場で使われる製品
    CLI / GUI
    ネットワーク運用環境の変化に対応しよう
    手動オペレーション 運用の自動化
    API Orchestrator
    開発背景
    運用自動化への対応

    View Slide

  9. 8
    なぜAnsible対応したのか
    どうやってネットワーク運用の自動化に対応しよう
    開発背景
    8
    当時(2017~2018)の選択肢(API)
    ● Ansible
    ● REST
    ● Netconf
    現在(2020.02)だと 上の3つに加えて以下も入るかもしれません
    ● RESTCONF
    ● gRPC
    ネットワーク機器が運用自動化に対応するとは = APIやツールに対応する事
    = Orchestrator からアクセスできる事

    View Slide

  10. 9
    なぜAnsible対応したのか
    Ansible対応を決めた理由
    開発背景
    9
    API 種別 Orchestrator 個人的な所感
    Ansible ツール Ansible Tower
    AWX
    ・自動化を最近導入し始めたユーザ
    REST プロトコル
    サーバ監視ツール
    内製ツール
    ・サーバ監視/管理ツールでネットワークも、の場合
    ・内製ツール文化の場合
    Netconf プロトコル NSO(cisco)
    内製ツール
    ・規模の大きいネットワーク運用環境の場合
    ● 社内では汎用性の高い機能追加となるよう、プロトコルに対応すべきという声も多かった
    → JANOGでAnsibleが取り扱われていた事は後押しになりました(管理手法としてデファクトになりつつあると)
    ● 最終的には チャレンジしてみよう、という事で Ansible に
    → プロトコル対応ではなく、ツール対応、しかもOSS という部分がチャレンジでもあり、リスクでもあり

    View Slide

  11. 10
    なぜAnsible対応したのか
    Ansible対応を決めた理由
    開発背景
    10
    私がやりたかったから
    ボトムアップじゃー

    View Slide

  12. Ansible ディベロッパー部 2020.02
    リリースまでの道のり
    ・どこを目指すか
    ・ネットワーク機器としてどう対応するか
    ・会社としてどう対応するか

    View Slide

  13. 12
    どこを目指すか
    リリースとは
    最初に
    12
    ● 初期リリースにあたって、どう対応するかをまずは決めました
    ・https://www.redhat.com/ja/explore/ansible/getting-started/ansible-module
    モジュールの大分類
    ・個人としても(会社としても)初めてトライする部分が多いので、
    スモールスタートの意識で
    今回対応したのは
    この部分です

    View Slide

  14. 13
    ネットワーク機器としてどう対応するか
    Ansibleとネットワーク機器をどう繋ぐか
    開発課題
    13
    ● コネクションプラグインの確認
    ・https://docs.ansible.com/ansible/latest/plugins/connection.html
    ・Ansible実践ガイド 第3版 P254「ネットワークモジュール用のコネクションプラグイン」
    Connection Plugin

    View Slide

  15. 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に
    対応した話をします

    View Slide

  16. 15
    ネットワーク機器としてどう対応するか
    Ansibleとネットワーク機器をどう繋ぐか
    開発課題
    15
    ● network_cli があるから対応しやすかった(非常に助かった)
    ・netconf や httpapi の場合、ネットワーク機器側にサーバ実装が必要となる
    → netconf : netconfのサーバ
    → httpapi : Webサーバ(ブラウザ用ではなくAPI用)
    ● ネットワーク機器側に特別な対応が不要 「エージェントレス」の恩恵かなと
    Webサーバ
    (HTTPS)
    httpapi
    client
    netconf
    client
    netconf
    server
    (SSH)

    View Slide

  17. 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
    ネットワーク機器

    View Slide

  18. 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 等
    既に存在するモジュールを修正する、モジュールを追加する
    という場合はここだけでいいはずです

    View Slide

  19. 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)

    View Slide

  20. 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>

    View Slide

  21. 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() ]

    View Slide

  22. 21
    ネットワーク機器としてどう対応するか
    Moduleの開発で苦労した点・悩んだ点
    開発課題
    21
    ● モジュールは何を用意すればよいか
    ・基本は以下の3点セットかなと
    - xxx_facts : 設定情報、コンフィグ等の収集
    - xxx_command : CLIコマンド(主にshow系)の実行
    - xxx_config : CLIコマンド(主に設定系)の実行
    ・この3つ以外を作るシチュエーション、モチベーション
    - CLIをなるべく意識しなくても設定できるように
    - 特定の機能を使う場合、CLIとしては複数行設定が必要なとき
    - 何か独自の機能を実現したいとき
    Ansibleと連携して効果が出るシチュエーションは
    どういう場合なのか、については
    リリース後に分かる場合もあります
    個人的にはスモールスタートでいいと思います

    View Slide

  23. 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

    View Slide

  24. 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)]

    View Slide

  25. 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モジュールをどう考えるか

    View Slide

  26. 25
    会社としてどう対応するか
    所感
    25
    ● 問い合わせ対応 やや増
    ・製品知識 + Ansible についての知識が必要に
    ・自社モジュール以外の Ansibleについての一般的な質問も当然頂く
    - Ansibleの一般的な知識をチームで習得する必要がある
    ● 「Ansible」が共通言語となり、これまでの対応領域が増えた印象
    ・自社製品の使い方がAnsibleと連携して少し変わった(増えた)
    ・対応しました! だけではなく、
    Ansibleと連携した場合の使い方(ユースケース)をきちんと考える必要がある
    ● Ansible用のコンテンツが必要
    ・モジュール説明、Playbook集、ユースケース紹介、など
    対応してみて10か月・・・

    View Slide

  27. Ansible ディベロッパー部 2020.02
    これからどう対応していくか

    View Slide

  28. 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) 夏位?

    View Slide

  29. 28
    これからどう対応するか
    課題
    28
    ● OSS化
    ・国内ベンダー初? コミュニティモジュールを目指したい
    Ansibleのバージョンアップに追従していく為に
    ここ!
    https://www.redhat.com/ja/explore/ansible/getting-started/ansible-module

    View Slide

  30. 29
    これからどう対応するか
    課題
    29
    ● メリット
    ・ansible.com にアップできる
    ・ソースの品質は上がる傾向に(PR等)
    ・知名度、認知度、ユーザの使いやすさ向上(入手性・情報) と、
    現在のベンダー配布よりはプラスになると考えています
    ● 基本的な考え方
    ・メンテナンスはアップした会社
    - Issue対応、PR対応等
    - Ansible Verup対応(NW機器での動作確認)
    OSS化

    View Slide

  31. 30
    これからどう対応するか
    課題
    30
    ● 直近のTODO
    ・社内の体制づくり
    - CI/CD環境の構築(ソースの修正 → 評価 というサイクルが定期的に発生する為)
    - Ansibleをサポートできるメンバの育成
    ・ソースのブラッシュアップ
    - 静的ソースチェック(Sanity Test)
    ・社内ルールの確認・整備
    - QAとテスト自動化の議論
    - GitHub, Ansible の Code of Conduct (規約) の会社としての確認
    OSS化

    View Slide

  32. 31
    最後に
    31
    ● Ansibleをもっとパワフルに!
    ・対応するネットワーク機器が増えるとAnsibleの魅力もアップ
    ・国内ネットワーク機器ベンダの対応がもっと増えると嬉しい、お役に立てればと
    ● 対応する事でいい事あります!
    ・従来の使い方+「Ansibleで運用の自動化」という付加価値を製品に
    ・対応しているベンダー、Ansibleを扱う会社との連携
    ● 個人的に
    ・まずは公式ドキュメントをしっかり確認( Developer Guide )
    ・Software Design 2020.2月号(Ansible問題解決マップ Ansibleモジュールの開発・テストをする)分かりやすい
    ・Ansible利用者側としてのスキルを伸ばしたい(個人目標)、OSS化したい

    View Slide

  33. Ansible ディベロッパー部 2020.02
    ご清聴ありがとうございました。

    View Slide