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

第5回ペパボテックカンファレンスに行ってきました

今回は「〜インフラエンジニア大特集〜」という副題が付いているとおりインフラ系のイベントなのですがWeb系な雰囲気満載だった第5回ペパボテックカンファレンスに行ってきました。
pepabo.connpass.com

本篇1 トーク&LT

各発表資料はアップされているので、発表部分は資料リンクとQ&A部分の書き起こしおよびひとことコメントだけで。
発表のフォーマット感があって流れが掴みやすいのがとても印象的でした。
発表されたみなさんが大まかに以下に沿っていました。

  • アジェンダ - 背景経緯 - 問題設定/設計実装 - 結果/効果 - 残課題 - まとめ - 今後 といった構成
  • イメージカラーベースの共通スライドマスター
  • ごせいちょうありがとうございました -> 拍手 がしやすい区切り方
  • 資料公開はSpeakerDeck

発表1 100行あったmod_rewirteを ngx_mrubyで書き換えた話 by buty4649さん

speakerdeck.com
Q&A
Q: apache/mod_rewriteの頃のテストは?
A: テスト環境に設定を入れて人手で確認

Q: Luaでも同じ事ができそうだがmrubyを選んだ理由は?またmod_rewriteよりレビューコストが上がっていないか?
A: Luaでもできるが、matsumotoryさん始め社内の知財的にruby,mrubyが強いので選んだ。元々得意な人が多いのでレビューコストもそれほどではない

Q: パフォーマンス劣化は無かったか
A: ngx_mrubyのwikiの情報ではパフォーマンスはそれほど落ちない。実際abコマンドでやってみてもそれほど劣化は見られなかった

発表2 ペパボのプライベートクラウド "Nyah" その後 / Pepabo's PrivateCloud "Nyah" After That by tnmtさん

speakerdeck.com

Q&A
Q: バックアップ構成は?
A: 現状けっこう課題
  OpenStack上の別インスタンスやOpenStack外の基盤に採っている

Q: OpenStackのバージョンアップ後の切り戻りは?
A: 新バージョンは別途構築して移行しているので実質切り戻しはない

Q: Neutro使うとLinuxでパフォーマンス落ちないか?
A: 現状構成は組めたけどパフォーマンスは細かく見られていない

LT 高集積ホスティングにおけるセキュリティとPHP実行基盤の高速化 by tshpaperさん

speakerdeck.com

下matsumoto-rさんの内容を超高速でご紹介された勢いのある発表でした。
5年ちょっと前くらいに当時のParalellsさんの製品で物理一台に7000ドメインくらい積めるのがありましたが今のハードスペックだと万単位でやってるんですね。


LT インフラエンジニアもCIがしたい by alotofweさん

drone.ioのCIをnested dockerで実施するお話。CIの行き倒れゴミとか経験してるとdrone.ioの良さ嬉しいですよね。CIツールはまだまだ増えていますがインフラで使うときはテスト環境の生成と、単体ではないテストを流せるか/どう流すかがネックというか鍵になる印象です。GitHub Ent.がすでに運用の真ん中に根付いているという前提条件もうらやましくも重要なポイント。
speakerdeck.com

発表3 時代が求めたSTNSと僕 〜夏の日の1986〜 by pyama86さん

AD以外のLDAPは挫折しましたすみません。deploy用の共通アカウント使うならChatからdeployすればいいかなとか(軟弱)。基本認証に対応していたり、api end pointを並べて書けば冗長できたり、使う側に便利なポイントも抑えてあったのが好印象でした。
SSH鍵管理はクッ社さんもいろいろ便利ツール作っていたり、管理の面では新たな課題ですね。
speakerdeck.com

Q&A
Q: 冗長可能な部分は
A: componentのdeployで考慮する必要有り。capistranoとか

LTベンチマークテストやろうぜ by pbmasakiさん

最後の大オチがwwEC2とか同じリソースサイズでもハードの世代によってパフォーマンスに差があるけど見えない部分だから..というIaaSガチャ的な話はありますよね。公開されているベンチマークはレギュレーションの読み解きが大事、というのはおっしゃる通りで刺さりました。個人的な昔話ですが、qmailからpostfixへ移行したら遅くなった、と言われていろいろいじって最終的に/var/spoolをext2にしたという闇経験があります。
speakerdeck.com


LT構成管理ツールを用いたインフラ開発フローの改善 by k_hanazukiさん

・本番環境とテスト環境の差分
マニフェストと実サーバー設定の差分
の検知と撲滅のお話。個人的にはテスト駆動インフラとかエンタープライズアジャイルとかの背景の一つが「本番と同じ環境でテストせよ」だと感じて取り組みを始めたので、ここを一番見張っています。先日のImageMagickのpolicy.xmlファイルとか変更する機会はそうそう無いので、Serverspecテストに即時に組み込まないと忘れ去られていきますからね(アップデートによって不要になった要素もありますが)。究極的にはサーバーに直接sshログインするのか、という話になるかと思います。ポータル&Chat(Slack)という通知共有は鉄板ですが良いですね。
speakerdeck.com



発表2のtnmtさんにはHosting Casual #1でもお世話になったのですが、Serverspec周りの2014年のこの発表資料だけでもリスペクトできます。今日の話題範囲にも関連するので貼っておきます。
speakerdeck.com

それぞれの発表内容は多岐に渡ったのですが、いずれも設定された具体的な課題に対する改善解決が示されていて聞いている私にも「おお、自分もやってみようかな」という思い持たせるような、巻き込む魅力のある発表で非常に有益でした。

トークセッション「ペパボのインフラを読み解く」

sugyさん(東京/EC事業) 以下S
tshpaperさん(福岡/ホスティング事業) 以下T
司会kumanoさん 以下K

K「インフラは幅広くラックやスペースを含めたモノからヒトまで含める範囲で。
  当初ペパボではインフラはGMOグループからホスティングで借りていた。
  それを自前ハウジング、さらにプライベートクラウドNyahへ移行しているが
  ハウジングに移行して自前サーバーが増える時の苦労は?」
S「キッティングやラッキングなどそれまではお願いしていたことを自分たちでやるのは大変だった」
K「福岡はしばらくホスティングでしたがあるプロジェクトで一気に移行した時の苦労は?」
T「ホスティングは自分たちでやってるものでもあるので、できるだけ現地に行かなくて済むようにはしていた」

K「ハウジング当時、自力人力でセットアップしていた頃は一台どのくらいかかっていたか?」
T「ホスティングは一台半日くらい」
S「簡単なもので1日、複雑なものは2-3日+他業務とかで期間的には1週間かかることも」

K「そうやっていると"サーバーを作るのがうまい人"になってしまいがち。
  これではイカン、と2007年頃(mizzyさんが)Puppetを使おうと提案してきた。
  で、今は一台どのくらいかかるか?」
T「1時間もあればできあがる。並列も可能で多いときは十数台並列とか」
S「10分弱から2,30分程度。時間が短いことよりも検証のテストが楽になることや繰り返しが楽になったメリットを大きく感じる」

K「Puppetもちょっとバージョンアップすると動かなかったり問題もあったがここまで来るのに苦労した点は?」
T「mizzyさんが創り出したものを福岡側で引き継いで吸収していた。その後Ver.3系に移るときに難しさはあったが、都度調べて議論して、を経てきたのでメンバーの共有&成長でカバーできている」
S「根付くのが大変だった印象。(自分の意識が低かったかもだが)Puppetは遅いイメージがあったのでShellでいいじゃん感は有った。その後、仮想環境および仮想環境を扱うツールが揃ってきた事でメリットを感じやすくなり意識が高まってきた」
K「秘伝のタレ化していたものがコード化されたのはメリットだと思う」
(ここで会場挙手アンケート。
 構成管理ツールを使ってる人: ほぼ全員
 Puppet 数名、Chef 多い Ansible Chefと同じくらい多い
 itamaeとholoなワタシ)

K「コード化されたことでメリットはあるとして、今何台くらい管理してるか?」
T「VM除いて1000台くらい。VM入れると1100から1200くらい。今集約も行っている」
S「オンプレ150台、クラウド600台くらい」

K「Nyahプライベートクラウドを使うことで構成管理は変わったか?」
S「変わったと思う。ドライバインストールなどが無いので統一しやすく、シンプルになった気がする」

K「そこに携わるインフラエンジニアはどう変わってきたか。開発者がインフラの領域に踏み込んで来られる環境になった。今後インフラエンジニアはどう振る舞っていくのか?」
S「正直要らないなと思う事はある」
K「半分は要らないかなと思ったけど今日の発表のようにインフラエンジニアも逆に開発寄りになってきているのか?」
S「開発寄りに行く人と、より専門的に行く人とありそう」
T「高集約にこだわっているので、必要となるkernelの最適化などより低いところへ行く人とmrubyのようにコードを書いて行く人との道がありそう」

K「実際開発の人たちはインフラに入ってきているか?」
T「Puppetの設定にcommitしたりはしている。」
S「あるRoleに対してはインフラエンジニアはコードのレビューのみになっている」
K「今まで煩雑な依頼があったのが、だいぶ良い環境になってきている。
  数年前からDevOpsに取り組んでいるが、アプリケーション寄りの活動も、物理やネットワークにも取り組んで行きます」

以上。以下Q&A

Q: 構成管理ツール、の難しさを感じる。社内への普及や教育はどうやっているか?
A: (T)一番最初はmizzyさんから直接教えてもらって、落とし込みは自分たちで議論しながら行った
  (K)当時は良い教材が無かった。あと普及面では世の中にはまだまだ手順書があるが、これを置き換えたときに何が得なのか、逆に手順書でないとできないことは何か、とみんなで考えてはどうか
  (S)当時「スクリプトではダメだぞお前」という空気があった
  (K)同調圧力ではなくて、問題意識を共有してる上でのこと

Q: インフラエンジニアとアプリケーションエンジニアの責任範囲の分け方は?
A: (K)アプリケーションエンジニアのプルリクをインフラエンジニアがレビューするのでその時点で責任範囲というかコードの通り。振り返りは大事だが、責任範囲を問うことはしていない

感想や小話

全体

先のqpstudyは比較的泥臭さも感じるインフラエンジニア界隈でしたが、今日はさすがペパボさんというか技術で様々な施策を打っていて、自社サービスの環境をちゃんと把握した上での対応が行われているという感じでした。
ruby/mrubyという軸が強くあるので、環境やツール選定にも大きな理由があってすんなり行っている印象でした。自社プラットフォーム開発をされている会社さんはこれがありますね。運用系の集まりだと強い言語は無かったり個々人で違ったりするので「RubyDSLで書けるっ」はそれほどメリットでなかったりも。個人的には「フレームワークとしてメリットを得られるものを選べば良いんじゃないでしょうか」と言うシーンが最近多かったので、明確な軸があるのはうらやましくも感じました。

構成管理

cfengine is cool, puppet is sexyというフレーズを聞いたのは10年近く前の気がしますが、古参ツールのpuppetを会得して使いこなしている感にあふれていて、ツールがちゃんと手段に収まっているのも印象的でした。構成管理ツールって最初に使った時に気持ちの良い感動があるはずなので、そのメリットが活かされたまま定着できているのが良いなあと。世には「Chefツライ」とか「YAMLプログラミング(Ansible)ツライ」とか「本当にholoで良いの?」いった話も多いですからね..ベアメタルレベルの管理のお話が聞けなかったので、そこの施策も聞いてみたいです。OpenStackで言うIronicとかUbuntuならMAASとか
tnmtさんに「ストレージ選定ネタの続きも期待してます」「StackStorm便利ですよ。どうっすか」と2つお話できたので、もしかするとOpenStack MistralのワークフローベースでStackStormを操るお姿が見られるかもしれません。StackStormは、都合がつけばHosting Casual #3でディスカッションのまな板に乗せてみたかったのですが。

ヒト

一方で4月のqpstudyや3月のIaas Casualと同じくインフラエンジニアの今後のキャリア形成やチームメイキング、採用といったヒトのお話では共通した課題や悩みが聞かれた気がします。クラウドやらコンテナやらと基盤が進化してツールも充実したことで、変化は感じていてそれに伴った危機感も感じている、といったところでしょうか。今回のpbtechと併せた3つのイベントで割と共通して聞かれたメッセージとしては「すべてできる人はいない」「コミュニケーション大事。コミュニケーションもChatOpsとか技術で改善できる部分もある」「そこはきっと楽しいところ(デマルコ風)」がありました。あと懇親会でkumanoさんからファシリテーターの活用というお話もあり、これまた実際の活用話はあまりお聞きする機会が無かったので、ファシリテーター人材という課題も有りそうですが納得感がありました。

実は前日まで抽選に落ちたと勘違いしていて午前中に髪を切りに予約入れちゃったりしていたのですが、無事参加できて様々な刺激を得られて良かったです。今後もpbtechでインフラ/運用系のネタをやって欲しいし自分のチームメンバーにも参加して欲しいです。
また、懇親会のカレーが小分けで配布されたのは食べやすかったので、Zoho各位にはナンのこだわりもあると思いますが参考にしてもらえれば。

おまけ

Web+DB Press Vol.92の第一特集"Web開発新人研修"はまるごとペパボさんのご執筆です。
gihyo.jp


(5/16 公開資料へのリンクを追加しました)

ntpの脆弱性201604公開分-雑まとめ

ひとまずRedHat情報で整理したものを。
"will not fix"でconf内容を見直せ、というものが結構あります。

CVE-2015-7973:Authentication Bypass by Capture-replay

CVSS v3 Base

アップデートパッケージ(RHEL)

なし

補足

Do not use NTP's broadcast mode by not configuring the "broadcast" directive in the ntp.conf file.

CVE-2015-7974:Improper Input Validation

CVSS

6.3

アップデート

なし

CVE-2015-7975:Improper Input Validation

補足

RHEL5-7のパッケージは該当せず

CVE-2015-7976:Improper Input Validation

アップデートパッケージ(RHEL)

なし

補足

Use the 'restrict default nomodify' directive in ntp.conf to disable modification of ntp.conf via the ntpq command.

CVE-2015-7977:NULL Pointer Dereference

アップデート

なし

補足

Keep the number of restriction list entries in ntp.conf lower than 500.

CVE-2015-7978:Uncontrolled Resource Consumption ('Resource Exhaustion')

アップデートパッケージ(RHEL)

なし

補足

Keep the number of restriction list entries in ntp.conf lower than 500.

CVE-2015-7979:Incorrect Synchronization

アップデートパッケージ(RHEL)

なし

補足

Do not use NTP's broadcast mode by not configuring the "broadcast" directive in the ntp.conf file.

CVE-2015-8138:Improper Input Validation

CVSS v3 Base

(Important)

アップデートパッケージ(RHEL)

https://rhn.redhat.com/errata/RHSA-2016-0063.html

CVE-2015-8139:Information Exposure

アップデートパッケージ(RHEL)

なし

補足

1-3のいずれかで緩和可能
(1)adding the noquery option to all restrict entries in ntp.conf,
(2)configuring ntpd to get time from multiple sources,
(3)using a restriction list in your ntp.conf to limit who is allowed to issue ntpq and ntpdc queries.
Note that ntpdc queries are disabled by default.

CVE-2015-8140:Authentication Bypass by Capture-replay

アップデートパッケージ(RHEL)

なし

補足

(1)disabling ntpq in ntp.conf,
(2)configuring ntpd to get time from multiple sources,
(3)using a restriction list in your ntp.conf to limit who is allowed to issue ntpq queries.

CVE-2015-8158:Uncontrolled Resource Consumption ('Resource Exhaustion')

アップデートパッケージ(RHEL)

なし

CVE-2016-1547:Incorrect Synchronization

CVE-2016-1548:Authentication Bypass by Spoofing

CVE-2016-1549:Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

CVE-2016-1550:Improper Input Validation

CVE-2016-1551:Authentication Bypass by Spoofing

CVE-2016-2516,CVE-2016-2517:Improper Input Validation

CVE-2016-2518:Out-of-bounds Read

CVE-2016-2519:Improper Restriction of Operations within the Bounds of a Memory Buffer

CVE-2015-7704:Improper Input Validation

アップデートパッケージ(RHEL)

https://rhn.redhat.com/errata/RHSA-2015-1930.html

CVE-2015-7705:Improper Input Validation

補足

Do not add the "limited" configuration option to any restrict lines in the ntp.conf file.

qpstudyに参加してエンシェントな焼酎をふるまってきました

初心者にもやさしい(頃もあった)勉強会、qpstudyに初参加してきました。
www.zusaar.com
今回のテーマは監視&運用+自動化。

本編

最初は @koemu さんによる「ITインフラ監視の今後を考える」。
惰性的に行われてきた面もある監視を根本から見直してみようという意欲的な問題提起でした。
経営や事業評価の視点も交えて誰にどういう価値を提供するか、という観点もあり非常に刺激的でした。
speakerdeck.com

後半挙げられた3つの課題が印象的だったので整理。

  • 1.PaaSをどう監視するか

 監視させてくれない/見えない部分が多い、検知しても対応は事業者任せでできることが無い
 監視も事業者提供ツール頼み? cf. http://www.stackdriver.com/

  • 2.監視システムはDIYSaaS

 SaaSはコストが明瞭、その分高く見える場合も
 DIYの場合の構築コスト/運用コスト/提供価値のトータルで比較してみる必要がある

  • 3.監視の細かさ

 対応の必要なものを確実に通知
 通知内容の優先度
  - 障害でなければ通知は要らない?
  - HDD容量など予防的通知は?
  - 冗長したWEbのうち1台落ちたときは?
  - ステークホルダーと合意は取れているか?


続いて前佛さんの「Re:運用に自動化を求めるのは間違っているだろうか?」
当初予定の時間枠では半分強しか話せずw懇親会で延長戦も行われました。

www.slideshare.net

冒頭のスライドの通り、ポイントは3+1つ。

  • 運用における自動化範囲の整理・分類
  • 自動化で運用はこんなにも楽しくなる
  • トラブルシューティング自動化は未解決課題
  • 本来あるべき状態から逆算して運用業務を楽しくしよう

運用における自動化範囲の整理・分類

ツールや手法で改善可能になった部分もある
-設計&構築 <- 構成管理ツール、Dockerfileからの起動
-監視設定 <- オートディスカバリー、テンプレートエージェント

会場からQ. 環境構築の自動化でDockerが構成管理ツールよりも優れている点は?
前佛さんA. ツールは一長一短あるのでどちらでも
      Dockerは間違いなく同じ環境を作ることができます

会場からQ. システムのライフサイクルを考えて維持管理や変更にDockerは耐えうるか
前佛さんA. Dockerだからどう、という問題点ではないと思います

会場からQ. コンテナ作成のタイミングというか依存ライブラリのバージョンが変わってしまう場合の対策は?
前佛さんA. 現で点ではローカルのResistryServerに作成したDockerイメージを置いてください

トラブルシューティング自動化

使えそうなツールはいくつか出てきた
-時系列メトリクスを何台分も並べて見ることができるもの(Elasticとか)
-クラスタ制御ツール(serf, consulとか)

よくある「サーバー重いんだけどちょっと見て」という状況に、コンテナ化されるインフラでどう対応するか。
-ツールによって"当たりをつける"ことの支援は可能
-問題の特定や支援はまだちょっと先?

他の業界で確立している手法に学んでみようシリーズ
-大事故,大規模災害時のトリアージ -> 障害の深刻度や対応復旧の優先度
-管制とレーダー -> オートディスカバリーでのクラスタ状態(の変化)の把握と各インベントリ,メトリクスの取得
(この辺で時間切れ)

グループディスカッション

それぞれ自分の業種の立場から、監視業務の価値を見直してより良い今後を考えよう、という内容で
3-4名 -> 各テーブル(8名程度) -> 全体 の三段階でのブレスト形式

自分のグループではクラウド化なんてできていないオンプレなメンバーが結構いたので
レガシーなところにも付与可能な価値、ということで一覧性の話をしたり、
DIY(オンプレ)な監視基盤の監視のためにSaaS系を用いる話、
cronやサービスウインドウを調整して日中など障害が起きるとしても対応しやすい時間に起こるようにする話、をしました。

なおテーブル班での議論を発表する際、「レガシー」という単語をど忘れして
エンシェントなシステム」と言ってしまったのがちょっとハネたので結果オーライです。

他のチームでは経営層に響くレポートの話や、内製で引き継ぎが無いとかそもそも独りとかのツラい話が今なお心を掴んでいたりととても多様な意見とそれでも共通したある種の危機感があって面白かったです。

懇親会&LT

自動化というトピックでちょうど良いかな、と思ってStackStormの紹介をLTしました。
単発作業の自動化/マクロ化はできていることが多いと思いますが、ノード間やクラスタ間をまたいだ自動化は急にハードルが高くなりがちなので役に立つかもしれません。
iftttとかplagerを想起させるツールなので、前佛さん資料の"ピタゴラ装置的な仕組み"を作る基盤になれるものだと思います。
StackStorm.pdf - Zoho Docs

以前、SoftwareDesign誌で"運用現場で役立ち開発力"という特集があったり昨今DevOpsというキーワードがあったりしますが、個人的にはインフラエンジニアが作るシェルスクリプトの品質という問題意識があります。会社の中でも開発部門にはコーディング規約があったりしてもインフラ運用部門は触れたこともないし出荷検品のプロセスも無いような状況というのがあるんじゃないかと思います。
ChefだとかこのStackStormのようなツールを利用することで、エラー処理や正規表現など書式のハンドリングといった部分を個別に書かずに済むフレームワーク的なメリットも得られ、テストやレビューも行いやすくなる点もあると思うので、何かしらツールを使ってみるという現状改善のアプローチもあると思います。
Software Design 2009年4月号|技術評論社

Enterprise版のお値段の質問がありましたが、やはり非公開になっていました。月額$500以下ぐらいで12ヶ月契約と書かれています。
Pricing - StackStorm
ただし現時点ではほとんどの機能がGitHubから落とせるOSS版で利用できます。Enterprise版のみの機能は、デモでお見せしたWorkflowのGUIエディタとLDAP連携、ロールベースアクセス制御の部分のみです。
stackstorm.com

監視におけるフルリゾルバのキャッシュ by ttkzwさん

DNSドメイン情報に起因する障害が発生している場合に監視基盤がリゾルバのキャッシュを使っていて検知できない、というようなケースをどう回避するかという課題設定。
理想的にはキャッシュDNS上のTTLをすべて監視間隔に合わせて、都度新しい情報で監視することを示され、例としてunboundでのcache-max-ttl設定をご紹介されました。(bindは省略というか足切りされましたが、max-cache-ttl/max-ncache-ttlで設定が可能です)
この問題ってFWのポリシーを名前ベースで設定する時にもからんできたりしますね。あと監視基盤がWindowsだとスタブリゾルバでもキャッシュしそうな気がします。

クラウドポリシーチェックリスト --間違えてました-> Wall-Architected フレームワーク by yktkoさん

冒頭に好きなAWSサービスはaws-cliとの言があって、そこ?と思いましたw
興味深かったので終わったあとに「Trusted Advisorと統合されないんですか?」と訊いてみましたが、汎用的にできていて「バックアップちゃんと採っていますか」といった項目もあるのでチェックリストにはなるけどすべてが機械診断に反映できるものではない旨言われ、納得でした。
こういうのはベストプラクティス的にそれぞれで経験されたものが集約されていって欲しいですね。

AWS Certificate Manager by mnakajima18さん

いろいろ理想値にすれば導入も更新も30分+アルファ+アルファ+アルファくらいでできた実績のお話。
Tokyoリージョンに無いのと、Let's Encryptという競合および既存大手との争いも気になりますね。Let's Encryptは更新のcronジョブの時に80/443がサービスリスタートよりも長い時間、多分1分弱くらい停止する点が気になっています。ACMはどういう動作をするんでしょうか。

MongoDB on EC2 by kuwa_twさん

「ログを入れるなって言ってるだろう」....すみません、StackStormでもMongoDBはログやauditの置き場です....
WiredTigerストレージエンジンなら改善されるか負荷テストしてみた、という結果グラフでしたが負荷がキツすぎて結果が正直すぎて良さが伝わりにくいというか....I/O waitが80%から60%に改善されたってterribly slowがvery slowになったとしか感じないのですが。とは言えwiredTigerへの期待およびMySQLでのFalconのように今後StorageEngineの開発がいろいろ進む先陣になることへの期待があります。
4/26お昼時のBlackBeltがMongoDB on AWSとのことです。
[Black Belt Online Seminar] AWSで使うMongoDB


あと、私が熊本生まれ宮崎育ちということで熊本の焼酎を差し入れしました。
www.fusanotsuyu.jp
35度とちょっと強めでしたが30年古酒にしたこともあって飲みやすいと好評で売り切れて良かったです。お気に召した方は、是非熊本や大分のお酒を入手してみてください。

日本酒ならば阿蘇の一所懸命とかメッセージ感もあっていかがでしょうか。
吟醸焼酎 一所懸命720ml | 商品のご購入はこちらから | 熊本の阿蘇にある酒屋【阿蘇・岡本】のオリジナルのお酒・リキュールやお土産にも喜ばれる地サイダーの通販サイト

感想・考察・補足情報

ただ監視するだけではなく、運用の改善やメタに役立つことを実装することもできるという面でZabbixに高い評価と期待が感じられた一方、導入の障壁(をDockerで緩和)や導入を後押しするメリットが欲しいという話も多く聞かれた気がします。
まずは仮想アプライアンスとかでPC上のVirtualBoxで起動してみるのもいかがでしょうか?
http://www.zabbix.com/jp/download.php#appliance

ただ問題意識も経験的比較対象もなく試しても判断しにくいと思うので、メールソフトやテキストエディタをいくつか試したことがあるならばその感じで試してみても良いと思います。
「最初に触るのがZabbixという若手にメリットを理解してもらいたい」という話に前佛さんが「Zabbix無しで同じものを得る環境を作らせてみては」ということをおっしゃっていたので「BigBrotherでやらせてみては?」と野次ってみました。
BBは極論として、解は一つではないと思うので私の好きなOSS監視ソフトも挙げておきます。どちらも仮想アプライアンスやLiveCDがあります。
PandoraFMS http://pandorafms.org/ja/features/download
ichinga2 https://www.icinga.org/download/

最後に

長時間のイベントでしたが参加者の意欲も旺盛で様々な意見交換ができて非常に有益でした。
人数の多いイベントをハンドリングしたスタッフのみなさまも素晴らしかったと思います。
主催・スタッフ・参加・ハッシュタグ参加されたみなさま、ありがとうございました。

余談

手元にまだ宮崎のおいしい焼酎があります。平日夜に空けるのは厳しいと思うので
 土曜日開催のインフラや運用系
 && 懇親会に焼酎持ち込み可
 && LTでツールネタ可
というイベントの情報を求めています。

(4/24 LTの他の方々の発表部分を追記しました。酔ってたしログ無いので薄めですが)