てくなべ (tekunabe)

ansible / network automation / 学習メモ

「3社共催 Ansible セミナー "経験から学ぶ Ansible の活用方法" Part 3」参加メモ

ansible automation

2017/10/06 にレッドハットさんを会場として開催された 「3社共催 Ansible セミナー "経験から学ぶ Ansible の活用方法" Part 3」 に参加してきました、参加メモを掲載いたします。

殴り書きに近い箇所もあるため、貼り付け付けたPDF資料もあわせてご参照していただければと思います。 （資料の掲載も主催の方から許可をいただいております。）

[目次]

■ 1. Ansible 最新情報 (by レッドハット）

【発表資料】

Ansible 最新情報 (PDF)

Ansible とは

  • 自動化の目的
    • 生産性と品質を継続的に改善し、陳腐化を防止
  • 自動化実現のポイント
    • 統一的な手法であること
    • 再利用、共有できること
    • 権限付与と集中管理できること
      • Ansbile Towerでセルフサービス化できる
  • 特定のユースケースにしか使えないツールもあるが、Ansible はあらゆる状況・ものを対象

9/7 Ansible Fest での発表

  • Red Hat Ansible Engineの発表
  • AWX Project の発表
  • Ansible Tower 3.2 のリリース予定

いままで

  • OSSのコードを含んでいた
  • これではサポートしきれない

これから

  • Ansible Engine
  • Red Hat Ansible Automation
    • 以下二つ
    • ラインナップ
      • Engine のみ
      • Tower と Engine の組み合わせ

Ansible Engine とは

  • いままでとは提供方法、インストール方法が変更になる
  • Red Hat 提供のリポジトリから取得
  • サポート可能な精査済みのソースコード
  • Ansible (core) 2.4 をベース

Ansible 2.4

  • Python 2.6 からのサポートに変更(2.5 とそれ以前はサポートしない)
  • 今後は 3 へ移行予定
    • 基本的なモジュールは Python 3 で動く
  • ネットワークモジュールのトピック
    • ios_vrf での例
      • コマンドベースではなく宣言的に記述できる
      • 冪統性もある
      • なにをする、ではなく、どういう状態かを定義
      • aggregate オプションでまとめて定義できる

Ansible Tower 3.2 新機能

  • Ansible Tower インスタンスグループ
    • Cluster の進化形
  • Ansible Tower 分離ノード
    • Web UI も持たない、Headless ノード
  • Red Hat Insights 連携
    • Insights の診断結果を Tower に表示できる
    • 問題に対処するための Playbook が提供される
  • カスタムクレデンシャル
    • いままでは特定の型のみだったが柔軟になる
  • SCM インベントリ
    • Tower に直接登録しなくても、git上等のインベントリファイルを取り込めるようになる
  • Built-in Fact Caching
    • ジョブ開始が早くなる

トレーニング

  • DO407/408
    • 資格試験ありのコースもあり

■2. みんなで使おう Ansible 応用編 （by ライトウェル）

【発表資料】

みんなで使おうAnsible 〜応用編〜 (PDF)

インベントリ

  • インベントリファイル単体での課題
    • 手動のメンテナンスは大変
  • ダイナミックインベントリ
    • 動的に生成できる
    • AWS EC2 のように IPアドレスがころころ変わるケースでも対応できる

kintone との連携の概要

  • 流れ
    • kintone上で必要な情報を入力
    • Ansibleが定期的な情報を取得
    • VMware テンプレートへの展開
    • kintone はホスト情報DB、操作UIとして利用
  • きっかけ
    • 検証環境がほしいときにVM担当者がいなくて作れなくて困ることがあった
    • 他の人でも検証環境を構築できるようにしたかった

Dnyamic Inventory

  • 作り方のルール
    • 実行可能
    • 言語は何でもいい（今回はbash）
    • jsonで返す

Ansible/kintone運用後の効果

  • 仮想マシンをVM担当者外でも作れるようになった
  • VM担当者の負担が減った

課題・小ネタ

  • kintone から動的にAnsibleをキックできない
    • Ansible側のスケジュール機能を使って対処
  • replace モジュール
    • 漢字の検索・置換ができない

まとめ

  • kintone は簡単にWebアプリを作れる
    • Ansible と組み合わせればインフラエンジニアでも業務アプリがつくれそう

■ 3. 使ってみよう Ansible コミュニティ版（by サイオステクノロジー）

【発表資料】

使ってみよう Ansibleコミュニティ版 (PDF)

AWX の位置づけ

  • Ansible Tower のOSS版
  • RHELとFedoraでいうと
    • RHEL が Ansible Tower
    • Fedora が Ansible AWX(upstream)
  • AWXでは新しい機能が入ってくるので安定性ではTowerのほうが勝る
  • 見つけた問題はコミュニティーにフィードバックできる

インストール

  • docker が必要なので敷居が高いように思われるが、やってみると簡単
  • docker-py が必要なのを忘れがちなので気を付ける
  • インストール用のPlaybookがあるので簡単
    • Docker の設定など含む
  • 手順詳細
  • はまるポイント
    • いくつかのコンテナが起動するので、スペック不足だと起動エラーになりがち
    • 4コア以上は必要では
    • 管理画面は80/TCPなのでFWで空ける

Tower との違い

  • メニューの表示は異なるが、中身は出方はだいたい同じ

■ 感想など

  • ここ最近、Ansibleのラインナップに大きな変化があったを改めて確認できた助かりました。
  • kintone は使用したことがなかったのですが、簡易的なWebアプリを画面から作成できる点が興味深かったです。インベントリとして活用するアイディアも面白いと思いました。
  • AWX はマシンスペックさえ気を付ければ思ったよりは簡単にインストールできそうだと感じました。

NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13 に参加と登壇してきました

ansible automation network napalm

2017/10/10 に　NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13 が開催され、参加と登壇してきました。 簡単な個人的な気付きやメモを記述します。

network-programmability.connpass.com

■ イントロダクション

www.slideshare.net

■ 自動化と監視の推進奮闘記

www.slideshare.net

  • 自動化、抽象化するツールがあっても、利用している機種やバージョンが対応している最も低いレベルに合わせてツール選定や開発を行う必要があったということで、なかなか理想通りにはいかないなと感じました。
  • 一部は JANOG40 での発表でもご紹介あった内容でした。 www.janog.gr.jp

■ Ansible x NAPALM x NSO 解説・比較パネルディスカッション

www.slideshare.net

様々なネットワーク自動化のためのツールが登場している中、馬淵さんがモデレータとなり、岩本さんがCisco NSO のご紹介、私が AnsibleとNAPALMの紹介をそれぞれ行い、その後パネルディスカッションを行いました。

Cisco NSO について

www.slideshare.net

  • 現状対応していない機種でも要望に応じて対応させるという点と、「Netsim」というモックデバイス機能がある点が素敵だなと思いました。

Ansible と NAPALM について（私の発表パート）

www.slideshare.net

  • ネットワーク対応も進んでいる構成管理ツール「Ansible」と、ネットワーク抽象化Pythonライブラリの「NAPALM」についてご紹介しました。
  • 7月、8月に弊社で行った勉強会の資料をベースしました。
  • Ansible は version 2.4 で追加になった net_* 系モジュールの紹介を加えました。
    • 代表してnet_static_route の使用例を載せました。
    • コマンドを直接書かなくていい点や、 state オプションがある点で、Ansible モジュールらしいなと思いました。
  • NAPALM ではテストとして利用できそうな Validateion 機能の紹介を加えました。

パネルディスカッション

  • モデレータの馬淵さんからあらかじめ用意されたいくつかのテーマに基づいてパネルディスカッションを行いました。
  • 自動化を進めるにあたっての壁は、安全性の担保であったり、自動化に対するマインド面であることが、ある程度共通認識であるように感じました。
  • 当日は発言できませんでしたが、いきなり設定変更を自動化するのではなく、影響の少ない状態取得から自動化していくと良いのかなと思いました。
  • Cisco NSO については、これから投入するコンフィグが何かを確認する機能があるとのことです。
    • Ansible でいう、 --check --diff オプションを付けたときのようなイメージかと思います。
  • 個人的には、Ansible はこれからも注目していきたいと思っています。

■ Telemetry事始め

www.slideshare.net

  • SNMPを置き換えるべく、新しい規格が作られていることを知れました。
  • gRPCやOpenConfigあたりの動向は追っていきたいと思います。

■ LT

他にも興味深い発表があり、発表資料が以下のページにまとまっていますので、もしよろしければご覧ください。

network-programmability.connpass.com

以下、抜粋となってしまいますが感想など。

On-box programmability

www.slideshare.net

  • Catalyst 3850 のような安価な機種でも On Box Python が使用できるようになって、これから活用事例が出てきやすいのかなと思いました。

Literate Computing for Reproducible Infrastructure

github.com

  • 便利な手順書としての Jupyter Notebook の活用方法が興味深かったです。

パケットキャプチャでインフラ主導のデバッグ環境を作る

www.slideshare.net

  • 異常時の問題解析は、通常時の情報収集がないと始まらないのだなと改めて思いました。

togetter まとめ

NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13 ツイートまとめ - Togetter

id:stereocat さん、まとめありがとうございます。

■ さいごに

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

AnsibleFest San Francisco 2017 で気になったネットワークとテスト自動化の動画

ansible automation

はじめに

先日行われた AnsibleFest San Francisco 2017 での発表の動画が、26個ほど以下のページに掲載されています。

www.ansible.com

私が特に気になったネットワークとテストの動画を簡単にご紹介します。

■ ANSIBLE FOR NETWORKS: GOING BEYOND STATIC CONFIG TEMPLATES

www.ansible.com

  • コンフィグのテンプレートファイルを利用してコンフィグ投入する事例
  • 紹介されていたplaybookは以下の通り
    • template モジュールで、コンフィグを生成
    • napalm_install_config モジュールで、コンフィグ投入
    • file モジュールでファイルを削除
  • gitを用いたワークフロー
  • 一連の流れは Jenkins の pipeline を利用して実装

■ AUTOMATING NETWORK OPERATIONS AT OPENTABLE

www.ansible.com

  • コンソールサーバーを利用して、初期セットアップを含めた以下のフローの図が気になりました f:id:akira6592:20171008193815p:plain

■ INFASTRUCTURE TESTING WITH MOLECULE

www.ansible.com

  • Ansible と組み合わせたテスト自動化には何を使うか（Ansible自身、TestKichen等々）
  • 今回は molecule というテストフレームワークの紹介
  • python製、Windowsは非サポート
  • テストは以下の流れ
    • テスト用ノードを作成
    • ノードに対してolaybookを実行
    • 再度playbookを実行してべき統性を確認
    • lintを実行
  • ノード作成は以下のドライバーを利用可能
    • Docker
    • OpenStack
    • Vagrant(デフォルト)
  • テスト実行は以下を利用可能（Verifiers）
    • testinfra(デフォルト)
    • Serverspec
    • Goss
  • 発表資料やコードは以下のページに掲載

以上です

【実機不要】 Ansible の FortiOSモジュールでコンフィグファイルの操作を試す（残課題あり）

ansible automation

f:id:akira6592:20171005113718p:plain

■ 1. はじめに

Ansible のネットワークモジュールは基本的に動作中の機器に対して操作を行います。 ただし、一部のモジュールでは実機ではなくコンフィグファイルを操作できるモジュールもあります。 この記事では fortios_address モジュールを利用して、Fortigate のコンフィグファイル中のアドレスオブジェクトを操作してみます。

（最後に記述しますが一部残課題があります。）

fortios_* 系モジュールの file_mode オプション

Ansible 2.4 で追加された fortios_config などの fortios_* 系モジュールにある file_mode を yes にすると、実機ではなく config_file オプションで指定したコンフィグファイルを操作します。

モジュール例

fortios_address - Manage fortios firewall address objects — Ansible Documentation

■ 2. 準備

モジュール のインストール

実行には pyFG と netaddr というモジュールが必要なので、インストールしておきます。

pip install pyfg netaddr

コンフィグファイルの準備

あらかじめ、実機からダウンロードするなどしてコンフィグファイルを準備しておきます。 ここでは config.txt というファイル名と仮定します。

なお、試した限りですと、操作対象の階層が含まれる部分的なコンフィグファイルでも大丈夫そうです。 例えば fortios_address モジュールで、アドレスオブジェクトを操作する場合、以下の部分的なコンフィグファイルで動作しました。

config firewall address
end

この方法であれば、実機不要で試すことができます。

■ 3. playbookの作成

以下のようなplaybookを作成します。 ここでは、公式ドキュメントの例にあるような、 google_dns というアドレスオブジェクトが 定義されている状態にするplaybookにします。

---
- hosts: localhost    # 実機を対象としない。ここではダミー的に localhost とする
  gather_facts: no
  connection: local

  tasks:
    - name: Register google DNS
      fortios_address:
        state: present
        name: "google_dns"
        type: ipmask
        value: 8.8.8.8
        file_mode: yes 　 　         # 実機ではなくコンフィグファイルを操作対象とするモード
        config_file: forti.config  # 操作したいコンフィグファイル

■ 4. 実行

事前確認

実行前の config.txt は以下の内容です。

～（略）～
config firewall address
    edit "all"
    next
end
～（略）～

実行

[vagrant@centos7 vagrant]$ ansible-playbook forti.yml

PLAY [localhost] ******************************************************************************************************************************

TASK [Register google DNS] ********************************************************************************************************************
changed: [localhost]

PLAY RECAP ************************************************************************************************************************************
localhost                  : ok=1    changed=1    unreachable=0    failed=0

事後確認

以下のコンフィグファイルの内容になりました。

～（略）～
    config firewall address
        edit all
        next
        edit google_dns
          set subnet 8.8.8.8 255.255.255.255
        next
    end
～（略）～

冪統制確認

もう一度、同じplaybookを実行してみます。

[vagrant@centos7 vagrant]$ ansible-playbook forti.yml

PLAY [localhost] ******************************************************************************************************************************

TASK [Register google DNS] ********************************************************************************************************************
ok: [localhost]

PLAY RECAP ************************************************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0

すでに google_dns というアドレスオブジェクトがあるため、 changed=0 となりました。

デモ動画

左上がplaybook、右上が部分的なコンフィグファイル、下がコンソールです 右上の部分的なコンフィグファイルが書き換わります。 f:id:akira6592:20171005120517g:plain

■ 5．残課題

事前事後のコンフィグファイルを比較すると分かるのですが、意図したアドレスオブジェクトの定義のほかに、全体的に以下の2点の変更がされました。

  • インデント追加
  • ダブルクォーテーションの削除

他にも意図しない変更があったためか、変更後のコンフィグファイルを実機にリストアしようとしても、エラーになってしまいました。 内部の動作を細かく見れていませんが、少なくとも私の環境（v5.0系）では現状は限定的な利用にとどめておいた方がよさそうです。

コンソールケーブルのツメ折れ問題と対策

f:id:akira6592:20170930130515p:plain

はじめに

ネットワーク機器の初期設定時などに接続するためのコンソールケーブルですが、コネクタがRJ-45のものはツメが折れてしまうことがあります。 LANケーブルでしたら、交換すればよいのですが、コンソールケーブルですと手元に代わりがなくて交換できないこともあります。 そこでツメが折れないような予防が大切と考えています。 この記事では「JJコネクタを挟む」「カバーを付ける」という2つの対策について書きます。

■ 対策1：JJコネクタを挟む

JJコネクタを挟むことによって、ツメ折れ防止のLANケーブルを利用できたり、交換可能な状態にできたりします。 ただし、パーツ数が多くて少々ゴワつくところが難点です。 f:id:akira6592:20170930120531j:plain

■ 対策2：カバーを付ける

この手のカバーを付けます。既存のケーブルに後から付けられるタイプです。 www2.elecom.co.jp

ただし「きしめん」と呼ばれるようなケーブルの形状ではそのままでは付けられません。 f:id:akira6592:20170930125522j:plain

そのため、カッターで削ることにします。 f:id:akira6592:20170930125532j:plain

完成です。 f:id:akira6592:20170930125632j:plain

どうしても空洞ができてしまいますが、簡単にはズレないので良しとします。

Ansibleでネットワーク機器のshowコマンド結果をパースする方法まとめ

ansible network automation

f:id:akira6592:20170924222135p:plain

Ansibleでshowコマンドの結果をパースする方法が増えてきています。 この記事ではCisco IOSを対象として、標準でできるかどうか、どういう情報をパースできるかなどの観点で、4つの方法を簡単にまとめます。

■ 概要

  • parse_cli_textfsm フィルター
    • Ansible 2.4 から標準で利用可能。TextFSMテンプレートを利用して拡張可能。
  • ansible_helpers フィルター
  • ios_facts モジュール
    • Ansible 2.2 から利用可能。パース可能情報は少なめ。
  • napalm_get_facts モジュール

■ 1. parse_cli_textfsm フィルター

・タイプ

標準のフィルタープラグイン

Filters — Ansible Documentation

・利用可能バージョン

Ansible 2.4 から

・パースできる情報

  • TextFSM 形式で定義すれば任意のコマンドをパース可能
  • Network to Code の テンプレートがとっかかりとして便利 https://github.com/networktocode/ntc-templates/tree/master/templates
  • 例
    • show interfaces
    • show interfaces status
    • show inventory
    • show ip bgp summary
    • show ip int brief
    • show ip ospf neighbor
    • show ip route

・パース結果例

インターフェース情報

        {
            "DUPLEX": "auto",
            "NAME": "",
            "PORT": "Gi1/0/1",
            "SPEED": "auto",
            "STATUS": "notconnect",
            "TYPE": "10/100/1000BaseTX",
            "VLAN": "1"
        },
        {
            "DUPLEX": "auto",
            "NAME": "",
            "PORT": "Gi1/0/2",
            "SPEED": "auto",
            "STATUS": "notconnect",
            "TYPE": "10/100/1000BaseTX",
            "VLAN": "1"
        },

・その他参考

tekunabe.hatenablog.jp

■ 2. ansible_helpers フィルター

・タイプ

サードパーティのフィルタープラグイン github.com

・利用可能バージョン

不明。当方では Ansible 2.3 で簡単な動作確認済み。

・パースできる情報

  • Network to Code のリポジトリにある TextFSM 形式のテンプレートで定義されたコマンド github.com

  • 例

    • show interfaces
    • show interfaces status
    • show inventory
    • show ip bgp summary
    • show ip int brief
    • show ip ospf neighbor
    • show ip route

・パース結果例

インターフェース情報

        {
            "intf": "GigabitEthernet1",
            "ipaddr": "10.0.0.51",
            "proto": "up",
            "status": "up"
        },
        {
            "intf": "GigabitEthernet2",
            "ipaddr": "10.0.2.1",
            "proto": "up",
            "status": "up"
        },

・その他参考

tekunabe.hatenablog.jp

■ 3. ios_facts モジュール

・タイプ

標準のfact収集系モジュール

ios_facts - Collect facts from remote devices running Cisco IOS — Ansible Documentation

・利用可能バージョン

Ansible 2.2 から

・パースできる情報

  • ハードウェア情報系、インターフェース系

・パース結果例

インターフェース情報

"ansible_net_interfaces": {
    "GigabitEthernet1": {
        "bandwidth": 1000000, 
        "description": null, 
        "duplex": "Full", 
        "ipv4": {
            "address": "10.0.0.51", 
            "masklen": 24
        }, 
        "lineprotocol": "up ", 
        "macaddress": "2cc2.60xx.xxxx", 
        "mediatype": "RJ45", 
        "mtu": 1500, 
        "operstatus": "up", 
        "type": "CSR vNIC"
    },

・その他参考

tekunabe.hatenablog.jp

■ 4. napalm_get_facts モジュール

・タイプ

サードパーティのfact収集系モジュール（napalm-ansible内）

github.com

・利用可能バージョン

不明。当方では Ansible 2.3 で簡単な動作確認済み。

パースできる情報

  • arp_table
  • bgp_neighbors
  • config
  • environment
  • facts
  • interfaces
  • interfaces_counters
  • interfaces_ip
  • lldp_neighbors
  • lldp_neighbors_detail
  • mac_address_table
  • ntp_servers
  • ntp_stats
  • optics
  • snmp_information

・パース結果例

インターフェース情報

"interfaces": {
    "GigabitEthernet1": {
        "description": "N/A",
        "is_enabled": true,
        "is_up": true,
        "last_flapped": -1.0,
        "mac_address": "2C:C2:60:XX:XX:XX",
        "speed": 1000
    },

・その他参考

tekunabe.hatenablog.jp

ネットワーク機器のコマンド結果をパースする parse_cli_textfsm フィルタープラグインを試す (Ansible 2.4新機能)

ansible network automation

f:id:akira6592:20170923214714p:plain

Ansible 2.4 で Ansible でネットワーク機器のコマンド結果をパースするための parse_cli_textfsm というフィルタープラグインが搭載されました。

http://docs.ansible.com/ansible/latest/playbooks_filters.html#network-cli-filters

今回は簡単な例で試してみることのします。

■ 1. 仕組み

parse_cli_textfsm は、テンプレートに従ってコマンド結果をパースする TextFSM というライブラリを呼び出します。 そのため、別途テンプレートファイルを用意する必要があります。

ありがたいことに、networktocodeのリポジトリにisoの show ip ospf neighbor や、junos show interfaces 等に対応した計180近い（2017/09/23現在）テンプレートファイルがあります。 今回はこれらを利用させていただきます。

github.com

■ 2. 環境の準備

TextFSM のインストール

前述したように、 parse_cli_textfsm フィルタープラグインでは、内部で TextFSM を利用しているので、あらかじめインストールします。

sudo pip install textfsm

テンプレートファイルのダウンロード

Network to Code のリポジトリからテンプレートファイル一式をダウンロードします。 ひとまず、playbookを作成する予定のディレクトリで git clone します。

git clone https://github.com/networktocode/ntc-templates.git

もちろん、利用したいテンプレートファイルが決まっているなら個別にダウンロードしてもOKです。

■ 3. Playbook の準備

---
- hosts: ios
  gather_facts: no
  connection: local

  tasks:
    - name: show int status
      ios_command:
        commands:
          - show int status
        provider: "{{ cli }}"
      register: result

    - name: DEBUG
      debug:
        msg: "{{ result.stdout[0] | parse_cli_textfsm('./ntc-templates/templates/cisco_ios_show_interfaces_status.template') }}"

  vars:
    cli: 
      host: "{{ inventory_hostname }}" 
      username: "{{ ansible_user }}"
      password: "{{ ansible_password }}"
      authorize: true
      auth_pass: "{{ cisco_enable_secret }}"

■ 4. 実行

先ほど作成した playbook を実行します。

[vagrant@centos7 vagrant]$ ansible-playbook ios_parse.yml

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

TASK [show int status] ****************************************************************************************************************************************************************************
ok: [192.168.1.254]

TASK [DEBUG] **********************************************************************************************************************************************************************************
ok: [192.168.1.254] => {
    "msg": [
        {
            "DUPLEX": "auto",
            "NAME": "",
            "PORT": "Gi1/0/1",
            "SPEED": "auto",
            "STATUS": "notconnect",
            "TYPE": "10/100/1000BaseTX",
            "VLAN": "1"
        },
        {
            "DUPLEX": "auto",
            "NAME": "",
            "PORT": "Gi1/0/2",
            "SPEED": "auto",
            "STATUS": "notconnect",
            "TYPE": "10/100/1000BaseTX",
            "VLAN": "1"
        },
        ～（略）～
        {
            "DUPLEX": "a-full",
            "NAME": "management",
            "PORT": "Gi1/0/24",
            "SPEED": "a-1000",
            "STATUS": "connected",
            "TYPE": "10/100/1000BaseTX",
            "VLAN": "192"
        }
    ]
}

PLAY RECAP ************************************************************************************************************************************************************************************
192.168.1.254               : ok=2    changed=0    unreachable=0    failed=0

無事に show int status の結果がパースされました。

■ 5. まとめ

ネットワーク機器のshowコマンドの結果は、人が目視する分には問題ないのですが、特定の値をプログラムに判断させるといったことが難しいです。 このようにパースする仕組みを利用すると、 assert モジュールなど併用して「Gi1/0/10 の VLAN が 99 であれば正常とする」といった簡単なテストもしやすくなるのではないでしょうか。