てくなべ (tekunabe)

ansible / network automation / 学習メモ

JANOG44 レポートその2【登壇編】ここからはじめよう、運用自動化

event janog automation network

はじめに

2019/07/24-26 に兵庫県神戸市の神戸国際展示場で開催された JANOG44 Meeting in Kobe に参加、登壇してきました。

本ブログでは、2回に分けてレポートします。

  • その1 参加編
  • その2 登壇編 ここからはじめよう、運用自動化 (本記事)

その2である本記事では、前哨戦として Day2 に開催した野良BoF「運用自動化、どこからはじめる？」と、Day3 の本編「ここからはじめよう、運用自動化」に登壇するまでの経緯や、当日の様子などをまとめます。

f:id:akira6592:20190730104614p:plain:w400
会場の様子。別途サテライト会場も用意していただきました（後述）



■ 経緯

ある意味リベンジ企画

JANOG では、過去にも運用自動化に関連する多数のプログラムがありました。 今回の発表は JANOG42 の「その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜」の流れを組むものです。このプログラムでは私は登壇者ではなく参加者でした。JANOG 42 では、話がネガティブになりがちだったため、JANOG43 ではまた別の話をしようということで、登壇者としてお誘いを頂きました。

当初 JANOG43 では、良い手順書を探るようなプログラムを検討していました。しかし、少々まとめるのが難しくなり、保留になりました。

日をおいて今回の JNAOG44 の準備期間（といっても2月）に入った頃に、検討しはじめ「ここからはじめよう」というテーマにすることにしました。JANOG44 自体のテーマ「The One」にピッタリなのは偶然なのか、合わせたのかは覚えていません・・・。

BoFもやろう

JANOG では、よく BoF というかたちで少人数が集まって話し合う、座談会のような企画もあります。JANOG meeting 自体も meeting なので、意見交換が重要な要素ですが、それよりもっとこじんまりする印象です。

過去にも開催してきた自動化関連の BoF が盛り上がって良かったので、野良BoFというかたちで開催することにしました。



■ Day2 野良BoF「運用自動化、どこからはじめる？」

野良BoFとはいえ、JANOG 用に確保していただいている会場を利用させていただきました。 おかげさまで大勢の方にお越しいただくことができました。

様々な方からご意見をいただきました。感じたのは、体制によって大きく状況が変わるといいうことです。

  • 人が少ないから自分たちで開発も運用もやっている
  • 人が多すぎて、開発と運用を分けざるを得ない
  • コード書ける人のみを採用している
  • トップからの意志で、特定のツールを利用することになる

などなど・・（一部、野良BoFと本編の記憶が混在してるかもしれません）

開催側としての心残りが一点。参加していただいた人数が多く（60人ほどでしょうか）、BoFというより少々セッション形式に寄ってしまいました。そのため、意見を出しにくかった方もいらっしゃったようです。分割するなりの工夫が必要だったのかもしれません。

toggeter



■ Day3 本編「ここからはじめよう、運用自動化」

概要

ここからはじめよう、運用自動化 :: janog44

9/2(月)の正午頃までの動画アーカイブ配信もあります。

資料

toggeter

流れ

金子さんからのイントロダクション、登壇者紹介のあと、なぜ自動化する必要があるのかを、社会情勢を含めて波田野さんから解説。

その後、3つの仮想ロールとして、それぞれが、どのように始めればよいかを、提示持していきました。運用責任者を波田野さん、現場に近い運用リーダーを私、その間に挟まれる運用マネージャーを長久さん、という順番で発表しました。

なぜ運用自動化が必要か

資料: 2019-07-26 なぜ運用自動化が必要なのか/20190726-why-need-operation-automation - Speaker Deck

生産人口が減少する一方で、業務が増えていく状況においては、業務をスリム化し、人がやる必要のない業務は自動化することが求められる。というお話。

途中、「30代後半から体力激減」という話があり、ドキッとしました。

各ロールごとの話

運用責任者として

資料: 運用責任者が最初にやるべきこと /20190726-janog44-start-operation-automation-guide - Speaker Deck

まずは、業務範囲、コアコンピタンスを明確化し、「人がやる業務」と「機械がやる業務」の分離をする必要がある。というお話。

P35 あたりで「公式サービス」「非公式サービス」という言葉ができます。これは、運用メンバー寄りの立場であっても、アピールできるものか、そうでもないものかを考える上で、意識したほうが良い観点だと思います。

運用リーダーとして: はじめどころを探る自動化アセスメント

資料: はじめどころを探る自動化アセスメント（JANOG44 ここからはじめよう、運用自動化）

私のパートです。思いつきで自動化対象作業の優先度を決めないように自動化のはじめどころを探る、自動化アセスメントの考え方をご紹介しました。

各スライドの内容を簡単におさらいします。

分類と観点を洗い出してからアセスメントする

自動化対象の優先順位を決めるときに、たとえば「小さなことから」とした場合、某異彩事を指しているのでしょうか。実装に掛かりそうな時間でしょうか、リスクが少ないところでしょうか。「小さなことから」と仮定しただけでも、このように考えていくと観点の偏りやモレが発生しそそうと感じました。そのため、これらの観点を一段抽象化した分類から考えてみます。分類してから該当する観点を洗い出し、各作業をスコアリングし、スコア計算値の高い作業が優先度が高いと決められるのではと考えました。

今回これを自動化アセスメントと呼ぶことにしました。

観点の分類

分類を考えるための軸は2つ。 1つめの軸は、自動化前・後。自動化前の観点は、自動化すること自身に対する観点。例えば、実装の難易度などです。自動化後の観点は、自動化したシステムがもたらすものに対する観点。例えば、見込まれる影響度などです。

2つめの軸は、大小の価値観です。大きいほうが優先の観点、小さい方が優先の観点、それぞれあります。

4つの分類

https://image.slidesharecdn.com/janog44startautoyokochiomiyage-190729010448/95/janog44-14-638.jpg

  • 【動機】自動化に対するもの（自動化前）で、大きいほうが優先の観点
    • 現状脅かされているQCD、かかっている精神・身体負荷など
  • 【抵抗】自動化に対するもの（自動化前）で、小さいほうが優先の観点
    • 実装難易度、想定コストなど
  • 【リターン】自動化がもたらすもの（自動化後）で、大きいほうが優先の観点
    • 見込まれるQCDの向上、精神・身体負荷の改善など
  • 【リスク】自動化がもたらすもの（自動化後）で、小さいほうが優先の観点
    • 影響度、運用難易度、過剰な人員削減

観点の洗い出し

考えた分類に対して、どのような観点があるか洗い出していきます。 今回ご紹介した分類や観点はあくまでも例なので、実際の業務に合わせるには、分類や観点をカスタマイズしたり、重み付けを設定したりする必要があります。

また、自動化アセスメントを関係者一同でおこなうことで、自チームだけでは見えない観点が見えてくることも期待できると考えました。

運用マネージャーとして

資料: janog44_190717_nagaku.pptx - Google ドライブ

運用マネージャーは、トップダウンとボトムアップを結んだり、チームを作ったり重要な役割。自身もエンジニアとして現場に出た場合、 3ヶ月で追いつけるぐらいの距離は保つために勉強しておくのが大切。というお話。

紹介されている「LeanとDevOpsの科学」という本は私も読んだことがあります。「デプロイ負荷」の考え方は、私の発表の自動化優先度の観点のヒントにさせていただきました。

ディスカッションタイム

作業の優先度を決めるのより先に必要なこと

ディスカッションで、印象的だったのが「順番を間違えると大変なことになる」というコメントでした。

マネジメントロール主導より、現場メンバー主導のほうが良いのでは。メンバーがやりたいと思う自発性、「これやれるんじゃないか」「ちょっとやってみました」のようなところが、一番始めるきっかけきになるのでは。マネージャーは、褒めたり、メンバーからの声をあげる機会を増やすほうが需要では。スキルを底上げする、現場のモチベーションをあげる、キープする、やりたいと思えるメンバーを増やすのがキモ。優先度を決めるのよりも先では。

私も現場主導でというのは、チームビルディングの一環と捉えて賛成しています。 私の今回の考え方の中では「動機」という分類のところに、メンバーの気持ちを含めたつもりでした。ですが、順番まではうまく考えられていなかった気がします。作業にフォーカスしすぎて、あまり人にフォーカスできていませんでした。

他にも、様々な立場の方から質問、コメントを頂きました。詳細は togetter をご確認ください。悩み方、解釈の仕方なども、置かれている立場によって変わるのだなと感じました。

こっそり考えていたこと

今回、アセスメントの作業の例として「ルーティング追加」「状態確認」「ACL変更」のような物をあげました。 これらはすべてネットワーク機器へ接続が必要な作業です。

そういう意味ではもししかして、機器に接続するために必要な構成管理情報（IPアドレス、認証情報など）の整理が先ではないかとも思いました。

なので、作業のなかにも「これを先にやらないとどうやっても先に勧めなれない」ような、土台、レイヤーのようなものもあるかも、とこっそり考えていました。

【謝辞】臨時サテライト会場のご用意ありがとうございました

大勢の方にご参加いただき、関心の高さと熱量を感じました。 立ち見が出始めた頃に「座ってもらいたいが椅子は場所をとってしまい、人が多く入れなくなる。とはいえ、80分プログラムで立ち見は負担が大きい。」という難しい状況の中、椅子を追加しつつ、別フロアにストリーミングを映し出すサテライト会場を臨時で用意、という対応をしていたきました。このことはあとで知ったのですが、スタッフの的確な判断と、対応の速さにただただ感謝するばかりです。本当にありがとうございました。



■ 登壇編のまとめ

3つのロールに分けてそれぞれの考えを提示するという本プログラム。この企画を準備の段階でさまざまな意見交換をしてきました。当日も様々な立場の方から、ご質問やコメントを頂きました。これらにより、私なりに視野を広げることができた気がします。

これまで、私自身も JANOG41のネットワーク運用自動化BoF、JANOG42のAnsible ネットワーク自動化チュートリアル、JANOG43の自動化の行き着く先は？、そして今回、と立て続けに自動化関連のプログラムで登壇させていただきました。ありがとうございました。 毎回、一定の関心の高さが伺えるため、今後も何かしらの切り口で運用自動化のプログラムがあり、意見交換ができると良いなと思いました。

スタッフみなさま、マイクに立っていただいたみなさま、ご参加頂いたみなさま、企画立ち上げ時に引っ張ってくださった今井さん、臨時でまとめ役をご担当いただいた金子さん、各ロールを演じてくださった波田野さん、長久さん、ありがとうございました！

JANOG44 レポートその1【参加編】

event janog

はじめに

f:id:akira6592:20190728212823j:plain:w400
開会宣言

2019/07/24-26 に兵庫県神戸市の神戸国際展示場で開催された JANOG44 Meeting in Kobe に参加、登壇してきました。

本ブログでは、2回に分けてレポートします。

その1である本記事では、参加した本会議の各プログラムの一覧と、いくつかピックアップして感じたことなどをまとめます。

togetter

@goto_ipv6 さん ありがとうございます



■ 参加したプログラム一覧

「★」は本記事ピックアップ対象のプログラムです。

Day1

Day2

Day3



■ IS-ISはじめの一歩 0から1へ

概要

IS-ISはじめの一歩 0から1へ :: janog44

発表者

資料

togetter まとめ

気づき・感想

意外と使われている

IS-IS は、ネットワークを勉強しはじめの頃は「あまり使われていないけど勉強の過程でよく出てくるプロトコル」の代表のように捉えていました。しかし近年、アンダーレイのネットワークとして意識/無意識に関わらず使われていることを知って、興味が出て聞きました。

日本ではIGPにOSPFを利用するケースが多いが、海外（アメリカ）ではIS-ISの利用も多いそうです。

Level2? Layer2?

IS-IS では、エリアの範囲を示すものとして、Level1、Level2 といった概念があるそうです。省略すると L1、L2 です。うっかりすると、Layer2 と Level2 を勘違いしてしまいそうと思いました。

MTU不一致の検出

Hello のパケットは、MTU最大までPaddingすることによって、Helloの時点でMTU不一致を検出することができるそうです。

知らないルーティングプロトコルの設計思想や、仕組みを知るのは面白いです。



■ Jupyter Notebookの拡張機能を使ってリモート機器にSSHして作業する

概要

初心者歓迎! Light Lightning Talk大会 :: janog44

発表者

資料

togetter まとめ

気づき・感想

SSH Kernel を作った

通常通りJupyter Notebook 内で ssh コマンドを実行すると、都度接続を繰り返すため動作が遅い。これを解決するために、セッションを共有する SSH Lernerl を作ったそうです。ちょっと試すだけではあまり困らない困りごとを解決したという取り組みの共有は良いなと思いました。

運用への適用例が増える Jupyter Notebook

Jupyter Notebook を利用した「動く手順書」の手法である LC4RI(Literate Computing for Reproducible Infrastructure) を私が初めて知ったのは、たしか NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13です。 JANOG41 でもネットワーク運用自動化BoFで紹介がありました。 適用する事例が徐々に増えてきた用に感じます。



■ ネットワークCIパイプラインの構築

概要

ネットワークCIパイプラインの構築 :: janog44

発表者

資料

togetter まとめ

気づき・感想

夢が膨らむ構成

元ネタとなっているブログ「Network CI/CD Part 3 – Building a network CI pipeline with Gitlab, Ansible, cEOS, Robot Framework and Batfish」を始めて見たときは、なかなかの衝撃でした。コンテナのNOSがあること、Batfish が対応していること、などいくつか条件はありますが、夢が膨らみます。

一方で、この仕組みで何をどこまで担保できるのか、できないのかというのはおさえておくべきポイントだと思いました。

OSSツールの継続性と内製コードについて

質疑応答の中で、OSSの継続性に関する話題が話題がありました。 確かに利用しているOSSのツールがメンテナンスされなくなってしまったら、という不安はあります。自らコミットしていたとしても、それだけではまかないきれない規模のものもあると思います。 一方で、自組織内でコードを書いていく分には、比較的コントロールができるので、先のような心配は少ないと思います。 とはいえ、内製でコードを書いている場合も何らかのライブラリを利用していると思います。例えば、SSH接続であれば Paramiko など。そういうったライブラリの継続性は、ツール類に比べるとあまり気にしない気がしています。

ここの本質的な違いは何でしょうか。規模の大小でしょうか、それともツール/ライブラリ、でしょうか。もう少し考えてみたいと思います。



■ 運用自動化に「失敗」しちゃった

概要

運用自動化に「失敗」しちゃった :: janog44

発表者

  • 後藤 芳和 さん (株式会社リコー)

資料

togetter まとめ

気づき・感想

人を減らされてしまった

自動化しても人が不要になることはなく、より高い価値を出すために人は引き続き必要になります。 今回は「チーム内」の改善活動として自動化をしたため、トップに真意が伝わらず、単に工数削減できたという理由で人が減らされてしまったというお話。（かなり私なりに噛み砕いています）

「なぜやるのか」の価値観をさまざまな方向で共有する難しいですね。

このような失敗談は発表するのが難しいと思いますので、とても貴重なお話が聞けたと思います。



■ JANOG44ハッカソンWrap-up & Winner

f:id:akira6592:20190728213010j:plain:w400
優勝チームの発表

概要

JANOG44 ハッカソン Wrap-up & Winner :: janog44

発表者

資料

togetter まとめ

気づき・感想

ハッカソンとは

JANOG42、JANOG43 と続いてきた JANOG ハッカソン。ネットワークの運用に関する自動化や可視化に関するテーマを各自が持ち込んで、チームで当日に作るイベントです。当日に成果発表、投票が行われて優勝チームが決めます。

全7テーマ

当日各チームが取り組んだテーマは以下の通り、様々だったようです。

  1. AWSとNotebookを使った検証自動化
  2. 自動資産管理棚卸ツール
  3. マルチCDNにおける運用ツール
  4. pcapファイル解析手法䛾改善と可視化
  5. ChatOpsによるトラブルシュート
  6. テレメトリによるTraffic䛾可視化
  7. NW構築䛾工程を全自動化する

優勝チームのテーマは「自動資産管理棚卸ツール」

優勝チームのテーマは「自動資産管理棚卸ツール」でした。おそらく手動では気の乗らない作業であり、かつ、ネットワーク機器へのアクセスは Read のみで安全なので、テーマとしてとても良いと思いました。

技術的には、Ansibleの nmap inventory plugin を利用して、自動的にネットワーク機器を見つけてくる点が興味深かったです。

相変わらず好評

参加者とスタッフによるアンケートでは、「とても良かった」「良かった」で100%、という高い評価だったようです。今回は、Day1 の午前から開催し、午後からはプログラムの裏となってしまうにもかかわらず、25人が参加されたそうです。

普段の業務とは違った環境で、好きなテーマに集中して取り組めるという素敵なイベントだと思います。私も前回の JANOG43 では私もスタッフ兼参加者として関わせていただきましたが、おすすめです。



■ 隠れトラヒック

概要

隠れトラヒック :: janog44

発表者

資料

togetter まとめ

気づき・感想

意外なトラヒック

CDNによるコンテンツ配信制御や、接続性など複雑になったりすることがトラヒックの隠れ要因となるそうです。

なかでも個人的に興味深かったのは、携帯のアラームに関するトラヒックです。アラームで携帯がアクティブな状態になると、裏でいろいろ通信が始まる。アラームを鳴らす前に時刻が合っているか確認ある。 なので、多くの人がアラームを鳴らす時間帯にトラヒックが増えるとのことです。



■ 参加編のまとめ

特に印象的だったプログラムをいくつかとりあげました。他にも、見れなかったプログラムがありましたので、アーカイブが公開されたらチェックしたいと思います。 www.janog.gr.jp

[2019/07/30追記] 各プログラムの詳細ページでアーカイブ配信がはじまりました。2019/9/2(月)の正午頃までの限定公開です。

JANOGは 41から参加させていただいています。参加して、様々な情報にふれ、様々な人たち触れるするたびに、私のエンジニア人生はコミュニティに支えてられているのだなと感じます。

ホストの株式会社アット東京様、協賛各社様、スタッフみなさま、登壇者みなさま、ありがとうございました！

おまけ

f:id:akira6592:20190728213212j:plain:w400
会場へ向かうポートライナー車内にて、地域の一体感が密かに楽しみです

f:id:akira6592:20190728213439j:plain:w400
本会議参加者数は1602名！

f:id:akira6592:20190728213118j:plain:w400
閉会後の空、偶然虹がかかっていました

[Ansible] callback plugin を yaml に変更して標準出力の改行を見やすくする

ansible

■ はじめに

Ansible には callback plugin という仕組みがあり、結果出力の形式を変更したりすることができます。 yaml に変更すると、改行コードごとに改行された形で標準出力されます。

本記事でも、callback plugin を yaml に変更する方法ど、出力例をご紹介します。

なお、本件は先日メンターとして参加させていただいた、Ansibleもくもく会 （サーバ編 & NW編）2019.07 での質疑応答でのやりとりの中で、参加者からいただいたコメントで気付きを得ました。 （いままで特に yaml に変更する用途が思い浮かびませんでた・・）

  • 動作確認環境: Ansible 2.8.0
  • 対象器機: Cisco DevNet Sandox 上の IOS-XE （とても便利です）


■ callback plugin を yaml に変更する

ansible.cfg や環境変数などで変更できます（参考: DEFAULT_STDOUT_CALLBACK）。今回は、ansible.cfg で変更します。

[defaults]
stdout_callback = yaml

なお、ansible-playbook コマンドではなく、ansible コマンドでこの設定変更を有効にするためには、さらに bin_ansible_callbacks = True も必要です。


■ 出力例

Playbook

今回は、 ios_command モジュールを利用して、show version コマンドを実行し、出力結果の stdout を出力させます。

- hosts: ios
  gather_facts: no

  tasks:
    - name: test
      ios_command:
        commands:
          - show version
      register: result

    - name: debug
      debug:
        var: result.stdout

実行

$ ansible-playbook -i inventory ios_test.yml

PLAY [ios] ************************************************************************************************************

TASK [test] ***********************************************************************************************************
ok: [iosal1]

TASK [debug] **********************************************************************************************************
ok: [iosal1] => 
  result.stdout:
  - |-
    Cisco IOS XE Software, Version 16.08.01
    Cisco IOS Software [Fuji], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.8.1, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2018 by Cisco Systems, Inc.
    Compiled Tue 27-Mar-18 13:32 by mcpre
  
(...略...)

    3 Gigabit Ethernet interfaces
    32768K bytes of non-volatile configuration memory.
    16370384K bytes of physical memory.
    7774207K bytes of virtual hard disk at bootflash:.
    0K bytes of WebUI ODM Files at webui:.
  
    Configuration register is 0x2102

PLAY RECAP ************************************************************************************************************
iosal1                     : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

このように、改行コードが解釈された形で表示されます。

なお、

  result.stdout:
  - |-

の | は YAML で複数行の値を示す Syntax です。

参考（デフォルトの場合）

参考までに、デフォルトの場合の出力結果を抜粋して掲載します。

ok: [iosal1] => {
    "result.stdout": [
        "Cisco IOS XE Software, Version 16.08.01\nCisco IOS Software [Fuji], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.8.1, RELEASE SOFTWARE (fc3)\nTechnical Support: http://www.cisco.com/techsupport\nCopyright (c) 1986-2018 by Cisco Systems, Inc.\nCompiled Tue 27-Mar-18 13:32 by mcpre\(...略...)3 Gigabit Ethernet interfaces\n32768K bytes of non-volatile configuration memory.\n16370384K bytes of physical memory.\n7774207K bytes of virtual hard disk at bootflash:.\n0K bytes of WebUI ODM Files at webui:.\n\nConfiguration register is 0x2102"
    ]
}

このように、改行コード \n はそのまま表示されます。

デフォルトの場合でも、stdout ではなく、stdout_lines を表示するようにすると、1行1リストアイテムとして表示されるので見やすいです。ただしクォーテーションが入ります。

ok: [iosal1] => {
    "result.stdout_lines": [
        [
            "Cisco IOS XE Software, Version 16.08.01", 
            "Cisco IOS Software [Fuji], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.8.1, RELEASE SOFTWARE (fc3)", 
            "Technical Support: http://www.cisco.com/techsupport", 
            "Copyright (c) 1986-2018 by Cisco Systems, Inc.", 
            "Compiled Tue 27-Mar-18 13:32 by mcpre", 

(...略...)

            "3 Gigabit Ethernet interfaces", 
            "32768K bytes of non-volatile configuration memory.", 
            "16370384K bytes of physical memory.", 
            "7774207K bytes of virtual hard disk at bootflash:.", 
            "0K bytes of WebUI ODM Files at webui:.", 
            "", 
            "Configuration register is 0x2102"
        ]
    ]
}


■ まとめ

callback plugin を yaml に変更して、改行コードごとに改行された形で標準出力されることをご紹介しました。

[2023/04/20]

この記事の4年後に、似たような記事をまた書いてしまったのでリンクを掲載します。以下の記事では、コレクションに移行後なので community.general.yaml という表記になっています。

tekunabe.hatenablog.jp

[Ansible] 実験的サポートが開始された名前空間機能 Ansible Collections

ansible

はじめに

[Ansible] Ansible 2.8 リリース、便利機能や注意点まとめ - てくなべ (tekunabe) でも少し触れたた通り、Ansible 2.8 から Ansible Collections という機能が実験的サポートとして追加されました。

正直、詳細はまだ理解できていないのですが、名前空間の新しい仕組みのようです。まだまだ情報が少ないのですが、公式の情報のリンクをまとめておきます。

Ansible 2.8 の Changelog

ansible/CHANGELOG-v2.8.rst at stable-2.8 · ansible/ansible · GitHub

Experimental support for Ansible Collections and content namespacing - Ansible content can now be packaged in a collection and addressed via namespaces. This allows for easier sharing, distribution, and installation of bundled modules/roles/plugins, and consistent rules for accessing specific content via namespaces.

Ansible 公式ドキュメント

docs.ansible.com 本記事投稿時現在、develバージョン(2.9相当)のドキュメントにしか掲載されていません。

Ansible Galaxy 公式ドキュメント

galaxy.ansible.com

Webinar

www.ansible.com

ブログ

www.ansible.com

In future releases, we plan for content Creators to be able to provide their content in a package format called a Collection. Collections will be able to be “installed” in the appropriate location for execution whether that’s on the Ansible control node or the managed node. The Collection Creator will be able to provide execution details via roles and playbooks in the package itself. The before mentioned changes to Ansible Engine will allow Collections to be one way to detach content from the official Ansible Engine software delivery process.

ネットワーク機器のコンフィグの固有情報を「匿名化」するツール netconan

network

はじめに

ネットワーク機器のコンフィグファイルをどこかに提示する際、パスワードや IP アドレス、SNMP コミュニティ名などの固有情報をマスクしたり、変更したりする機会はないでしょうか。 netconan はそれを自動で変換してくれるツールです。

github.com

インストール

pip ですぐにインストールできます。

pip install netconan

使い方

オプションで、コンフィグファイル名や、匿名化の詳細を指定します。

  • -i オプションで対象のコンフィグファイル（またはディレクトリ）
  • -o オプションで出力先のファイル名（またはディレクトリ）
  • IPアドレスを匿名化する場合は、-a または --anonymize-ips オプションを指定します
  • -w オプションで「この単語があったら匿名化して」という指定もできます

詳細は、README を参照してください。

以下、ヘルプを転記します。

$ netconan --help
usage: netconan [-h] [-a] [-c CONFIG] [-d DUMP_IP_MAP] -i INPUT
                [-l {DEBUG,INFO,WARNING,ERROR,CRITICAL}] [-n AS_NUMBERS] -o
                OUTPUT [-p] [-r RESERVED_WORDS] [-s SALT] [-u]
                [-w SENSITIVE_WORDS] [--preserve-prefixes PRESERVE_PREFIXES]

Args that can start with '--' can also be set in a config file (specified via
-c). If an arg is specified in more than one place, then command line values
override config file values which override defaults. Config file syntax
allows: key=value, flag=true, stuff=[a,b,c] (for more details, see here
https://goo.gl/R74nmi).

optional arguments:
  -h, --help            show this help message and exit
  -a, --anonymize-ips   Anonymize IP addresses
  -c CONFIG, --config CONFIG
                        Netconan configuration file with defaults for these
                        CLI parameters
  -d DUMP_IP_MAP, --dump-ip-map DUMP_IP_MAP
                        Dump IP address anonymization map to specified file
  -i INPUT, --input INPUT
                        Input file or directory containing files to anonymize
  -l {DEBUG,INFO,WARNING,ERROR,CRITICAL}, --log-level {DEBUG,INFO,WARNING,ERROR,CRITICAL}
                        Determines what level of logs to display
  -n AS_NUMBERS, --as-numbers AS_NUMBERS
                        List of comma separated AS numbers to anonymize
  -o OUTPUT, --output OUTPUT
                        Output file or directory where anonymized files are
                        placed
  -p, --anonymize-passwords
                        Anonymize password and snmp community lines
  -r RESERVED_WORDS, --reserved-words RESERVED_WORDS
                        List of comma separated words that should not be
                        anonymized
  -s SALT, --salt SALT  Salt for IP and sensitive keyword anonymization
  -u, --undo            Undo reversible anonymization (must specify salt)
  -w SENSITIVE_WORDS, --sensitive-words SENSITIVE_WORDS
                        List of comma separated keywords to anonymize
  --preserve-prefixes PRESERVE_PREFIXES
                        List of comma separated IPv4 prefixes to preserve

対応ベンダー

残念ながら一覧になっているドキュメントが見当たりませんでした。 例示されているのは Cisco です。試せてもいませんが、過去の issue などを見ると他に、Juniper、Arista について言及するものはありました。

まとめ

ネットワークコンフィグファイルを「匿名化」するツール netconan をご紹介しました。 この手の作業は意外と手間で、漏れも発生しがちなので、本ツールの活用を検討してみてはいかがでしょうか。

DevLOVE X、やらかした（いい意味で）

event

■ DevLOVE X とは

f:id:akira6592:20190629211239j:plain

2019/06/22 - 23 に、DevLOVE X を開催しました。 devlove.doorkeeper.jp devlove.wixsite.com

DevLOVE X は、DevLOVEという開発(Develop)を愛する人たちのコミュニティの10周年を記念したイベントです。ことの始まりは2008年6月21日。つまり実際は丸11年だったりもします。

2days、60を超えるセッション、5トラックという規模感です。

資料まとめ

まとめありがとうございます。

DevLOVE Xのスライドまとめ #devlovex - 名前考えるの苦手

devlovex を含むはてブ

はてブありがとうございます。

本文 「devlovex」 を検索 - はてなブックマーク

toggeter

まとめありがとうございます。

devlovexに関連する86件のまとめ - Togetter


■ スタッフをやってきました

このイベントのスタッフとして数ヶ月間関わってきました。当日はルームDという部屋の司会を2日間担当しました。twitterの反応を見ながら1日目と2日目のやり方を少し変えたりしました。

続々と揃う登壇者の面々、集まる参加者。そして当日の熱気。 もちろんここまででも充実感に満たされたのですが、その後もぞわぞわした感触に見舞われました。


■ 続々と集まる参加、登壇報告ブログ

その感触は、イベント後に続々とアップされる参加報告によるものでした。やらかしたぞ、これは、と。登壇者によるすばらしいセッションの数々と、参加者によるアウトプットという行動に感謝です。ブログ書くのは初めてという方もいらっしゃって、そんな機会を作れたことをとてもうれしく思います。

ここでは感謝の意味を込めて、私が見つけられた範囲で、参加や登壇、スタッフ報告のブログをまとめます。

ykmc09.hateblo.jp shinyorke.hatenablog.com poohsunny.hatenablog.com iwakiri.hatenablog.com takaking22.com note.mu hub.attractor.co.jp daiksy.hatenablog.jp blog.samuraikatamaris.red note.mu run-around.hatenablog.com keinumata.hatenablog.com www.tsuyok.work note.mu medium.com www.yohhatu.com sun0range.com makow.hatenablog.com shinkufencer.hateblo.jp shinkufencer.hateblo.jp tenten0213.hatenablog.com sun0range.com shacho.beproud.jp arclamp.hatenablog.com hmatsu47.hatenablog.com hmatsu47.hatenablog.com kobase16.hatenablog.com note.mu note.mu note.mu sadayoshi-tada.hatenablog.com note.mu note.mu medium.com note.mu note.mu note.mu

■ さいごに

登壇者みなさま、スポンサー各社さま、会場提供＆当日スタッフしていただいたナビタイムジャパンさま、そしてご参加いただいたみなさま、ありがとうございました！

スタッフのみなさんもおつかれさまでした！！

[Ansible] ネットワークプラットフォームのバージョンとサポートの関係

ansible network

はじめに

Ansible は、Ansible 2.8 現在 50以上のネットワークプラットフォームに対応しています。

プラットフォームごとに、どのバージョンでテスト、サポートされているかの情報が、探すのにやや手間取ってしまうので、こちらにリンクまとめておきます。

Ansible Network Team でメンテナンスされているネットワークモジュール

docs.ansible.com

Ansible のバージョンとネットワークプラットフォームのバージョンのマトリックス

access.redhat.com

その他 参考

www.redhat.com