Empowered by expect

希望は体力

Monitorama2018のスライドへのリンク集(更新中)

先週はMonitoramaでした。今年も名言名スライドが生まれました。
ひとまずタイムテーブルに沿って公開された資料へのリンクを集めていきます。

Day1

・Optimizing for Learning
Logan McDonald

https://speakerdeck.com/loganmeetsworld/optimizing-for-learning?slide=1

・Serverless and CatOps: Balancing trade-offs in operations and instrumentation
Pam Selle

https://thewebivore.com/serverless-and-catops-slides/

・Mentoring Metrics Engineers: How to Grow and Empower Your Own Monitoring Experts
Zach Musgrave, Angelo Licastro



・The Power of Storytelling
Dawn Parzych



・Principia SLOdica - A Treatise on the Metrology of Service Level Objectives
Jamie Wilkinson



・On-call Simulator! - Building an interactive game for teaching incident response
Franka Schmidt



・Observability: the Hard Parts
Peter Bourgon

https://peter.bourgon.org/observability-the-hard-parts/

・Warning: This Talk Contains Content Known to the State of California to Reduce Alert Fatigue
Aditya Mukerjee

https://speakerdeck.com/chimeracoder/warning-this-talk-contains-content-known-to-the-state-of-california-to-reduce-alert-fatigue?slide=1

・Monitory Report: I Have Seen Your Observability Future. You Can Choose a Better One.
Ian Bennett


Day2

・Want to solve Over-Monitoring and Alert Fatigue? Create the right incentives!
Kishore Jalleda


SRECon https://www.usenix.org/conference/srecon17europe/program/presentation/jalleda

・Next-Generation Observability for Next-Generation Data: Video, Sensors, Telemetry
Peter Bailis



・Coordination through community: A swarm of friendly slack bots to improve knowledge sharing
Aruna Sankaranarayanan



・Automate Your Context
Andy Domeier

https://www.youtube.com/watch?v=5vbqwTXSvjY


・Slack in the Age of Prometheus
George Luong



Sparky the fire dog: incident response as code
Tapasweni Pathak



・Reclaim your Time: Automating Canary Analysis
Megan Kanne

https://speakerdeck.com/megankanne/reclaim-your-time-automating-canary-analysis?slide=1

Lightning Talks



Day3

・Achieving Google-levels of Observability into your Application with OpenCensus
Morgan McLean



・The present and future of Serverless observability
Yan Cui

https://www.slideshare.net/theburningmonk/the-present-and-future-of-serverless-observability-100983842

・Putting billions of timeseries to work at Uber with autonomous monitoring
Prateek Rungta



・Building Monitoring tools when you don't own applications or infrastructure
Mercedes Coyle

https://www.slideshare.net/MercedesCoyle/building-open-source-monitoring-tools


・Autoscaling Containers... with Math
Allan Espinosa


KubeCon2016 http://schd.ws/hosted_files/cnkc16/8c/espinosa-autoscaling-presentation.pdf

・Assisted Remediation: By trying to build an autoremediation system, we realized we never actually wanted one
Kale Stedman



・Security through Observability
Dave Cadwallader


blog https://www.honeycomb.io/blog/2018/02/security-through-observability/

・How to include Whistler, Kate Libby, and appreciate that our differences make our teams better.
Beth Cornils



Posts

http://johan.org.uk/sysadmin/blog/2018/06/06/monitorama-2018-pdx-day-1/

https://hackernoon.com/highlights-of-monitorama-pdx-day-1-d07ed6dc816f

https://github.com/joncav/monitorama-pdx2018-notes

https://github.com/sohonet/monitorama2018

Tech Night @ Shiodome # 8 に行ってきました

f:id:w4yh:20170329213053j:plain
※資料が公開されたら後日アップデートします

techsio.connpass.com

StackStorm 勉強会としては4回目の位置付けでいいんですかね。
汐留のステキな会場と撮影機材の中で行われました。ソフトバンク様、ありがとうございます!

今回も興味深い発表連発でした。それぞれの用途を踏まえた具体的なお話で、かつ「なぜStackStormを選んだか」にも触れていたのが印象的でした。
ツールとして何と競合する位置付けなのか明確になって、使いどころやストロングポイントが実感されるようになってきた、ということでしょうか。

明日からできる、st2のActionの作り方 by @_manji0 さん

speakerdeck.com

中級者?くらいをターゲットにした自作 Action ガイドのお話でした。
定義とインターフェース情報の metadata と実際の処理の action を書けばできるよ!とサンプルを交えて解説していただきました。

Q: 実際にはどんな Action を書いてますか?
A: 仕事ではネットワーク機器操作用のを書いてます
(補足: 以前NTT tech conf #02の展示でもご紹介されてました)

なお10分巻いた原因はこちらのようですw


データの民主化のためにStackStormを活用した事例 by @laclefyoshi さん

www.slideshare.net

事業部をまたいだデータ活用のためにStackStormを採用したという事例のご紹介でした。
解析処理部分のワークフローだとDigdagが思い浮かびますが、Telendとかが使われそうなフェーズも含めた段階に採用した感じでしょうか。こちらの資料でいう Subscription ~ Deliver に相当する部分とのお話でした。
( A Look Under the Hood – How Amazon.com Uses AWS Services for Analytic… )

採用理由として
耐障害性 / Scheduker機能 / リトライも容易 / ワークフローが再利用しやすい / REST APIがある
という点が挙げられました。
REST APIによってEntry pointが統一できるという意味では、第2回勉強会で @shusugmt さんが発表された内容も思い出しました。

Q: StackStorm OSS版では権限分離(RBAC)が無いが公開先を限定したいデータの扱いは?
A: 今回は扱う対象から外した。もしくはマスキングを行うなどデータ側で対応

3万台のリスクから会社を守る。st2で24時間リモートワイプ by 森 さん

www.slideshare.net

自動化すると人力と違って すぐ | 深夜でも休日でも | 多数でも 処理できますからね。

採用理由には
学習コストが低そう / 様々なサービスとの連携機能
が挙げられました。でもRedmineとの連携部分は独自開発、というのもすごい。

Q: Google SpreadSheetからは更新された内容だけ取得できるのか?
A: JSON形式で毎回全部読んでいる。最終行番号を見て差分のところだけ拾うようにしている

Q: 自動化したことによって他の人の証明書を無効化する悪用もできるのでは?
A: 悪意の無い証明書ID間違いでも、自動化する前から起こりうるので....

Q: RedmineのPluginはぜひ StackStorm Exchange に公開を!

NW機器・サーバ機器の設定自働化に向けたst2機能の活用案 by 福田 さん

www.slideshare.net


NW工事の作業をStackStormのワークフローで流す際に pause | resume で停止をかける方法と tips についてデモを交えての発表でした。
StackStorm 2.4で導入された機能です。
What's This? StackStorm 2.4 Already? - StackStorm

スライド中で多数の Action と 子Workflow を持った大きなワークフローが図示されましたが、実際にあのような大きさのワークフローを運用されているのでしょうか。キニナル

参考: 発表でも触れられましたが、あらかじめ予定されていてワークフローに組み込めるシェルスクリプトで言う read みたいな待機は StackStorm 2.5で入ったinquiriesで実現できます。
stackstorm.com

st2-docker ことはじめ by @shusugmt さん

www.slideshare.net

StackStormはコンポーネントが多く割と大きな仕組みですが、導入を容易にするために Ansible とか Vagrant、Docker イメージなどの方式が用意されています。
st2-docker は docker-composeで簡単に起動できる、けどデータストア系は別コンテナで用意する必要があるとのこと。まあそうですよねー
とは言え小~中規模であれば十分運用できる感じで、また helm chart も目下PRが出ているようで StackStorm のコンテナ化も進みそうです。

他のツールとかで Kubernetes 基盤をすでに持っているならいいですが、新規に基盤を立てるとなるとパーシステントボリュームをどうするかが悩みどころです。自分も Docker 環境で使ってた Open vStorage 部分を k8s でどうするかまだ決めかねてます。

蛇足ですが、去年私が内部で行った発表で「StackStorm は様々なツールとの連携に対応していて、ヘテロな環境で強みを発揮する。では世界が例えば kubernetes で統一されたらどうなるだろう」という考察をしました。この辺議論してみたいです。
f:id:w4yh:20180530063413j:plain

StackStorm アップデート&ロードマップ by @LindsayHill さん

www.slideshare.net

スケジュール
2018/06 StackStorm 2.8) Python3化、WebUI刷新、k8s HA対応、メトリクス framework、新ワークフローエンジン Orchestra(beta)
2018/08 2.9
2018/10 3.0) ChatOps RBAC、Orchestra(GA)

WebUI: また色が変わるようですw 左右の比率が変わって、右側の詳細表示やパラメータフォームの欄が大きくなる事が強調されてました。うんうん

SupportOS: Ubuntu18.04 が出て RHEL8 も見えてきたので Ubuntu 14.04 や RHEL6 の対応は終わる予定とのことです。「でもまだ時間あるから。それまでには移行できるよな?」というメッセージでした。 アッハイ

Orchestra: 独自に新たなワークフローエンジンを用意するとのことです。「Mistral は非常に良いが OpenStack のプロジェクトなので開発ペースや優先事項もあっちで決まる。独自にやりたい。ちなみに PostgreSQL は不要になる」という意欲的なメッセージでした。なんか、Nutanix が独自ハイパーバイザー(現AHV)を発表した時に似てる空気感です。
....代わりにどれかワークフローエンジンが外れるのかな....CloudSlangも使ってるけどピンチかな....Javaだしなあ.... st2ctl で管理してないしなあ....

買収が続いて不透明な部分もありましたが、StackStorm チームは順調かつ意欲的に開発も進められているようで安心しました。

StackStormユーザ会からのお知らせ by @user_localhost さん


ユーザー会サイト https://stackstorm.jp/ の告知&ブログ執筆の募集
ドキュメント日本語訳のご協力募集

をいつもよりゆっくりめのトークでご案内いただきました。

5月29日*総括

全体的に慌ただしい感じになってしまったのが残念でした。テクシオで StackStorm は2回目なのでイントロな話は無しでしたがそこは大丈夫だと信じてます。
なぜか日本ではネットワーク機器を対象とした事例が多いので、今回のデータ解析基盤のお話は非常に良かったです。

「使ってみるぞー」「セットアップしてから放置してたけど Action 書いて使っていくぞー」という気持ちになった方がたくさんいるといいなあ、と思います。
次回は CloudSlang 追悼 LT かなあ

(2018/06/03 福田さんの発表資料へのリンクを追加しました)
(2018/06/06 森さんの発表資料へのリンクを追加しました)

2017年ふりかえり

年末らしく一年のふりかえりエントリをざっと書きます。

今年残念だったもの

ついった

今年の初めは「ノーリターンでも課金していいぞ」という気持ちでしたが、一連の凍結騒動でちょっと引いた感があります。発言に対して法律や公序良俗による規制をかけるのは当然としてアカウント自体を規制せずに済む方向だと嬉しいのですが。
凍結騒動の時には付随して"人は遠くの出来事と身近に起きたことでは反応が変わるものだなあ"、というのも観測しました。自分自身も遠く安全地帯からスカした発言を気取らないように気をつけねば、と感じさせられました。

Questetra

ダウンロード版が4月で公開終了してしまいました。高機能さと簡易さを兼ね備えたとても優れたワークフローツールなので残念でした。SaaS版が引き続き進化を続けているので、豊富なサンプルと今後の連携サービスの拡大に期待です。

今年なぜか行けなかったイベント

rancher meetup

去年は割と参加できていましたが、今年は日程かぶりが調整できずあまり参加できませんでした。第一回がコンテナSIGとかぶった伝統かもしれませんが来年はもうちょっと参加したいです。

Nutanix Community meetup

こちらはなぜか当日になると障害が起きたり体調に問題が起きたりでほぼ全滅でした。たまたまだと思いますが来年は参加してチョコレートのお供えもしたいです(?)。

今年印象的だったイベント

builderscon

builderscon tokyo 2017 - Aug 3, 4, 5 2017

チケットゲットできました。王道なものも道を外れたものも道を引き返すものも、どのお話も突き詰めた感にあふれていて技術的な刺激が非常に強いイベントでした。次回もチケットを買い逃さないようにしなければです。

Zulip & PGroonga Night

Zulip & PGroonga Night - connpass

2年前くらいからチームで使っているZulip。まさか日本で特化したイベントが行われるとは。開発者Gregさん、PGroongaとの統合で日本語検索環境をぐっと改善してくれた須藤さんによるコアなお話が聞けてとても良かったです。今年はZulipがコミュニティ活動も活発になり、開発の勢いもぐっと上がった感があります。

Internetweek

H3 運用自動化ハンズオン ~StackStormで実践するインフラ運用革命~ - IW2017

推しの卒業公演の翌日という最悪な日程でしたがStackStormハンズオンセッションでTAをしました。一年ちょいでこんなに興味を持つ人が増えたのか、と感慨深くまた期待を持つことができるセッションでした。使う人が増えて、使用例やつらみがどんどん発表&議論されていくといいなあ。

今年良かった記事

Web+DB vol.98

WEB+DB PRESS Vol.98|技術評論社

特集2の"これからはじめるDocker"が印象的でした。yak shavingとも言える部分ですが、sshの鍵登録やパスワード無しのsudoなどについてしっかり記されていて"ありそうで無かった"感がありました。初心者向けにも多く説明の場数を踏んでいるエバンジェリストの方々らしい優れた記事だったと思います。

今年便利だったツール

holo2

Holo - Minimalistic Configuration Management

ほぼ一人で開発されていたHolo-cmに救世主が現れ、大幅に改善が行われた2.0がリリースされました。これは良いです。holo scan -> holo applyの流れが固まり非常にすっきりしました。Holo 1系を使っている人がもしいたら必ず2系を試して欲しいです。

GitLab

どんどん高機能化が進むGitLabですが9.台からはどっぷり依存した使い方をするようになりました。今後もCEを見捨てずにお願いしたいです。そう言えばOctotree的なものを統合する話はどうなったんでしょう。

今年印象的だったコンテンツ

スキマから聴こえてくるラジオスペシャル 『AIか、人間か~ラジオパーソナリティの未来~』

スキマから聴こえてくるラジオスペシャル 『AIか、人間か~ラジオパーソナリティの未来~』|JFN PARK

AIについて技術的な面ではなく、生活への影響や言葉、コミュニケーションの切り口で迫った番組。情報としての言葉とコミュニケーションとしての言葉との境目を考えさせられました。りんなとじゃれたりする緩さと、いのちの電話の理事長さんへのインタビューなどの真摯さと、すべてが一人語りで投げかけられてくるラジオとしての迫力に満ちた番組でした。

{code}のreading-suggest channel (Slack)

Slackで読んでいるチャンネルも増えてきましたが、流量は少ないながらも面白い記事が流れてくるこのチャンネルは良い情報源でした。最近だとkubeconの注目セッションなんかも流れていました。

2018年期待するもの

Podcastイベント

rebuildが200回に迫っていたり、engineer meeting podcastが100回までにカードゲームができあがらなかったり、年明けにはPodcast系のイベントがあるんじゃないかなと期待しています。

レジリエンスエンジニアリング/Safety-II

論説自体は以前からあったそうですが、去年他業界の知り合いから聞いて知りNHKの番組きっかけで学び始めて、今年というか最近になって社内発表したりついったで言及したところ反響があったテーマです。これまでとは考え方からがらっと変えることを求められるので理解も実践への落とし込みも大変なテーマですが、引き続き学んで発信していきたいと思います。

第10回ペパボテックカンファレンス が楽しかった

第10回ペパボテックカンファレンスに、推しの生誕祭に外れた想いを込めて行ってきました。
講演も懇親会もとても楽しく得るものもありました。ひとまず備忘的な列挙。

  • 気象系の研究やってたので時系列の将来予想は大好物。毎時40分にやる処理はナッジング的な物に感じたので重み付けとかで工夫されてたら聞いてみたいです。
  • MAASはおぷすた系イベントでMINDさんが発表された時から興味ありました。ベアメタルは以前 Genesis / Collins を使っていて特に Collins 超有能だったのですがちょっと最近開発が....。MAAS触ってみたいです。と言いつつ懇親会でtnmt様に RackHD よさげと吹聴してきました。
  • 排他制御のチューニングはすごく待ち行列の授業感があって思わずトークンリングとか思い出してました。最初のretry intervalで大幅に改善してて驚きでした。
  • Veetaは必要から生まれた感があって、かつ分かりやすくてよさげでした。

以下は懇親会での話。

  • 書籍"リナックスの革命"が良いらしい
  • 火災発生時はエレベーターが止まるので階段で待避らしい
  • 「お嫁さんの実家が佐世保」とか言うと福岡にロックオンされるらしい
  • MAASは思ってたより3倍は良いらしい
  • 全職種大募集中らしい

Let's EncryptクライアントAcmeFetch使ってみた

※※後ほど簡易図を追加します※※

今年に入ってからはLet's EncryptのクライアントにすべてAcmeFetchを使っています。

github.com

MRTGでおなじみTobiさん作ということで使っています。
Ver. 0.6.1でnginxなど用の中間証明書一体型の出力にも対応したのでご紹介します。

私の見立てで特徴は以下のような点です。
・シンプル
・証明書の取得、更新自体にはroot権限不要
・cfg設定でSNIも指定可能
・実行時に余計なアップデートが走らない
・実行時にCDをおねだりされない :-P

以下、利用手順を示します。

インストール

wget https://github.com/oetiker/AcmeFetch/releases/download/v0.6.2/acmefetch-0.6.2.tar.gz
tar xvf acmefetch-0.6.2.tar.gz
cd acmefetch-0.6.2
./configure --prefix=/opt/local/acmefetch
make
sudo make install

設定

cd /opt/local/acmefetch/etc
mv acmefetch.cfg.dist acmefetch.cfg
vi acmefetch.cfg

cfgファイルの内容はこのようになります。

{
    "GENERAL": {
        "ACMEstaging": "acme-staging.api.letsencrypt.org",
        "ACMEservice": "acme-v01.api.letsencrypt.org",
        "accountKeyPath": "/etc/ssl/private/letsencryptAccountKey.key"
    },
    "CERTS": [
        {
            "certOutput": "/etc/ssl/certs/testCert.pem",
            "certFormat": "PEM",
            "keyOutput": "/etc/ssl/private/testCert.key",
            "keyFormat": "PEM",
            "chainOutput": "/etc/ssl/certs/testCertChain.pem",
            "chainrmaFot": "PEM",
            "commonName": "hoge.example.com",
            "SITES": {
                "hoge.example.com": {
                    "challengeHandler": "SimpleSSH",
                    "challengeConfig": {
                        "www_root": "/var/www/html/",
                        "ssh_host": "root@127.0.0.1"
                    }
                }
            }
        }
    ]
}

こちらはapache httpdサーバー環境で、AcmeFetchをlocalのroot権限で実行する想定の内容です。
証明書を配置する権限と、http-01のテストファイルを設置する権限が必要なのでそれぞれ書き込み権限を設定してください。
またssh_hostの部分は鍵認証でパスワード無しのログインができるようにauthorized_keysへの登録も必要です。

SITESの部分で証明書を取得するそれぞれのFQDNに関する設定を行います。SNIとして登録するFQDN用の設定はSITES部分を追加して書きます。
www_root以下に .well-known/acme-challenge というディレクトリが作成され、その中にhttp-01のチャレンジID名のファイルが作成されます。

nginx環境の場合は、cfgから chainOutput および chainrmaFot の項目を削除します。
すると、証明書と中間証明書が一体となった形式で certOutput が生成されます。

cfgができたら実行します。

/opt/local/acmefetch/bin/acmefetch --cfg=/opt/local/acmefetch/etc/acmefetch.cfg
(以下は出力例)
/tmp/yRAb7m8bc2.cfgGenerating a 2048 bit RSA private key
................................................+++
...................................................................................................................................+++
writing new private key to '/etc/ssl/private/testCert.key.7302'
-----

更新の時は --force オプションも指定します。

/opt/local/acmefetch/bin/acmefetch --cfg=/opt/local/acmefetch/etc/acmefetch.cfg --force

cronで自動実行する場合は、 && systemctl reload nginx などで読み込み反映も行う必要があります。

MRTG同様(ややパースしにくいですが)簡潔なcfgで、動作も分かりやすく使いやすいです。
開発も継続的に行われているので、Let's Encryptクライアントをお探しの方や、お使いのクライアントに(余計なアップデートが同時に行われるなど)ご不満のある方はお試しになってはいかがでしょうか。

StackStorm勉強会 第2回に行ってきました

※発表内のカット部分が判明したり資料が公開されたりした場合は後ほど修正します

3月23日に行われたStackStorm勉強会 第2回に行ってきました。第1回から約半年、他のイベントでもStackStormの名前を見る機会が出てきたので広まりを感じられるかな...と楽しみにしていました。

connpass.com

"Event-driven automation, DevOps way" by Dmitri Zimine氏

ついにご本人に会えました。背も高くて足も長い方でした。
発表内容は、過去のこちらのプレゼンから技術的に細かい部分を省いた感じだったかなと思います。

www.slideshare.net

(4/1追記。資料公開されました)

www.slideshare.net


(まさかDmitriさんから「日本でStackStormを検索すると芸能的な情報が出てくる」ネタを聞くとは..
cf. http://w4yh.hatenablog.com/entry/2016/09/22/104100 )

他のツールとの違いについての話もあり、「DevOpsに最適である」ことが強調されていました。過去のツールやプロプライエタリなソフトウェアと比較して、コードベースのスピーディーな運用を可能とするインターフェースと拡張性で勝る、という説明はなるほどと感じました。

最後にGitHub Starつけろよ、という念押しもありましたので参加されたみなさまはお忘れなく。

Q&A

Q.ST2と一緒に使われることが多いソフトウェアは?
A.モニタリングソフトが代表(Zabbix, Sensu, Nagios, NewRelic)
OSSに限らず、商用ソフトやクラウドサービスも多い(IaaS系に限らず、PagerDutyとか)
補足.でもZabbixのPackはまだ無いですけどね

Q.ワークフローの例がたくさんあると良いのだがそんなサイトはあるか
A.まとまったものは無いが、公式Docのチュートリアルの中でも紹介している。最近はNetworkの例を2つ公開した

Q.商用のBWC(brocade Workflow Conmposer)の売りは?
A.サポートが付くこと、ビジュアル的なワークフロー作成画面が付くことなど

if 自動化するなら then StackStormを使おう! by 小島さん

200機種、30000台を超える規模の社内ネットワーク運用をどう効率化していくか、というチャレンジの中でStackStormを使うようになったというお話でした。

www.slideshare.net


ネットワークを対象とした、監視検知時の初動対応の自動化を実装してみたら数日でできた、とのことでしたがそこまでに至る

  • 業務のコード化
  • コード化の際に行われたであろう、業務のフローチャート的な整理
  • Puppet/Ansibleといった個別作業のツール実装

が行われていたことも大きく寄与していたんだろうなと思います。

最後に「思うこと」として挙げられた点はまったく同意でした。

  • 自動化を前提としたワークフローを再定義する必要がある
  • syslogベースの場合はベンダー間の差を吸収するべくある程度の標準化や自動化対象の明確化が必要
  • 自動化に適した構成管理も必要

運用作業の手順書を見直すと「ログを見て問題無いことを確認する」というゆるふわなものがあって自動化に落とし込みにくい、とかは私も経験しました。私は単体テスト/サービス可用テストが通ればOK、に切り替えましたがネットワークが大規模で切り分けが難しい場合はログをきちんと拾っていく方が明確かもですね。
構成管理についても、ohai的なものをどこまで詳細にどう取得するかは課題になりがちですね。自動収集に変えるためにndp/cdpを有効にしてみたり、それがVxLANを超えられなくて困ったり、とか。OpenStackのPandamanプロジェクトも動き止まってそうですし、アセットマネジメントはさらなるツールが求められる分野なのかもしれません。(逆に、作っては壊す時代だからアセット管理にこだわるなということかもしれません)

自動化/StackStorm取組み事例 by 杉本さん

本家Slackでも発言をお見かけする杉本さんによる、IXでStackStormを導入したお話でした。

www.slideshare.net

主にユーザー加入時の開通作業の自動化が紹介され、ExcelからDBへ、手打ちコマンドからexpectスクリプトへ、といった取り組みを進めていくなかで、各ステップの自動化ツール化はできるがそれをつなぐものが無い、というところへStackStormがうまくはまった、という流れでした。現在はcurlを用いたWebhook送信で開始する仕組みになっているとのこと。

導入した利点として挙げられたのは以下。

  • アーキテクチャ全体の見通しが良くなった
  • 開発効率が向上した
  • 将来的な機能拡張が考えやすくなった

さらに感想やTipsとして

  • 学習コストは高め。特にPackを自作する場合
  • バージョンアップは早いが対応はしやすい
  • コミュニティがオープンで活発

を挙げられました。0.12あたりで失敗して以降いつも作り直していたのでバージョンアップはやってなかったのですが、Upgrade Guide通りで行けるとのことでしたので次はやってみようと思います。

今後の取り組みとして

  • アラート対応の自動化
  • ネットワーク機器に対する操作のAction化
  • StackStorm自体の運用

を考えているとのお話でした。ST2自体も大きな仕組みなので運用は持ち寄りでベストプラクティス考えていきたいですね。

Q&Aで同時実行の制御について確認がありましたが、こちらのPolicy action.concurrencyを使っているとのことでした。
https://docs.stackstorm.com/reference/policies.html

StackStormを用いたネットワーク機器の制御 by 北川さん(社会人一年目!)

納品時の初期設定作業の自動化について、デモを交えてお話いただきました。

www.slideshare.net

Excel Packを用いてパラメータを読み込んで、設定テンプレート/Jinja2とAnsible PackでNW機器への設定投入を行うという流れで、ほぼ標準モジュールを採用されていたので理解しやすいユースケースでした。

Excelから読み込む、という所がsfunaiさんのOpenPIE(https://github.com/oss-laboratries/OpenPIE)を彷彿とさせました。デモでは割とシンプルなシートでしたが、実際に使われているシートがどういうものなのか興味ありました。
....その、なんというか....人はなぜパラメーターシートに勝手に列を追加したりパラメータ欄に日本語コメントをつけたりするのだろうか(過去にExcelをパースする仕組みで破綻した人)。
最後に触れられていましたが、Webフォームなど制約をかけやすい形でinputデータを得たほうが入力加工はしやすい気がします。

懇親会でのトーク

私は可用性はハイパーバイザーに任せると割り切ったチキンです。来週のohtamaさんのお話で詳しく訊けるのかな..

  • 踏み台を経由する環境

~stanley/.ssh/configがすごいことになるのは避けたいですよね....

  • Workflow途中での失敗時や再実行

JP1のようなジョブマネージャーが活躍する領域ですね。私はWorkflowを小さめに分けるのが好きですが、retry-continueの紹介がありました
Mistral + YAQL — StackStorm 2.2.1 documentation

  • スーツの人が多いですね

確かに。日本で知られるようになったのはBrocadeさんに買収されてからなので代理店さん含めた商流での広まりに現場技術者の間での広まりが追いついてないんですかね....もしくは商材としての魅力が大きくてそちら側の人が多く集まるのか

  • もっとテッキーな話したいですね

ユーザー会ができるかも?公式ドキュメントと公式ブログがかなり充実しているので、個人的にはそれらの読み解き会とか有益ではないかと思います。

  • いただいたロゴのステッカーはもうちょっと小さくて良いと思うのです

f:id:w4yh:20170329213053j:plain

所感

使ってる人増えたなー、と感じられたのが何より良かったです。一年前は全然知られてなかったからなぁ
StackStormはあくまでつなぎ役なので、単体でポンと入れれば何かが解決する類のものではありません。どの発表にも共通していましたが、そこに持っていく前段階としてのワークフローの整理や各作業(Action)のツール化がST2を使う使わないに関わらず大事だな、ということも再確認できました。テスト系の話も訊きたかったかな。
あとActionChainがかなり賢いのでActionChainで済ませている人が多い印象でした。Mistralはもちろん、CloudSlangも運用フローチャートから焼きなおしやすくて楽しいですよ。

開催にご尽力された皆様やスポンサー各社など、みなさま大変有益な機会をありがとうございました!

最後に、最近のDmitriさんの発表スライドへのリンクをご紹介しておきます。

www.slideshare.net

www.slideshare.net

StackStormでBINDのアップデートをtwitterに通知する

注) BINDに関する有益な情報はありません。StackStormのピタゴラ遊び編です

概要: BINDの脆弱性情報が出た際に知らせる仕組みをStackStormで作ってみました

要求: (if)BINDの脆弱性情報が出たら(then)知らせて欲しい

仕様: (if)bind-announce MLに件名がCVE-で始まるメールが配信されたら(then)twitterで@メンションツイートを送る

StackStormのemail packと、twitter pack ... ではなく core.local のシェルコマンドで実装してみます。

しつこい注) StackStormを使う興味の無い方は、bind-announceのメールを携帯に転送すれば良いかと

全体設計

環境: CentOS7 + StackStorm 2.2
   メール: postfix + dovecot
   twitter操作: t(ruby) もしくは twitter gem


今回はピタゴラ遊びなのですべて1台のサーバー上に構築します。メールの確認もlocalhostへのimapなのでtls化は省略します。

f:id:w4yh:20170320193157j:plain

StackStormのTrigger設定

StackStormのemail packをインストールします。

st2 pack install email

設定ファイルを編集します。
/opt/stackstorm/packs/email/config.yaml

---
imap_mailboxes:
  main:
    server: localhost
    port: 143
    username: USERNAME
    password: PASSWORD
    folder: INBOX
    ssl: false
max_attachment_size: 1024
attachment_datastore_ttl: 1800

USERNAMEとPASSWORDは適宜編集してください。
StackStormのemail packはメールの内容に対する条件設定が弱いので、「bind-announce宛に配信された、件名がCVE-で始まる」のような条件指定には他の仕組みを用います。StackStorm勉強会 #1ではSylpheedの仕分けを用いる方法を紹介しましたが、今回は条件に日本語も無いのでprocmailを使ってみます。

メール設定

dovecotの設定

dovecot.conf

protocols = imap pop3 lmtp
listen = *, ::
base_dir = /var/run/dovecot/
login_trusted_networks = 127.0.0.1/32

10-mail.conf

mail_location = maildir:~/Maildir

10-auth.conf

disable_plaintext_auth = no
auth_mechanisms = plain
procmailの条件設定

ヘッダー条件はList-Idも検討しましたが、今回は手抜きでX-Original-Toでマッチさせました。

/home/mluser/.forward

"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #username"

/home/mluser/.procmailrc

LOGFILE=$HOME/procmail.log
MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
LOCKFILE=$HOME/.lockmail

:0 c
*^X-Original-To: bind-announce@lists.isc.org
*^Subject: CVE*
! user2@example.com

Twitter設定

dev.twitter.com でアプリの登録

専用のTwitterアカウント作成し、API操作用にアプリ登録を行います。

https://dev.twitter.com
に作成した専用のアカウントでログインし、上部メニューの[My Apps]へ進みます。

Name, Description, Website の三項目が必須なので入力します。WebsiteはBotの場合はあまり意味が無いので適当で良いと思います。

Twitter Developer Agreementを確認した上で同意のチェックを付けてから[Create your Twitter application]をクリックすることで登録が完了します。
作成したアプリの詳細ページで、まずはツイート書き込みを行う権限を追加します。

[Application Settings] - [Access level]を"Read and Write"に変更します。

次に、"Keys and Access Tokens"のタブでAPI Key情報を入手します。以下の4つの値が必要になります。

  • Consumer Key
  • Consumer Secret
  • Access Token
  • Access Token Secret
CLIツールのセットアップ

今回はruby実装のt (https://github.com/sferik/t) を用います。

gem install t

ツール(t)の認可を行います。最終的にtを使った操作はStackStormから実行するので、以下の認可設定はstanleyアカウントで行います。

t authorize

ブラウザでdev.twitterが立ち上がってきます。(リモートターミナルで行っている場合はX転送でブラウザが上がってきます)
先の手順でアプリの登録をおこなったさいに得た以下の情報を入力します。

Enter your API key:  ここにConsumerKeyを入力
Enter your API secret: ここにはConsumerSecretを入力

すると今度はブラウザ上でtwitterサイトにPINコードが表示されるので、コマンドラインにその数字を入力します。
以上でtが使えるようになりました。アプリの登録情報は /home/stanley/.trcに保存されます。
試しに自分のTwitterアカウント情報を表示してみましょう。

t whois @アプリ登録用に作成したTwitterアカウント

アカウント作成日時やアカウント名/表示名などが出れば成功です。

t update "Hello World"

で新規tweetができることも確認しておきます。

Tweetするスクリプトの作成

Triggerで検知したメールの件名が引数として渡されるので、$@で受け取って軽くエスケープ処理した上で
tを用いてtweetします。ついでに自分への@メンションツイートとします。

/home/stanley/script/tweet_chofuku.sh

#!/bin/bash
# tweet_chouku.sh: This script tweets "cho-fuku" when CVE for BIND has announced."
#                  ST2 trigger: email(imap)
#                  ST" action: shell(core.local)

ARGSUBJ=`printf %q "$@"`

/usr/local/bin/t update "@自分が普段使っているアカウント $ARGSUBJ"

exit

StackStormのRule, Action設定

StackStormのRuleを設定し、該当するメールを受信した後の動きを定義します。
Ruleのyamlファイルは設置ディレクトリに特に規定はありません。

bindcve_to_CLI_twitter.yaml

---
name: 'bindcve_to_CLI_twitter'
description: 'Tweets when CVE on BIND has announced.'
enabled: True
trigger:
  type: email.imap.message

action:
  ref: 'core.local'
  parameters:
cmd: /home/stanley/script/tweet_chofuku.sh {{trigger.subject}}

Rule定義ファイルの中の必須項目や設定項目については公式ドキュメントを参照してください。 https://docs.stackstorm.com/rules.html

一点だけ補足すると、一連の動作の中で変数の参照を行っています。届いたメールの件名をツイートするために、trigger部分で検知したメールが含まれるアウトプットから trigger.subject をaction部分で参照することで件名文字列の受け渡しを行っています。

作成したRuleを登録します。

# st2 rule create bindcve_to_CLI_twitter.yaml

一覧を確認して、以下のような表示があればRuleの作成は完了です。
f:id:w4yh:20170321235809j:plain

動作例


(ちょっと変更して、twitter gemを用いて画像とともにtweetしています)

追加したい処理

  1. ISCのサイトに詳細が出ていたらそのURLもtweetで知らせる
  2. 対象バージョン範囲を抜き出して該当環境の抽出
  3. といった処理をActionではなくWorkflowで流したい

今回使ったファイルはGitHub上にも置いてあります。
github.com