てくなべ

インフラ、ネットワーク、自動化などの技術的なことを書いていきます。

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 をデバッグしたいときのあれこれ

■ -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

実行例

ここでは、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

ネットワーク自動化(Salt)についての Free eBookがダウンロード可能

O'Reilly Velocity Conference 開催に合わせてだと思いますが、 「Network Automation at Scale」という Free eBook がダウンロード可能になっています。 ご興味がある方はダウンロードしてみてはいかがでしょうか。

www.cloudflare.com

中身は Salt の話がメインになっています。 目次を引用させていただきます。

1. Introduction
   Salt and SaltStack
   Installing Salt: The Easy Way
   Introducing NAPALM
   Brief Introduction to Jinja and YAML
   Extensible and Scalable Configuration Files: SLS

2. Preparing the Salt Environment
   Salt Nomenclature
   Master Configuration
   Proxy Configuration
   The Pillar Top File
   Starting the Processes

3. Understanding the Salt CLI Syntax
   Functions and Arguments
   Targeting Devices
   Options

4. Conguration Management: Introduction
   Loading Static Configuration
   Loading Dynamic Changes

5. Salt States: Advanced Conguration Management
   The State Top File
   NetConfig
   NetYANG
   Capirca and the NetACL Salt State Module

6. The Salt Event Bus
   Event Tags and Data
   Consume Salt Events
   Event Types

7. Beacons
   Configuration
   Troubleshooting

8. Engines
   Engines Are Easy to Configure
   napalm-logs and the napalm-syslog Engine

9. Salt Reactor
   Getting Started
   Best Practices
   Debugging

Acknowledgments

ansible-console はモジュール名やオプションのTAB補完ができて便利

はじめに

Ansible 2.1 から ansible-console という、REPL のような対話型コンソール機能があります。 モジュール名やオプションのTAB補完ができて便利なので、動画付きでご紹介します。

デモ動画

以下のデモ動画でお分かりになるかと思います。 f:id:akira6592:20171014211805g:plain

補足

  • 確認したバージョンは Ansible 2.4.0 です。
  • 上記で指定しているオプションは ansible-playbook コマンドと共通です。
  • インベントリの指定オプションでは "-i 172.16.0.3," のようにカンマを含めていますが、この場合はインベントリファイルではなく、直接ホスト名を指定することになります。

参考

qiita.com ansible-console — Ansible Documentation