てくなべ

ネットワーク、自動化などの技術的なことを書いていきます。Ansible、StackStorm等

自動化を考える前に読んでおきたいプレゼン資料たち

はじめに

以前こんな記事を書きました。(ほぼリンク集ですが・・) tekunabe.hatenablog.jp

今回はこれのプレゼン資料版のような記事です。ここ半年くらいの資料を対象にしています。 具体的なツールの使い方などのスキルとは別に、考え方についても備えていきたいと思っています。


運用自動化、不都合な真実

いろいろと考えるきっかけになった資料です。


生き残る運用管理者 ~運用自動化を成功させる人、失敗させる人~


リクルート流SRE インフラ運用がサービスを変える世界


新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた

www.slideshare.net

イベントレポートも参照。 www.atmarkit.co.jp

Ansible 目線で見た Interop Tokyo 2018


■ はじめに

2018/06/13 -15 に幕張メッセで開催された Interop Tokyo 2018 に参加してきました。

www.interop.jp

f:id:akira6592:20180618134348p:plain

今回は、Ansible というキーワードを中心にしてブースを回ってみました。 回ってみた各ブースなどで紹介していただいた内容を簡単ですがまとめます。


■ Show Net

一括設定

現物は見逃してしまいましたが、以下のツイートを後で見かけました。 一括設定に Ansible Tower が利用されていたそうです。


セイコーソリューションズさん

SmartCS と Ansible の連携(参考出展)

コンソールサーバー SmartCS とAnsible (+AWX) を連携することにより、IP到達性がない機器にも操作できるという構成でした。

紹介されていたユースケースは以下の2つです。

  • 機器のICMP死活監視が落ちたら、コンソールポート経由で情報を取得する
  • コンソールポート経由でIP設定を行う

いずれも、コンソールサーバーを活用することで、今まで思いつかなかったようなユースケースに感じました。

f:id:akira6592:20180618141956p:plain f:id:akira6592:20180618135403p:plain

f:id:akira6592:20180618135329p:plain


■ アラクサラネットワークスさん

サードパーティモジュール ax_*

日本のネットワーク機器ベンダーの Ansible 対応状況(Alaxala・APRESIA)でもご紹介しましたが、会員サイトから Alaxala モジュールがダウンロードできるようになっています。

応用的なケースとして、AX3660Sに搭載されているオンボックスなPythonを利用して、機器自身で機器側のイベントを検出して Ansible Tower を呼ぶ、という方法も紹介されていました。

f:id:akira6592:20180618140852p:plain f:id:akira6592:20180618140908p:plain f:id:akira6592:20180618140931p:plain f:id:akira6592:20180618140947p:plain


■ A10ネットワークスさん

a10_* モジュールの紹介と活用例

サードパーティモジュールとして以下のリポジトリでA10モジュールが提供されているそうです。 詳細は聞きそびれてしまいましたが、こちらかと思います。 https://github.com/a10networks/a10-ansible もともと機器側にあるAPIを呼び出す仕様だそうです。

f:id:akira6592:20180618141236p:plain

また、活用例の図も見せていただきました。 Ansible が中心となり、OpensStack 経由で vThunder を起動させて設定をする構成です。 プロビジョニングする構成が新鮮でした。

f:id:akira6592:20180618141857p:plain


■ Zabbix

システナさんのコーナーで、Ansibleの導入支援や、モジュール開発について紹介されていました。

f:id:akira6592:20180618142203p:plain f:id:akira6592:20180618142136p:plain


■ ジュニパーネットワークスさん

弊社エンジニアによるセッション「ネットワーク運用自動化こと始め」の中でもAnsibleが取り上げられていました。


■ 所感・まとめ

思いのほか Ansible という言葉を見かけました。視野が狭かった可能性は大いにありますが、類似の構成管理ツールの名前は見かけませんでした。今まで標準モジュールばかりウォッチしていましたが、ベンダー自身がサードパーティモジュールとして提供しているものものあり、今後も増えてくるかも知れません。 今後も Ansible とネットワーク機器との関わり方には注目していきたいと思います。

Ansible でインベントリファイルを用意せずに対象ホストを指定する方法

-i にカンマ区切りで直接ホストを指定できる

通常、 ansible-playbook コマンドや ansible コマンドのオプション -i オプションでは、イベントリファイル名を指定することが多いと思います。 この -i オプションですが、インベントリファイルを用意することなく、対象ホストをカンマ区切りで直接指定することもできます。


例えば、rt01sw01 を対象とする場合は、以下のように指定します。

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 と記載あり)

[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

docker run で Ansible の Playbook を実行する

ansible のリポジトリに ansible-runner なるものを見つけました。

github.com

デモ用に docker で ansible を動かす例が載っていました。

docker run -it --rm -e RUNNER_PLAYBOOK=test.yml ansible/ansible-runner:latest

手元に ansible がない環境で docker run 経由で ansible を動かす、という方法は面白いなと思ったので試すことにしました。

f:id:akira6592:20180607161707g:plain

実行される Playbook は、

ansible-runner/test.yml at master · ansible/ansible-runner · GitHub

のようです。

- hosts: all
  tasks:
    - debug: msg="Test!"

Vagrant で手軽に VM ごと StackStorm の環境を準備する

■ はじめに

StackStorm の環境を準備するには、インストールスクリプトを実行する方法や Ansible の Playbook を実行する方法などがありますが、先日の公式ブログでは vagrantVMごと StackStorm の環境を準備する方法が紹介されていました。

stackstorm.com

公式ドキュメントの「Vagrant & Virtual Appliance」にも、記載されていましたので、これらの情報をもとに試しに、環境を準備して、ごく簡単な動作確認をします。

環境:

※ Ansible で StackStorm にインストールする場合はこちら http://tekunabe.hatenablog.jp/entry/2018/03/12


■ StackStorm 入りのVMの準備と起動

以下の2行だけです。

vagrant init stackstorm/st2
vagrant up

vagrant init stackstorm/st2 で最低限の Vagrantfile が生成され、その情報をもとに vagrant upVMを起動するという流れです。

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!


CLIの確認

SSHログイン

そのまま 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を利用しているようです。

なお、VirtualBoxVM として 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の各種操作には、StackStormへのログインが必要です。ここでは環境変数トークンを仕込む方法でログインと同等の状態にします。 ユーザーは st2admin、パスワードは Ch@ngeMe です。

vagrant@stackstorm:~$ export ST2_AUTH_TOKEN=`st2 auth -t -p Ch@ngeMe st2admin`

st2 run 動作確認

簡単な動作確認として 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

正常に実行できました。


GUI(Web)の確認

ログイン

今度は、Web画面の確認をします。 VMの設定で、9000/TCP から 443/TCP へのポートフォワーディングが設定されていますので、ホストOSのブラウザから https://localhost:9000 にアクセスします。 CLI と居と同じく、ユーザーは st2admin、パスワードは Ch@ngeMe です。 f:id:akira6592:20180606212440p:plain

ログ確認

ログイン後トップ画面の左の方で、先程CLIから実行した st2 run core.local -- date -R のログが確認できます。 f:id:akira6592:20180606212652p:plain


■ ログイン情報まとめ

初期のログイン情報は以下のとおりです。

ログイン方法 ポート番号 ユーザー名 パスワード 備考
SSH 2222 vagrant vagrant 秘密鍵 .vagrant/machines/default/virtualbox/private_key
Web 9000 st2admin Ch@ngeMe https://localhost:9000
st2 login - st2admin Ch@ngeMe


■ まとめ

VagrantVirtualBox で艱難に OSごと StackStorm の環境を準備できることが確認できました。 特に OS/ディストリビューションにこだわりがなく、とにかく手軽にローカルに StackStorm の独立した環境を準備するには、この Vagnrant の方法が良いのではないかと思います。

日本のネットワーク機器ベンダーの Ansible 対応状況(Alaxala・APRESIA)

■ はじめに

Ansible は Cisco、Juniper、ARISTAなどのネットワーク機器にも対応しています。 公式ドキュメント上のネットワークモジュールの一覧ページを確認すると分かりますが、日本のネットワーク機器に対応するモジュールは標準モジュールにはありません。 ただ、今年に入って日本のネットワーク機器ベンダーが Ansible に対応する動きが見られます。

この記事では、Alaxalaと、APRESIAの対応状況について調べた範囲でご紹介します。(いずれも本記事執筆時点)


■ Alaxala はサードパーティモジュールを提供済み

Alaxala は、対応モジュールを提供済みです。

Ansibleを活用したITインフラの運用自動化ソリューションを強化:アラクサラネットワークス株式会社

会員専用サイトから無償でダウンロード可能で、日本語マニュアルも用意されています。

提供モジュールは以下。

  • ax_command
  • ax_config
  • ax_facts

パッと見、オプション含めて既存の標準モジュールに合わせた仕様で作られているようでした。

また、Interop Tokto 2018 で、デモの展示があるそうです。

OSSである運用自動化ツールAnsibleを活用したプロビジョニングのデモを行います。

Interop Tokyo 2018:出展のご案内:アラクサラネットワークス株式会社


■ APRESIA は "将来実装予定"

2018年5月23日 : APRESIA Systemsが次世代モバイル向けにネットワーク装置を発表 | ニュースリリース : -APRESIA Systems- : APRESIA

上記 Apresia22000シリーズのニュースリリースに、将来実装予定と注釈がついていますが

– 収集した情報を更に詳細に分析するためのツールやOSS、AI、機械学習との連携を容易にするTelemetryやansibleなどの標準技術やAPIの実装

とありました。

詳細は不明ですが、こちらもサードパーティモジュールとして提供されるのかもしれません。


■ まとめ

他にもあるかもしれませんが、 日本のネットワーク機器ベンダーの Ansible 対応状況についてまとめました。 もしかしたら今後も対応するベンダーが現れるかもしれませんので、引き続きにしておこうと思います。

Ansible の loop は flatten されない(with_items ではなく with_list と同じ)

■ はじめに

Ansible 2.5 で with_* の代わりに利用できる loop キーワードが利用できるようになりました。

今まで with_items と同じと思い込んでいたのですが、そうではなく with_list と同じ、ということに気がついたのでまとめます。 違いは、一段階flatten(ネストを平らにして展開)されるか、されないかです。

キーワード  flatten
with_items 一段階 flatten される
with_listloop flatten されない

■ 検証

違いを確認するために、簡単な Playbook で検証します。

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 されて、 123 という3回のループ
  • with_listloop は flatten されず、 [1, 2]3 という2回のループ

になったことが確認できました。

with_items を loop で置き換えるなら、| flatten(levels=1) する

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 が増えてくるのではないかと思います。