Serfが面白いと俺の中で話題にwwwwww 【改訂版】

serf が面白いと俺の中で話題にwwwwww 『ニンゲンヤメマスカ→運用自動化への希望、オーケストレーション』 @zembutsu Masahito Zembutsu Mar 1, 2013 オープンクラウドにゃんぱすー Open Source Conference 2014 Tokyo/Spring #osc14tk

今回の資料は「改訂版」です。昨年12月に公開した資料のアップデート版という位置づけです。最新情報にあわせて書き換えました。 Serf アップデート情報 New! 参考 https://github.com/hashicorp/serf/blob/master/CHANGELOG.md

version 0.3.0 (2013年12月5日)  主な追加機能 ➡ 設定ファイルに “profile” を追加  WAN, LAN, LOCAL モードの指定が可能に  kill -1 <PID> が使えるので、一般的な linux プロセス風に扱えます。微妙に便利。 ➡ CLI コマンドに “leave” が使えるように ➡ SIGINT や SIGTERM を指定できる ➡ SIGHUP で設定ファイルを再読み込み  主な改良点 ➡ “SERF_USER_LTIME” イベントハンドラ ➡ members 表示で正規表現を使えるように ➡ “replay_on_join” ➡ NAT 配下でも “monitor” が使える

version 0.4.0 (2014年1月31日)  主な追加機能 ➡ “role” 機能はダイナミックタグ機能に変更へ • “-tag” でキー・バリュー形式の指定 • 書き方は“-tag role=foo” に ➡ “-discover”コマンドで mDNS のサポート  重要な変更点従来の –role コマンドが置き換わります。１つのホストに対して、複数のタグを付ける事が出来るようになりました。 ➡ “members”は、-format でファイル形式指定  その他 ➡ プロトコル version 0 ( Serv 0.1 ) 非対応に  初期リリース時のバージョンで動いている serf エージェントと、互換性が無くなりました。

version 0.4.5 (2014年2月25日)  機能追加 ➡ ‘tags’ コマンドで、動的にタグの更新が可能に  主な改良点 ➡ members コマンドで、タグのフィルタ対応 ➡ members 出力の整形 ➡ agent に -iface フラグで、複数NIC環境対応従来、複数インターフェースの環境では、-bind で IP アドレスの明示が必要でした。ですが、今度は –iface=eth1 等の指定で、IP アドレスが分からなくても agent が起動出来ます。地味に便利で好きです。  何気に便利そう agent の再起動を行わなくても、タグ（旧ロール）の変更が可能になりました。しかも、複数のタグを追加・削除が可能です。 $ serf tags -set key=value Successfully updated agent tags  地味に便利確認は、serf members 等です。 $ serf members manager.pocketstudio.net 192.168.39.3:7946 alive key=value 削除も可能です。 $ serf tags -delete key Successfully updated agent tags

LVS ( Linux Virtual Server ) は、Linux 同梱の負荷分散システム。分散方式は NAT と DSR があります。ここでは、ネットワークをシンプルにしたかったので DSR で試みます。各マシンには serf をインストールします。

serf クラスタに追加するタイミングで、 LVS のノード追加コマンド (ipvsadm –a ) を発効し、バランシングに入れようと。 DSRは、ダイレクトにクライアントに対してリクエストを返します。

もし、serf ノードの１つがダウンすることがあれば、自動的に検出し、LVS のバランシング先から切り離しを行います。

また、監視対象ノードが雨後の竹の子のように増えまくっても、serf があれば、増減が楽ですよね、というのとしたかったのですが

で得しならんたれ ||| まの ||| ||| 成 ||| !! せ果んも !! すみません、時間がたりませんでした。調べて blog にあげます。ごめんなさい。 m(__)m

今日の概要  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 で監視自動化

serf-wall 今日ご紹介のデモは３つ。たとえばこんな使い方。全サーバで 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?

Why am I here? インフラエンジニアから、エヴァンジェリストですが、農業もこのまま続けます。 (意訳：コイツ馬鹿ww)

エヴァと言えば…アスカが好きです!! って、エヴァ違いや・・・

2014年冬期にチェック中の作品  本命 I should be watching… 私たち、アイドルになります！なりたいんです！ ➡ キルラキル "kill la kill" http://www.kill-la-kill.jp/  次点 ➡ 最近、妹の様子がちょっとおかしいんだが。 "Recently, My Sister is Unusual" http://imocyo-anime.com/ ➡ Z/X IGNITION "Z/X" http://zxignition.tv/ ➡ ノブナガン , ノブナガ・ザ・フール "Nobunagan" http://www.vap.co.jp/nobunagun/ ➡ ウィザード・バリスターズ～弁魔士セシル～ "Wizard Barristers" http://wizardbarristers.com/  番外 ➡ みんな集まれ！ファルコム学園 ←オススメ "Everyone Assemble! Falcom Academy" http://www.fal-gaku.com/ （ｺﾞｰﾌｧｲ!!  映画 ➡ 劇場版 THE IDOLM@STER MOVIE 輝きの向こう側へ！ "The IDOLM@STER Movie: To the Glittering Other Side!" http://www.idolmaster-anime.jp/

――最近、思います。戦争(運用)は変わった PRESENT DAY, PRESENT TIME

Before 10年前は中規模ECサイトでも、せいぜい数台（一ケタ台）の規模感。 After 今は用途に応じてサーバを分けたり、アクセスを捌くため台数が激増中

それでも、現状は Munin や Zabbix といった監視ツールのお陰で、管理台数が増えてもなんとか続けられてます。システムやリソースを俯瞰するツール群のおかげで、状況把握やトラブルシュートの速度が格段に向上したからです。

しかし、今後はどうでしょう。もうそろそろ人が介在するような監視や運用は限界かもしれない。ネ申（スーパーハカー）に頼る時代は終わろうとしているのでは。 ? 端末数の爆発的増加 M2M ; Machine to Machine このまま行くと、運用は・・・

運用を続けるためには、イカの質問に答える必要があります。 It is necessary to answer the following questions to start OPERATION. ニンゲンヤメマスカ? Do you resign as as human being? YES はい NO いいえ

オーケストレーション運用を自動化する「鍵」 What is an orchestration?

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.4.5 のバイナリが配布中 (3/1現在) ➡ オープンソースとして公開・開発 • 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 ) ライブラリの依存関係はありません。バイナリ１つを実行するだけで、全機能が使えます。

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

Serf で大切な概念の１つが、この「イベントハンドラ」と呼ばれるものです。イベント発生時に、コマンドを実行させることが出来ます。イベントハンドラ EVENT HANDLERS

イベントハンドラの扱いが胆  Serf のイベントハンドラ ➡ イベントは「ただちに」全 serf ノードに通知 ➡ イベントは4種類 • member-join ノードに誰が参加 • member-leave 誰かがメンバを離れる • member-failed メンバ参加不能すぐに情報共有できるのが特徴。 (◕‿‿◕) ←が大量にいて、情報を同期しているようなイメージでしょうか。  参考 “Event Handlers” http://www.serfdom.io/docs/agent/even t-handlers.html  serf と組みあわせると、Munin の作業もある程度自動化できます。  ‘XXXX’ という引数は、イベント名として通知され、各 serf サーバ側のスクリプトでは、環境変数 SERF_USER_EVENT で取得できます。 • member-update か user 任意イベント ➡ それぞれのイベントで、任意コマンドを実行可能 • 例：serf メンバ追加時に Munin に追加 ➡ ‘user’ イベントは特殊 • コマンド ‘serf event XXXX’ で、参加ノード全体に任意のイベントを送信出来る。

環境変数でイベントのデータを処理  4種類の環境変数 ➡ SERF_EVENT • • • • member-join member-leave member-failed member-evenr または user serf 起動時に、「何のイベント発生時」に「どのコマンドを実行するか」定義します。設定方法により、全イベントで、共通の処理を行う事もできますし、個々のイベントにおいて、別々のスクリプトを実行することもできます。例： serf agent –event-handler=“/opt/hello.sh” ➡ SERF_SELF_NAME • イベントを発行したノード名 ➡ SERF_SELF_ROLE • イベントを発行したロール ➡ SERF_TAG_${タグ名} • roleの代替、タグ名称は大文字で記述すること ➡ SERF_USER_EVENT • ユーザ定義によるイベント名称 ➡ SERF_USER_LTIME • ユーザイベントの実行回数  ver 0.3.0 からは、’serf event’ １つめの引数 ( 環境変数 SERF_USER_EVENTで引き渡し ) に加え、２つめの引数 ( 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.4.5_linux_amd64.zip https://dl.bintray.com/mitchellh/serf/0.4.5_linux_amd64.zip unzip 0.4.5_linux_amd64.zip sudo mv ./serf /usr/local/bin/serf-0.4.5 sudo ln -s /usr/local/bin/serf-0.4.5 /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 したり色々面倒。なので普段の操作環境に統一すると色々楽ですしおすし。

見るんじゃない、感じるんだ！ Don’t think! Feel!

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 homura もお友達

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 ３台目が加わっても同様の処理です 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 ３台のメンバーシップも 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 ２台の時と同じお互いの応答を 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

同時に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

作ってみた 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

これを、複数台の環境に仕込んで置けば、同時に 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 が１つでも欠けると、グラフは描画されま entropy.graph_order ¥ せん。つまり、障害発生でサーバが落ちて node1=net;node1:entropy.entropy しまうと、グラフが表示されなくなり、 ¥ node2=net;node2:entropy.entropy まったくもって残念なことになります。 ¥ node3=net;node3:entropy.entropy 何のための Munin かという・・・そこで考えました。

これまでのMunin サーバの状況を見るためには、一覧する機能があります。しかし、

これまでのMunin 管理台数が増えると、縦に横にスクロールしなくてはいけません。迅速なトラブルシュートの為にどうしたら・・・

だったら、複数ノードの情報を１つにしたらいいんじゃね？これは 3台のLoad Average を１つにしたグラフ。変な挙動のサーバがあれば、一目瞭然。 ∩＿∩ ／＼／＼ | （゜）=（゜） | | ●_● | / ヽ | 〃 ------ ヾ | ＼＿＿二＿＿ノ人人人人人人人人人人人人人人人人人人人人人人人人人人人人人＜すごい一体感を感じる。今までにない何か熱い一体感を。＞＜風・・・なんだろう吹いてきてる確実に、着実に、俺たちのほうに。. ＞＜中途半端はやめよう、とにかく最後までやってやろうじゃん。＞＜ネットの画面の向こうには沢山のサーバがいる。決して一人じゃない。＞＜信じよう。そしてともに戦おう。＞＜障害や過負荷はあるだろうけど、絶対に流されるなよ。＞ＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹ

Muninの設定ファイルの動的調整  RDBMSの’view’のような概念 ➡ munin-node のデータは従来通り取り続ける  何かあった時は、やはり詳細を確認したいので。プラグインを削るという選択肢はありませんでした。  比較的規模の落ち着いた環境であれば、実現できます。しかし、今日日のように構成が頻繁に変わる状況では、現実的に使用に耐えうるものではありません。 ➡ トラブルシュート用のグラフを定義 • 見たい metrics のみ表示  従来までの課題 ➡ ノード追加・削除時の管理が煩雑 • １つでもデータ欠損すると、グラフが表示されない ➡ 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 で複数のグラフを１つに。ここは「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 で複数のグラフを１つに。ここは「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 偏在する使者としての存在

運用を続けるためには、イカの質問に答える必要があります。 It is necessary to answer the following questions to start OPERATION. ニンゲンヤメマスカ? Do you resign as as human being? YES はい NO いいえ

とりあえず触ってみなイカ？  簡単に動きます。簡単に試せます。 ➡ wget で回収 ( http://serfdom.io/ ) ➡ unzip ➡ ./serf agent ➡ ./serf –join=192.168.0.2  応用方法は、自分次第。 ➡ コマンドは何でも実行できる！ • 自分の PC に仕込んで、自動出退勤管理とかにも！？うはー夢がひろがりんぐｗｗｗｗ ^^^^^^^^^^^^^^^円環の理、ゴシッププロトコルな意味でも

参考情報 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 |｡| | ｒ-､y ｀ﾆﾉ＼ l | |ー─ | ￣ l ｀~ヽ＿ノ＿＿＿_ ／￣￣￣￣ヽ-'ヽ--' ／オプーナ／| .|￣￣￣￣￣￣|／| |￣￣￣￣￣￣|／| ＿＿＿＿＿＿／￣オプーナ／| ￣|__」／_オプーナ／|￣|__,」＿＿_ ／| |￣￣￣￣￣|／オプーナ￣／￣￣￣￣|／オプーナ／| ／ .| |￣￣￣￣￣|￣￣￣￣￣|／l￣￣￣￣|￣￣￣￣￣|／ | ／ |￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣| 前回の質問と回答ダイジェスト – –  RasPi でも Serf は使えますか？ Serf は ARM に対応したバイナリが配付されています。Go 言語の環境を整えなくても、ARM で動いている Linux であれば、問題ありません。 Serf ノードが1万台になったら？今の所答えは持ち合わせていません。シミュレータが公開されているので、参考になるかもしれません。 http://www.serfdom.io/docs/intern als/simulator.html 自分用のメモ – Immutable なインフラストラクチャという文脈では、監視用途に Serf を使うのは邪道かも。

おしまい。ありがとうございました。  よい子の皆も Serf を試してみよう！お兄さんとの約束さ！ Serfためさなイカみんな～ @zembutsu

Serfが面白いと俺の中で話題にwwwwww 【改訂版】

by Masahito Zembutsu, Technology Evangelist at Creationline, Inc. on Mar 03, 2014

Statistics

Views

Actions

0 Embeds 0

Accessibility

Categories

Upload Details

Usage Rights

Report content

Serfが面白いと俺の中で話題にwwwwww 【改訂版】 Presentation Transcript