てくなべ (tekunabe)

ansible / network automation / 学習メモ

Linux女子部主催「新定番!Ansible とZabbixで実現する次世代運用管理」に参加とLT登壇してきました

2018/01/09 に Linux女子部主催の「新定番!Ansible とZabbixで実現する次世代運用管理」という勉強会が開催され、参加とLT登壇させていただきました。 かなり簡単ではありますが個人的な気付きやメモを記述します。

ljstudy.connpass.com


■ 第一部「Zabbix with Red Hat Ansible Automation」(レッドハット 平田さん)

資料はアップされていないようですが、2017/10/07 のイベント時の発表資料と一部は同じ感じでした。 運用管理自動化を実現するポイントとして「誰でも簡単に利用でき、共有 & 再利用しやすい」が挙げられたのが印象的でした。


■ 第二部「今だからこそ活用したいZabbix運用管理」(@qryuu さん )

www.slideshare.net かなり広い範囲の説明がありました。監視サーバーがどんなものかを知っている状態であれば、Zabbixの最初はとりあえずこれ読んでけばOKといった感じがしました。 また「Zabbix 3.2 以降」の比較的新しい情報も含んでいます。


■ LT1 「ネットワークエンジニア的Ansibleの始め方」(私の発表)

www.slideshare.net ネットワークエンジニアにとって、以下の利用でAnsibleはとっつきにくいのではないかという仮定をしました。

  • TeraTermマクロで十分
  • どのモジュールを使えばよいか分からない
  • 試せるネットワーク機器がない

そのうえで、これらのとっつきにくさを解消するための提案をしました。

試せるネットワーク機器がない、対しては仮想環境を利用する方法と、オンラインラボサービスを利用する方法を紹介しました。 詳細は以下の2つの記事にまとめておきました。


■ LT2 「Ansibleで構成管理。〜たったひとつの冴えたやりかた〜」(@isobecky74 さん)

speakerdeck.com パラメータシートと実際の状況が乖離してしまうなら、実ホストからパラメータを生成しようという発想でした。 hash_behaviour という、変数のマージポリシーの設定項目は知りませんでした。


■ LT3「Ansibleブログ活動報告2017」(@curry9999 さん)

speakerdeck.com ものすごいアウトプットの量とAnsibleへの愛を感じました。


参考まとめ・ブログ

togetter.com dev.classmethod.jp www.ap-com.co.jp

さいごに

このような有益な勉強会を開催していただきありがとうございました。 次回開催がありましたら是非参加したいと思います。

HashiCorp Japan による Terraform 日本語ウェビナー動画が見れる件

2017/12/21 に HashiCorp Japan による Terraform の日本語ウェビナーがありました。

ありがたいことに、その時の動画を以下のページ経由で見れるようになっています。 https://register.gotowebinar.com/register/7880841238881662210

以下のような内容になっています。

時間 内容
00:00 - 15:42 HashiCorp の概要、製品の各役割
15:42 - 18:52 DevOpsについて
18:53 - 21:32 Infrastructure As Code について
21:33 - 39:15 Terraformの特徴)
39:16 - 44:58 Terraform Enterprise について
44:59 - Q&A

Terraformは一度も触ったことがなかったのですが、どういうものか、運用上のポイント、Enterprise版の特徴などが知れたので大変助かりました。

今後も日本語ウェビナーを開催される予定とのことなので、 HashiCorp Japanのtwitterアカウント(@hashicorpjp)などで情報を追っていきたいと思います。

twitter.com

仮想ネットワーク機器のオンラインラボサービスの使い方(Network to Code Self Service & On Demand Labs)

[2020/07/23 追記]

残念ながら本サービスは終了したとのことです。いままでありがとうございました。

本サービスは有償でしたが、無償でできる代替としては、以下のようなものがあります。




f:id:akira6592:20180105184134p:plain:w400]

■ はじめに

ネットワーク機器の操作の学習をしたいときや、自動化の仕組みの動作確認をしたいときは物理や仮想環境としてネットワーク機器を用意する必要があります。ハードウェアやソフトウェアの手配が難しかったり、環境構築の手間がかかったりして、用意がしにくいこともあります。

そこで候補に挙げられるのが、インターネット経由で利用できるラボサービスです。今回は Network to Code Self Service & On Demand Labs (以下、ラボサービス)という有料サービスの概要と使い方をご紹介します。

(サービスの情報は 2018/01/05 現在、独自の調査に基づくものです)


■ ラボサービスの概要

Network to Code Self Service & On Demand Labs は、インターネット経由で利用できる仮想ネットワーク環境の有料ラボサービスです。 機種や台数によって料金は異なりますが、$4.00/5h からプランがあります。(例 Cisco CSR 1000V 1台)

詳細はプランの一覧ページ]を参照してください。

https://labs.networktocode.com/labs

また、各プランには Ubuntu ホストもセットになっています。 各ネットワーク機器、Ubuntu ホストにはそれぞれグローバルIPv4アドレスが払い出されます。 そのため、お手元のWindows端末からTeraTermSSH接続したり、グローバルIPv4アドレスを持った既存のネットワーク機器と連携するといったことができます。

対応機種・OS

以下の機種・OSに対応するプランがあります。


■ 登録

ラボサービスを利用するには、まずユーザー登録する必要があります。

https://labs.networktocode.com/

右上の Sign Up ボタンからユーザー登録を行います。


■ ラボの利用

プランの選択と購入

ユーザー登録後、ログインし、 Labs をクリックするとプランの一覧が表示されます。 f:id:akira6592:20180105182624p:plain:w500

  ↓

f:id:akira6592:20180105182738p:plain:w500

利用したいプランの Buy Now ボタンをクリックし、期間や数量、クレジットカード情報を記入して Buy Now ボタンをクリックします。 ここでは vMX STANDALONE を選択したものとして説明をします。

f:id:akira6592:20180105183111p:plain:w500

起動

購入したプランの Start ボタンをクリックするとラボ環境が起動します。 f:id:akira6592:20180105183210p:plain:w500

  ↓

f:id:akira6592:20180105183300p:plain:w500

なお、一度クリックしただけでは起動しないことがあるようなので、以下のように起動中の表示(Loading...)になるまで Start ボタンをクリックします。 (料金が多重引き落としされた経験はありません)

起動が完了すると以下のように Started という表示なります。 f:id:akira6592:20180105183335p:plain:w500

接続

前述したとおり、各環境にはグローバルIPv4アドレスが払い出されますので、払い出されたIPアドレスを確認するために Console & IP Address Information をクリックします。 f:id:akira6592:20180105183402p:plain:w500

  ↓

f:id:akira6592:20180105184833p:plain:w500

今回の場合は、 jump_hostUbuntuvmx1 がネットワーク機器(vMX)になります。この画面に表示されている Public IP AddressSSH接続できます。ユーザー名/パスワードは上記画面にも記載されている通りです。

jump_host という名前から、jump_host を踏み台にしてからでないと vmx1 に接続できない印象をもたれるかもしれませんが、実際は各環境に直接接続できます。 なお、 Private Address は、ラボサービス内機器同士でだけ接続可能なプレイベートIPアドレスです。

また、各環境の Console をクリックすると、ブラウザ上でコンソールを開けます。

jump_host のコンソール(GUI

f:id:akira6592:20180105183613p:plain:w500

vmx1 のコンソール(CLI

f:id:akira6592:20180105183622p:plain:w500

jump_host の環境

記事執筆現在は以下の通りでした。

vmx1 の環境

記事執筆現在は以下の通りでした。

  • Junos 15.1F4.15

■ ラボの停止

ラボを停止したい場合は、 Stop ボタンをクリックします。 f:id:akira6592:20180105183653p:plain:w500

停止が完了すると以下のように Not Started という表示なります。 f:id:akira6592:20180105183810p:plain:w500

一度停止しても、一定の残り時間があれば再開・停止を繰り返すことができます。 詳細は Frequently Asked QuestionsCan labs be stopped and re-started? を参照してください。


■ まとめ

ラボサービスのユーザー登録とラボへの接続までの手順をご覧いただきました。 有料ですが、環境構築の手間がかからないのは魅力ではないでしょうか。 検証環境の候補にして頂ければと思います。

StackStormの勉強会(Tech Night @ Shiodome # 5)のスライドと動画まとめ

2017/10/11 に StackStorm をテーマにした「Tech Night @ Shiodome # 5」が開催され、参加してきました。 日本語の情報はまだそこまで多くないので、大変参考になる勉強会でした。 techsio.connpass.com

各発表のスライドはconnpassのページにまとまられていますが、この他にもExtreme Networks Japan のYouTube アカウントで動画がアップされていたことに気が付いたので、まとめてリンクを掲載します。


■ カンバン×Chatで変わる運用

スライド

www.slideshare.net

動画

www.youtube.com


■ StackStormを用いて業務を自動化してみませんか?

スライド

www.slideshare.net

動画

www.youtube.com


■ StackStormのワークフローを使ってみよう!

スライド

docs.google.com

動画

www.youtube.com


■ 本気で使うStackStorm

スライド

www.slideshare.net

動画

www.youtube.com

予防より復旧:システム障害に対する考え方

■ 予防より復旧

以前「Infrastructure as Code」という本を読んだときの全体的な感想として「予防より復旧が重要」と書きました。

tekunabe.hatenablog.jp

いくらシステムを堅牢に作っていても壊れれるときは壊れます。 また、ニーズなどの外部環境は絶えず変更が繰り返され、システムへの変更を行う際にも障害は発生しやすいです。 そのため、障害を恐れて予防に注力するあまり復旧の仕組みをおろそかにするよりも、障害を前提としていかに早く、正確に復旧させるかを考える方が重要だと感じました。


レジリエンスエンジニアリングとSafety-Ⅰ、Safety-Ⅱ

最近「レジリエンスエンジニアリング」「Safety-Ⅰ、Safety-Ⅱ」という言葉に出会いました。  

参考: レジリエンスエンジニアリング目指すSafety-Ⅱ とその実現法(PDF)  

私が目にする資料での「レジリエンス」は「復元力」「耐久力」といった意味合いです。 Safety-Ⅰ、Safety-Ⅱ は、安全に対する考え方のモデルです。

- Safety-Ⅰ: うまくいかなくなる可能性を持つことを取り除く
- Safety-Ⅱ: うまくいくこと理由を調べ、それが起こる可能性を増大させる

参考: Safety‐1 & Safety‐2―安全マネジメントの過去と未来

参考: Safety-Ⅰ&Safety-Ⅱ ─ 安全マネジメントの過去と未来(書籍紹介PDF)

ちょうど、予防メインの考え方がSafety-Ⅰ、復旧メインの考え方がSafety-Ⅱという対応なのかなと思い、自分の考えが少し整理できました。 「設定より規約」のようなノリの言葉として、システム設計をするうえで考慮するポイントの一つにしていきたいと思います。

プレゼンでデモをするときに気を付けていること

これは プレゼン研究会 Advent Calendar 2017 の7日目の記事です。 (空いているところへの遡り投稿です)

はじめに

エンジニアがプレゼンをする際、デモを伴うこともあると思います。 せっかく準備したデモ、失敗したくありませんし、見てほしいですよね。 ここでは私がプレゼン中にデモをするときに気を付けてるポイントを記述します。

いきなりまとめ

  • 1. 動画を準備する - 失敗に備える

  • 2. きちんと説明する - 何をするのか、どこを見てほしいか

  • 3. 場を繋ぐ - 準備中も黙らずに何か話す


■ 1. 動画を準備する - 失敗に備える

f:id:akira6592:20171224103216p:plain

限られた時間の中でデモをするには失敗時に備える必要があります。 具体的には、動画を準備します。

動画を準備しておかないと、いつまでもライブデモにこだわって時間を消費してしまったり、何も伝わらなかったりします。

動画を準備しておくことで、ライブデモ失敗時に諦めて動画に切り替えて時間を守ることができ、そこそこ見せたかったものを見せることができます。また、気持ちにも余裕ができます。

■ 2. きちんと説明する - 何をするのか、どこを見てほしいか

f:id:akira6592:20171224103228p:plain

参加者はデモで具体的に何をするかを詳細には知りません。 知らないと、ただマウスポインタや、カチカチ切り替わるウィンドウをひたすら追ったりして、酔ってしまい内容に集中できません。

  • これから何をするのか
  • どこを見てほしいか

をきちんと説明することによって、内容に集中することができます。

■ 3. 場を繋ぐ - 黙らずに何か話す

f:id:akira6592:20171224103322p:plain

本番中のデモの準備や手順と手順の間は沈黙になりがちです。

沈黙が続くと参加者は「さっき初耳だった言葉を調べてみよう」とか「懇親会どうしようかなぁ・・」といったように、気がそれてしまいます。

簡単でもいいので「今準備しますね。こちらが操作画面で、、、で、こっちがログが出る画面っと」とか「いま処理中で、裏では~~が走っています」とか、話すことで場を繋いで意識を集中したままにしてもらうようにします。


まとめ

プレゼンでもデモをする際に個人的に気を付けていることを記述しました。

「1. 動画を準備する」は少し手間ではありますが、事前にできて不安を潰せるので、オススメです。

「2. きちんと説明する」「3. 場を繋ぐ」はいずれも本番中のポイントですが、発表に集中してもらいたいという意味で共通です。

どこまで効果的かは判断が難しいですが、参考になれば幸いです。

Ansible で Cisco IOS からの ping 結果を CSV 出力する

これは Ansible Advent Calendar 2017 の18日目の記事です。

■ やりたいこと

Ansible で Cisco IOS から複数のIPアドレスに対してpingを実行し、その結果をCSVファイルに出力します。本記事では、利用する ios_ping モジュールの説明と、 Playbookのサンプルをご紹介します。 f:id:akira6592:20171216125403p:plain

ios_ping モジュールの説明

ios_pingCisco IOS の機器から ping を実行して、ロス率やRTT値など パース して返してくれるモジュールです。Ansible 2.4 で追加されました。(本記事は Ansible 2.4.2 を前提としています)

参考: ios_ping モジュール公式ドキュメント

手作業によるコマンド結果と、パースして取得できる情報の関係は以下の通りです。 f:id:akira6592:20171216130704p:plain

主なオプション

ios_ping モジュール固有のオプションは以下の通りです。

オプション名 必須/任意 デフォルト 説明 対応IOSコマンド書式 要特権(*1)
dest 必須 ping を実行する相手先のIPアドレス、ホスト名です。 ping [dest] 要特権
count 任意 5 ping を実行する回数です。本オプションと、IOSpingコマンドのタイムアウト(私の環境では2秒)を考慮し、ios_ping モジュールのタスクとしてのタイムアウト( timeout オプション: デフォルト10秒) を設定する必要があります。 ping [dest] repeat [count] 要特権
source 任意 送信元の指定です。 ping [dest] source [source] 要特権
state 任意 present 想定するping結果の指定です。 想定結果が成功なら present、失敗なら absent を指定します。成功、失敗の基準は公式ドキュメントに記載されていませんが、ios_ping.pyのコードを見ると「ロス率が100%未満→成功」「ロス率が100%→失敗」ということが分かります。 要特権
vrf 任意 default 利用するVRFの指定です。 ping vrf [vrf] [dest] 要特権
  • 要特権(*1) と書かれているオプションを利用するには、IOSへログインするユーザーに特権が必要です。手動実行と同じ事情です。
  • 認証系のオプションである provider 等は 他の ios_command 等のモジュールと共通です。
  • 全オプションは ios_ping モジュール公式ドキュメント を参照して下さい。

ping結果をCSV出力するためのPlaybookなど

・Playbook

Playbook 本体です。

---
- hosts: ios  # インベントリファイルにて10.0.0.1を定義済み
  gather_facts: no
  connection: local
  
  tasks:
    - name: ping
      ios_ping:
        dest: "{{ item }}"
        count: 5        # default
        provider: "{{ cli }}"
      with_items:
        - 192.168.1.1
        - 192.168.1.2
        - 192.168.1.3
        - 192.168.1.4
        - 192.168.1.5
        - 192.168.1.6
        - 192.168.1.7
        - 192.168.1.8
        - 192.168.1.9
        - 192.168.1.10
      ignore_errors: yes
      register: result
    
    - name: output csv file
      template:
        src: ./template_ping_result.txt
        dest: "./ping_from_{{ inventory_hostname }}_result.csv"

  vars:
    cli:
      host: "{{ inventory_hostname }}"
      timeout: 15     # (5 * 2) + margin
      username: testuser
      password: testpassword
      authorize: yes
      auth_pass: testpassword

Playbook の補足説明

  • with_items を利用して、複数の宛先へのping結果を取得するようにしています。必要に応じてパラメータ化して下しさい。
  • state オプションは省略しているため、成功(ロス率100%未満)を想定しています。もしpingが失敗した場合は、playbook中のタスクとしてfailed 扱いになります。
  • 今回は想定外の state になった場合の挙動も確認しつつ、タスクを続行したかったため、少々乱暴ですが ignore_errors: yes を指定しています。
  • count: 5(デフォルトと同じ)にしているため、IOS側のpingコマンド仕様のタイムアウト2秒を考慮すると、ロス率100%の宛先相手の場合pingが完了に10秒かかります。タスクとしての timeuout オプションのデフォルトも10秒のため、pingが完了する前にタスクとしてタイムアウトしています。この問題の対策として「count オプション × pingコマンドタイムアウト = 10秒」にさらに余裕を加えて、ios_ping モジュールの timeout オプションを 15 としています。

・テンプレート

ping結果をCSVファイルに整形するするためのテンプレートです。いろいろカスタマイズできます。

"dest","packet_loss","packets_rx","packets_tx","rtt_avg","rtt_max","rtt_min","msg"
{% for r in result['results'] %}
"{{r['item'] }}","{{ r['packet_loss'] }}",{{ r['packets_rx'] }},{{ r['packets_tx'] }},{{ r['rtt']['avg'] }},{{ r['rtt']['max']}},{{ r['rtt']['min'] }},"{{ r['msg'] | default('') }}"
{% endfor %}

テンプレートの補足説明

  • Playbook 中で 変数 results として取得した複数のping結果を、1宛先ごとにループしています。
  • msg は想定外の stete の時のみ返ってくる値です。そのため、想定通りの state の場合に msg を出力しようとするとエラーになっていまいます。エラー対策として、default フィルターを利用して、返ってこなかった場合に空文字になるようにしています。

■ 実行その1(全OK)

すべての宛先のping結果が想定通りの state の場合です。

・playbookの実行

[vagrant@centos7 vagrant]$ ansible-playbook -i hosts ping.yml

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

TASK [ping] ********************************************************************
ok: [10.0.0.1] => (item=192.168.1.1)
ok: [10.0.0.1] => (item=192.168.1.2)
ok: [10.0.0.1] => (item=192.168.1.3)
ok: [10.0.0.1] => (item=192.168.1.4)
ok: [10.0.0.1] => (item=192.168.1.5)
ok: [10.0.0.1] => (item=192.168.1.6)
ok: [10.0.0.1] => (item=192.168.1.7)
ok: [10.0.0.1] => (item=192.168.1.8)
ok: [10.0.0.1] => (item=192.168.1.9)
ok: [10.0.0.1] => (item=192.168.1.10)

TASK [output csv file] *********************************************************
changed: [10.0.0.1]

PLAY RECAP *********************************************************************
10.0.0.1               : ok=2    changed=1    unreachable=0    failed=0

CSV出力結果

[vagrant@centos7 vagrant]$ cat ping_from_10.0.0.1_result.csv
"dest","packet_loss","packets_rx","packets_tx","rtt_avg","rtt_max","rtt_min","msg"
"192.168.1.1","0%",5,5,2,9,1,""
"192.168.1.2","0%",5,5,2,9,1,""
"192.168.1.3","0%",5,5,8,9,8,""
"192.168.1.4","0%",5,5,7,9,1,""
"192.168.1.5","0%",5,5,6,9,1,""
"192.168.1.6","0%",5,5,8,9,8,""
"192.168.1.7","0%",5,5,8,9,8,""
"192.168.1.8","0%",5,5,7,9,1,""
"192.168.1.9","0%",5,5,7,9,1,""
"192.168.1.10","0%",5,5,8,9,8,""

■ 実行その2(一部NG)

一部宛先のping結果が想定外の state の場合です。

・Playbook実行

[vagrant@centos7 vagrant]$ ansible-playbook -i hosts ping.yml

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

TASK [ping] ********************************************************************
ok: [10.0.0.1] => (item=192.168.1.1)
failed: [10.0.0.1] (item=192.168.1.2) => {"changed": false, "commands": ["ping 192.168.1.99 repeat 5"], "item": "192.168.1.99", "msg": "Ping failed unexpectedly", "packet_loss": "100%", "packets_rx": 0, "packets_tx": 5, "rtt": {"avg": null, "max": null, "min": null}}
ok: [10.0.0.1] => (item=192.168.1.3)
ok: [10.0.0.1] => (item=192.168.1.4)
ok: [10.0.0.1] => (item=192.168.1.5)
ok: [10.0.0.1] => (item=192.168.1.6)
ok: [10.0.0.1] => (item=192.168.1.7)
ok: [10.0.0.1] => (item=192.168.1.8)
ok: [10.0.0.1] => (item=192.168.1.9)
ok: [10.0.0.1] => (item=192.168.1.10)
...ignoring

TASK [temp] ********************************************************************
changed: [10.0.0.1]

PLAY RECAP *********************************************************************
10.0.0.1               : ok=2    changed=1    unreachable=0    failed=0

想定外だった宛先に対するpingのタスクは failed になります。

CSV出力結果

以下の通り、疎通が取れる想定だった宛先に対して、ロス率100%だった場合は、msgPing failed unexpectedly となります。

[vagrant@centos7 vagrant]$ cat ping_from_10.0.0.1_result.csv
"dest","packet_loss","packets_rx","packets_tx","rtt_avg","rtt_max","rtt_min","msg"
"192.168.1.1","0%",5,5,2,9,1,""
"192.168.1.2",”100%",0,5,,,,"Ping failed unexpectedly"
"192.168.1.3","0%",5,5,8,9,8,""
"192.168.1.4","0%",5,5,7,9,1,""
"192.168.1.5","0%",5,5,6,9,1,""
"192.168.1.6","0%",5,5,8,9,8,""
"192.168.1.7","0%",5,5,8,9,8,""
"192.168.1.8","0%",5,5,7,9,1,""
"192.168.1.9","0%",5,5,7,9,1,""
"192.168.1.10","0%",5,5,8,9,8,""

なお、疎通が取れない想定だった宛先に対して、ロス率100%未満 の場合は、msgPing succeeded unexpectedly となります。

■ まとめ

Ansible の ios_ping モジュールと template モジュール利用して、Cisco IOS からの ping 結果を CSV 出力してみました。 counttimeout の関係や、「何をもって成功/失敗とするか」あたりがポイントです。 また、今回はping実行ホスト1台につき1つのCSVファイルを生成しましたが、作り方次第では1つのファイルにまとめることも可能かと思います。 もし、今回のような内容をしたい場合に、本記事が参考になれば幸いです。