SlideShare a Scribd company logo
1 of 117
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
Serfが面白いと俺の中で話題にwwwwww
イベントハンドラ
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 を使うのは邪道かも。
おしまい。最後まで、ありがとうございました。

More Related Content

What's hot

インフラ自動化とHashicorp tools
インフラ自動化とHashicorp toolsインフラ自動化とHashicorp tools
インフラ自動化とHashicorp toolsUchio Kondo
 
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introductionMasahito Zembutsu
 
今日から業務で使える17の運用系Linuxツール、そして円環の理
今日から業務で使える17の運用系Linuxツール、そして円環の理今日から業務で使える17の運用系Linuxツール、そして円環の理
今日から業務で使える17の運用系Linuxツール、そして円環の理Masahito Zembutsu
 
Hashicorpのツール群とオーケストレーション
Hashicorpのツール群とオーケストレーションHashicorpのツール群とオーケストレーション
Hashicorpのツール群とオーケストレーションMasahito Zembutsu
 
Drone.io のご紹介
Drone.io のご紹介Drone.io のご紹介
Drone.io のご紹介Uchio Kondo
 
Dockerの基本と応用~快適コンテナライフを実現するArukas~
Dockerの基本と応用~快適コンテナライフを実現するArukas~Dockerの基本と応用~快適コンテナライフを実現するArukas~
Dockerの基本と応用~快適コンテナライフを実現するArukas~Masahito Zembutsu
 
ネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chefネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chefnpsg
 
Infrastructure as Codeの取り組みと改善
Infrastructure as Codeの取り組みと改善Infrastructure as Codeの取り組みと改善
Infrastructure as Codeの取り組みと改善Takashi Honda
 
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Masahito Zembutsu
 
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾外道 父
 
さくらのインフラコード
さくらのインフラコードさくらのインフラコード
さくらのインフラコードYukihiko SAWANOBORI
 
ZabbixのAPIを使って運用を楽しくする話
ZabbixのAPIを使って運用を楽しくする話ZabbixのAPIを使って運用を楽しくする話
ZabbixのAPIを使って運用を楽しくする話Masahito Zembutsu
 
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化Gosuke Miyashita
 
今日から始めるDigitalOcean
今日から始めるDigitalOcean今日から始めるDigitalOcean
今日から始めるDigitalOceanMasahito Zembutsu
 
AWSスポットインスタンスの真髄
AWSスポットインスタンスの真髄AWSスポットインスタンスの真髄
AWSスポットインスタンスの真髄外道 父
 
Infrastrucure as a CodeにおけるJenkinsの役割
Infrastrucure as a CodeにおけるJenkinsの役割Infrastrucure as a CodeにおけるJenkinsの役割
Infrastrucure as a CodeにおけるJenkinsの役割Takashi Honda
 
すごく分かるwarden
すごく分かるwardenすごく分かるwarden
すごく分かるwardeni_yudai
 
2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについてMasahito Zembutsu
 
Pythonユーザのための構成管理入門 #pyconapac
Pythonユーザのための構成管理入門 #pyconapacPythonユーザのための構成管理入門 #pyconapac
Pythonユーザのための構成管理入門 #pyconapacTakeshi Komiya
 

What's hot (20)

インフラ自動化とHashicorp tools
インフラ自動化とHashicorp toolsインフラ自動化とHashicorp tools
インフラ自動化とHashicorp tools
 
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction
 
今日から業務で使える17の運用系Linuxツール、そして円環の理
今日から業務で使える17の運用系Linuxツール、そして円環の理今日から業務で使える17の運用系Linuxツール、そして円環の理
今日から業務で使える17の運用系Linuxツール、そして円環の理
 
Hashicorpのツール群とオーケストレーション
Hashicorpのツール群とオーケストレーションHashicorpのツール群とオーケストレーション
Hashicorpのツール群とオーケストレーション
 
Drone.io のご紹介
Drone.io のご紹介Drone.io のご紹介
Drone.io のご紹介
 
Dockerの基本と応用~快適コンテナライフを実現するArukas~
Dockerの基本と応用~快適コンテナライフを実現するArukas~Dockerの基本と応用~快適コンテナライフを実現するArukas~
Dockerの基本と応用~快適コンテナライフを実現するArukas~
 
ネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chefネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chef
 
Infrastructure as Codeの取り組みと改善
Infrastructure as Codeの取り組みと改善Infrastructure as Codeの取り組みと改善
Infrastructure as Codeの取り組みと改善
 
Reading NATS
Reading NATSReading NATS
Reading NATS
 
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
 
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾
 
さくらのインフラコード
さくらのインフラコードさくらのインフラコード
さくらのインフラコード
 
ZabbixのAPIを使って運用を楽しくする話
ZabbixのAPIを使って運用を楽しくする話ZabbixのAPIを使って運用を楽しくする話
ZabbixのAPIを使って運用を楽しくする話
 
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
 
今日から始めるDigitalOcean
今日から始めるDigitalOcean今日から始めるDigitalOcean
今日から始めるDigitalOcean
 
AWSスポットインスタンスの真髄
AWSスポットインスタンスの真髄AWSスポットインスタンスの真髄
AWSスポットインスタンスの真髄
 
Infrastrucure as a CodeにおけるJenkinsの役割
Infrastrucure as a CodeにおけるJenkinsの役割Infrastrucure as a CodeにおけるJenkinsの役割
Infrastrucure as a CodeにおけるJenkinsの役割
 
すごく分かるwarden
すごく分かるwardenすごく分かるwarden
すごく分かるwarden
 
2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて
 
Pythonユーザのための構成管理入門 #pyconapac
Pythonユーザのための構成管理入門 #pyconapacPythonユーザのための構成管理入門 #pyconapac
Pythonユーザのための構成管理入門 #pyconapac
 

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

Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力
Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力
Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力ThinReports
 
Fluxflex meetup 2011 in Tokyo
Fluxflex meetup 2011 in TokyoFluxflex meetup 2011 in Tokyo
Fluxflex meetup 2011 in TokyoKyosuke Inoue
 
Docker hands on nifty sakura jul19
Docker hands on nifty sakura jul19Docker hands on nifty sakura jul19
Docker hands on nifty sakura jul19Masahito Zembutsu
 
マイクロサービス時代の生存戦略 with HashiCorp
マイクロサービス時代の生存戦略 with HashiCorpマイクロサービス時代の生存戦略 with HashiCorp
マイクロサービス時代の生存戦略 with HashiCorpMasahito Zembutsu
 
分散環境におけるDocker とオーケストレーション
分散環境におけるDocker とオーケストレーション分散環境におけるDocker とオーケストレーション
分散環境におけるDocker とオーケストレーションMasahito Zembutsu
 
クラウド時代のネットワーク再入門
クラウド時代のネットワーク再入門クラウド時代のネットワーク再入門
クラウド時代のネットワーク再入門Naoto MATSUMOTO
 
Movable Type for AWS - JAWS-UG 沖縄 CMS祭り!
Movable Type for AWS - JAWS-UG 沖縄 CMS祭り!Movable Type for AWS - JAWS-UG 沖縄 CMS祭り!
Movable Type for AWS - JAWS-UG 沖縄 CMS祭り!Yuji Takayama
 
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)Daisuke Ikeda
 
fluxflex meetup in Tokyo
fluxflex meetup in Tokyofluxflex meetup in Tokyo
fluxflex meetup in TokyoKyosuke Inoue
 
クラウド開発に役立つ OSS あれこれ
クラウド開発に役立つ OSS あれこれクラウド開発に役立つ OSS あれこれ
クラウド開発に役立つ OSS あれこれMasataka MIZUNO
 
コンテナ技術と普及がシステム・インテグレータに与える影響
コンテナ技術と普及がシステム・インテグレータに与える影響コンテナ技術と普及がシステム・インテグレータに与える影響
コンテナ技術と普及がシステム・インテグレータに与える影響Masahito Zembutsu
 
2013OSC関西@京都_CloudStackとCloudFoundaryがまるわかり!
2013OSC関西@京都_CloudStackとCloudFoundaryがまるわかり!2013OSC関西@京都_CloudStackとCloudFoundaryがまるわかり!
2013OSC関西@京都_CloudStackとCloudFoundaryがまるわかり!Midori Oge
 
「ディープラーニングでは、エコシステムが大切よ!」
 「ディープラーニングでは、エコシステムが大切よ!」 「ディープラーニングでは、エコシステムが大切よ!」
「ディープラーニングでは、エコシステムが大切よ!」Mr. Vengineer
 
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜Hyperleger Tokyo Meetup
 
NAO/Pepper 開発環境 について
NAO/Pepper 開発環境 についてNAO/Pepper 開発環境 について
NAO/Pepper 開発環境 についてTakuji Kawata
 
Enterprise Redmine
Enterprise RedmineEnterprise Redmine
Enterprise RedmineDai FUJIHARA
 
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい) 泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい) Akihiro Kuwano
 
"Up" with vagrant and docker
"Up" with vagrant and docker"Up" with vagrant and docker
"Up" with vagrant and dockerHiroshi Miura
 
第12回CloudStackユーザ会_ApacheCloudStack最新情報
第12回CloudStackユーザ会_ApacheCloudStack最新情報第12回CloudStackユーザ会_ApacheCloudStack最新情報
第12回CloudStackユーザ会_ApacheCloudStack最新情報Midori Oge
 

Similar to Serfが面白いと俺の中で話題にwwwwww (20)

Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力
Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力
Ruby向け帳票ソリューション「ThinReports」の開発で知るOSSの威力
 
Fluxflex meetup 2011 in Tokyo
Fluxflex meetup 2011 in TokyoFluxflex meetup 2011 in Tokyo
Fluxflex meetup 2011 in Tokyo
 
Docker hands on nifty sakura jul19
Docker hands on nifty sakura jul19Docker hands on nifty sakura jul19
Docker hands on nifty sakura jul19
 
マイクロサービス時代の生存戦略 with HashiCorp
マイクロサービス時代の生存戦略 with HashiCorpマイクロサービス時代の生存戦略 with HashiCorp
マイクロサービス時代の生存戦略 with HashiCorp
 
分散環境におけるDocker とオーケストレーション
分散環境におけるDocker とオーケストレーション分散環境におけるDocker とオーケストレーション
分散環境におけるDocker とオーケストレーション
 
クラウド時代のネットワーク再入門
クラウド時代のネットワーク再入門クラウド時代のネットワーク再入門
クラウド時代のネットワーク再入門
 
Movable Type for AWS - JAWS-UG 沖縄 CMS祭り!
Movable Type for AWS - JAWS-UG 沖縄 CMS祭り!Movable Type for AWS - JAWS-UG 沖縄 CMS祭り!
Movable Type for AWS - JAWS-UG 沖縄 CMS祭り!
 
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
 
fluxflex meetup in Tokyo
fluxflex meetup in Tokyofluxflex meetup in Tokyo
fluxflex meetup in Tokyo
 
クラウド開発に役立つ OSS あれこれ
クラウド開発に役立つ OSS あれこれクラウド開発に役立つ OSS あれこれ
クラウド開発に役立つ OSS あれこれ
 
コンテナ技術と普及がシステム・インテグレータに与える影響
コンテナ技術と普及がシステム・インテグレータに与える影響コンテナ技術と普及がシステム・インテグレータに与える影響
コンテナ技術と普及がシステム・インテグレータに与える影響
 
2013OSC関西@京都_CloudStackとCloudFoundaryがまるわかり!
2013OSC関西@京都_CloudStackとCloudFoundaryがまるわかり!2013OSC関西@京都_CloudStackとCloudFoundaryがまるわかり!
2013OSC関西@京都_CloudStackとCloudFoundaryがまるわかり!
 
[Japan Tech summit 2017] DEP 005
[Japan Tech summit 2017] DEP 005[Japan Tech summit 2017] DEP 005
[Japan Tech summit 2017] DEP 005
 
「ディープラーニングでは、エコシステムが大切よ!」
 「ディープラーニングでは、エコシステムが大切よ!」 「ディープラーニングでは、エコシステムが大切よ!」
「ディープラーニングでは、エコシステムが大切よ!」
 
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
 
NAO/Pepper 開発環境 について
NAO/Pepper 開発環境 についてNAO/Pepper 開発環境 について
NAO/Pepper 開発環境 について
 
Enterprise Redmine
Enterprise RedmineEnterprise Redmine
Enterprise Redmine
 
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい) 泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
 
"Up" with vagrant and docker
"Up" with vagrant and docker"Up" with vagrant and docker
"Up" with vagrant and docker
 
第12回CloudStackユーザ会_ApacheCloudStack最新情報
第12回CloudStackユーザ会_ApacheCloudStack最新情報第12回CloudStackユーザ会_ApacheCloudStack最新情報
第12回CloudStackユーザ会_ApacheCloudStack最新情報
 

More from Masahito Zembutsu

CentOS Linux 8 の EOL と対応策の検討
CentOS Linux 8 の EOL と対応策の検討CentOS Linux 8 の EOL と対応策の検討
CentOS Linux 8 の EOL と対応策の検討Masahito Zembutsu
 
さくらインターネットのコミュニティ with COVID-19
さくらインターネットのコミュニティ with COVID-19さくらインターネットのコミュニティ with COVID-19
さくらインターネットのコミュニティ with COVID-19Masahito Zembutsu
 
ブックトーク@CROSS ~SF編~ 発表資料「攻殻機動隊」「導きの星」
ブックトーク@CROSS ~SF編~ 発表資料「攻殻機動隊」「導きの星」ブックトーク@CROSS ~SF編~ 発表資料「攻殻機動隊」「導きの星」
ブックトーク@CROSS ~SF編~ 発表資料「攻殻機動隊」「導きの星」Masahito Zembutsu
 
インターネットでウェブサイトを表示している裏側の話
インターネットでウェブサイトを表示している裏側の話インターネットでウェブサイトを表示している裏側の話
インターネットでウェブサイトを表示している裏側の話Masahito Zembutsu
 
3分で分かる「プログラミング教育・情報教育」
3分で分かる「プログラミング教育・情報教育」3分で分かる「プログラミング教育・情報教育」
3分で分かる「プログラミング教育・情報教育」Masahito Zembutsu
 
ようこそオンラインの展示会場へ
ようこそオンラインの展示会場へようこそオンラインの展示会場へ
ようこそオンラインの展示会場へMasahito Zembutsu
 
小学校プログラミング教育に対する企業の取り組みと課題 #KOF2020
小学校プログラミング教育に対する企業の取り組みと課題 #KOF2020小学校プログラミング教育に対する企業の取り組みと課題 #KOF2020
小学校プログラミング教育に対する企業の取り組みと課題 #KOF2020Masahito Zembutsu
 
オンライン発表で気を付けているポイント~姿勢編
オンライン発表で気を付けているポイント~姿勢編オンライン発表で気を付けているポイント~姿勢編
オンライン発表で気を付けているポイント~姿勢編Masahito Zembutsu
 
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解Masahito Zembutsu
 
Docker 9 tips~意外と知られていない日常で役立つ便利技
Docker 9 tips~意外と知られていない日常で役立つ便利技Docker 9 tips~意外と知られていない日常で役立つ便利技
Docker 9 tips~意外と知られていない日常で役立つ便利技Masahito Zembutsu
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」Masahito Zembutsu
 
クリスマスに工場(Factorio)を作るゲームをしよう
クリスマスに工場(Factorio)を作るゲームをしようクリスマスに工場(Factorio)を作るゲームをしよう
クリスマスに工場(Factorio)を作るゲームをしようMasahito Zembutsu
 
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Masahito Zembutsu
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Masahito Zembutsu
 
2020年から始まる小学校プログラミング教育の話 #osc19os
2020年から始まる小学校プログラミング教育の話 #osc19os2020年から始まる小学校プログラミング教育の話 #osc19os
2020年から始まる小学校プログラミング教育の話 #osc19osMasahito Zembutsu
 
CNCF Updates 2019 Winter version and Knative
CNCF Updates 2019  Winter version and KnativeCNCF Updates 2019  Winter version and Knative
CNCF Updates 2019 Winter version and KnativeMasahito Zembutsu
 
[1C5] Docker Comose & Swarm mode Orchestration (Japan Container Days - Day1)
[1C5] Docker Comose & Swarm mode Orchestration (Japan Container Days - Day1)[1C5] Docker Comose & Swarm mode Orchestration (Japan Container Days - Day1)
[1C5] Docker Comose & Swarm mode Orchestration (Japan Container Days - Day1)Masahito Zembutsu
 

More from Masahito Zembutsu (20)

CentOS Linux 8 の EOL と対応策の検討
CentOS Linux 8 の EOL と対応策の検討CentOS Linux 8 の EOL と対応策の検討
CentOS Linux 8 の EOL と対応策の検討
 
さくらインターネットのコミュニティ with COVID-19
さくらインターネットのコミュニティ with COVID-19さくらインターネットのコミュニティ with COVID-19
さくらインターネットのコミュニティ with COVID-19
 
Docker Chronicle 2021.09
Docker Chronicle  2021.09Docker Chronicle  2021.09
Docker Chronicle 2021.09
 
ブックトーク@CROSS ~SF編~ 発表資料「攻殻機動隊」「導きの星」
ブックトーク@CROSS ~SF編~ 発表資料「攻殻機動隊」「導きの星」ブックトーク@CROSS ~SF編~ 発表資料「攻殻機動隊」「導きの星」
ブックトーク@CROSS ~SF編~ 発表資料「攻殻機動隊」「導きの星」
 
インターネットでウェブサイトを表示している裏側の話
インターネットでウェブサイトを表示している裏側の話インターネットでウェブサイトを表示している裏側の話
インターネットでウェブサイトを表示している裏側の話
 
3分で分かる「プログラミング教育・情報教育」
3分で分かる「プログラミング教育・情報教育」3分で分かる「プログラミング教育・情報教育」
3分で分かる「プログラミング教育・情報教育」
 
ようこそオンラインの展示会場へ
ようこそオンラインの展示会場へようこそオンラインの展示会場へ
ようこそオンラインの展示会場へ
 
小学校プログラミング教育に対する企業の取り組みと課題 #KOF2020
小学校プログラミング教育に対する企業の取り組みと課題 #KOF2020小学校プログラミング教育に対する企業の取り組みと課題 #KOF2020
小学校プログラミング教育に対する企業の取り組みと課題 #KOF2020
 
オンライン発表で気を付けているポイント~姿勢編
オンライン発表で気を付けているポイント~姿勢編オンライン発表で気を付けているポイント~姿勢編
オンライン発表で気を付けているポイント~姿勢編
 
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解
 
Jitsi Meetとは?
Jitsi Meetとは?Jitsi Meetとは?
Jitsi Meetとは?
 
Docker 9 tips~意外と知られていない日常で役立つ便利技
Docker 9 tips~意外と知られていない日常で役立つ便利技Docker 9 tips~意外と知られていない日常で役立つ便利技
Docker 9 tips~意外と知られていない日常で役立つ便利技
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
クリスマスに工場(Factorio)を作るゲームをしよう
クリスマスに工場(Factorio)を作るゲームをしようクリスマスに工場(Factorio)を作るゲームをしよう
クリスマスに工場(Factorio)を作るゲームをしよう
 
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
 
2020年から始まる小学校プログラミング教育の話 #osc19os
2020年から始まる小学校プログラミング教育の話 #osc19os2020年から始まる小学校プログラミング教育の話 #osc19os
2020年から始まる小学校プログラミング教育の話 #osc19os
 
Docker Compose 徹底解説
Docker Compose 徹底解説Docker Compose 徹底解説
Docker Compose 徹底解説
 
CNCF Updates 2019 Winter version and Knative
CNCF Updates 2019  Winter version and KnativeCNCF Updates 2019  Winter version and Knative
CNCF Updates 2019 Winter version and Knative
 
[1C5] Docker Comose & Swarm mode Orchestration (Japan Container Days - Day1)
[1C5] Docker Comose & Swarm mode Orchestration (Japan Container Days - Day1)[1C5] Docker Comose & Swarm mode Orchestration (Japan Container Days - Day1)
[1C5] Docker Comose & Swarm mode Orchestration (Japan Container Days - Day1)
 

Recently uploaded

20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 

Recently uploaded (12)

20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 

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