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

StackStorm勉強会に参加&発表してきました

9月13日に行われたStackStorm勉強会に参加&発表してきました。
感想や補足について書き記しておきます。

今年の春頃はStackStormで検索しても日本語ではバンド名/芸名/アルバムなどの作品名しかヒットせずほとんど情報が無かったので、今回100人以上の方が申し込まれたというのは驚きというか感慨というか数ヶ月での変化の大きさを感じました。

connpass.com

私がStackStorm(以下st2と略す場合もあります)を知ったのは去年の春頃です。
今年の年明けくらいから懇親会やLTの場で何度か紹介していたのがきっかけで今回発表の機会をいただきました。
というわけで、内容はこれまでのLTの総まとめをしつつ、これからst2を触る人への
励ましと期待と地雷案内(?)といった感じにしました。

speakerdeck.com
#スライドの色もst2っぽいオレンジベースにしてみました

補足1

HA構成ガイドの図なども出したのでかなり大がかりな仕組みという印象を与えたかもしれません。まあたしかに小さくはないですが、最近のGitLab Omnibusと比べれば見通しやすいレベルだと思います。
以前qpstudyでLTした際に「MongoDBにはヒストリーログやauditが入ります」と言ったところ2つ後のLTで@kuwa_twさんが「Mongoにログ入れんなっつってんだろ」とスライドで叫んでいて大変忍びなかったです。あ、あの、いわゆるログメッセージはテキストに落ちますのでどうか..

補足2

st2はつなぎ役というか裏方的なソフトウェアなので、いろんなものと比較されがちです。発表内で紹介したように公式ブログにも比較記事が多くあります。
ということで、初めてのst2勉強会なのでst2に集中した方が良いかなとも思いましたが、これからst2を使うみなさまも言われるであろう比較論にも触れておきました。

補足3

入力->処理->出力のところで「Northbound API / Southbound API」の表現もしたかったのですが当日言いそびれた気がします。系/システムの捉え方として補足しておきます。

補足4

私の立場は「あまりスクリプト作成が得意でない運用エンジニア、またはiRuleもちょっと苦手なネットワークエンジニアのチームにおいてどうやってスクリプト化を質を保って進めていくか」という問題意識がベースにあります。
Ansible等もmoduleを使ってフレームワークとして活かすことで、シェルスクリプトで起きがちな問題(例: ヌルい正規表現によるバグ、ムラのあるエラー処理)を自然と防ぐのに役立つ素晴らしいツールだと思います。
単体タスクを超えたワークフロー的な処理ではst2が同様にフレームワークとして分岐-合流処理や変数引き渡しといった部分を整理できそう、というところで活かしたいと思っています。

....という問題意識がステ猫さんの2年前のブログにすでに整理して書かれていたりします。
d.hatena.ne.jp

補足5

以前NetOpsCodingでLTした時に、コメントツイをいただきました。


まったくご指摘の通りで、enterpriseBWCはワークフローのIDE的なエディタとして便利ですが、操作系の標準GUIの方はまだイマイチなところもありますし、あまり標準GUIには期待せずよくできているst2コマンドで行うのが良いと思います。

感想

まだまだこれからのソフトウェアだよね、という感はありつつも多様な話題で登壇されたみなさまとcuriousなご参加のみなさまで面白い勉強会だったと思います。私がひときわ泥臭い発表内容だった感じなのがかなり心配ですが。

拡張Packが豊富なこともあり、利用シーンや重視する機能、トラブルポイントが個々に異なったりすることも予想されますが(Communty Slackでも話題論点が様々です)、st2を通して多くの人が集まってディスカッションしたり課題解決のヒントを得たりする場になると良いなと思います。
第2回が行われたら、ちゃんとした話はいったん出し切ったのでピザが届く系のネタでLTしようと思います。

そう言えばブロケードさん9月1日のOSC.Enterpriseに出展したら良かったのにとも思ったり。

番外

今回も熊本焼酎を差し入れしました。
www.tsuruya-dept.co.jp

手元にはまだおいしい焼酎がありますので、引き続き
 インフラや運用系
 && 懇親会に焼酎持ち込み可
 && LTでツールネタ可
というイベントやディスカッションの情報を求めています。

自分用メモ:Monitorama 2016の資料リンク

Monitorama 2016 PDX


開幕したMonitoramaが期待以上の面白さです。
動画はアーカイブ公開されると思いますが、
ひとまず資料などへのリンクを随時まとめておきます。

Day2

Scaling Pinterest's Monitoring
http://www.slideshare.net/BrianOverstreet1/scaling-pinterests-monitoring


What Your Javascript Does When You're Not Around


CHICKEN and WAFFLES: Identifying and Handling Malice


Fake it Til You Make It


5 Lines I Couldn't Draw
http://www.slideshare.net/librato/five-lines-i-could-not-draw


Everything is Broken


Metrics are for Chumps - Understanding and overcoming the roadblocks to implementing instrumentation