StackStormを活用した運用自動化の実践

INTERNET MULTIFEED CO.Copyright ©
StackStormを活用した運用自動化の実践
Shu Sugimoto
Software Development Manager, JPNAP
2019-03-19(Tue)

今日の内容
• StackStormとは？一体何が出来るの？
• StackStormが「運用自動化」にどう活用できるのか？
• 弊社のJPNAP(IXサービス)における業務の自動化に対する取
り組みの中での実例を交え、StackStormの「ココが効く」
をご紹介
• 「現在既にある業務」を自動化していく、というポイントに
フォーカス
• StackStormの「ここもすごい」
• 実際に使って開発をして分かったTipsやノウハウ、
Pros/Consを共有
2

インターネットマルチフィード(株)
3
IX (Internet Exchange) VNE (Virtual Network Enabler)
ネットワークな会社です
Public NTPや、RPKI ROAキャッシュサーバーの提供などもしています
ntp1.jst.mfeed.ad.jp とか

インターネットマルチフィード(株)
4
IX (Internet Exchange) VNE (Virtual Network Enabler)
ネットワークな会社です
Public NTPや、RPKI ROAキャッシュサーバーの提供などもしています
ntp1.jst.mfeed.ad.jp とか
自身の所属はこっち
• NW運用→ソフトウェア開発マネージャー
• 運用自動化/DevOps/クラウド化推進

JPNAP
• IX: Internet Exchange
• 色々な組織のネットワークを相互接続する場所を提供する
• お客様にL2スイッチのポートを提供
5
IX
BGPルータ
L2SW
BGPルータ
BGP
経路交換とトラフィック交換

JPNAP
6
• IX: Internet Exchange
• ⇒ 超巨大なL2ネットワーク
• JPNAP東京の規模感
• 都内8拠点に展開
• ピークトラフィック 1.29 Tbps
• 接続AS数 150～
• 提供インターフェース数 200～

本日の「運用自動化」テーマの対象
7
JPNAP
Backbone
管理網
お客様
ルータ光スイッチ
L2SW(主系)
L2SW(副系)
お客様に提供するポートの開通に関係する作業
監視サーバー
監視サーバー, etc…

「自動化」って言うけれど…
• 「自動化」の重要性は増すばかり？
• どのカンファレンスに行っても大体自動化の話は出てくる
• コスト削減、リードタイム短縮、オペミス削減、etc…
• 現実
• 「自動化の重要性はわかっている」
• 「自動化には力を入れているつもり」
• 「でもなんか思ったより全然進んでない」
• なぜなのか？
8

自動化が何故「難しい」のか
• A: そもそも、今の運用が自動化に向いていない
• 1. 実は手順が思ったよりも複雑
• 単純に上から順番に実行すればよいわけではない
• 複数のホストが関わってくる
• 2. 人による判断を要する部分が手順内に紛れている
• 『結果が問題ないこと』『出力が意図した通りであること』
• どこか一つでも上記に該当すると、急激に難易度上昇！
• 既に確立している運用フローを変えるのはとても x1000大変
• もし仮に、既存の手順書を変えることなく自動化できたなら
ば…？ ⇒ 「それ、StackStormで出来るよ！」
9

StackStorm (st2)
• IFTTTライクなミドルウェア・フレームワーク
• IF This Then That
10
“Then That”の部分単体でもかなり使える
https://www.slideshare.net/brocade/eventdriven-automation-devops-way-iot-73581697

StackStormの「ココ」が効く
• 1. 強力なワークフローエンジン
• 複雑な手順もシンプルな記述で実装が可能
11

st2 Workflow vs Shell script
12
Shell Script StackStorm Workflow
Image from tweet by StackStorm official Twitter account @Stack_Storm
https://twitter.com/stack_storm/status/684921149898113024

st2 Workflow vs Shell script
13
with-items: 配列の全要素に対して同じアクションを実行
例: 複数のホストで同じ操作をしたい
join: 並列実行したものが全部終わるまで待つ
loop:
繰り返し
柔軟な制御構造を簡単に記述出来る

Workflow components
14
Workflow
Action

Workflow components
15
version: 1.0
description: A basic sequential workflow.
input:
- name
vars:
- greeting: null
output:
- greeting: <% ctx().greeting %>
tasks:
task1:
action: core.echo message=<% ctx().name %>
next:
- when: <% succeeded() %>
publish: greeting=<% result().stdout %>
do: task2
task2:
action: core.echo
input:
message: "All your base are belong to us!"
next:
publish:
- greeting: <% ctx("greeting") %>, <% result().stdout %>
do:
- task3
task3:
action: core.echo message=<% ctx('greeting') %>
next:
publish: greeting=<% result().stdout %>aaa
Workflow
Action
Action
Action

st2 Workflow
• StackStormにおけるWorkflowの基本
• Workflow = Actionの組み合わせ
• 処理の流れを、Action同士を接続することで組み立てる
• YAMLで記述する
• 入力パラメータを定義して与えることが出来る
• ワークフローの中で処理の分岐に使ったり、アクションを呼び
出す際のパラメータとして使う
• 関数の引数のようなもの
• 出力を返すことが出来る
• 文字列や数値だけでなくハッシュなどのオブジェクトも返せる
• 関数の戻り値のようなもの
• ワークフローの結果を返す
• Success/Failure
• 上記の「出力」とは異なる
16

st2 Action
• StackStormにおけるActionの基本
• Workflowを構成する最小単位
• 実際に処理を行う場所である
• e.g. ディレクトリ作成、makeコマンド実行、etc…
• Workflowと同様に…
• 入力として引数をとり、出力を返すことができる
• ステータスを返す (Success/Failure)
• Actionの実装方法は何種類かある
• 最も一般的なのはpythonでコードを書いて実装する手法
• その他、ビルトインの「runner」を使っても実装が可能
• pythonのactionも、実際には ”python-script” というrunnerを
使って呼び出している
17

remote-shell-cmd runner
• `remote-shell-cmd`
• ビルトインで提供されているrunnerの一つ
• 端的にいうと…
• sshでtarget_hostにusernameでログインして、
• cwdでcmdを実行する
• 以下を入力として渡す
• target hostname
• username
• ssh_key or password
• cwd
• cmd
• こいつがとても便利なんです！
18

remote-shell-cmdを使ったActionの例 1
19
---
enabled: true
name: remote-sample
runner_type: remote-shell-cmd
parameters:
hosts:
default: 192.168.33.10
username:
default: vagrant
password:
default: vagrant
cwd:
default: /vagrant
cmd:
default: |
set -x
pwd
ls -al
df -h
root@9fe86b6dce75:/# st2 run demo.remote-sample
.
id: 5bdd72e9ecc69005aed541d4
status: succeeded
parameters: None
result:
192.168.33.10:
failed: false
return_code: 0
stderr: '+ pwd
+ ls -al
+ df -h'
stdout: '/vagrant
total 8
drwxr-xr-x 1 vagrant vagrant 128 Nov 3 02:13 .
drwxr-xr-x 23 root root 4096 Nov 1 15:53 ..
drwxr-xr-x 1 vagrant vagrant 128 Nov 2 23:58 .vagrant
-rw-r--r-- 1 vagrant vagrant 165 Nov 3 02:13 Vagrantfile
Filesystem Size Used Avail Use% Mounted on
udev 487M 0 487M 0% /dev
tmpfs 100M 4.4M 96M 5% /run
/dev/mapper/debian--9--vg-root 62G 1.3G 58G 3% /
tmpfs 499M 0 499M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 499M 0 499M 0% /sys/fs/cgroup
/dev/sda1 236M 37M 187M 17% /boot
vagrant 932G 111G 822G 12% /vagrant
tmpfs 100M 0 100M 0% /run/user/1000'
succeeded: true
remote-sample.meta.yaml

remote-shell-cmdを使ったActionの例 2
20
---
enabled: true
name: remote-install-sl
parameters:
hosts:
default: 192.168.33.10
username:
default: vagrant
password:
default: vagrant
cwd:
default: /
cmd:
default: |
set -eux
TMPDIR=$(mktemp -d)
cd $TMPDIR
git clone https://github.com/mtoyoda/sl
cd sl
make
sudo cp sl /usr/local/bin
# cleanup working directory
cd /
rm -Rf $TMPDIR
remote-install-sl.yaml
• YAMLで記述
• 複数行のコマンドを書ける
• シェルの機能も普通に使える
• 変数
• コメント
• cmd substitution: $()
• etc…
• sudoも可能
• TTY allocationしてくれる
※他のホストで実行したい場合、単
純にパラメータを変えて実行
$ st2 run demo.remote2 hosts=192.0.2.1
既存の手順の中でやっている実際の
作業部分を、簡単に置き換えていく
ことが出来る

Workflowの特徴・機能
• Workflowを構成するActionを、Workflowにすることが可能
• ＝Workflowをネストすることが出来る
• 階層に制限はない
• Actionの「出力」を、後続のActionへの入力として渡したり、条
件分岐等の制御構造で使うことが出来る
21
A
W
A
A
W
A
A
A
1
2
3
4
5
6
78

出力を次の入力として使う例
22
version: 1.0
tasks:
mktemp:
action: demo.remote-mktemp
next:
- when: "{{ succeeded() }}"
publish:
- tmpdir: "{{ jsonpath_query(result(), '*.stdout')[0] }}"
do: build
build:
action: demo.remote-build
input:
cwd: "{{ ctx().tmpdir }}"
next:
do: cleanup
cleanup:
action: demo.remote-cleanup
input:
target_path: "{{ ctx().tmpdir }}"
---
enabled: true
name: remote-mktemp
parameters:
hosts:
default: 192.168.33.10
username:
default: vagrant
password:
default: vagrant
cmd:
default: mktemp -d
---
enabled: true
name: remote-build
parameters:
hosts:
default: 192.168.33.10
username:
default: vagrant
password:
default: vagrant
cmd:
default: |
git clone https://github.com/mtoyoda/sl
cd sl
make
sudo cp sl /usr/local/bin
input-output-chaining.yaml
remote-mktemp.meta.yaml
remote-build.meta.yaml

Workflowの機能・特徴
• Action execution concurrency policy
• Actionごとに、同時実行数の制御が可能
• 同時実行可能数以上がリクエストされた場合、キャンセルす
るか、Delayさせるかのいずれかを指定出来る
• 同時実行の判断に使用するパラメータを追加も出来る
• e.g. あるアクションに対し、hostパラメータまで見て実行を判
断する→hostが異なれば、制御はかからず同時実行可能
• Jinja/YAQLのサポート
• Workflowを記載するYAMLの中でテンプレートエンジンが使
える
• 主にパラメータの操作に使ったりする
• そこそこ複雑なことも出来る
• が、やらないほうがよい
23

Workflow(というかst2)の機能・特徴
• Datastore (st2kv)
• 任意のデータを保存するKVS
• 暗号化をサポート
• TTLをサポート
• 切れたら自動的に削除してくれる
• コンフィグ的なパラメータを保存しておいたり、複数の
Workflowをまたがって使いたいデータを一時保存するとき等
に使える
• (Workflowの実装は複数のエンジンをサポート)
• Mistral-v2: OpenStack Projectの実装
• Orquesta: StackStormの開発元が実装している新しいエン
ジン
24

• remote-shell-cmdを使うと、既存の手順を簡単にActionに
置き換えていくことが出来る
• StackStorm Exchangeの存在
• …と、Packと呼ばれる仕組み
25

PackとStackStorm Exchange
• Pack
• Action/Workflow、Rule/Policy/Sensor/(Action )Aliasを一
つにまとめて管理する単位
• Debianのdebパッケージ、Rubyのgemのようなもの
• 2種類のPack
• Integration Pack: 外部システムと連携するためのPack
• Automation Pack: 何らかしら特定の物を対象とした自動化の
ためのAction/Workflowを含むもの
• 内部的には何ら違いはない
• 社内の手順を自動化している → ”Automation Pack”
• StackStorm Exchange (https://exchange.stackstorm.org)
• “Integration Pack” の集まり、Packの公開レポジトリ
• 誰でも自由に利用可能
26

• remote-shell-cmdを使うと、既存の手順を簡単にActionに
置き換えていくことが出来る
• StackStorm Exchangeの存在
• …と、Packと呼ばれる仕組み
• ⇒ 既に用意されているActionを自身のWorkflowに組み込んで
活用出来る
27

• 2. Inquiry機能
• Workflowを中断し、入力を求めることが出来る
• 『この出力結果は正しいですか？(y/N)』
• “core.ask” というデフォルトのActionで実装されている
28

Inquiry機能
29
止めたいところにcore.askを入れる
“Would you like to continue? (yes/no)”
yesなら再開、noなら中断
core.ask
中断
yes no
人によるレスポンス

Inquiry機能の例
30
version: 1.0
tasks:
mktemp:
action: demo.remote-mktemp
next:
publish:
- tmpdir: "{{ jsonpath_query(result(), '*.stdout')[0] }}"
do: pause_workflow
pause_workflow:
action: core.ask
next:
- when: "{{ result().response.continue == true }}"
do: build
- when: "{{ result().response.continue != true }}"
do: fail
build:
action: demo.remote-build
input:
cwd: "{{ ctx().tmpdir }}"
next:
do: cleanup
cleanup:
action: demo.remote-cleanup
input:
target_path: "{{ ctx().tmpdir }}"
root@9fe86b6dce75:/# st2 execution get 5bdf1631ecc6900824f95afd
id: 5bdf1631ecc6900824f95afd
action.ref: demo.inquiry-simple
parameters: None
status: paused
result_task: mktemp
result:
192.168.33.10:
failed: false
return_code: 0
stderr: ''
stdout: /tmp/tmp.bFbYga6wDz
succeeded: true
start_timestamp: Sun, 04 Nov 2018 15:54:25 UTC
end_timestamp:
+--------------------------+------------------------+---------------
| id | status | task
+--------------------------+------------------------+---------------
| 5bdf1634ecc6900824f95b00 | succeeded (2s elapsed) | mktemp
| 5bdf1636ecc6900824f95b02 | pending | pause-workflow
+--------------------------+------------------------+---------------
root@9fe86b6dce75:/# st2 inquiry respond 5bdf1636ecc6900824f95b02
continue (boolean): yes
Response accepted for inquiry 5bdf1636ecc6900824f95b02.

Inquiry機能応用編
31
“What is your favorite editor?”
(vi/vim/emacs/nano)
core.ask
中断
vi
応答の結果によって処理を分岐させることも可能
Oops...
vim emacs nano

• 2. Inquiry機能
• これらの特徴を持つStackStormを使えば、今既にある運用につ
いて、手順を変えたりツールを書き換えたりすることなく(半)自
動化することが可能
• StackStormを使うと、自動化の「スモールスタート」が容易
32

JPNAPでの実例
• 自動化したい手順
• お客様の接続が新規に追加されたときに、各種サーバーに対
し監視の設定等を入れていく作業
33

チェックするdiff
手順書の一部抜粋
(全体としては300行程度)
『意図した設定が追加されているか』

JPNAPでの実例
• 自動化したい手順
• お客様の接続が新規に追加されたときに、各種サーバーに対
し監視の設定等を入れていく作業
• st2 Workflowに置き換える前の状況
• 人が実施するための手順書は存在
• 手順のざっくりとした概要
• 作業するサーバーにssh
• ツールのディレクトリにcd
• `rake` コマンドを叩く
• これによってサーバーの設定が生成される
• 生成されたconfigを、差分で目視確認する
• `rake deploy` コマンドを叩く
• 生成された設定を全サーバーに適用する
35

Workflowの実装方法
• やること
• 「sshでログインしてツールのコマンドを叩く」部分を全て
remote-shell-cmd runnerを利用してAction化
• 人の判断が必要となるところ(例えば「出力結果が意図したと
おりであること」を確認する部分)に、都度core.askを入れて
一時停止させる
• (ついでに) core.askの際に確認する内容をSlackに投稿する
• いちいちst2のWeb GUIを確認しなくても済むように
• とてもシンプルかつ愚直 
36

実装したWorkflow
37
slack
core.ask
deploy
done
abort!
yes no
init
rake
---
name: "server_config_generator_rake"
runner_type: "remote-shell-cmd"
description: "Generate server-config with server-config-generator."
enabled: true
parameters:
scg_env:
type: string
immutable: true
default: "{{ st2kv.system.scg.config.scg_env }}"
env:
type: object
immutable: true
default:
SCG_ENV: "{{ scg_env }}"
cwd:
type: string
default: "{{ st2kv.system.scg.config.scg_directory | trim | d('/usr/local/mfeed/bin/server
cmd:
type: string
immutable: true
default: bash -lc "rake"
hosts:
type: string
immutable: true
default: "{{ st2kv.system.scg.config.scg_hostname }}"
username:
type: string
immutable: true
default: "{{ st2kv.system.scg.config.username | trim | d('mfeed', true) }}"
private_key:
type: string
immutable: true
default: "{{ st2kv.system.scg.config.ssh_key.remote_cmd }}"
sudo:
type: boolean
immutable: true
default: false

38
コミュニティに公開されている `slack.files.upload` Actionを活用
確認したい内容(Diff)がSnippetとして投稿される
slack
core.ask
deploy
done
abort!
yes no
init
rake

39
“Does this diff look right? (yes/no)”
$ st2 inquiry respond 5bdbe0395c48de01de0f84cd -r
'{"continue": true}'
slack
core.ask
deploy
done
yes no
init
rake
abort!

40
slack
core.ask
deploy
done
yes no
init
rake
---
name: "server_config_generator_deploy"
runner_type: "remote-shell-cmd"
description: "Deploy configs to servers"
enabled: true
parameters:
scg_env:
type: string
immutable: true
default: "{{ st2kv.system.scg.config.scg_env }}"
env:
type: object
immutable: true
default:
SCG_ENV: "{{ scg_env }}"
deploy_main:
type: boolean
default: false
description: "Choose a deploy target system. Can choose backup( = false ) or main( = true
cwd:
type: string
default: "{{ st2kv.system.scg.config.scg_directory | trim | d('/usr/local/mfeed/bin/server
cmd:
type: string
immutable: true
default: bash -lc "rake deploy_{% if deploy_main %}main{% else %}backup{% endif %}"
hosts:
type: string
immutable: true
default: "{{ st2kv.system.scg.config.scg_hostname }}"
username:
type: string
immutable: true
default: "{{ st2kv.system.scg.config.username | trim | d('mfeed', true) }}"
private_key:
type: string
immutable: true
default: "{{ st2kv.system.scg.config.ssh_key.remote_cmd }}"
sudo:
type: boolean
immutable: true
default: false
abort!

わかったこと
• 短期間で実際に使えるワークフローを実装することが出来た
• `remote-shell-cmd`と “core.ask” のおかげで、既存の手順
から簡単にWorkflow/Actionを組み立てられる
• このアプローチを用いて、同じような手順に対し広く水平展
開が可能
• 次に着手すべきポイントが自然と見えてくる
• 1. “core.ask” を減らす → 半自動化から自動化へ
• 一旦Workflow化が出来ると、今度はcore.askでいちいち止まる
のが鬱陶しく感じるようになる
• 一つずつ着手できるため、スコープが明確で取り組みやすい
• 2. “If This” と連携させる → より包括的な自動化へ
• Workflowのキックを、何らかしらのイベントドリブンにするこ
とが後から簡単に出来る
41

StackStormを使ってわかったPros/Cons
• 全てをYAMLで記載する、ということが素晴らしい
• 通常のソフトウェア開発と全く同じ手法が、Workflowや
Actionの開発にも適用可能
• gitによるバージョン管理
• Branch > PR > Code review > Merge
• CI/CD
• Staging/Production
• Packの仕組みがあることで、上記がより一層実現しやすく
なっている
• 環境の再構築が簡単
• 必要な物は全てgitにあるので、gitから取ってくれば良いだけ
• 面倒くさいエクスポート・インポート等は不要
42

• 開発が活発でコミュニティもうまく形成されている
• 四半期に1回のバージョンアップ
• Pull Requestを広く受け付けている
• Slackが活発
• 開発者やプロダクトマネージャが普通にいて、直接やり取りす
ることが出来る
• 開発元以外の「第三者」がたくさんいて、何か書くと大抵みん
なが助けてくれる
• そこそこ学習コストは高い
• 簡単に出来る…と言いつつ、再利用性高く書くには
Workflow/Actionの設計がキモ
• こまいところで引っかかる
• 特にJinja周り
43

• システム全体のアーキテクチャの見通しがよくなる
• StackStormをコアに置き、各システムの連携はst2の
Workflowで実装する、というルールで統一出来ている
• 見るべき場所はPackとWorkflow → 探しやすい
• YAML → 読みやすい
• Workflowは何でも出来る
• 汚いものはWorkflowに押し込む
• Open Sourceであるということ
• いざというときには自分で何とかする、という選択肢がある
• 商用サポートがある
• 必要な人には必要
44

StackStorm 運用関連Tips
• バージョンアップについて
• 比較的頻繁に行われるが、追うのは簡単
• Content Rollover Upgrade*がいつでも出来る状態を維持し
ておく
• 過去の実行情報が全て消えるため、そうなっても良いようなア
プリケーション設計にしておくことが大事
• 永続化が必要なデータはStackStorm内(st2kv)に保存しない
• JPNAPでは普通にバージョンアップを繰り返していて、これま
で失敗したことは一度もない
• High Availability構成
• そもそも可能？ ⇒ 出来る。公式にリファレンスあり
• 構成が複雑になるので必要性に応じてやるかどうか判断する
• JPNAPではやってない
• 公式Helm chartによるKubernetesへのデプロイも可能(β)
45
https://docs.stackstorm.com/install/upgrades.html#content-roll-over

• StackStorm自体の正常性監視・メトリック収集
• プロセスについては現時点であまり良い方法が無いので、と
りあえず愚直に各プロセスが上がっているかを見る
• 各種メトリックはstatsd形式で取得が可能
• Prometheusはstatsd_exporterを経由させれば何とかなる
• RabbitMQがおかしくなって動かなくなる、という事例が
多々あるようなので、これの監視をしたほうが良い
• ロギング
• *.audit.logに「誰が」「何をしたか」の情報が出るので、こ
れはちゃんととっておく
• デフォルトで全てJSON形式で出力されるので、最近のログ収
集フレームワーク・アプリなら特に問題にならない
• 目grepはとても厳しい
46

• ユーザー認証のLDAP統合
• 有料版(EWC: Extreme Workflow Composer)とコミュニ
ティ版(Open Source)の二種類ある
• ユーザー認証をしたいだけなら、コミュニティ版で問題なし
• RBACが必要であれば、EWCを購入する必要あり
• ロールによって実行できるWorkflowを分ける、とか
• JPNAPではオープンソース版を使用
47

StackStorm その他のTips
• どのワークフローエンジンを採用すべきか？
• 現状、選択肢はmistral-v2とorquestaの2種類
• 今から始めるならorquestaで書いたほうが良い
• mistralは今年中にdeprecatedとなる予定
• Ubuntu 18.04のパッケージから既に非サポート
• orquestaは未だRCの状態だが、もうすぐ出るst2 3.0でGA
• mistralは何か問題があった時にdebugが困難、修正も困難
• 一方、orquestaはStackStormの開発元が実装しているため、
非常にシームレス
• mistralはPostgreSQLが必要
• 依存コンポーネントは少ないほうが良い
• mistralは非ユニコード文字をサポートしない
• 日本語を含むものは扱えない
• orquestaでしか出来ないことがある
48

StackStormの始め方
49
$ git clone git@github.com:stackstorm/st2-docker.git
$ cd st2-docker
$ make env
$ cat env/stackstorm.env
# Web GUIで必要なのでパスワードをメモる
# 適当なものに書き換えてもよい
$ docker-compose up –d
# Web GUIにアクセスする
$ open https://localhost:443
# コンソールを使う
$ docker-compose exec stackstorm bash
(container)$ st2 action list –p core
(container)$ st2 run core.local cmd=date

50
$ cd packs.dev
$ git clone https://github.com/shusugmt/st2-pack-examples
> examples
(container)$ st2 run packs.load packs=examples
(container)$ st2 action list –p examples
(container)$ st2 run examples.orquesta-sequential
(container)$ st2 execution list
(container)$ st2 execution get
(container)$ st2 run –a examples.orquesta-sequential
(container)$ st2 execution tail

51
$ pwd
/path/to/st2-docker/packs.dev
$ mkdir your-pack
$ cd your-pack
$ cp ../examples/pack.yaml .
$ vim pack.yaml
# nameを”your-pack”に変更する
$ mkdir –p actions/workflows
$ vim actions/action1.meta.yaml
$ vim actions/workflow1.meta.yaml
$ vim actions/workflows/workflow1.yaml
(container)$ st2 run packs.load packs=your-pack
(container)$ st2 run your-pack.action1
(container)$ st2 run your-pack.workflow1

• StackStormの環境をとりあえず立ち上げる
• vagrant-st2
• st2-docker
• (oneline installer)
• Tutorials
• (実はあまりいいものが無いです…)
• https://github.com/StackStorm/st2-
docker/blob/master/docs/tutorial.md
• 公式ドキュメント
• https://docs.stackstorm.com
• Workflow examples
• https://github.com/stackstorm/st2/tree/master/contrib/examples
• Community Slack
• https://stackstorm.com/community-signup
52

おまけ：ネットワーク機器はどうする？
• 1. StackStorm ExchangeにあるIntegration Packを使う
• 1-a. 他の汎用ライブラリを経由
• Napalm
• SaltStack
• Ansible
• 1-b. 直接機器を扱うタイプ
• acos (A10)
• EXOS, vdx, vdx_vtep, Network Essentials (Extreme)
• 2. 自分で実装して、それを呼び出すAutomation Packを作る
53

StackStormを活用した運用自動化の実践

More Related Content

What's hot

Similar to StackStormを活用した運用自動化の実践

StackStormを活用した運用自動化の実践