てくなべ (tekunabe)

ansible / network automation / 学習メモ

2017年の社内外発表のまとめ(ほぼAnsible)

今年は社内社内外で発表することが増えた年でした。 アウトプットするとフィードバックを頂けるという点では、ブログ等でも同じなのですが、発表の場合はより早く頂ける印象があります。 フィードバックを頂いた皆様や、イベント運営の皆様に感謝いたします。 少し早いですが、LT含めて2017年の振り返りをしたいと思います。

[1] 2017/01/30 (社内)基盤フェス

カギをひねるとHTTPをしゃべる Hackey で遊ぶ

Hackeyの紹介と、これを使ってネットワーク機器の設定変更をするデモを行いました。

社内イベントのため資料公開はありませんが、デモ動画のみ公開しています。 www.youtube.com


[2] 2017/05/19(社内)AP TECH FEST 2017 #1

Ansibleモジュールのコードの読み方

ドキュメントでもわからない詳細な挙動を知ろうとすると時にコードを読むことがありますが、 .py ファイルの探し方や共通の構造の説明をしました。 (社内イベントのため資料公開はありません)

f:id:akira6592:20171217114203p:plain


[3] 2017/07/21 「8a1」APC勉強会#30

ネットワークの自動化、何つかう?~自動化ツール紹介~

既存のネットワーク機器でも自動化できるツールやライブラリが増えています。それらを整理するために紹介、比較をしました。 Ansible、salt、netmiko、NAPALM を扱いました。デモの実施が緊張しました。

www.slideshare.net


[4] 2017/08/18「8a1」APC勉強会#30(2回目)

ネットワークの自動化、何つかう?~自動化ツール紹介~ (2回目)

上記で[3]で、ありがたいことに定員オーバーしてしまったため同様の内容で追加開催しました。 資料も少しだけ修正をしています。

www.slideshare.net


[5] 2017/08/25 (社内)AP TECH FEST 2017 #2

LTネットワークでもテストを自動化したい

後述の[6]とほぼ同じです。 (社内イベントのため資料公開はありません)


[6] 2017/09/01 Ansible Meetup in Tokyo 2017.09

AnsibleとNAPALMでネットワークをテストする

Ansible と NAPALM の連携モジュールを使用して、ネットワークテストの自動化をするデモ動画をお見せしました。

www.slideshare.net


[7] 2017/10/10 NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13

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

大変ありがたいことに登壇オファーをいただきました。 私は Ansible、NAPALM担当として登壇、パネルディスカッションをさせていただきました。

www.slideshare.net


[8] 2017/11/ 17 (社内)AP TECH FEST 2017 #3

NW運用自動化デモでAnsibleがやってたこと

社内で取り組んだNW運用自動化の環境構築の際にAnsibleがやっていた仕組みや苦労した点を紹介しました。 (社内イベントのため資料公開はありません)


これから

来年もマイペースで発表していけたらなと思います。どうぞよろしくお願いいたします。

「この時代でもなぜ書籍なのか」に対する答えの一つに出会った時

f:id:akira6592:20171216150152p:plain

■ 書籍のいいところって?

技術書、大好きです。でもWeb上にもたくさん情報が存在しています。スピードも速いです。 では、技術書の価値はどういうところにあるのでしょうか。時々考えることがあります。

  • 内容の品質がよい
  • 一覧性が高い
  • 紙をめくるという行為が良い
  • 所有欲を満たしてくれる

などなど、色々あるかとは思います。

ところが、先日「BPStudy#123〜技術書籍執筆の実際、ノウハウ」という勉強会のある発表で、全く別の観点の話を聞いて、とても印象に残りました。

slideship.com 発表者は、PythonユーザのためのJupyter[実践]入門 の著者の一人である池内孝啓さん(@iktakahiro)です。

■ 書籍は歴史として国レベルで保全される

以下の2点で、書籍は歴史として国レベルで保全されると言えます。

1. 国レベルで記録される

日本には納本制度という制度があり、この制度により国レベルで記録されることになります。

納本制度|国立国会図書館―National Diet Library

納本制度」とは、図書等の出版物をその国の責任ある公的機関に納入することを発行者等に義務づける制度のことです。わが国では、国立国会図書館法(昭和23年法律第5号)により、国内で発行されたすべての出版物を、国立国会図書館に納入することが義務づけられています。

納本された出版物は、現在と未来の読者のために、国民共有の文化的資産として永く保存され、日本国民の知的活動の記録として後世に継承されます。

資料の該当ページ(P18)

2.「知識や技術は陳腐化しても当時の人間が考えていたことの記録は褪せない」

はっとしました。歴史ですね。

資料の該当ページ(P22)


Webサイト上のデータと比較して、書籍が残されるレベルは高いと言えると思います。 これからどういう技術、文化になるかは分かりませんが、少なくともしばらくは「歴史として国レベルで保全される」という点が「この時代でもなぜ書籍なのか」に対する答えの一つなのかなと思いました。

Ansible の jinja2 フィルタを色々試すときも ansible-console が便利

以前のエントリでもご紹介しましたが、 ansible-console というインタラクティブな Ansible 環境が便利です。 tekunabe.hatenablog.jp

最近、また便利だなと思ったのは使い方は、jinja2 フィルタを色々試すときです。

・デモ動画 f:id:akira6592:20171111225642g:plain 試してみて、やり方が定まってからPlaybookに書く、という流れもなかなか良い気がしています。特にどことも接続する必要はなく、インベントリファイルを用意するのも手間なので、

ansible-console -c local -i localhost,

というコマンドを打って起動しています。 -i localhost,, をお忘れずに。

・参考 qiita.com

Windows 7 と Vagrant 2.0.1 の環境で vagrant up が止まる現象の対処

■ はじめに

Windows 7 で VitualBox 5.1.x と Vagrant 1.9.6 の組み合わせを利用していましたが、 Vagrant 2.0.1 で VirtualBox 5.2 に対応したとのことなので、両方ともアップデートしました。

Vagrant CHANGELOG.md 2.0.1 (November 2, 2017)

providers/virtualbox: Virtualbox 5.2 support [GH-8955]

すると、正常に vagrant up 出来なくなってしまいました。詳細は次の通り。

(結論としては、 PowerShell を 2 から 5.x にアップグレードしたら解消)

■ 遭遇した現象とログ

新規に Vagrantfile を作成して vagrant up を実行したところ、何も出力されれず、進みませんでした。 そこで、デバッグログ出力もつけて vagrant up --debug を実行したとろろ、以下のログの箇所で止まっていました。

  DEBUG push: finalizing
 INFO subprocess: Starting process: ["C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\/powershell.EXE", "-NoLogo", "-NoProfile", "-NonInteractive", "-ExecutionPolicy", "Bypass", "-Command", "$PSVersionTable.PSVersion.Major"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stdout: 2

なお、VirtualBox 5.1.x/Vagrant 1.9.6 に 作成済み( .vagrant フォルダ生成済み)の環境は、VirtualBox 5.2/Vagrant 2.0.1 でも vagrant up できました。 今回の現象は新規の Vagrantfile という条件のようです。

■ 原因

どうも Vagrant 1.9.7 から PowerShell 5.x が必要のようです。 (Windows 7 デフォルトの PowerShell 2ではなく)

github.com

■ 対処

WMF5.1 をインストールして、PowerShell を 5.1 にアップデートします。少し時間がかかります。

WMF 5.1 のインストールと構成 | Microsoft Docs

ダウンロード対象: Win7AndW2K8R2-KB3191566-x64.ZIP

インストール方法は、上記ページに「Windows Server 2008 R2 および Windows 7 で WMF 5.1 をインストールする」に記載されている通り、

ZIP ファイルを展開した後、管理者として PowerShell を開いて

から

Install-Wmf5.1.ps1 スクリプトを実行

します。

インストール後、OS再起動を要求されますので再起動します。

■ 確認

DOSプロンプトで powershell $PSVersionTable を実行して、 PSVersion5.1 から始まっているいることを確認します。

実行例

C:\> powershell $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.14409.1012
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14409.1012
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

これで正常に vagrant up できるようになりました。

■ まとめ

調べたり試したりした限り、以下の組み合わせなら大丈夫のようです。

・VirtualBox 5.1.x、Vagrant 1.9.6、PowerShell 2.0 以上
・VirtualBox 5.1.x、Vagrant 1.9.7、PowerShell 5 以上
・VirtualBox 5.2.x、Vagrant 2.0.1 以上、PowerShell 5以上

第11回 Jenkins勉強会 の資料まとめ

参加できませんでしたが、2017/11/8 に第11回 Jenkins勉強会が実施されたそうです。

www.meetup.com

資料のまとめた見当たらなかったので、自分で探してこちらにまとめさせていただきます。 資料の共有ありがとうございます。

■ [講演1]初めての自動テスト meets Jenkins(@nkns165 さん)

www.slideshare.net 翻訳を担当することになった経緯や翻訳こぼれ話もあります。

■ [講演2]Jenkins world 2017の報告(@ikikkoさん)

www.slideshare.net

■ [講演3]Jenkins PipelineとBlue Oceanによる、フルスクラッチからの継続的デリバリ(@kohsukekawa ‏さん)

今回用の資料は見当たりませんでしたが、別の場で同タイトルの発表をされていたようなのでそちらの資料のリンクを掲載します。

www.slideshare.net

■ [LT1] 遠くの"計画"よりも今日の"CD"(継続的デプロイ) (@/kazuhito_m さん)

www.slideshare.net

■ [LT2] タミヤカムプログラムロボット作セットで作るXFD(@kiy0takaさん)

docs.google.com

■ [LT3]開発者(個人)のためのJenkins 運用編(@yasuhirokiさん)

speakerdeck.com


参考

前回

tekunabe.hatenablog.jp

Ansibleのインベントリファイルの拡張子に .ini を使わない方がいい理由

オライリーの「初めてのAnsible」の訳注で初めて知ったのですが、 ansible.cfghostfile パラメータや、ansible-playbook コマンドなどの -i オプションでディレクトリごと指定して、複数のインベントリファイルをマージして扱う場合、 拡張子が .ini の静的インベントリファイルは無視されてしまいます。

・公式ドキュメント内の記載 Using Inventory Directories and Multiple Inventory Sources

~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

実際に試してみます。 (Ansible 2.4.1で実験)

■ 拡張子なしの場合

インベントリファイル

[vagrant@centos7 vagrant]$ cat inventory/inv
172.16.0.3

1つだけエントリしています。inventory/ ディレクトリはこのファイルのみです。

ディレクトリ指定の ansible-playbook 実行

[vagrant@centos7 vagrant]$ ansible-playbook show_config_set.yml -i inventory/

PLAY [172.16.0.3] *******************************************************************************************************************

TASK [show config to file] **********************************************************************************************************
ok: [172.16.0.3]

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

無事実行されました。

■ 拡張子 .ini の場合

インベントリファイル

[vagrant@centos7 vagrant]$ cat inventory/inv.ini
172.16.0.3

内容は先ほどと同じです。inventory/ ディレクトリはこのファイルのみです。

ディレクトリ指定の ansible-playbook 実行

[vagrant@centos7 vagrant]$ ansible-playbook show_config_set.yml -i inventory/
 [WARNING]: Unable to parse /vagrant/inventory as an inventory source

 [WARNING]: No inventory was parsed, only implicit localhost is available

 [WARNING]: Could not match supplied host pattern, ignoring: all

 [WARNING]: provided hosts list is empty, only localhost is available

 [WARNING]: Could not match supplied host pattern, ignoring: 172.16.0.3


PLAY [172.16.0.3] *******************************************************************************************************************
skipping: no hosts matched

PLAY RECAP **************************************************************************************************************************

ホストが見つかりませんでした。

■ まとめ

-i inventory/hosts.ini のようにファイルを指定する分には特題はありませんが、ディレクトリ指定したときにうっかりこの挙動を忘れてしまいそうなので、習慣としては静的インベントリファイルに拡張子 .ini を使わない方がよいかもしれません。

Ansible の playbook をデバッグしたいときのあれこれ

■ debug モジュール

- debug:
    msg: "{{ var1 }}"

のようにすると var1 変数の内容が 表示されます。

公式ドキュメント

debug – Print statements during execution — Ansible Documentation


■ -v オプション

ansible-playbook コマンドの -v オプションでデバッグ的な情報が画面に表示されるようになります。 -v-vv-vvv といったように、 v の数が多いほど詳細な表示となります。


■ --step でステップ実行

playbook 中のタスクを一つ一つステップ実行していきたい場合はありませんでしょうか。 ansible-playbook コマンドに --step オプションを指定することでステップ実行ができます。

実行例

[vagrant@centos7 vagrant]$ ansible-playbook j_command.yml  --step

PLAY [172.16.0.3] *******************************************************************************************************************
Perform task: TASK: show version (N)o/(y)es/(c)ontinue: y  ← 入力待ちになるので y で続行

Perform task: TASK: show version (N)o/(y)es/(c)ontinue: *****************************************************************************

TASK [show version] *****************************************************************************************************************
ok: [172.16.0.3]
Perform task: TASK: debug result (N)o/(y)es/(c)ontinue: y  ← 入力待ちになるので y で続行

Perform task: TASK: debug result (N)o/(y)es/(c)ontinue: *****************************************************************************

TASK [debug result] *****************************************************************************************************************
ok: [172.16.0.3] => {
    "msg": {
        "changed": false,
        "failed": false,
        "stdout": [
            "Hostname: vsrx3\nModel: firefly-perimeter\nJUNOS Software Release [12.1X47-D15.4]"
        ],
        "stdout_lines": [
            [
                "Hostname: vsrx3",
                "Model: firefly-perimeter",
                "JUNOS Software Release [12.1X47-D15.4]"
            ]
        ]
    }
}

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

公式ドキュメント

Start and Step — Ansible Documentation


■ debug strategy

Ansible 2.1 から標準で利用可能になった strategy plugin です。 Playbook失敗時に、デバッガモードになり、変数の値の確認、再代入、タスクの再実行などが可能になります。 debug strategy を利用するには、playbookの最初のほうで、 strategy: debug と指定しておきます。

---
- hosts: junos
  strategy: debug   # here
  gather_facts: no
  connection: local

(2018/04/07 追記) また、Ansible 2.5 から debugger というキーワード利用することで、デバッガーを起動する条件も指定できるようになりました。 例えば、失敗時だけでなく、常にデバッガーを起動する場合は、以下のように debugger: always と指定します。

---
- hosts: junos
  debugger: always    # here
  gather_facts: no
  connection: local

(参考)  Ansible の Playbook Debugger を常に起動させる方法(Ansible 2.5 から) - てくなべ (tekunabe)

実行例

ここでは、Juniperのネットワーク機器へのパスワードが間違っていたため、ログインできずにデバッガーが起動し、 正しいパスワードを指定して、タスクの再実行をしています。

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

PLAY [172.16.0.3] ********************************************************************************************

TASK [show version] ******************************************************************************************
fatal: [172.16.0.3]: FAILED! => {"changed": false, "failed": true, "msg": "unable to open shell. Please see: https://docs.ansible.com/ansible/network_debug_troubleshooting.html#unable-to-open-shell"}
Debugger invoked    # ★デバッガ起動
(debug) p vars["provider"]["password"]  # ★ パスワードの確認
u'xxxxxxxxxx'
(debug) vars["provider"]["password"] = "password"  # ★ 正しいパスワードを指定
(debug) redo  # ★ タスクの再実行(成功)
ok: [172.16.0.3]

TASK [debug result] ******************************************************************************************
ok: [172.16.0.3] => {
    "msg": {
        "changed": false,
        "failed": false,
        "stdout": [
            "Hostname: vsrx3\nModel: firefly-perimeter\nJUNOS Software Release [12.1X47-D15.4]"
        ],
        "stdout_lines": [
            [
                "Hostname: vsrx3",
                "Model: firefly-perimeter",
                "JUNOS Software Release [12.1X47-D15.4]"
            ]
        ]
    }
}

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

公式ドキュメント

Playbook Debugger — Ansible Documentation


■ --syntax-check で YMAL文法チェック

playbookを実行せずに、純粋にYMALとしての文法チェックができます。

実行例(文法OK)

[vagrant@centos7 files]$ ansible-playbook j_command.yml --syntax-check

playbook: j_command.yml

実行例(文法NG)

[vagrant@centos7 files]$ ansible-playbook j_command.yml --syntax-check
ERROR! Syntax Error while loading YAML.


The error appears to have been in '/vagrant/j_command.yml': line 10, column 20, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

   - name: show version
      junos_command:
                   ^ here

exception type: <class 'yaml.scanner.ScannerError'>
exception: mapping values are not allowed here
  in "<unicode string>", line 10, column 20:
          junos_command:
                       ^

公式ドキュメント

Intro to Playbooks — Ansible Documentation