てくなべ (tekunabe)

ansible / network automation / 学習メモ

Arista EOS の検証用コンテナ版「cEOS-lab」の環境構築手順（1台編）

network


これは Network engineering Advent Calendar 2018 の17日目の記事です。


■ はじめに

Arista EOS には、コンテナ版の「cEOS」という製品があります。この cEOS の検証用として無償の「cEOS-lab」というものがあります。

2018年11月に開催された Red Hat Forum Tokyo 2018 内の「Arista Networksが実現するAnsibleによるネットワーク自動化とcEOS-labを使ったネットワークシミュレーション」というセッションでも紹介がありました。

この記事ではシンプルに、1台だけの cEOS-lab の環境を構築してみたときの手順をご紹介します。

  • 環境
    • CentOS Linux release 7.5.1804
    • Docker version 1.13.1
    • cEOS-lab 4.21.2F

なお、GNS3上で動かす方法はで以下のエントリで紹介されています。 qiita.com


■ 構築手順

イメージのダウンロード

arista.com のダウンロードページ(要ログイン)から cEOS-lab のイメージをダウンロードします。 今回は 4.21.2F を選択しました。

f:id:akira6592:20181217150703p:plain
4.21.2F の cEOS-lab を選択

cEOS-lab（検証用・無償） と cEOS（製品版） は別物ですのでご注意下さい。

import と create

ダウンロードした cEOS-lab のイメージを import します。

$ sudo docker import cEOS-lab.tar.xz ceos:latest

続いて、create します。

$ sudo docker create --name=ceos --privileged -p 443:443 -e CEOS=1 -e container=docker -e EOS_PLATFORM=ceoslab -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e ETBA=1 -e INTFTYPE=eth -i -t ceos:latest /sbin/init

もし、cEOS-lab 4.20.5F のイメージを利用する場合は、EOS_PLATFORM という変数の値は、ceossim を指定します。（ceoslabではなく）

ネットワークの作成と接続

今回は、 docker0 以外に、もう一つ足を生やす先として net1 というネットワークを作成して、接続します。

$ sudo docker network create net1
$ sudo docker network connect net1 ceos

start

コンテナを start します。

sudo docker start ceos

少々時間をおきます。

CLI へのアクセス

CLI へアクセスします。

$ sudo docker exec -it ceos Cli
localhost>

コンテナが起動しおわっていない状態で上記コマンドを実行すると、CLIにアクセスできなかったり、プロンプトが localhost> にならなかったりします。

動作確認

簡単な動作確認として、show version と show running-config コマンドを実行してみます。

localhost#show version
Arista cEOSLab
Hardware version:
Serial number:       N/A
System MAC address:  Not available

Software image version: 4.21.2F-10430819.4212F (engineering build)
Architecture:           i386
Internal build version: 4.21.2F-10430819.4212F
Internal build ID:      7b26fbef-3d08-4910-bb95-df08faaa5b13

cEOS tools version: 1.1

Uptime:                 0 weeks, 0 days, 0 hours and 21 minutes
Total memory:           1882836 kB
Free memory:            511160 kB

localhost#show running-config
! Command: show running-config
! device: localhost (cEOSLab, EOS-4.21.2F-10430819.4212F (engineering build))
!
transceiver qsfp default-mode 4x10G
!
spanning-tree mode mstp
!
no aaa root
!
interface Ethernet1
!
no ip routing
!
end
localhost#

コンフィグには、コンテナネットワーク net1 に接続している interface Ethernet1 があることを確認できます。


■ まとめ

Arista EOS 検証用コンテナ版「cEOS-lab」で1台の環境を構築する手順をご紹介しました。

同じく、検証用途の仮想EOSとして vEOS-labもあります。検証環境の特性に応じて使い分けるのが良いと思います。

なお、2台以上の環境を docker-compose や docker-topo(複雑なコンテナネットワークをyamlで定義できるツール) を利用して構築する手順は、Arista 公式Blog (要ログイン)「Network CI/CD Part 1 – Building network topologies with Docker and cEOS-lab」に紹介されています。記事中の docker create コマンドですが、 docker create --name=ceos --privileged となるべきところが、docker create –name=ceos –privileged となっています（おそらく何らかの自動変換の結果）。そのままコピペで実行するとエラーになるのでご注意ください。

[Ansible] group_vars 配下にグループ名の「ディレクトリ」を用意すると複数の変数ファイルをまとめられる

■ はじめに

例えば、グループ名が junos の場合、 gourp_vars/junos.yml のような ファイルを用意して、グループ共通で利用する変数を定義すできます。このとき、ファイル名はグループ名(ここでは junos)を含む形式に固定されます。

応用的なやり方として、gourp_vars/junos ディレクトリ を用意すると、そのディレクトリ配下に、複数の任意の名前の変数ファイルを置くことができます。

  • グループ名ディレクトリを利用した変数ファイルの配置例
.
|-- group_vars
|   `-- junos             # グループ名のディレクトリ
|       |-- commands.yml  # junos が利用する変数ファイル
|       |-- general.yml   # junos が利用する変数ファイル
|       `-- login.yml     # junos が利用する変数ファイル

group_vars/グループ名 ディレクトリだけでなく, host_vars/ホスト名 ディレクトリでも同じです。

公式ドキュメント上の記載

As an advanced use case, you can create directories named after your groups or hosts, and Ansible will read all the files in these directories in lexicographical order.

https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#splitting-out-host-and-group-specific-data

なお、複数ファイルで変数定義が競合した場合はファイル名順で後にロードされたものが採用されます。(Ansible 徹底入門 P152から)


■ サンプル

具体的なサンプルで動作例をご紹介します。 ここでは group_vars/junos ディレクトリ を作成し、その中にログイン情報、汎用的な情報、コマンド情報を定義した3つの変数フィアルを用意しています。

  • ファイル構成
.
|-- group_vars
|   `-- junos
|       |-- commands.yml
|       |-- general.yml
|       `-- login.yml
|-- inventory
`-- varstest.yml

インベントリファイル

  • inventory
[junos]
vsrx1 ansible_host=172.16.0.1

変数ファイル

  • group_vars/junos/login.yml (ログイン情報を定義)
---
ansible_network_os: junos
ansible_connection: netconf
ansible_user: admin
ansible_password: admin9999
  • group_vars/junos/commands.yml (実行したいコマンドを定義)
---
show_commands:
  - show version
  - show configuration
  - show interfaces
  • group_vars/junos/general.yml（汎用的な変数を定義）
---
greeting_msg: Hello, Junos!

Playbook

  • varstest.yml
- hosts: junos
  gather_facts: no

  tasks:
    - name: command test
      junos_command:
        commands: "{{ item }}"
      loop: "{{ show_commands }}"  # group_vars/junos/commands.yml 内の変数

    - name: debug test
      debug:
        msg: "{{ greeting_msg }}"   # group_vars/junos/general.yml 内の変数

実行結果

$ ansible-playbook -i inventory varstest.yml

PLAY [junos] ***************************************************************

TASK [command test] ********************************************************
ok: [vsrx1] => (item=show version)
ok: [vsrx1] => (item=show configuration)
ok: [vsrx1] => (item=show interfaces)

TASK [debug test] **********************************************************
ok: [vsrx1] => {
    "msg": "Hello, Junos!"
}

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

これにより、以下の 3つのことが確認できました。

  • group_vars/junos/login.yml で定義したログイン情報によってログインした
  • group_vars/junos/commands.yml で定義したコマンドを実行した
  • group_vars/junos/general.yml で定義したあいさつ文が表示された

[Ansible] 2018年のAnsible ネットワークモジュールのアップデートまとめ（詳細版）

ansible automation network


これは Ansible Advent Calendar 2018 の15日目の記事です。

■ はじめに

2018年、Ansible は 2.5、2.6、2.7 とバージョンアップを重ねてきました。ネットワーク関連では、新規対応プラットフォームやモジュールの追加の他にも、ネットワークモジュール用コネクプラグインの追加といった、アーキテクチャ的なアップデートもありました。

この記事では、ネットワークモジュール周辺のアップデートについて、バージョンごとに振り返ります。

2018/12/06 開催の Ansible Night in Tokyo 2018.12 での発表「5分でふりかえる2018年のネットワークモジュールのアップデート」の詳細版です。

目次



■ Ansible 2.5.0 (2018/03/22 リリース)

新規対応プラットフォーム: 7 (計40)

Ansible 2.5.0 では以下の 7 つのプラットフォームに新たに対応しました。FortiManager、NSO といった運用管理系プラットフォームにも対応したことが特徴です。

追加モジュール: 116 (計595)

追加モジュール一覧

クリックすると Ansible 2.5 追加モジュール一覧が表示されます


プラットフォーム別の追加モジュール数は以下のとおりです。

プラットフォーム名 2.7 での追加モジュール数 備考
aci 20
avi 8
edgeos 3
enos 3
eos 6
f5 30
fortimanager 1
ios 5
iosxr 1
ironware 3
junos 2
netact 1
nso 5
nxos 4
onyx 17
panos 4
radware 2
vyos 1

なお、Ansible 2.5 時点の全ネットワークモジュールの一覧はこちらです。

コネクションプラグインの導入（network_cli、netconf）

これまでネットワークモジュールは local コネクションプラグインを利用する仕組みでした。2.5.0 では、以下の 2 つのネットワークモジュール用のコネクションプラグインが初めて導入されました。

これらのネットワークモジュール用のネクションプラグインを利用することで、以下のような利点があります。

  • 各タスクの provider オプションに都度認証情報を指定しなくてよい
  • 特権モードの指定を、サーバー系モジュールと同じく become で指定できる（authorize ではなく）

以下に ios_* モジュールを利用した Playbook のサンプルを、比較のため Ansible 2.4 までの場合と 2.5 からの場合に分けて紹介します。

Ansible 2.4 までの場合

Ansible 2.4 までの場合、このように privider オプションで認証情報を定義します。 内部で定義するオプション名は authorize など、ネットワークモジュール固有のものになっています。

---
- hosts: ios1
  gather_facts: no
  connection: local   # local コネクションプラグインを利用

  vars:     # 別途変数定義ファイルに書き出しても良い
    login:  # 認証情報をまとめたディクショナリ（NWモジュール固有）
      username: user          # ユーザー名
      password: testpass99    # パスワード
      authorize: yes          # 特権モードへの移行有無
      auth_pass: testenable99 # 特権パスワード

  tasks:
    - name: get information
      ios_command:
        commands:
          - show running-config
        provider: "{{ login }}"     # 認証情報の指定 
    
    - name: set ntp
      ios_config:
        lines:
          - ntp server 10.0.0.123
        provider: "{{ login }}"     # 認証情報の指定（再）

Ansible 2.5 から

Ansible 2.5 からは privider オプションの代わりに、サーバー系モジュールと同じような変数（ ansible_become など）を利用できます。

---
- hosts: ios1
  gather_facts: no
  connection: network_cli   # network_cli コネクションプラグインを利用

  vars:  # 別途変数定義ファイルに書き出しても良い
    ansible_network_os: ios         # プラットフォーム名
    ansible_user: user              # ユーザー名
    ansible_password: user01        # パスワード
    ansible_become: yes             # 特権パスワード
    ansible_become_pass: enable01   # 特権モードへの移行有無
    ansible_become_method: enable   # 特権モードへの移行コマンド

  tasks:
    - name: get information
      ios_command:   # 認証情報の指定は不要
        commands:
          - show running-config
    
    - name: set ntp
      ios_config:    # 認証情報の指定は不要
        lines:
          - ntp server 10.0.0.123

なお、プラットフォームと対応するコネクションプラグインは、以下の表にまとまっています。 https://docs.ansible.com/ansible/latest/network/user_guide/platform_index.html#settings-by-platform

上記の表を確認すると分かるように、現在でも local コネクションプラグインを利用するプラットフォームもあります。

ネットワーク自動化向けドキュメントの拡充

各モジュールの説明ページだけでは分からなかった、トラブルシューティングやベストプラクティス、プラットフォームごとに利用できるオプションの説明 )などのページが、追加、集約されました。公式ドキュメントとしてまとまったという印象を受けます。

https://docs.ansible.com/ansible/latest/network/index.html

Ansible 2.5 参考情報



■ Ansible 2.6.0 (2018/06/28 リリース)

新規対応プラットフォーム: 3 (計43)

Ansible 2.6.0 では以下の 3 つのプラットフォームに新たに対応しました。 Extreme のプラットフォームが徐々に増えてきています。

追加モジュール: 56 (計651)

追加モジュール一覧

クリックすると Ansible 2.6追加モジュール一覧が表示されます


プラットフォーム別の追加モジュール数は以下のとおりです。

プラットフォーム名 2.6 での追加モジュール数 備考
aci 1
avi 3
cnos 2
exos 1
f5 32
files 2 ベンダー非依存（後述の net_get、net_put）
fortios 1
meraki 4
netconf 2 | ベンダー非依存（後述の netconf_rpc、netconf_get）
slxos 8

なお、Ansible 2.6 時点の全ネットワークモジュールの一覧はこちらです。

ベンター非依存モジュール（net_get/net_put/netconf_get/net_rpc）

ベンダー非依存モジュールとして以下の 4 つが追加されています。

net_get、get_put は SCP や SFTP でコンフィグを転送するモジュールです。 netconf_get、netconf_rpc は NETCONF 対応機器から NETCONF で情報を取得したり処理を実行するモジュールです。

httpapi コネクションプラグインの追加

ネットワークモジュール用のコネクプラグインに httpapi が追加されました。

HTTP による API に対応しているネットワーク機器と通信するためのコネクションプラグインです。具体的には、Cisco NX-OSと、Arista EOS に利用できます。

HTTPS によるアクセスも可能

デフォルトでは、HTTPS ではなく HTTP です。HTTPS でアクセスしたい場合は、use_ssl オプション（変数 ansible_httpapi_use_ssl ）を yes にセットします。

この場合、証明書の検証を必ず行うため注意が必要です。もし、検証を無効にしたい場合は、後述の Ansible 2.7 で追加されるオプション validate_certs (変数 ansible_httpapi_validate_certs )を no にセットします。

ネットワークモジュール用コネクションプラグインならではのメリットが

これまでも、local コネクションプラグインと各 nxos_* モジュールの transport: nxapi や、eos_* モジュールの transport: eapi を指定することで、ネットワーク機器に HTTP API によってアクセスできました。

ただし、local コネクションプラグインを利用する場合、以下のように都度 provider というオプション経由で認証情報を渡す必要がある、など少々面倒でした。

- name: task1
  eos_command:
    commands:
      - show version
    provider: "{{ eapi }}"     # 認証情報の指定

そこで、今回追加された httpapi コネクションプラグインを利用することで、認証情報は ansibe_user や ansible_password などの変数で定義するれば良くなり、provider オプションは不要になります。

このようなメリットは、Ansible 2.5 で導入された network_cli や netconf コネクションプラグインを利用するメリットと同様です。

なお、Arista EOS での connettion: local と connection: httpapi でも書き方は、公式ドキュメントの EOS Platform Options で確認できます。

Ansible 2.6 参考情報



■ Ansible 2.7.0 (2018/10/04 リリース)

新規対応プラットフォーム: 5 (計48)

Ansible 2.7.0 では以下の 5 つのプラットフォームに新たに対応しました。引き続き Extreme のプラットフォームが追加されています。また、私の周辺では「ついに RouterOS に対応」と反応されている方もいらっしゃって、Router Board User's Group Jp のブログでも取り上げられていました。

追加モジュール: 46 (計697)

追加モジュール一覧

クリックすると Ansible 2.7 追加モジュール一覧が表示されます


プラットフォーム別の追加モジュール数は以下のとおりです。

プラットフォーム名 2.7 での追加モジュール数 備考
aci 1
cli 2 ベンダー非依存（後述の cli_command、 `cli）
exos 2
f5 19
fortimanager 1
ftd 3
meraki 7
nos 3
nxos 1
onyx 1
opx 1
panos 1
routeros 1
slxos 1
voss 2

なお、Ansible 2.7 時点の全ネットワークモジュールの一覧はこちらです。

ベンター非依存モジュール（cli_command/cli_config）

ベンダー非依存モジュールとして以下の 4 つが追加されています。 - cli_command - Run a cli command on cli-based network devices - cli_config - Push text based configuration to network devices over network_cli

両者とも、コマンドをそのまま指定するタイプのモジュールです。ただし ios_command モジュールの commands オプションた、ios_config の lines オプションのように、コマンドをリストで指定できません。代わりに改行を含んだ複数コマンドの文字列を指定します。使い勝手が、ベンダー固有の *_command、*_config とは異なるので少し注意が必要です。

httpapi コネクションプラグインで証明書の検証有無を指定可能に

Ansible 2.6 で追加された httpapi コネクションプラグインで、SSL/TLS証明書の検証有無を validate_certs というオプション（変数 ansible_httpapi_use_ssl ）で指定できるようになりました。デフォルトは true です。

例えば、Arista EOS の API に HTTPS でアクセスし、証明書の検証はしない場合は、以下のような変数定義をします。

  • group_vars/eos.yml
ansible_network_os: eos             # プラットフォームの指定
ansible_connection: httpapi         # httpapi コネクションプラグインを利用
ansible_httpapi_use_ssl: yes        # API に HTTPS でアクセスする
ansible_httpapi_validate_certs: no  # 証明書検証をしない
ansible_user: testuser              # ログインユーザー名
ansible_password: testpass9999      # ログインパスワード
ansible_become: yes                 # 特権モード移行を有効化
ansible_become_method: enable       # 特権モード移行コマンド
ansible_become_pass: enable9999     # 特権モード移行パスワード

Ansible 2.7 参考情報



■ まとめ（2.5 - 2.7）

大まかにまとめると以下の3点です。

  • ネットワークモジュール用のコネクションプラグインの導入
    • network_cli、netconf、httpapi
  • 15 プラットフォーム追加
    • Extreme Networks 系が特に増加
  • 218 モジュール追加
    • net_get、net_put、cli_* 等ベンダー非依存モジュールも

特に、ネットワークモジュール用のコネクションプラグインの導入については、大きな変化だったと思います。ネット上のサンプルも connection: local と connection: network_cli が混在した状態がしばらく続く気がします。（bigip_* のように、もともと local のみサポートするプラットフォームもあります）

次期バージョンである Ansible 2.8 (ロードマップ) では、さらに NAPALM コネクションプラグインも追加される予定です。引き続き注目していきたいと思います。

Ansible 2.5 - 2.6 参考情報

[Ansible] ansible-playbook コマンドの -e (--extra-vars) オプションは変数ファイル名も指定できる

ansible

-e (--extra-vars) オプションとは

ansible-playbook コマンドには、-e（または --extra-bars） という、extra vars（一番優先される変数の種類）を指定するオプションがあります。複数指定する場合は、複数の -e オプションを使用します。

ansible-playbook -i localhost, -e key1=val1 -e key2=val2 -e key3=val3


-e @ファイル名 で変数ファイルも指定できる

-e オプションの指定が多かったり、リストやディクショナリの値を指定すると、コマンドが見にくくなってしまいます。そこで、-e @ファイル名 のように指定すると、変数たちを書き出したファイルを扱うことができ、コマンドをすっきりさせることができます。 （ドキュメントやコマンドヘルプにも記載があります）

ファイルは yaml か json を指定できます。 https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html?highlight=JSON#passing-variables-on-the-command-line


サンプル

  • playbook
- hosts: localhost
  gather_facts: no

  tasks:
    - name: vars test
      debug:
        var: "{{ item }}"
      loop:
        - key1
        - key2
        - key3
  • myvars.yml (変数たちを書き出したファイル)
---
key1: val1
key2: val2
key3:
  - val3_1
  - val3_2
  - val3_3
  • 実行結果
$ ansible-playbook -i localhost, varstest.yml -e @myvars.yml

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

TASK [vars test] ***********************************************************
ok: [localhost] => (item=key1) => {
    "item": "key1",
    "key1": "val1"
}
ok: [localhost] => (item=key2) => {
    "item": "key2",
    "key2": "val2"
}
ok: [localhost] => (item=key3) => {
    "item": "key3",
    "key3": [
        "val3_1",
        "val3_2",
        "val3_3"
    ]
}

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

他にも変数ファイルを取り込める機能は、host_vars ディレクトリ、group_vars ディレクトリ、vars_files ディレクティブなどがありますが、この方法も選択肢として頭の隅に置いておくと良いかもしれません。

参考

qiita.com

[Ansible] Playbook Debugger でタスク変数の値を変更してもタスクに反映されない現象について

ansible issue

■ はじめに

Ansible には Playbook Debugger という、Playbook 実行時に変数の値を確認、変更などできる機能があります。

参考

タスク変数も変更できますが、変更後、タスクを再実行しても変更前の値のまま再実行してしまう現象があります。 2.5 系 から 2.7 系までが対象です。2.4 系では発生しない現象でした。次期バージョンの Ansible 2.8 で、追加される Debugger のコマンド update_task によって改修される予定です。

この記事ではこの現象についてご紹介します。


■ 公式ドキュメントに記載の手順は正しくタスク変数の値が変更できない

本記事執筆時点で、最新安定版(2.7対応)のドキュメントの Playbook Debugger の説明ページには、以下のようなタスス変数の変更手順が記載されています。

  • Playbook
- hosts: test
  strategy: debug
  gather_facts: yes
  vars:
    pkg_name: not_exist
  tasks:
    - name: install package
      apt: name={{ pkg_name }}
  • デバッガ操作手順
[192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name']
u'not_exist'
[192.0.2.10] TASK: install package (debug)> task_vars['pkg_name'] = 'bash'
[192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name']
'bash'
[192.0.2.10] TASK: install package (debug)> redo

手順はここで終わっていて、redo の結果が記載されていません。これを実際試すと redo 後にエラーにってしまいます。 （環境の都合上、apt ではなく yum モジュールを利用しますが、現象に影響はありません）

$ ansible-playbook -i localhost, debuger_ad.yml

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

TASK [Gathering Facts] *******************************************
ok: [localhost]

TASK [install package] *******************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "No package matching 'not_exist' found available, installed or updated", "rc": 126, "results": ["No package matching 'not_exist' found available, installed or updated"]}
[localhost] TASK: install package (debug)> redo
fatal: [localhost]: FAILED! => {"changed": false, "msg": "No package matching 'not_exist' found available, installed or updated", "rc": 126, "results": ["No package matching 'not_exist' found available, installed or updated"]}
[localhost] TASK: install package (debug)> task_vars['pkg_name'] = 'bash'
[localhost] TASK: install package (debug)> p task_vars['pkg_name']
'bash'
[localhost] TASK: install package (debug)> redo
fatal: [localhost]: FAILED! => {"changed": false, "msg": "No package matching 'not_exist' found available, installed or updated", "rc": 126, "results": ["No package matching 'not_exist' found available, installed or updated"]}
[localhost] TASK: install package (debug)>

redo 後も、not_exist というパッケージ名を探していて、見つからないためエラーになっています。つまり、task_vars['pkg_name'] = 'bash' のようにタスク変数を書き換えても、実際のタスク実行上に利用する値は変更前（この場合 not_exits）ということになります。


■ 2.7 までのワークアラウンド

変更した（見かけ上の）タスク変数の値をタスクのオプション（task.args['name']）に代入すれば、変更後の値で redoできます。

(...略...)
[localhost] TASK: install package (debug)> task_vars['pkg_name'] = 'bash'
[localhost] TASK: install package (debug)> p task_vars['pkg_name']
'bash'
[localhost] TASK: install package (debug)> task.args['name'] = '{{ pkg_name }}'
[localhost] TASK: install package (debug)> redo
ok: [localhost]

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

もちろん、タスク変数を経由せずに、最初から task.args['name'] = 'bash' のようにタスクのオプションの値を直接変更しても、正常に redo できます。

(...略...)
[localhost] TASK: install package (debug)> task.args['name'] = 'bash'
[localhost] TASK: install package (debug)> redo
ok: [localhost]

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


■ 2.8 からの新しい手順で正しく変更

次期バージョンの Ansible 2.8 の Playbook Debugger では update_task というコマンドが利用できます。 このコマンドにより、Debuger 上で変更したタスク変数の値を、正しく redo 時にタスクが利用できます。

次期バージョン（2.8/devel）のドキュメントにも以下の手順が記載されています。

[192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name']
u'not_exist'
[192.0.2.10] TASK: install package (debug)> task_vars['pkg_name'] = 'bash'
[192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name']
'bash'
[192.0.2.10] TASK: install package (debug)> update_task
[192.0.2.10] TASK: install package (debug)> redo


■ [補足] Ansible 2.4 では本現象は発生しない

Ansible 2.4 にも Playbook Debugger 機能はあります(debugger ディレクティブではなく、strategy: debug としての機能)。2.4 では本件の現象は発生せず、通常の手順で変更後のタスク変数の値でタスクを再実行できます。

$ ansible --version
ansible 2.4.0.0
(...略...)

$ ansible-playbook -i localhost, debuger_ad.yml

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

TASK [Gathering Facts] ******************************************************
ok: [localhost]

TASK [install package] ******************************************************
fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "No package matching 'not_exist' found available, installed or updated", "rc": 126, "results": ["No package matching 'not_exist' found available, installed or updated"]}
Debugger invoked
(debug) p vars['pkg_name']
u'not_exist'
(debug) vars['pkg_name'] = 'bash'
(debug) p vars['pkg_name']
'bash'
(debug) redo
ok: [localhost]

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

※ Ansible 2.4 までは、タスク変数は vars 内に格納されていましたが、Python のオブジェクト名と重複するため、2.5 で task_vars に変更されました。


■ まとめ

  • Ansible 2.5 系 から 2.7 系までの Playbook Debugger で、タスク変数の値を変更後に redo しても、変更前の値のまま再実行してしまう
  • ワークアラウンドはタスクのオプション task.args への代入
  • Ansible 2.8 で改修予定（update_task コマンドの追加）

参考

  • 対応issue

github.com

  • 対応PR

github.com

[Ansible] ios_config モジュールはデフォルトでは copy run start しない

ansible

■ デフォルトでは copy run start によるコンフィグ保存をしない

Ansible には、Cisco IOS ネットワーク機器に対して設定変更などができる ios_config モジュールがあります。 lines オプションなどを利用して実行したいコマンドを指定します。

  • 使用例
- name: test
  ios_config:
    lines:
      - ntp server 10.0.0.123

デフォルトでは、コマンド実行後は copy runnning-config start-config コマンドによるコンフィグ保存をしません。（ ios_config モジュールのドキュメント を確認すると分かるのですが、時々忘れそうになるので書いておきます。）

もしコンフィグ保存をする場合は、save_when オプションを利用します。


■ save_when オプション で選択できる値

save_when オプションでは、コンフィグを保存する条件を以下の4つから選択できます。

選択値 説明 利用可能バージョン
always 実際に設定変更があってもなくても、常にコンフィグ保存します。タスクとしては changed になります。 2.4
never コンフィグ保存をしません（デフォルト） 2.4
modified 当該タスクで実際に設定変更されたかどうかに関わらず、startup-configと running-config に差分がある場合、コンフィグ保存する。 2.4
changed 当該タスクで、実際に設定変更があった場合、コンフィグ保存します。 2.5
  • save_when オプションの使用例
- name: test
  ios_config:
    lines:
      - ntp server 10.0.0.123
    save_when: changed  # このタスクで実際に設定変更があった場合コンフィグ保存

必要に応じて save_when オプションを指定しましょう。


補足

ios_system など、他の設定変更系モジュールも、コンフィグ保存しません。これらのモジュールには save_when オプションが無いので、もしコンフィグ保存をする場合は、別タスクで ios_config の save_when を指定することになると思います。

Ansibleもくもく会を誘致して自社会場で開催した話

ansible

■ はじめに

2018/12/10 に弊社を会場として「Ansibleもくもく会 2018.12 ネットワーク編 in エーピーコミュニケーションズ」を開催しました。

ansible-users.connpass.com

Ansibleもくもく会は、Ansible ユーザー会というコミュニティ主催とするハンズオンのイベントです。これまで、東京近郊での開催はレッドハットさんのセミナールームでのみの開催でした。会場や設備面では非常に助かっていたのですが、コミュニティ感が出にくいなと感じていました。そこで、精力的に引っ張ってきている中村さんに、弊社の会場でもくもく会をできないかと相談したところ快諾いただきました。

この記事では、準備したことや感じたことなどを会場提供のスタッフ目線でまとめます。


■ 準備

開催日程の決定

場所の都合もありますので、何より先に日程を決めました。

結果としては、

と、 Ansible ユーザー会のイベントが3週連続開催というかたちになりました。（すべて参加させていただきました！）

タスクの分担

ざっくり、レッドハットさん側と弊社側で準備や当日やることを分担しました。もくもく会は何回か参加した事があるので、どんな準備がタスクがあるだろうと想像しながら洗い出しました。

  • 会場提供
  • 会場案内
  • Wi-Fi案内
  • 受付
  • 司会
  • 司会進行用スライド作成
  • AWSリソース手配
  • 環境情報
  • リモート参加者向けカメラ
  • Q&A 用 Google Doc 準備
  • アンケートフォーム作成
  • ドリンク・おかし
  • ノベルティ
  • サポーター・メンター

会場に関わるものとドリンクやお菓子については弊社、という大まかな方針にしました。共同で担当するものもあります。

（余談）会場案内はフロア違いの喫煙所の案内も含みますが、行ったことがなかったので初めて行って確認しました。

人数の設定

レッドハットさんのセミナールームと違って、あまり人数を多く設定できませんでした。

枠 人数
一般参加枠 12人
ブログ枠 2人
成果共有LT枠 2人
次回メンター枠 2人
メンター枠 2人

正直、結構悩んで心苦しい感じがしましたが、別途リモート参加枠を用意していただけたのが救いでした。

お菓子・ソフトドリンクの選定

会場提供＋αのことをしたいなと思ったので、ちょっとしたお菓子やソフトドリンクをご用意しました。PC を触るイベントですので、手が汚れないものにしました。

設備

いつももくもく会に参加している感じから、ゲスト用の Wi-Fi とプロジェクターと机と椅子があれば大丈夫だと思ってました。設備に関しては考えることは多くなかったです。

Connpass のイベントページで定番となっている（？）以下の文言は流用しました。

また、Macの電源アダプタは形状の問題で会場床下のコンセントに挿すと抜けませんので、MacBookユーザの方はご注意ください。

実際は挿せないくらいですが。

受付の準備

弊社では、8a1 という社外向け勉強会を年に数回開催しています。そこで受付を担当してもらっている部署に今回も受付を依頼しました。

はじめて Connpass の受付票発行機能を利用しました。ユーザ名や受付番号を含む参加者一覧を CSVファイルとしてダウンロードして、少し見やすく調整したものを受付担当者に渡しました。受付担当者からは、受付票は便利とだと言っていました。

スポンサー欄（広告）

Ansible もくもく会では、もくもく作業中に質問があった場合に、オンライン上のドキュメントに書いて、誰かが回答を書くというスタイルをとっています。最近では Google Doc を利用しています。

その Google Doc 上にスポンサー欄というかたちで、採用情報と、自社プロダクトの情報を掲載させていただきました。

f:id:akira6592:20181211202214p:plain
少々ロゴが多すぎでしょうか・・

会場案内の流れで、告知タイムを設けていただこうかとも思いました。しかし、なるべくもくもくタイムに時間をとりたいのと、もくもく会ならではのやりかたで、という意味で Google Doc に記入というかたちを取らせていただきました。

図々しいお願いとなりましたが、今後のイベントの継続性のためにも、会場提供側にもメリットがあるかたちで実績を作っておいたほうが良いと思いました。


■ 当日の様子

ガラガラでもなく、ぎゅうぎゅうでもないくらいの参加人数になりました。 お越しいただきありがとうございました。

f:id:akira6592:20181211194216j:plain:w400
イントロダクション時の様子

成果共有

成果共有LTでは 2人から発表していただきました。そのうち @matt_zeus さんの資料がアップされていました。

www.slideshare.net

ブログ

ブログ枠で参加された @ken5owata さんが、当日早々に Qiita へ記事をアップされていました。ありがとうございます。

qiita.com


■ 感想・まとめ

とにかく、東京近郊の Ansible ユーザ会のイベントをレッドハットさん以外の会場で開催した実績を作れました。これにより、もっともっといろいろな場所で開催する流れになったら良いなと思いました。

今回のように、自社会場で Ansible のイベントを開催したい場合は、レッドハットの中村さん(@fideleruuth)に、相談してみてはいかがでしょうか。

また、個人的には、小規模なイベントではありますが思ったよりは考えたり悩むことがあるなぁと感じました。今回の場合は特に人数です。普段イベント運営をされているみなさまに敬意を表します。

いつもありがとうございます！