モジュール開発 と 運用 Ansible Night Online 2021.02

1 自己紹介 1 名前 ：中山 真一 （ @naka_shin1 ） 所属 ：セイコーソリューションズ株式会社 業務内容 ：NW機器のソフトウェアエンジニア 担当製品紹介 ： ペット： - フクロモモンガ: 7歳 子供： - 息子: 4歳 - 娘 : 2歳 運用自動化を支えるSmartCSの役割 ＆ ユーザ事例紹介

背景 「ネットワーク運用者の為の製品」の開発担当を担当しています。 Ansible Module を開発/提供 している上で 運用を考えて工夫している点 公式の『Developer Guide』に書かれている「実装方法」ではない部分 Ansible Collection や、Ansible Galaxy の Local環境構築 によって Ansible Module を「必要な場所」に「必要な機能」を開発して公開する なんて流れを感じ、 「開発担当」「運用担当」の方の参考になればと。 発表者はAnsible運用の経験はありません ● 経験の共有 ● 技術的背景（個人の所感です） 2

運用を意識したモジュール開発 Ansible Module Ansible実行 Ansible呼び出し Target ● Ansible実行とその環境の整理 運用ツール (運用者) Playbook Module群 .yml Playbookの実行 (variables, vars, role等) Moduleへの引数 Target へのリクエスト (Connection plugin 経由) Target からのレスポンス (標準出力, CLI実行結果, 等) Moduleの戻り値 Playbookの実行結果 (フィルタ、整形) 3

Ansible Module Ansible実行 Ansible呼び出し Target ● 運用の方目線でPlaybook設計時や運用を考えた際に大事な部分 運用ツール (運用者) Playbook Module群 .yml Playbookの実行 (variables, vars, role等) Moduleへの引数 Target へのリクエスト (Connection plugin 経由) Target からのレスポンス (標準出力, CLI実行結果, 等) Moduleの戻り値 Playbookの実行結果 (フィルタ、整形) 4 → Playbook設計：Playbook作成時、運用ツールからどう変数を与えるか ← ログ（エビデンス）として、必要な実行結果をどのように残すか 運用を意識したモジュール開発

Ansible Module Ansible実行 Ansible呼び出し Target ● 開発目線でModule作成時に、大事な部分 運用ツール (運用者) Playbook Module群 .yml Playbookの実行 (variables, vars, role等) Moduleへの引数 Target へのリクエスト (Connection plugin 経由) Target からのレスポンス (標準出力, CLI実行結果, 等) Moduleの戻り値 Playbookの実行結果 (フィルタ、整形) 5 → Moduleでどのような引数を用意するか（型、形式）、どうターゲットに伝えるか ← ターゲットからの応答を解釈して実行結果として返す。（比較的そのまま返す） 運用を意識したモジュール開発

Ansible Module Ansible実行 Ansible呼び出し Target ● 運用の方が使いやすい Ansible Module とは ・・・ 6 Playbookの実行 (variables, vars等) Moduleへの引数 Target へのリクエスト (Connection plugin 経由) Target からのレスポンス (標準出力, CLI実行結果, 等) Moduleの戻り値 Playbookの実行結果 (フィルタ、整形) ● Playbook作成時に、運用ツールからの引数を Moduleに渡しやすい → 引数の設計 ： 型や形式 ● Moduleの戻り値が、ログやエビデンスとして使いやすい（扱いやすい） → 戻り値の設計： 必要な値が抽出しやすい、フィルターをあまり介さなくてもよい ここを意識したモジュール開発が 大事かなと 考えています 運用を意識したモジュール開発

● 補足 運用を意識したモジュール開発 という訳ではない、と考えています。 引数の加工が少ない 戻り値のフィルタや整形が少ない ＝いいモジュール？ 汎用的なモジュール 専用的なモジュール ・多くの人が使う ・様々なシチュエーションで使う → 特定の場面で使う場合においては 引数も戻り値も加工が必要 ・限定的なシチュエーションで使う ※限られたユーザ、環境、用途 → ある程度特化しても良いのかなと思っています。 ※修正が必要となったらリリース後に追加や修正する。 最初はスモールスタートで作ってみる、使ってもらう。 7 特定のプロダクト専用 社内だけのツール専用

運用を意識したモジュール開発：進め方 モジュール要件の確認 ・与えたい引数 ・期待する戻り値 試作（β版） フィードバック リリース コミュニケーション大事 ● 進め方 実際に運用する方に触って頂く、という機会が１回はあった方がいいと思います。 8

経験談 stdout_lines には、指定したコマンドの実行結果だけ が 格納されるので、投入したコマンドも一緒に確認したい。 例. 戻り値の改善、機能拡張 ● 実際に運用しているお客様から頂いた要望とその対応 ※ネットワークモジュールの、xxx_command のような独自モジュールについて はい喜んで！ モジュール開発者にとって、改善提案はとってもうれしいです。 連絡を頂ける場合の多くは『これ動かな(ry』 9

経験談 ● できたもの "stdout_lines": [ [ "System : System Software Ver 2.0 (Build 2019-03-25)", "Boot Status : Power on (00:01:00)", "System Up Time : 2019/05/22 15:33:07", "Main System : Ver 2.0", "Backup System : Ver 1.2" ], ], "stdout_lines_custom": [ { "execute_command": "show version", "response": [ "System : System Software Ver 2.0 (Build 2019-03-25)", "Boot Status : Power on (00:01:00)", "System Up Time : 2019/05/22 15:33:07", "Main System : Ver 2.0", "Backup System : Ver 1.2" ] }, ], 通常のstdout_linesは残して新しい戻り値を用意 register: result としてから、 result.stdout_lines_custom[0].response などと指定可 戻り値のネーミングセンスは本当にごめんなさい！ https://docs.ansible.com/ansible/latest/reference_appendices/common_return_values.html 独自の戻り値を用意して ええんやで 10

11 ご清聴ありがとうございました。 Happy Automation まとめ ● モジュール開発も運用も 『明確な答え』というのはなかなか無い分野だと思っています。 ただ 開発については、「使いやすさ」を具体化 してみると いい方向に進む気がします。 ● 意見交換をしながら、『使う側』『作る側』が ブラッシュアップしていけると いいAnsibleモジュールに育っていくのかな、なんて考えています。 Ansible Night Online 2021.02