• Save
Serfが面白いと俺の中で話題にwwwwww
Upcoming SlideShare
Loading in...5
×
 

Serfが面白いと俺の中で話題にwwwwww

on

  • 21,430 views

Cloud Management Tool Workshop #2 at IDC Frontier, Shinjuku, Tokyo

Cloud Management Tool Workshop #2 at IDC Frontier, Shinjuku, Tokyo
クラウドマネジメントツール勉強会 第2回 #cmt_study
Masahito Zembutsu Dec 4, 2013

Statistics

Views

Total Views
21,430
Views on SlideShare
16,932
Embed Views
4,498

Actions

Likes
65
Downloads
0
Comments
1

14 Embeds 4,498

http://pocketstudio.jp 3701
http://inokara.hateblo.jp 607
https://twitter.com 97
http://s.deeeki.com 35
http://feedly.com 28
https://postre.am 13
http://b.hatena.ne.jp 5
http://openlink.to 4
https://www.chatwork.com 2
http://translate.googleusercontent.com 2
http://tweetedtimes.com 1
http://newsblur.com 1
http://www.slideee.com 1
https://tweetdeck.twitter.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Hi, I wrote this slide. I'm interested in orchestration, automation and knew Serf.
    An author of Serf is not me, but wishes that I want many people to know Serf. Serf is going to change my operations.

    Unfortunately this slide is written in Japanese and wants to show a slide with English version if there is a request of somebody.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Serfが面白いと俺の中で話題にwwwwww Serfが面白いと俺の中で話題にwwwwww Presentation Transcript

  • Serf が面白いと俺の中で話題にwwwwww 『 監視システムに serf を使ってみる話 』 monitoring systems with Serf / Serf the Liberator @zembutsu Masahito Zembutsu Dec 4, 2013 クラウドマネジメントツール勉強会 第2回 #cmt_study Cloud Management Tool Workshop #2 at IDC Frontier, Shinjuku, Tokyo
  • 今日の概要  1. Serf は汎用オーケストレーションツール ➡ http://serfdom.io/ • Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者 ➡ 分散型ソリューション • サービス検出やオーケストレーションのため • 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant ) ➡ 高い汎用性 • Immutable Infrastructure (変わらないインフラ) 向けのツ―ル
  • 今日の概要  1. Serf は汎用オーケストレーションツール ➡ http://serfdom.io/ • Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者 ➡ 分散型ソリューション • サービス検出やオーケストレーションのため • 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant ) ➡ 高い汎用性 • Immutable Infrastructure (変わらないインフラ) 向けのツ―ル  2. Serf の始めかた ➡ できる!Serf … コマンドリファレンス、画面デモ serf-wall
  • 今日の概要  1. Serf は汎用オーケストレーションツール ➡ http://serfdom.io/ • Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者 ➡ 分散型ソリューション • サービス検出やオーケストレーションのため • 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant ) ➡ 高い汎用性 • Immutable Infrastructure (変わらないインフラ) 向けのツ―ル  2. Serf の始めかた ➡ できる!Serf … コマンドリファレンス、画面デモ serf-wall  3. 監視システムに応用してみた話 ➡ Raspberry Pi 検出や、serf-munin で監視自動化
  • 今日の概要  1. Serf は汎用オーケストレーションツール ➡ http://serfdom.io/ • Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者 ➡ 分散型ソリューション • サービス検出やオーケストレーションのため • 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant ) ➡ 高い汎用性 • Immutable Infrastructure (変わらないインフラ) 向けのツ―ル  2. Serf の始めかた ➡ できる!Serf … コマンドリファレンス、画面デモ serf-wall  3. 監視システムに応用してみた話 ➡ Raspberry Pi 検出や、serf-munin で監視自動化
  • serf-wall 今日ご紹介のデモは3つ。たとえばこんな使い方。 全サーバで wall コマンドを同時実行。serf のイベ ント発行がトリガ。使用例:偽シャットダウン 簡単なので、すぐに作る&試すことができます。
  • serf-raspi-notice Raspberry Pi は、モニタがありません。ネット ワークに DHCP 接続すると、IP アドレスが分か らなくなります。モニタを使わずに、デスク トップにIP アドレスとホスト名を表示できます。 そう、serf ならね。
  • serf-munin リソース監視ツール Munin 向けにも応用できます。 Serf のノード join をトリガとして、ロールに応じ た自動グループ別登録が可能です。そう、Serf(略
  • serf-munin 通常、手動で設定すると非常に設定が面倒な TREND ( トレンド ) や PREDICTION ( 予測 ) のグラフ設定。 serf と連携させれば、こんな感じで自動管理。
  • ところで WHY AM I HERE?
  • (意訳:コイツ馬鹿ww)
  • 脳内関心空間 最近の興味は監視と運用に関するツール全般、 Raspberry Pi のような小型コンピュータや自動化、 そして今期のアニメ。それより俺の婚期がヤバイ。
  • 2009年 2011年 PostgreSQL Pukiwiki EC2 S3 RDS CloudStack OpenStack IaaS全般 Munin Cacti moint SES SNMP 2012年 RRDtool Node.js Chef Zabbix S.M.A.R.T OpenIPMI Raspberry Pi BeagleBoard Serf memcached okuyama MySQL Ganglia Puppet Route 53 技術の興味変遷 を棚卸し 2013年 Perl Amazon Web Services Eucalyptus 2010年 Nagios Xen KVM Ansible Graphite Cassandra Asterisk varnish Mediawiki Redmine serverspec IRC Ruby
  • 鯖屋 ホスティングと言えば、 http://www.flickr.com/photos/ewan_the_moomintroll/4127615397/ by Ewan Bellamy
  • 世界の中心で DATACENTER SERVER こんな職場のイメージです。 最近は、ほとんど現場運用 に携わっています。 OPERATION 鯖を捌いた けもの INFRASTRUCTURE ENGINEER http://www.flickr.com/photos/torkildr/3462606643/ by torkildr http://www.flickr.com/photos/toyohara/395472864/ by toyohara
  • ――最近、思います。 戦争(運用)は変わった PRESENT DAY, PRESENT TIME
  • Before 10年前は中規模ECサイ トでも、せいぜい数台 (一ケタ台)の規模感。 After 今は用途に応じてサーバ を分けたり、アクセスを 捌くため台数が激増中
  • それでも、現状は Munin や Zabbix といった監視ツールのお 陰で、管理台数が増えてもなんと か続けられてます。 システムやリソースを俯瞰する ツール群のおかげで、状況把握や トラブルシュートの速度が格段に 向上したからです。
  • しかし、今後はどうでしょう。 もうそろそろ人が介在するような 監視や運用は限界かもしれない。 ネ申(スーパーハカー)に頼る時 代は終わろうとしているのでは。 ? 端末数の爆発的増加 M2M ; Machine to Machine
  • 私の身近な所でも BY THE WAY
  • 私は富山県出身なのですが、 富山県はどこかご存知ですか? TOKYO
  • true tears ゆるゆり PERSONAトリニティソウル おおかみこどもの雨と雪 Another 富山県 TOYAMA Pref. ここです!新幹線が開通したら、 行き来が楽になりそうです!! 富山は自然もありますが、工業県でもあります。 “工場萌え”企画とか考えたら良いと思います(真剣 北陸新幹線 2015年春開業 東京<->金沢 2時間30分 東京<->富山 2時間10分 (≒東京<->名古屋間)
  • 富山県滑川市が実家の場所。 これがウチの田んぼです。 今年の作付面積は、約5ha。 東京ドーム1個分の広さです。
  • わたしです 有機JAS認証コシヒカリ米を生産中 (農林水産省認定/第三者機関評価) もちろん無農薬・有機肥料栽培です。 米屋様、ご興味ありましたら。是非是非m(__)m お問い合わせ m.zembutsu [at] gmail.com まで!
  • 激しくアナログ 結構真面目に、アナログな部 分を機械化・自動化していか なくちゃと考えています。
  • 今更ながら勉強中 小型コンピュータの可能性。RaspberryPi や BeagleBoard 等。 今は何が出来るのか?何が必要になるのかという調査段階。 そんな折、Serf に出会いました。
  • Serf http://serfdom.io/
  • Serf それは世界を暴くシステム THE ABYSS OF THE INTERNET
  • なぜなにSerf THE HELETIC ACTIVATES
  • 乗るしかない、 このビッグウェーブに! http://www.flickr.com/photos/mikebaird/4177569971/ by Ewan Bellamy
  • Serf  Serf は “オーケストレーションツール”  “オーケストレーション”については様々 な意味解釈がありそうです。ここでは、 ”日々の運用やシステム管理における自動 化手法”として考えています。  開発に携わっているのは、Vagrant 作者 の Mitchell Hashimoto 氏 ( @mitchellh )と、 Armon Dadger 氏 ( @armon )。  開発状況は GitHub を通して参照する事が できます。 https://github.com/hashicorp/serf  ARM に対応しているので Raspberry Pi 上 の Linux であれば、もちろん Serf を稼働 させられます。 ➡ http://serfdom.io/ • version 0.2.1 のバイナリが配布中 (12/4現在) ➡ オープンソースとして公開・開発 • Mozilla Puglic License, version 2.0 • go 言語 1.2 以上の開発環境 ➡ 幅広い対応 OS、配付バイナリ • Linux ( 386 , AMD64, ARM ) • Mac OS ( 386, AMD64 ) • Windows ( 386, AMD64 ) • FreeBSD ( 386, AMD64, ARM ) • OpenBSD ( 386, AMD64 ) ライブラリの依存関係はありません。 バイナリ1つを実行するだけで、全機能が使えます。
  • Serfは何なのか?  Serfの特長は、”シンプルかつ高い汎用性”  参考 “Introduction to Serf” http://www.serfdom.io/intro/index.html  UDP Port:7946 と、RPC サーバとして 127.0.0.1:7373 を使用。設定によって ポートは変更可能。  参考 “Serf Convergence Simulator” ➡ 軽量 ( lightweight ) • メモリ 5 ~ 10 MB程度 、UDP で通信 ➡ 高可用性 ( Highly Available ) ➡ 障害耐性 ( Fault Tolerant )  サービス検出とオーケストレーション ➡ ノードの自動管理 ( membersip ) • メンバ情報を管理する中央サーバが無い ➡ 障害検知と回復 • 数秒程度でエラー検出。再度メンバ追加も容易 ➡ 任意のイベント発効 • 任意のコマンドを実行させる事も可能 http://www.serfdom.io/docs/internals/simulator.html 内部的な処理では、ゴシッププロトコ ルを使って実現しています。この複雑 なプロトコルを理解しなくても、serf は ”魔法”のように使えるのです。
  • Serfの登場背景  Immutable Infrastructure ➡ サーバには変更を加えない(設定変更も) • • 予めテスト・確認済みのイメージを使用 イメージを使う利点は、凄く早い事 ➡ 経緯 • • ネットワークが不達なら? パッケージ管理やバージョン管理は? Chef / Puppet が変わったら? マシンイメージの管理のため Packer を開発 – • 運用ワークフローの改革 そして、オーケストレーションツールとしての Serf – サービス発見と、オーケストレーション(運用自動処理)  勝手な理解 ➡ 迅速な対応を行う為には、Immutableな環境を! • • 参考 "Towards Future Ops: Stable, repeatable, environments from dev to prod.“ http://www.slideshare.net/profyclub_ru/ 8-mitchell-hashimoto-hashicorp 専用サーバ→複数台運用→VPS→クラウドの流れ 設定管理が課題になってきた – – – •  「私が死んでも代わりがいるもの」 「ホスト名が許されるのは小学生まで(ry」といった考え? この資料を読んで、ようやくイミュータブ ルなインフラについてイメージが湧いてき たような。。←出遅れています。
  • ゴシッププロトコル 私としては、要するに “友達の友達はアルカイダ 魔法少女仲間”な理解でいます。  Gossip Protocol ➡ 分散コンピュータにおける通信プロトコルの一種 • Gossip = 【名】噂、噂話 【自動】おしゃべり • Serf は、クラスタ全体のメッセージ通知で使用 ➡ Serf は「中央管理サーバ」が存在しない • お互いに情報(メンバ情報 membersip)を保持  SWIM Protocol ➡ Serf が使っているものは “Scalable Weaklyconsistent Infection-style Proces Group Membersip Protocol” を基本に調整したもの。 • 障害検知 • ノード間の probe/ack • ノードの追加・削除やイベント発効  参考: http://www.cs.cornell.edu/~asdas/resear ch/dsn02-swim.pdf
  • イベントハンドラ EVENT HANDLERS
  • イベントハンドラの扱いが胆  Serf のイベントハンドラ ➡ イベントは「ただちに」全 serf ノードに通知 ➡ 4種類 • member-join ノードに誰が参加 • member-leave 誰かがメンバを離れる • member-failed メンバ参加不能 • user すぐに情報共有できるのが特徴。 (◕‿‿◕) ←が大量にいて、情報を同期し ているようなイメージでしょうか。 任意イベント ➡ それぞれのイベントで、任意コマンドを実行可能  参考 “Event Handlers” http://www.serfdom.io/docs/agent/even t-handlers.html  serf と組みあわせると、Munin の作業も ある程度自動化できます。  ‘XXXX’ という引数は、イベント名として 通知され、各 serf サーバ側のスクリプト では、環境変数 SERF_USER_EVENT で取 得できます。 • 例:serf メンバ追加時に Munin に追加 ➡ ‘user’ イベントは特殊 • コマンド ‘serf event XXXX’ で、 参加ノード全体に任意のイベントを送信出来る。
  • 環境変数でイベントのデータを処理  4種類の環境変数 ➡ SERF_EVENT • member-join • member-leave • member-failed serf 起動時に、「何のイベント発生時」に「どのコマ ンドを実行するか」定義します。設定方法により、 全イベントで、共通の処理を行う事もできますし、 個々のイベントにおいて、別々のスクリプトを実行す ることもできます。 例: serf agent –event-handler=“/opt/hello.sh” • user ➡ SERF_SELF_NAME • イベントを発行したノード名 ➡ SERF_SELF_ROLE • イベントを発行したロール ➡ SERF_USER_EVENT • ユーザ定義によるイベント名称  ver 0.3.0 からは、’serf event’ 1つめの引 数 ( 環境変数 SERF_USER_EVENTで引き渡 し ) に加え、2つめの引数 ( payload ) が 用意されるようです。payload は、標準 入力としてスクリプト等で取り込むこと が出来ます。 例:serf event deploy appserver3
  • 例えばシェルスクリプトで #!/bin/sh  このスクリプトは、こちらの issue に上 がっていたスクリプトです。シンプルで すが、動作確認に役立ちます echo https://github.com/hashicorp/serf/issues/54 echo "$0 triggered!" echo  serf がイベンントを受け取ると、予め起 echo "SERF_EVENT is ${SERF_EVENT}" 動時に指定しておいたコマンドを実行し echo "SERF_SELF_NAME is ${SERF_SELF_NAME}" ます。そのとき、環境変数を通して、 echo "SERF_SELF_ROLE is ${SERF_SELF_ROLE}" データを引き渡します。 echo "SERF_USER_EVENT is ${SERF_USER_EVENT}" echo echo "BEGIN event data"  join 等の時は、ノード名・IPアドレス・ ロール名の情報が標準入力で取得します。 while read line; do  user イベント時は、v.0.2.0 ではデータを echo $line 渡せないようです。 done echo "END event data" echo "$0 finished!" 要は、何でも実行出来ます。条件に応じた処理をさせたいのであれば、環境変数が echo 扱えるもの;シェルスクリプト以外にも、Ruby , PHP, Perl 等々が使えます。
  • 使ってみよう DO IT YOURSELF
  • インストールとセットアップ(バイナリ)  ダウンロード ソースから構築する方法もあり ますが、バイナリ版を使えば、 楽ですね。 ➡ http://www.serfdom.io/downloads.html  Linux (AMD64)の例 wget -O 0.2.1_linux_amd64.zip https://dl.bintray.com/mitchellh/serf/0.2.1_linux_amd64.zip unzip 0.2.1_linux_amd64.zip sudo mv ./serf /usr/local/bin/serf-0.2.1 sudo ln -s /usr/local/bin/serf-0.2.1 /usr/local/bin/serf  serf は何処に置いても構いません。私の 場合は、バージョン変更時に楽に対応で きるよう、/usr/local/bin 以下に置いて、 /user/local/bin/serf にシンボリックリン クを作成しています。
  • Serf の基本操作 チュートリアル
  • Serfをはじめよう!  チュートリアル ➡ まずは動かしてみましょう! ➡ 用意するもの • 2台のサーバ ➡ 作業概要 • serf agent を起動し、ノードへの参加と イベントの発行までを行います $ serf argent $ serf members $ serf join $ serf event serf agent serf agent
  • 起動の仕方  基本 $ ./serf agent  serf に ‘agent’ を付けない場合は、serf に対す るコマンドラインツール ( CLI ) になります。  ‘serf members’ と実行すると、繋がっている ノードの一覧を表示します。  拙作 Serf用のinitスクリプトを書いてみた http://pocketstudio.jp/log3/2013/11/25/sysv _init_script_for_serf/  systemdでserfを自動起動する方法 http://pocketstudio.jp/log3/2013/11/06/how to_run_serf_with_systemd/ 別サーバに対し、 agent 起動時に join 先を指定 例:’192.168.10.1’ で動いているなら $ ./serf agent –join=192.168.10.1 これだけで繋がります  SysVinit 対応や systemd もあるんだよ # service serf start # service serf stop
  • Serf Agentを立ち上げてみよう  serf のオプションに ‘agent’ をつけるだけ  このままだとログが流れ続けて操作を受 け付けてくれません。別端末としてログ インしなおす方法もありますが、 serf agent & と、バックグラウンドとして 起動するほうが楽かもしれません。  終了すると、自動的にノードから切り離 されます。 ➡ $ serf agent ==> Starting Serf agent... ==> Serf agent running! Node name: 'node1.pocketstudio.net' Bind addr: '0.0.0.0:7946' RPC addr: '127.0.0.1:7373' Encrypted: false ==> Log data will now stream in as it occurs: 2013/12/03 22:35:57 [INFO] Serf agent starting 2013/12/03 22:35:57 [INFO] serf: EventMemberJoin: node1.pocketstudio.net 192.168.10.1 ➡ <CTRL+C> で終了 ==> Gracefully shutting down agent... 2013/12/03 22:35:58 [INFO] agent: requesting graceful leave from Serf 2013/12/03 22:35:58 [INFO] serf: EventMemberLeave: node1.pocketstudio.net 192.168.10.1 2013/12/03 22:35:58 [INFO] agent: requesting serf shutdown 2013/12/03 22:35:58 [INFO] agent: shutdown complete 2013/12/03 22:35:58 [ERR] RPC accept error: accept tcp 127.0.0.1:7373: use of closed network connection
  • joinしてみよう node1 ( 192.168.10.1 ) 1. まずエージェントを起動します。 $ ./serf agent & 起動すると、ログが流れ始めます。 コマンドを実行させたいので、バックグラウンドで 動作させています。 4. members コマンドで、確認します。 $ serf members node1 192.168.10.1 alive node2 192.168.10.2 alive node2 ( 192.168.10.2 ) 2. 片方もエージェントを起動します。 $ ./serf agent & 3. join コマンドを使い、join します。 $ ./serf join 192.168.10.1 Successfully joined cluster by contacting 1 nodes. 5. こちらで members を実行しても、同じ結果です。 $ serf members node1 192.168.10.1 alive node2 192.168.10.2 alive
  • イベントを送ってみよう node1 ( 192.168.10.1 ) node2 ( 192.168.10.2 ) 6. ユーザイベントを発行 $ serf event 'Hello world!' 2013/12/05 19:36:16 Requesting user event send: Hello world!. Coalesced: true. Payload: "" Event 'Hello world!' dispatched! Coalescing enabled: true 7. イベントが届きます 2013/12/05 19:36:17 [INFO] agent: Received event: user-event: Hello world! 7.イベントが届きます。 2013/12/05 19:36:17 [INFO] agent: Received event: user-event: Hello world! 同時にイベントが発行されるのがポイントです。 ※どのサーバからもイベントを送ることが出来ます。 このタイミングで、任意のコマンドを実行することが出 来るのが serf の面白い所ではないでしょうか。
  • もう少しkwsk
  • Serf CLI  CLI の主な管理コマンド  ‘serf’ はエージェントとして稼働するとき に使うほか、コマンドライン・ツールと しても使用します。  serf agent コマンドを実行していなくて も、serf のログ状況を確認することがで きます。デバッグ時は必見。  慣れてくると、agent 起動時に ‘serf agent –join=xxx’ と指定したり、設定 ファイルを用意した方が楽です。  間違いなく対象ホストがダウンしている 場合など使うようです。force-leaveされ た側から接続しようとしても、タイムア ウトして接続できなくなります。 ➡ serf members メンバ一覧の表示 node1 192.168.10.1 node2 192.168.10.2 node3 192.168.10.3 ホスト名 IPアドレス alive alive left 状態 dev dev standby ロール名 ➡ serf monitor ログ表示 2013/12/03 22:24:08 [INFO] Initiating push/pull sync with: 192.168.10.2:7946 2013/12/03 22:24:36 [INFO] Responding to push/pull sync with: 192.168.10.2:54031 2013/12/03 22:24:38 [INFO] Initiating push/pull sync with: 192.168.10.2:7946 ➡ serf join <ホスト名> ノードに参加 [INFO] Agent joining: [192.168.10.2] [INFO] Initiating push/pull sync with: 192.168.10.2:7946 [INFO] serf: EventMemberJoin: node2 192.168.10.2 Successfully joined cluster by contacting 1 nodes. ➡ serf force-leave <ホスト名> ノード強制切り離し $ serf join 192.168.1.1 [INFO] Agent joining: [192.168.1.1] Error joining the cluster: dial tcp 192.168.1.1:7946: i/o timeout
  • 暗号化にも対応  serf keygen でランダム鍵を作成 ➡ $ serf keygen vznfEejVPSeTZphDWts4uA==  Serf v0.2.0 から対応しました。  16byte, base64 エンコード。詳細は http://www.serfdom.io/docs/internals/security.html  serf agent 起動時に指定 ➡ $ serf agent -encrypt=cg8StVXbQJ0gPvMd9o7yrg== ==> Starting Serf agent... ==> Serf agent running! Node name: 'node1.pocketstudio.net' Bind addr: '0.0.0.0:7946' RPC addr: '127.0.0.1:7373' Encrypted: true 暗号化対応によって、実環境で 使えるようになったと思います。 ➡ 同じ encrypt のノード間でのみ、通信が可能に $ serf join 192.168.10.1 [INFO] Agent joining: [192.168.10.1] [INFO] Initiating push/pull sync with: 192.168.10.1:7946 Error joining the cluster: Reading remote state failed: EOF [ERR] Failed to receive remote state: SecretKey is configured but remote state is not encrypted  接続しようとしても、エラーになります。 勿論、ログにも残ります。
  • Serf Agent 起動時オプション  コマンドラインの主要なもの ➡ 自ホスト名の指定  $ serf agent –node=nyanpasu 実際は複数のコマンドを組みあわせます。 $ serf agent –node=nyanpasu ¥ -join=192.168.10.2 ¥ -role=webapp ¥ -encrypt=XXXX ➡ 自動ジョイン先の指定 $ serf agent –join=192.168.10.2 ➡ ロールの指定 でも、これは都度実行すると大変です。 そこは、外部ファイルを使うと楽になり ます。 $ serf agent –role=webapp ➡ 暗号化 $ serf agent –encrypt=XXXX ➡ その他は、公式ドキュメント参照 • http://www.serfdom.io/docs/agent/options.html  外部ファイルを参照する場合 ➡ $ serf agent –config-file=/etc/serf.conf ➡ $ serf agent –config-dir=/etc/serf/  ディレクトリの場合は、拡張子 .json のみ 参照するので注意。
  • イベントハンドラの指定  イベントをトリガとしてコマンドを実行 ➡ Serf agent 起動時に指定 • serf agent –event-handler=“./foo.sh” • ‘serf event XXXX’ 実行時に逐次実行  より細かな制御 ➡ メンバ join 時だけ実行 • serf agent –event-handler=member-join=./foo.sh ➡ ユーザイベント発生時だけ実行 • serf agent –event-handler=user=./foo.sh ➡ ユーザイベント’deploy’時だけ実行 • serf agent –event-handler=user:deploy=./foo.sh  より詳細と参考は、Event Handlers http://www.serfdom.io/docs/agent/even t-handlers.html
  • 設定ファイルの書き方  起動オプションを設定ファイルに ➡ JSON 形式 ➡ serf agent –config-file=/etc/serf.conf { } "role": "web", "node_name": "ap3", "encrypt_key": "ukmr3yRhM39ONNWAQOAH8w==", "log_level": "debug", "start_join": [ "192.168.10.1" ], "event_handlers": [ "user=/opt/serf/foo.sh" ]  自分の場合は /etc/serf.conf にファイルを 置いています。中身が JSON なので、本 来であれば /etc/serf-conf.json のほうが 分かりやすいかもしれません。 JSON 形式なので、基本は 「”key”:”value”」の記述、複 数データは「,」区切りです。 ’start_join’と’event_handlers’ は例外で、配列として記述す る必要があります。
  • SysVinitスクリプト対応が楽かも  設定法や設置方法 ➡ Serf用のinitスクリプトを書いてみた http://pocketstudio.jp/log3/2013/11/25/sysv_init_script_for_serf  使い方  正直、stop は単に serf の PID を kill して いるだけ。そのため他のノードからする と ‘failed’ と表示されるのがイマイチ… ➡ 設定ファイルを /etc/serf.conf に JSON で記述 ➡ 起動 # service serf start ➡ 停止 # service serf stop ➡ 再起動 # service serf restart  GitHubに置いてあります ➡ https://gist.github.com/zembutsu/7640108 やはり、都度 kill したり色々面倒。 なので普段の操作環境に統一する と色々楽ですしおすし。
  • membership では、serf の挙動を理解するため “メンバーシップ” というものの、正体を見ていきます。
  • こんな風にサーバが2台あるとします。 192.168.10.1 madoka.local 192.168.10.2 homura.local
  • それぞれにSerfを入れた後は、 ‘serf join’ で相手に自分の存在を伝えます 192.168.10.1 madoka.local こんにちは 192.168.10.2 homura.local serf join
  • お互いがやりとり出来ると イベント ‘member-join’ が発生します event: member-join homura は お友達 192.168.10.1 madoka.local こんにちは 192.168.10.2 homura.local serf join にゃんぱすー madoka は お友達 event: member-join
  • そして、お互いをメンバとして認識します。 メンバは常に「イベント」を同時に共有します。 192.168.10.1 madoka.local 大切な ともだち 192.168.10.2 homura.local
  • 192.168.10.1 madoka.local おや、新しいサーバが。 サーバ madoka の 友達のようです serf join を試みます 大切な ともだち こんにちは 192.168.10.3 sayaka.local 192.168.10.2 homura.local serf join
  • event: member-join sayaka は お友達 192.168.10.1 madoka.local にゃんぱすー どうやらお友達でしたね。 ‘madoka’と’sayaka’だけでなく、 ‘madoka’ と ‘homura’ は既に友 達なので、同時にお互いのこと を友達として認識します。 大切な ともだち こんにちは 192.168.10.3 sayaka.local 192.168.10.2 homura.local sayaka は お友達 event: member-join event: member-join madoka は お友達 event: member-join madoka も お友達
  • 192.168.10.1 madoka.local 大切な ともだち これが Serf のメンバーシップ。 お互いのことを気遣いながら イベント(時間)を共有します 大切な ともだち 192.168.10.3 sayaka.local 192.168.10.2 homura.local 大切な ともだち serf event ‘お茶会’ メンバであれば、誰でも任意イ ベント ( user event ) を発効可
  • event: user ‘お茶会.sh’ 192.168.10.1 madoka.local 大切な ともだち イベントは発効した自分も含め、 同時に発生します。この時点で、 任意のスクリプトを実行できます。 ”イベントハンドラ”で指定します。 大切な ともだち 192.168.10.3 sayaka.local 192.168.10.2 homura.local 大切な ともだち event: user ‘お茶会.sh’ event: user ‘お茶会.sh’
  • event: member-leave sayaka は お友達 192.168.10.1 madoka.local 大切な ともだち 192.168.10.2 homura.local 192.168.10.3 sayaka.local 不幸にも舞台から降りることが あったとしても・・・ 障害発生 “もう何も 恐くない” event: member-leave sayaka は お友達
  • sayaka の事は 忘れないわ 192.168.10.1 madoka.local ズッ友だょ… その存在は忘れられません。 復活するその日まで、 常に話し続けようとします。 大切な ともだち 192.168.10.3 sayaka.local 192.168.10.2 homura.local ズッ友だょ… sayaka の事は 忘れないわ
  • 192.168.10.1 何を言ってるのか madoka.local 分からないよ 大切な ともだち 192.168.10.2 homura.local Make contract with me and became a magical girl! ( 僕と契約して魔法少女に! ) 192.168.10.9 kyubey.local Serf は暗号化にも対応している ので、知らないメンバが勝手に 参加することは出来ません。 以上が Serf の membersip に ついて、基本的な概念です。
  • Serf が実際に行う処理 それでは、実際の通信状況を見てみます。
  • serf 起動直後は、自分自身に対して イベント ‘member-join’ を発効します。 node1 192.168.10.1 serf: EventMemberJoin: node1 192.168.10.1 node2 192.168.10.2 serf: EventMemberJoin: node2 192.168.10.2
  • node2 が node1 に加わるときは node2 で ‘serf join’ を発効します node2 192.168.10.2 node1 192.168.10.1 serf join
  • まずは node1 に問い合わせ node2 192.168.10.2 node1 192.168.10.1 initiating push/pull sync Agent joining: [192.168.10.1] Initiating push/pull sync with: 192.168.10.1
  • 応答があれば、お互いをそれぞれの メンバとする event: member-joinが発生 node2 192.168.10.2 node1 192.168.10.1 initiating push/pull sync Responding to push/pull sync Responding to push/pull sync with: 192.168.10.2 serf: EventMemberJoin: node2 192.168.10.2 Agent joining: [192.168.10.1] Initiating push/pull sync with: 192.168.10.1 serf: EventMemberJoin: node1 192.168.10.1
  • その後は、定期的に node2 192.168.10.2 node1 192.168.10.1 initiating push/pull sync Responding to push/pull sync Initiating push/pull sync with: 192.168.10.2 Responding to push/pull sync with: 192.168.10.1
  • お互いを確認します node2 192.168.10.2 node1 192.168.10.1 initiating push/pull sync Responding to push/pull sync Responding to push/pull sync with: 192.168.10.2 Initiating push/pull sync with: 192.168.10.1
  • node2 192.168.10.2 node1 192.168.10.1 serf members serf join 3台目が加わっても 同様の処理です node3 192.168.10.3
  • node2 192.168.10.2 node1 192.168.10.1 serf members initiating push/pull sync node3 192.168.10.3 Agent joining: [192.168.10.1] Initiating push/pull sync with: 192.168.10.1 リクエストを送り
  • node2 192.168.10.2 node1 192.168.10.1 serf members serf: EventMemberJoin: node3 192.168.10.3 Responding to push/pull sync with: 192.168.10.3 serf: EventMemberJoin: node3 192.168.10.3 initiating push/pull sync node3 192.168.10.3 Responding to push/pull sync 応答があれば、それぞれ event: member-join を発効します。 Agent joining: [192.168.10.1] Initiating push/pull sync with: 192.168.10.1 serf: EventMemberJoin: node1 192.168.10.1 serf: EventMemberJoin: node2 192.168.10.2
  • node2 192.168.10.2 node1 192.168.10.1 serf members serf members 3台のメンバーシップも node3 192.168.10.3 serf members
  • node2 192.168.10.2 node1 192.168.10.1 initiating push/pull sync Responding to push/pull sync initiating push/pull sync node3 192.168.10.3 Responding to push/pull sync 2台の時と同じ お互いの応答を Responding to push/pull sync
  • node2 192.168.10.2 node1 192.168.10.1 initiating push/pull sync Responding to push/pull sync initiating push/pull sync node3 192.168.10.3 Responding to push/pull sync 相互に確認しあいます Responding to push/pull sync
  • node2 192.168.10.2 node1 192.168.10.1 serf members serf members node3 192.168.10.3 node3 で問題が起きると DOWN! initiating push/pull sync
  • node2 192.168.10.2 node1 192.168.10.1 serf members serf members node3 192.168.10.3 node3 で問題が起きると DOWN! initiating push/pull sync
  • 同時にevent member-failed が発生 node2 192.168.10.2 node1 192.168.10.1 serf: EventMemberFailed: ap3 192.168.10.3 agent: Received event: member-failed serf: attempting reconnect to node3 192.168.10.3 一度フェイルしても相手のことは覚えて います。定期的なチェックは続きます。 そのため、node3 は serf を起動するだけ で( join を明示せずに)自動的にノードに 復旧します。 serf members node3 192.168.10.3 serf: EventMemberFailed: ap3 192.168.10.3 serf: attempting reconnect to ap3 192.168.10.3 agent: Received event: member-failed serf: attempting reconnect to node3 192.168.10.3
  • 見るんじゃない、感じるんだ! Don’t think! Feel!
  • 実機デモ DEMONSTRATION
  • 作ってみた HANDMAID
  • その壱 serf-wall Serf を使って wall コマンドを同時発効してみる話
  • serf-wall 全サーバで wall コマンドを同時実行。serf のイベ ント発行がトリガです。各サーバの設定詳細を覗 いてみます。
  • これが 各サーバのconf ファイルの中身です。 JSON で記述。重要なのは “event_handlers” の箇所。 { } "role": "development", "node_name": "ap2", "encrypt_key": "ukmr3yRhM39ONNWAQOAH8w==", "log_level": "debug", "start_join": [ "192.168.10.1" ], "event_handlers": [ "user=/opt/serf/wall.sh" ] #!/bin/sh echo "${SERF_USER_EVENT}" | wall このブロックは、 お約束的な記述です。 event_handlers は、イベン トハンドラ発生時に、どのよ うな処理をするか定義します。 ここはuserイベント発生時に wall.sh を実行します。イベ ント名は環境変数で渡される ので、echo で表示し、wall にパイプで渡すだけ。
  • これを、複数台の環境に仕込んで置けば、 同時に wall コマンドを実行できます。 ある1台でコマンドを実行すると、同時にメッセージが表示 ( wall 実行 ) $ serf event 'nyanpasu-^^/' Event 'nyanpasu-^^/' dispatched! Coalescing enabled: true 偽シャットダウン風の緊張感を走らせることも出来るよ! $ serf event 'The system is going down for reboot NOW!' 本番稼働中のサーバで使って みんなを驚かせよう! 会社の皆には内緒だよっ★ 心臓に悪いので、本当に行わないでね。。。 おい、やめろ。 やめてください。
  • その弐 serf-raspi-notice Raspberry Pi の IP アドレス確認が面倒なので Serf を使って通知する話
  • serf-raspi-notice Raspberry Pi は、モニタがありません。ネット ワークに DHCP 接続すると、IP アドレスが分か らなくなります。モニタを使わずに、デスク トップにIP アドレスとホスト名を表示できます。 そう、serf ならね。
  • Raspi の通知?  問題点 ➡ Raspberry Pi は DHCP で起動させると、IP 確認が面倒 ➡ 起動時、手許の MaxOS X 上に通知させたい ダイアログ・警告音・音声  別解として、小型パネル上に IP アドレス を表示させたり、音声通知という方法も あります。しかし、リモートからでは確 認が出来ません。さらに、お金もかかり ますし・・。  解決方法 ➡ 後ろで serf を使って実現 • serf が起動するのはブートしてアドレス取得後 • その状態でノードに join させると、 イベントハンドラ member-join 時にコマンドを実行 何台 RasPi 機を用意しても、全て 同じシンプルな設定で serf が通 ります。 面倒な管理の必要はありません。 【試してみた】RaspberryPi起動・停止時にSerfで画面に通知する方法 http://pocketstudio.jp/log3/2013/11/12/raspberrypi-notify-with-serf/
  • Raspi の通知? 標準入力からホスト名とIPアドレスを取得  問題点 イベント 確認が面倒 ➡ Raspberry Pi は DHCP で起動させると、IPmember-join 時に処理 ➡ 起動時、手許の MaxOS X 上に通知させたい ダイアログ・警告音・音声 ➡ 後ろで serf を使って実現 AppleScript の‘activate’ で前面に、’display’ でダイアログ表示 こちらは離れた時の処理 【試してみた】RaspberryPi起動・停止時にSerfで画面に通知する方法 http://pocketstudio.jp/log3/2013/11/12/raspberrypi-notify-with-serf/
  • その参 serf-munin-x Munin の手動設定によるデータ参照が死ぬほど面倒なので Serf を使った話
  • serf-munin あまりメジャーではありませんが、Munin は複数サーバのデータを一つにまとめたり、 トレンドを表示させることが出来ます。
  • serfでMunin設定ファイルを自動生成  https://github.com/zembutsu/serf-munin こちらは原型になった、シンプルなものです。 member-join 時に設定ファイルを 作成します。標 準出力で、/etc/munin/conf.d/ に置いていきます。 このように、追加だけであればシンプルです。 参考:Akira Maeda さんのアプローチ素敵ですね。 とても勉強になります。 serf-muninを導入してmunin-nodeの監視追加、削除を自動化し た - Glide Note - グライドノート http://blog.glidenote.com/blog/2013/11/06/serf-munin/ serf-muninでmunin-nodeの監視自動追加/削除 http://pocketstudio.jp/log3/2013/11/01/serf-munin-eventhander-auto-monitorin/
  • 本領発揮は、従来自動化出来なかった所で  これがあれば ➡ リソースの需要予測のお供に(効率的) ➡ 異常状態のサーバを迅速に特定 cpu_idle.graph_category cpu cpu_idle.graph_title CPU idle : role app cpu_idle.graph_vlabel idle (%) cpu_idle.graph_args --lower-limit 0 cpu_idle.node1.draw LINE1 cpu_idle.node2.draw LINE1 cpu_idle.node3.draw LINE1 cpu_idle.node1.predict 86400,6 cpu_idle.node2.predict 86400,6 cpu_idle.node3.predict 86400,6 cpu_idle.graph_order ¥ node1=net;node1:cpu.idle ¥ node2=net;node2:cpu.idle ¥ node3=net;node3:cpu.idle load1.graph_category overview load1.graph_title Loads side by side type7 load1.graph_vlabel Load Average load1.graph_args --lower-limit 0 load1.graph_order ¥ node1=net;node1:load.load ¥ node2=net;node2:load.load ¥ node3=net;node3:load.load entropy.graph_category system_stability entropy.graph_title Available entropy entropy.graph_vlabel entropy (bytes) 少々面倒な記述が必要です。しかもデータ entropy.graph_args --lower-limit 0 が1つでも欠けると、グラフは描画されま entropy.graph_order ¥ せん。つまり、障害発生でサーバが落ちて node1=net;node1:entropy.entropy しまうと、グラフが表示されなくなり、 ¥ node2=net;node2:entropy.entropy まったくもって残念なことになります。 ¥ node3=net;node3:entropy.entropy 何のための Munin かという・・・ そこで考えました。
  • これまでのMunin サーバの状況を見るためには、一覧する機能 があります。しかし、
  • これまでのMunin 管理台数が増えると、縦に横にスクロールしなくてはいけません。 迅速なトラブルシュートの為にどうしたら・・・
  • だったら、複数ノードの情報を1つにしたらいいんじゃね? これは 3台のLoad Average を1つにしたグラフ。 変な挙動のサーバがあれば、一目瞭然。 ∩_∩ / \ /\ | (゜)=(゜) | | ●_● | / ヽ | 〃 ------ ヾ | \__二__ノ 人人人人人人人人人人人人人人人人人人人人人人人人人人人人人 < すごい一体感を感じる。今までにない何か熱い一体感を。 > < 風・・・なんだろう吹いてきてる確実に、着実に、俺たちのほうに。. > < 中途半端はやめよう、とにかく最後までやってやろうじゃん。 > < ネットの画面の向こうには沢山のサーバがいる。決して一人じゃない。 > < 信じよう。そしてともに戦おう。 > < 障害や過負荷はあるだろうけど、絶対に流されるなよ。 > YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
  • Muninの設定ファイルの動的調整  RDBMSの’view’のような概念 ➡ munin-node のデータは従来通り取り続ける  何かあった時は、やはり詳細を確認した いので。プラグインを削るという選択肢 はありませんでした。  比較的規模の落ち着いた環境であれば、 実現できます。しかし、今日日のように 構成が頻繁に変わる状況では、現実的に 使用に耐えうるものではありません。 ➡ トラブルシュート用のグラフを定義 • 見たい metrics のみ表示  従来までの課題 ➡ ノード追加・削除時の管理が煩雑 • 1つでもデータ欠損すると、グラフが表示されない ➡ serf のイベントをトリガにして、自動管理が実現 • ますます Munin が手放せなくなるぜ!
  • 作っているファイル [-overview;role-app] update no serf の role 毎にグループを指定 通常のグループとは異なる view 用グループを生成 load1.graph_category overview load1.graph_title Loads load1.graph_vlabel Load Average load1.graph_args --lower-limit 0 load1.graph_order ¥ node1=net;node1:load.load ¥ node2=net;node2:load.load ¥ node3=net;node3:load.load graph_order で複数のグラフを1つに。 ここは「net」グループのホスト名「node1」の、 ‘load’ プラグインの ‘load’ 値を取得
  • 作っているファイル [-overview;role-app] update no serf の role 毎にグループ カテゴリ名も任意に load1.graph_category overview load1.graph_title Loads load1.graph_vlabel Load Average load1.graph_args --lower-limit 0 load1.graph_order ¥ node1=net;node1:load.load ¥ node2=net;node2:load.load ¥ node3=net;node3:load.load graph_order で複数のグラフを1つに。 ここは「net」グループのホスト名「node1」の、 ‘load’ プラグインの ‘load’ 値を取得 参考:faq – Munin Q: How do I borrow data from another graph ? http://munin-monitoring.org/wiki/faq#Q:HowdoIborrowdatafromanothergraph
  • 作っているファイル cpu_idle.graph_category cpu cpu_idle.graph_title CPU idle : role app cpu_idle.graph_vlabel idle (%) cpu_idle.graph_args --lower-limit 0 cpu_idle.node1.draw LINE1 cpu_idle.node2.draw LINE1 cpu_idle.node3.draw LINE1 cpu_idle.graph_order ¥ node1=net;node1:cpu.idle ¥ node2=net;node2:cpu.idle ¥ node3=net;node3:cpu.idle cpu_iowait.graph_category cpu cpu_iowait.graph_title CPU iowait : role app cpu_iowait.graph_vlabel iowait (%) cpu_iowait.graph_args --lower-limit 0 cpu_iowait.graph_order ¥ node1=net;node1:cpu.iowait ¥ node2=net;node2:cpu.iowait ¥ CPUの idle状態、iowaitだけをまとめて表示するグラフを作らせる node3=net;node3:cpu.iowait 事も出来ます。どれに余裕があるかや異常を把握しやすいですね。
  • 【未来】TRENDやPREDICTもあるんだよ【日記】  TREND (単純な移動平均)であれば、 load1.node1.trend yes で表示されます。 ですが、サーバのリソースにはあまり役 立たない感じです。  PREDICT は周期的な平均を算出してます ので、TREND よりは傾向がつかみやすく なります。目で見てわかるところを、エ ビデンス的に残す役割が現実的かなと。  Munin の参考 URL #1033 (future trends and predictions) – Munin http://munin-monitoring.org/ticket/1033  [-overview;role-app-forecast] update no TREND と PREDICT の詳細については、 RRDTool のドキュメントを参照ください。 http://oss.oetiker.ch/rrdtool/doc/rrdgrap h_rpn.en.html 1日先まで # 1day graph_future 288 ## 300s = 5M ## 12 = 300s x 12 = 3600sec = 1H load1.graph_category overview load1.graph_title Loads load1.graph_vlabel Load Average load1.graph_args --lower-limit 0 縦実線は 現時刻 load1.node1.predict 86400,6 load1.node2.predict 86400,6 load1.node3.predict 86400,6 load1.graph_order ¥ 1日周期 node1=net;node1:load.load ¥ node2=net;node2:load.load ¥ node3=net;node3:load.load おおまかな 傾向分析に
  • 【未来】TRENDやPREDICTもあるんだよ【日記】 月ごとのグラフであれば、これまで・これからの傾向が なんとなく分かります。これも、serf のお陰です。
  • 今日のまとめ CONCLUSION
  • 今日のまとめ  1. Serf は汎用オーケストレーションツール ➡ http://serfdom.io/ • Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者 ➡ 分散型ソリューション • サービス検出やオーケストレーションのため • 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant ) ➡ 高い汎用性 • Immutable Infrastructure (変わらないインフラ) 向けのツ―ル  2. Serf の始めかた ➡ できる!Serf … コマンドリファレンス、画面デモ serf-wall  3. 監視システムに応用してみた話 ➡ Raspberry Pi 検出や、serf-munin で監視自動化
  • 監視と運用の世界が変わる  オーケストレーションやゴシッププロトコル ➡ 正直自分の理解の範疇を越えているので、詳しくは説明できません。ごめんなさい。 • こまけぇことは(以下略  Serf は、監視と運用の自動化の考えを変えるきっかけに…? ➡ Immutable な時代の運用とは? • deploy 技術の延長としての automation 技術が鍵 人間が対応するための監視運用システムから、 自律的運用システムの指向というパラダイム シフトの兆し――新しい風を感じます。 • 運用=operation ( 作業 ) ではなく、運用=logistics ( 兵站 ) に変わろうとしている ➡ 抽象化されるInfrastructureと、そうでない環境の混在 • 人間による運用の限界(人間がボトルネック)、そこを支える自動化技術 • serf は、インフラや運用担当者にとって武器に成り得るのではないか • 自動的に障害要因の特定や対処、予測への応用も可能か ➡ 拡がるコンピューティングの世界 • 現実世界の物やサービスと、コンピューティングの融合が産み出す新しい社会
  • 導き出される結論は CONCLUSION
  • マ ド カ Serfは神 MADOKA 偏在する使者としての存在
  • とりあえず触ってみなイカ?  簡単に動きます。簡単に試せます。 ➡ wget で回収 ( http://serfdom.io/ ) ➡ unzip ➡ ./serf agent ➡ ./serf –join=192.168.0.2  応用方法は、自分次第。 ➡ コマンドは何でも実行できる! • 自分の PC に仕込んで、 自動出退勤管理とかにも!? うはー 夢がひろがりんぐwwww ^^^^^^^^^^^^^^^円環の理、ゴシッププロトコルな意味でも
  • 参考情報 REFERENCE and RESOURCES
  • 参考情報・情報源  Serf ➡ ➡ GitHub … http://github.com/hashicorp/serf ➡ Serf Google Group … https://groups.google.com/forum/#!forum/serfdom ➡  ドキュメント … http://serfdom.io/  ドキュメントは常に最新バージョン向け に書き換わっているので要注意かも。 GitHub は issues も参考になります。 IRC … #serfdom ( Freenode )  Immutable Infrastructure ➡ Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowler • ➡ 今さら聞けない Immutable Infrastructure - 昼メシ物語 - @mirakui氏 • ➡ http://blog.mirakui.com/entry/2013/11/26/231658 http://mizzy.org/blog/2013/10/29/1/ 最近の仮想化界隈を知る:VMWareからCoreOSまで - 射撃しつつ前転b - @tkng氏 • ➡  インフラ系技術の流れ - Gosuke Miyashita - @gosukenator氏 • ➡ http://chadfowler.com/blog/2013/06/23/immutable-deployments/ http://tkng.org/b/2013/11/17/vm-and-container/ 2014年のウェブシステムアーキテクチャ - stanaka's blog - @stanaka氏 • http://blog.stanaka.org/entry/2013/12/01/092642 勉強になりますm(__)m みなさん素晴らしい!!
  • 参考情報・情報源  Serf and orchestration ➡ "HighLoad++" developer Conference heavily loaded systems • ➡ https://github.com/kentaro/serf-hosts • Utopian Rubber Bands •  http://blog.glidenote.com/blog/2013/11/06/serf-munin/ Automatic /etc/hosts management with Serf • ➡ http://blog.glidenote.com/blog/2013/10/30/serf-haproxy/ serf-muninを導入してmunin-nodeの監視追加、削除を自動化した - Glide Note - グライドノート @glidenote氏 • ➡ Towards FutureOps: Stable, repeatable, environments from dev to proud. http://www.slideshare.net/profyclub_ru/8-mitchell-hashimoto-hashicorp Redis Cluster http://megam.in/post/66659169136/utopian-redis-cluster 自分のblog記事 http://pocketstudio.jp/log3/tag/serf/ ➡ ➡ 【試してみた】RaspberryPi起動・停止時にSerfで画面に通知する方法  serf-muninでmunin-nodeの監視自動追加/削除 • • ➡ http://pocketstudio.jp/log3/2013/11/01/serf-munin-eventhander-auto-monitorin/ http://pocketstudio.jp/log3/2013/11/12/raspberrypi-notify-with-serf/ 【Serf】v0.2.0 へのバージョンアップと、変わった所を確認してみた • ➡ Serf の背景が一番詳しい資料です。 Immutable Infrastructure という文脈で、 Vagrant Packer そして Serf が登場! Serf+HAProxyで作るAutomatic Load Balancer - Glide Note - グライドノート @glidenote氏 • ➡  http://pocketstudio.jp/log3/2013/11/02/serf-version-0-2-0/ Serf用のinitスクリプトを書いてみた • http://pocketstudio.jp/log3/2013/11/25/sysv_init_script_for_serf/ 手前の所ですみません(;´Д`)
  • 質疑応答  / ̄\ | | \_/ | / ̄ ̄ \ / \ / \ / ⌒ ⌒ \ よくぞ訊いてくれた | (__人__) | 褒美としてオプーナを買う権利をやる \ ` ⌒´ / ☆ /ヽ、--ー、__,-‐´ \─/ / > ヽ▼●▼<\ ||ー、 / ヽ、 \ i |。| |/ ヽ (ニ、`ヽ .l ヽ l |。| | r-、y `ニ ノ \ l | |ー─ |  ̄ l `~ヽ_ノ____ / ̄ ̄ ̄ ̄ヽ-'ヽ--' / オプーナ /| .| ̄ ̄ ̄ ̄ ̄ ̄|/| | ̄ ̄ ̄ ̄ ̄ ̄|/| ______ / ̄オプーナ/|  ̄|__」/_オプーナ /| ̄|__,」___ /| | ̄ ̄ ̄ ̄ ̄|/オプーナ ̄/ ̄ ̄ ̄ ̄|/ オプーナ /| / .| | ̄ ̄ ̄ ̄ ̄| ̄ ̄ ̄ ̄ ̄|/l ̄ ̄ ̄ ̄| ̄ ̄ ̄ ̄ ̄|/ | / | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄| 話した後の質問と回答ダイジェスト – –  RasPi でも Serf は使えますか? Serf は ARM に対応したバイナリが 配付されています。Go 言語の環境 を整えなくても、ARM で動いてい る Linux であれば、問題ありません。 Serf ノードが1万台になったら? 今の所答えは持ち合わせていません。 シミュレータが公開されているので、 参考になるかもしれません。 http://www.serfdom.io/docs/intern als/simulator.html 自分用のメモ – Immutable なインフラストラク チャという文脈では、監視用途に Serf を使うのは邪道かも。
  • おしまい。最後まで、ありがとうございました。