以前こんな記事を書きました。（ほぼリンク集ですが・・） tekunabe.hatenablog.jp
今回はこれのプレゼン資料版のような記事です。ここ半年くらいの資料を対象にしています。 具体的なツールの使い方などのスキルとは別に、考え方についても備えていきたいと思っています。
いろいろと考えるきっかけになった資料です。
www.slideshare.net
イベントレポートも参照。 www.atmarkit.co.jp
2018/06/13 -15 に幕張メッセで開催された Interop Tokyo 2018 に参加してきました。
今回は、Ansible というキーワードを中心にしてブースを回ってみました。 回ってみた各ブースなどで紹介していただいた内容を簡単ですがまとめます。
現物は見逃してしまいましたが、以下のツイートを後で見かけました。 一括設定に Ansible Tower が利用されていたそうです。
Ansible Towerで一括設定！！(≧∇≦)#interop18 pic.twitter.com/RlOxoBExHP
— もりはや (@morihaya55) 2018年6月15日
コンソールサーバー SmartCS とAnsible (+AWX) を連携することにより、IP到達性がない機器にも操作できるという構成でした。
紹介されていたユースケースは以下の2つです。
いずれも、コンソールサーバーを活用することで、今まで思いつかなかったようなユースケースに感じました。
日本のネットワーク機器ベンダーの Ansible 対応状況（Alaxala・APRESIA）でもご紹介しましたが、会員サイトから Alaxala モジュールがダウンロードできるようになっています。
応用的なケースとして、AX3660Sに搭載されているオンボックスなPythonを利用して、機器自身で機器側のイベントを検出して Ansible Tower を呼ぶ、という方法も紹介されていました。
サードパーティモジュールとして以下のリポジトリでA10モジュールが提供されているそうです。 詳細は聞きそびれてしまいましたが、こちらかと思います。 https://github.com/a10networks/a10-ansible もともと機器側にあるAPIを呼び出す仕様だそうです。
また、活用例の図も見せていただきました。 Ansible が中心となり、OpensStack 経由で vThunder を起動させて設定をする構成です。 プロビジョニングする構成が新鮮でした。
システナさんのコーナーで、Ansibleの導入支援や、モジュール開発について紹介されていました。
弊社エンジニアによるセッション「ネットワーク運用自動化こと始め」の中でもAnsibleが取り上げられていました。
思いのほか Ansible という言葉を見かけました。視野が狭かった可能性は大いにありますが、類似の構成管理ツールの名前は見かけませんでした。今まで標準モジュールばかりウォッチしていましたが、ベンダー自身がサードパーティモジュールとして提供しているものものあり、今後も増えてくるかも知れません。 今後も Ansible とネットワーク機器との関わり方には注目していきたいと思います。
-i にカンマ区切りで直接ホストを指定できる通常、 ansible-playbook コマンドや ansible コマンドのオプション -i オプションでは、イベントリファイル名を指定することが多いと思います。
この -i オプションですが、インベントリファイルを用意することなく、対象ホストをカンマ区切りで直接指定することもできます。
例えば、rt01 と sw01 を対象とする場合は、以下のように指定します。
ansible-playbook -i rt01,sw01 playbook.yml
対象が1ホストだけの場合は、末尾のカンマを残したかたちにします。
ansible-playbook -i rt01, playbook.yml
なお、末尾のカンマがないと、インベントリファイル名が指定されたとみなされます。
ansible-playbook -i rt01 playbook.yml
（この場合 rt01 というインベントリファイルを探しいく）
インベントリファイルを用意するほどでもないときは、この方法を利用してみてはいかがでしょうか。
コマンドオプションヘルプ (or comma separated host list と記載あり)
[vagrant@centos7 ~]$ ansible-playbook
Usage: ansible-playbook [options] playbook.yml [playbook2 ...]
Runs Ansible playbooks, executing the defined tasks on the targeted hosts.
(略)
-i INVENTORY, --inventory=INVENTORY, --inventory-file=INVENTORY
specify inventory host path or comma separated host
list. --inventory-file is deprecated
[https://docs.ansible.com/ansible/2.9/plugins/inventory/host_list.html:title]
ansible のリポジトリに ansible-runner なるものを見つけました。
デモ用に docker で ansible を動かす例が載っていました。
docker run -it --rm -e RUNNER_PLAYBOOK=test.yml ansible/ansible-runner:latest
手元に ansible がない環境で docker run 経由で ansible を動かす、という方法は面白いなと思ったので試すことにしました。
実行される Playbook は、
ansible-runner/test.yml at master · ansible/ansible-runner · GitHub
のようです。
- hosts: all tasks: - debug: msg="Test!"
StackStorm の環境を準備するには、インストールスクリプトを実行する方法や Ansible の Playbook を実行する方法などがありますが、先日の公式ブログでは vagrant で VMごと StackStorm の環境を準備する方法が紹介されていました。
公式ドキュメントの「Vagrant & Virtual Appliance」にも、記載されていましたので、これらの情報をもとに試しに、環境を準備して、ごく簡単な動作確認をします。
環境:
※ Ansible で StackStorm にインストールする場合はこちら http://tekunabe.hatenablog.jp/entry/2018/03/12
以下の2行だけです。
vagrant init stackstorm/st2 vagrant up
vagrant init stackstorm/st2 で最低限の Vagrantfile が生成され、その情報をもとに vagrant up でVMを起動するという流れです。
akirapc:st2 akira$ vagrant init stackstorm/st2
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
akirapc:st2 akira$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'stackstorm/st2' could not be found. Attempting to find and install...
default: Box Provider: virtualbox
default: Box Version: >= 0
==> default: Loading metadata for box 'stackstorm/st2'
default: URL: https://vagrantcloud.com/stackstorm/st2
==> default: Adding box 'stackstorm/st2' (v2.7.2-20180523) for provider: virtualbox
default: Downloading: https://vagrantcloud.com/stackstorm/boxes/st2/versions/2.7.2-20180523/providers/virtualbox.box
==> default: Successfully added box 'stackstorm/st2' (v2.7.2-20180523) for 'virtualbox'!
==> default: Importing base box 'stackstorm/st2'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'stackstorm/st2' is up to date...
==> default: Setting the name of the VM: stackstorm
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports...
default: 443 (guest) => 9000 (host) (adapter 1)
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
[default] GuestAdditions 5.2.12 running --- OK.
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
default: /vagrant => /Users/akira/Documents/git/python_test/vagrant/st2
==> default: Running provisioner: st2-version (shell)...
default: Running: inline script
default: st2 2.7.2, on Python 2.7
==> default: Machine 'default' has a post `vagrant up` message. This is a message
==> default: from the creator of the Vagrantfile, and not from Vagrant itself:
==> default:
==> default: ███████╗████████╗██████╗ ██████╗ ██╗ ██╗
==> default: ██╔════╝╚══██╔══╝╚════██╗ ██╔═══██╗██║ ██╔╝
==> default: ███████╗ ██║ █████╔╝ ██║ ██║█████╔╝
==> default: ╚════██║ ██║ ██╔═══╝ ██║ ██║██╔═██╗
==> default: ███████║ ██║ ███████╗ ╚██████╔╝██║ ██╗
==> default: ╚══════╝ ╚═╝ ╚══════╝ ╚═════╝ ╚═╝ ╚═╝
==> default:
==> default: To access the Web UI, head to:
==> default: https://10.10.10.10/
==> default: Username: st2admin
==> default: Password: Ch@ngeMe
==> default:
==> default: Thanks for trying StackStorm!
そのまま vagrant ssh コマンドでログインできます。
akirapc:st2 akira$ vagrant ssh Welcome to StackStorm v2.7.2 (Ubuntu 16.04 LTS GNU/Linux x86_64) * Documentation: https://docs.stackstorm.com/ * Community: https://stackstorm.com/community-signup * Forum: https://forum.stackstorm.com/ * Enterprise: https://stackstorm.com/#product Last login: Wed Jun 6 11:59:12 2018 from 10.0.2.2 vagrant@stackstorm:~$ hostname stackstorm vagrant@stackstorm:~$ uname -a Linux stackstorm 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux vagrant@stackstorm:~$
ログインできました。Ubutuを利用しているようです。
なお、VirtualBox の VM として SSH へポートフォワーディングは 2222/TCP に設定されますので、ssh コマンドやターミナルソフトでログインする場合は、 2222/TCP を指定します。
ユーザー名、パスワードともに vagrant です。秘密鍵を利用する場合は .vagrant/machines/default/virtualbox/private_key を指定します。
akirapc:st2 akira$ ssh vagrant@localhost -p 2222 vagrant@localhost's password: Welcome to StackStorm v2.7.2 (Ubuntu 16.04 LTS GNU/Linux x86_64) * Documentation: https://docs.stackstorm.com/ * Community: https://stackstorm.com/community-signup * Forum: https://forum.stackstorm.com/ * Enterprise: https://stackstorm.com/#product vagrant@stackstorm:~$ hostname stackstorm
StackStormの各種操作には、StackStormへのログインが必要です。ここでは環境変数にトークンを仕込む方法でログインと同等の状態にします。
ユーザーは st2admin、パスワードは Ch@ngeMe です。
vagrant@stackstorm:~$ export ST2_AUTH_TOKEN=`st2 auth -t -p Ch@ngeMe st2admin`
簡単な動作確認として st2 run コマンドで date コマンドを実行します。
vagrant@stackstorm:~$ st2 run core.local -- date -R . id: 5b17d02802ebd505e4388361 status: succeeded parameters: cmd: date -R result: failed: false return_code: 0 stderr: '' stdout: Wed, 06 Jun 2018 12:14:33 +0000 succeeded: true
正常に実行できました。
今度は、Web画面の確認をします。
VMの設定で、9000/TCP から 443/TCP へのポートフォワーディングが設定されていますので、ホストOSのブラウザから https://localhost:9000 にアクセスします。
CLI と居と同じく、ユーザーは st2admin、パスワードは Ch@ngeMe です。
ログイン後トップ画面の左の方で、先程CLIから実行した st2 run core.local -- date -R のログが確認できます。
初期のログイン情報は以下のとおりです。
| ログイン方法 | ポート番号 | ユーザー名 | パスワード | 備考 |
|---|---|---|---|---|
| SSH | 2222 | vagrant | vagrant | 秘密鍵 .vagrant/machines/default/virtualbox/private_key |
| Web | 9000 | st2admin | Ch@ngeMe | https://localhost:9000 |
st2 login |
- | st2admin | Ch@ngeMe |
Vagrant と VirtualBox で艱難に OSごと StackStorm の環境を準備できることが確認できました。 特に OS/ディストリビューションにこだわりがなく、とにかく手軽にローカルに StackStorm の独立した環境を準備するには、この Vagnrant の方法が良いのではないかと思います。
Ansible は Cisco、Juniper、ARISTAなどのネットワーク機器にも対応しています。 公式ドキュメント上のネットワークモジュールの一覧ページを確認すると分かりますが、日本のネットワーク機器に対応するモジュールは標準モジュールにはありません。 ただ、今年に入って日本のネットワーク機器ベンダーが Ansible に対応する動きが見られます。
この記事では、Alaxalaと、APRESIAの対応状況について調べた範囲でご紹介します。(いずれも本記事執筆時点)
Alaxala は、対応モジュールを提供済みです。
Ansibleを活用したITインフラの運用自動化ソリューションを強化:アラクサラネットワークス株式会社
会員専用サイトから無償でダウンロード可能で、日本語マニュアルも用意されています。
提供モジュールは以下。
パッと見、オプション含めて既存の標準モジュールに合わせた仕様で作られているようでした。
また、Interop Tokto 2018 で、デモの展示があるそうです。
OSSである運用自動化ツールAnsibleを活用したプロビジョニングのデモを行います。
Interop Tokyo 2018:出展のご案内：アラクサラネットワークス株式会社
Interopレポート (2019/02/06 追記） tekunabe.hatenablog.jp
2018年5月23日:APRESIA Systemsが次世代モバイル向けにネットワーク装置を発表｜ニュースリリース｜APRESIA | APRESIA Systems株式会社
上記 Apresia22000シリーズのニュースリリースに、将来実装予定と注釈がついていますが
– 収集した情報を更に詳細に分析するためのツールやOSS、AI、機械学習との連携を容易にするTelemetryやansibleなどの標準技術やAPIの実装
とありました。
詳細は不明ですが、こちらもサードパーティモジュールとして提供されるのかもしれません。
[2022/10/21 追記] 提供されたことがアナウンスされました。
ApresiaNPシリーズ用のAnsibleモジュールの提供を開始いたしました。
— APRESIA Systems株式会社 (@APRESIA_Systems) 2022年10月21日
以下のページの最下部、関連情報からダウンロードできます。https://t.co/q5iQRcOMzO
2019年1月に開催された、JANOG43 Meeting in Yamanasi のブースで、Ansible モジュールを使ったデモをされていました。
デモの内容は、Zabbixで機器の障害を検出したら予備機（マネジメントIPだけ設定済み）にコンフィグを投入して、切り替えるといったものでした。
モジュールの提供方法については検討中とのことでした。
他にもあるかもしれませんが、 日本のネットワーク機器ベンダーの Ansible 対応状況についてまとめました。 もしかしたら今後も対応するベンダーが現れるかもしれませんので、引き続きにしていこうと思います。
Ansible 2.5 で with_* の代わりに利用できる loop キーワードが利用できるようになりました。
今まで with_items と同じと思い込んでいたのですが、そうではなく with_list と同じ、ということに気がついたのでまとめます。
違いは、一段階flatten（ネストを平らにして展開）されるか、されないかです。
| キーワード | flatten |
|---|---|
with_items |
一段階 flatten される |
with_list、loop |
flatten されない |
違いを確認するために、簡単な Playbook で検証します。
- hosts: localhost gather_facts: no connection: local vars: testitems: - [1, 2] - 3 tasks: - name: with_items debug: msg: "{{ item }}" with_items: "{{ testitems }}" - name: with_list debug: msg: "{{ item }}" with_list: "{{ testitems }}" - name: normal loop debug: msg: "{{ item }}" loop: "{{ testitems }}"
akira:~/environment $ ansible-playbook -i inventory looptest.yml PLAY [localhost] *********************************************** TASK [with_items] ********************************************** ok: [localhost] => (item=None) => { "msg": 1 } ok: [localhost] => (item=None) => { "msg": 2 } ok: [localhost] => (item=None) => { "msg": 3 } TASK [with_list] *********************************************** ok: [localhost] => (item=None) => { "msg": [ 1, 2 ] } ok: [localhost] => (item=None) => { "msg": 3 } TASK [normal loop] ********************************************* ok: [localhost] => (item=None) => { "msg": [ 1, 2 ] } ok: [localhost] => (item=None) => { "msg": 3 } PLAY RECAP ***************************************************** localhost : ok=3 changed=0 unreachable=0 failed=0
このように、 [[1, 2], 3] というネストされたリストが、
with_items は flatten されて、 1、2、3 という3回のループwith_list と loop は flatten されず、 [1, 2]、3 という2回のループになったことが確認できました。
loop でも flatten フィルターを通すと flatten されて、 with_items と同じ動作になります。
- name: loop with flatten debug: msg: "{{ item }}" loop: "{{ testitems | flatten(levels=1) }}"
akira:~/environment $ ansible-playbook -i inventory looptest.yml
PLAY [localhost] ***********************************************
TASK [loop with flatten] ***************************************
ok: [localhost] => (item=None) => {
"msg": 1
}
ok: [localhost] => (item=None) => {
"msg": 2
}
ok: [localhost] => (item=None) => {
"msg": 3
}
PLAY RECAP ************************************************************************************
localhost : ok=1 changed=0 unreachable=0 failed=0
通常の loop は、with_list と同じく、 flatten されない
フィルター| flatten(levels=1)| を通すと、with_items と同じく一段階 flatten される
ということが分かりました。これから Playbook のサンプルは with_* ではなく、 loop が増えてくるのではないかと思います。
Ansible 2.5 へのポーティングガイドで with_x から loop への以降方法が記載されています。
https://docs.ansible.com/ansible/latest/porting_guides/porting_guide_2.5.html#migrating-from-with-x-to-loop
