Re: ご注文は自動化ですか？[2]

Re: ご注文は自動化ですか？[2] オーケストレーションで仕事を楽しくする話

Masahito Zembutsu @zembutsu Technology Evangelist (Creationline, Inc) Jul20, 2014 ,#hbstudy ,Shinjyuku,Tokyo IS THE ORDER AN AUTOMATION? v1.02

This illustration credited by TAKUMI-CG / PIXTA(ピクスタ)

!

WARNING

このスライドには過激な表現やネットスラング、アニメなどアキバ的文化の演出が含まれています。

今回は冒頭から画面デモ３つの仮想マシンで Serf のクラスタを構成

コマンドを実行するだけでクラスタが構成できました。そして、瞬時にイベントが同期するデモでした。


Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going?

この先生きのこるには

我々は何処から来たのか、我々は何者か、我々は何処へ行くのか、

“Listen, kid... You’ve got a ghost, and a brain... And you can access an e-brain... Create your own future...”

「お前にだってゴーストがあるだろ脳だってついてる電脳にもアクセスできる未来をつくれ」――攻殻機動隊草薙素子



タイトルは、いろいろ旬なので・・・

https://twitter.com/zembutsu/status/483624850531950592

＼にゃんぱすー／＼ﾌｧﾝﾀｼﾞｽﾀｯﾄﾞｰ／＼やっぱり小惑星は最高だぜ！（by はやぶさ／

https://twitter.com/zembutsu/status/483624850531950592�



Re:ご注文は自動化ですか？[2] オーケストレーションで仕事を楽しくする話

Agenda

流れ

1. オーケストレーション#とは ← New

2. 基本編

・ Serf, Consul, envconsul

3. 実践編

・ API 連携、ZABBIX など

4. まとめ



Agenda

今日のまとめ

Serf や Consul は軽量シンプルでありながら、

様々なシーンに利用できる。また、他の類似

ツールを使うよりも利用の敷居が低い。

そのため、運用・開発にかかわらず、日々の

煩雑な業務から解放されるので、各々が取り

組む本来業務、とりわけ人間しかできない事

に集中できる。結果、仕事が楽しくなる。




Agenda

今日のまとめ











ご注文は監視自動化ですか？ S e r f と C o n s u l を使って運用を楽しくする話

Agenda

この時間で得られるもの

・Serf や Consul とは ○○ です(ｷﾘｯと言える

・Serf や Consul の使い所をイメージできる

・運用や開発における自動化のための仕組み

（ロジック）を自分で考えることができる



ご注文は監視自動化ですか？ S e r f と C o n s u l を使って運用を楽しくする話

Agenda

この時間で得られるもの






本日はお越しいただきありがとうございます

ニコニコ常連です。最近、ニコられ数が偶然キリ番をゲットしました！！


質問「 Serf や Consul を知っていますか？」

1. とても使ってるバッチリ使ってます

2. 使ってる検証したことあり

3. ふつう聞いたことはある

4. しらん食えるのか？ 5. 花不可避

1. とても使ってるバッチリ使ってます

会場では、使っている方と検証数名大半の方が「３」聞いたことがある、でした。


？？？「クラウドじゃないからはずかしくないもんっ！」

今日日クラウドを全く知らない！というのは、あぁ＾～という感じになりそうですが、オーケストレーションツールは新しい分野なので、知らなくても大丈夫です！というか、知っていたら、このセッションを訊く必要ありませんし、そもそも、このスライドを読む必要もありませんので。。。 Serf とか Consul とか聞くけど、イマイチわからん！という疑問はありませんか？どのような働きをするのかや、使いどころを、皆さんと共有したいなと思っています。


もう１つだけ質問「あなたの役割は？」

?


1. 運用 2. 開発 3. 両方

4. どちらでもない 5. ごらく部

アンケートへのご協力ありがとうございました

両方という方が多かったです。

1割 1割 7 割

数名

ところで、私は誰？

@zembutsu 前佛雅人

・Technology Evangelist クリエーションライン株式会社

・経歴；ホスティングの運用部隊 10年近く, 物理 10,000 台の環境メインは Linux 系運用監視・サポート所謂インフラエンジニア的な運用保守(一次,二次)データセンタ常駐企画営業広報宣伝検証開発

http://slideshare.net/zembutsu

自己紹介 Why am I here?

Munin LOVE!!

残念なスライドに定評がある・・・

http://slideshare.net/zembutsu�

わたしです

激しくアナログ

・いずれ実家で農業をするが、その時は Cloud Computing や監視、自動化等周辺技術を積極導入し、生産効率を上げたい

・ Open Source や Open Computing のように、農業生産情報化 3Dプリンタやロボット運用技術、様々なデータをネット通じオープンに共有できるように

・現在の農業情報化ソリューションは高価

ささやかなモチベーション

昔取った杵柄一応、電気工学科@高専

このあたりの技術も

ネットと現実の境界が無くなる社会の実現

農業でやると・・・でも、この業界なら

そのためにも、まずは目の前の仕事を自動化


1 ● ○ ○ ○

オーケストレーション ORCHESTRATION

Docker 入門 HOW TO USE DOCKER

「スターバックの夜食」…鯨を料理しよう

？「あーあ、猫も杓子も Docker 、Dockerか」？「みな平和なもんや」

あの日見た鯨の名前を僕達はまだ知らない。

The Docker We Saw That Day

今日、話すこと今日、話さないこと・今日話すこと - 鯨はどこから来たのか - 鯨とは何者か - 鯨はどこへ行くのか

・ Docker 技術背景や自動化、監視 - control group - namespace - aufs - devicemapper @enakai00先生の資料やいろいろな所で語られています。それに自分はさほど詳しくないので、興味があれば、自分で調べて下さいねっ

「いまからでも遅くはありません。ご覧ください！鯨はあなたを求めてはいません。やつを狂ったように求めているのは、あなた、あなたなのです！」（白鯨）

みなさんと共有する内容興味があれば、帰って自習して欲しい

「鯨」とは、 dockerであり我々エンジニアでもある

http://www.slideshare.net/enakai/docker-34668707�

技術要素としての LXC は昔からありました。Docker は、それらを簡単に利用出来るよう抽象化したシステム。

話は聞かせてもらった同じ事はクラウドでも聞いた

それ仮想化と何が違うの？

本番じゃ使えないよね

クラウド（笑）

あぁ、ゲームの

テスト環境向けかな

日本語の情報ないし

【2009年】

セキュリティがー

商習慣がー

【2014年】

弊社ではクラウドに以前から対応してきました

クラウドなんか普通でしょ

エンタープライズもクラウド

そして Docker やオーケストレーション

どこで？いつ使うの？いまでしょ？

使える所があるんだったら、使えば良いのではないでしょうか。

いまそこにある機器システム

「ヤツはまさに巨大な・・・白い青い悪魔だ・・・！」

まぁ、Linux コンテナですとか

automate engine

configuration management

system monitoring

Integration automatic operation Configuration management, recource management and system monitoring are necessary for automation . target：・Cloud Infrastructure ・Virtual Machines, Containers ・Services ( processes ) etc

management domain of orchestrator

Self-development We are plans to develop an automate engine and integration systems and services: - Algorithmic management - resource management -performance management This is the orchestrator “Pythagoras”.

Cloud providers Datacenters or, other Public Cloud Infrastuctures

Users ( access via dashboard )

AP

I resouce mangagement

API

orchestration tools

こんな応用が

Changing concepts of “operation” and “monitoring” NOW … handling to trouble is important FUTURE … make much of service continuity

The role of orchestrator is an engine to manage systems that will be

changing dynamically orchestrator

Serf Serf Serf

datacenter 1 datacenter 2 datacenter 3

GUI Operation ・It’s not necessary to be conscious of data centers. ・We do not manage the directly physical machine resources.

dashboard

Existing systems to live together

Monitoring for autonomy ・Monitoring necessary for orchestrator to work ・A system performs the existing fault detection and support automatically ・A monitroing operation needs the indexes of the service level - resource monitoring - service response time - KPI - …etc ・Therefore the cooperate that is close to each layers through “API” is important physical data centers layer

system layer

platform base layer

IaaS

Developing platform bases ・An IaaS technologies are establishing ・The infrastructure layer will be abstracted, and operation to intertwine in datacenters is necessary

shipyard, etc

Layer 1

Layer 0

example： Docker will deploys some machine images, replication setting, management, and orchestrator will recovery system

出来ないかな？

VM VM hardware

datacenter A

VM VM hardware

VM VM

hardware datacenter B

VM VM hardware

Chef Metal

Resouce management of containers and virtual / physical machines

configuration management of OS and middleware layer

Provisioning API

“Pythagoras” is orchestrator

service and node state monitoring

cloud API cloud API

We are trying to develop orchestrator called “Pythagoras”. The element of the monitoring and automation tool are indispensable here.

to migrate another data center

consul gossip pool

API API API

API

API migration

IPMI

っと、思っています。

この辺は、またどっかーで話しを。そこに至る道として、今日ご紹介する Serf や Consul は第一歩になるのではと考えています。千里の道も、一歩から！

オーケストレーション#とは WHAT IS ORCHESTRATION

「スターバックの夜食」…鯨を料理しよう

自動化

オーケストレーション機械化

自動化オートメーション

オーケストレーション

オーケストレーションは、まさにオーケストラで言う所の、指揮者。ツールが何かをするのではなく、全体を司るだけ。そして、音楽の「楽」。

楽しい楽 Easy

≠ Fun

楽しい楽 Fun Easy

≒

一斉に処理する仕組みオーケストレーション

自動化

オーケストレーション

機械化システム化

環境構築、構成管理、テスト、監視、運用業務、チケット管理 … などなど

• Apache Mesos

• Atomic / geard

• Fleet / etcd

• Orchard

• Helious

• Centurion

• Shipper

• Geard

• Serf

• Consul 他にも様様なツールがあります。今日皆さんと共有するのは Serf と Consul です。


2 ● ● ○ ○

基礎編 SERF , CONSUL, ENVCONSUL

Serf http://serfdom.io/

Serfの登場背景 Immutable Infrastructure

➡ サーバには変更を加えない（設定変更も） • 予めテスト・確認済みのイメージを使用 • イメージを使う利点は、凄く早い事

➡ 経緯 • 専用サーバ→複数台運用→VPS→クラウドの流れ • 設定管理が課題になってきた

– ネットワークが不達なら？ – パッケージ管理やバージョン管理は？ – Chef / Puppet が変わったら？

• マシンイメージの管理のため Packer を開発 – 運用ワークフローの改革

• そして、オーケストレーションツールとしての Serf – サービス発見と、オーケストレーション（運用自動処理）

勝手な理解 ➡ 迅速な対応を行う為には、Immutableな環境を！

• 「私が死んでも代わりがいるもの」 • 「ホスト名が許されるのは小学生まで(ry」といった考え？

参考 "Towards Future Ops: Stable,

repeatable, environments from dev to prod.“ http://www.slideshare.net/profyclub_ru/8-mitchell-hashimoto-hashicorp

この資料を読んで、ようやくイミュータブルなインフラについてイメージが湧いてきたような。。←出遅れています。

http://www.slideshare.net/profyclub_ru/8-mitchell-hashimoto-hashicorp�

http://www.slideshare.net/profyclub_ru/8-mitchell-hashimoto-hashicorp�

Serf の概要

軽量なオーケストレーションツール

全ノードで秒単位のイベント同期

メンバ一覧とイベントの発生を管理

障害検知、フェイルオーバー機能

Serf は軽量単純なツール

軽量簡単

バイナリファイル一個で動作

Linux, MacOS, Windows

ロールとタグ機能を持つ

重要なのは、非常に軽い点。実メモリの使用も 8KB 程度で、さほど負担になりません。同じ仕組みは、たとえばZoo Keeper でも出来るかもしれませんが、環境構築・維持が負担です。

Serf とは

Serf ➡ http://serfdom.io/ ➡ “サービス検出とオーケストレーションツール”

• ゴシッププロトコル (SWIM) を拡張 • 分散型、高可用性、耐障害性

開発状況 ➡ オープンソースで公開・開発が進行中

• Vagrant ( Oracle 社製 Virtual Box 管理ツール ) の作者、Mitchel Hashimoto 氏らが開発 • 開発言語は Go 言語：Linux, Mac OS X, Windows のバイナリが配布中

➡ リリース状況 • 2013年10月23日に version 0.1.0 が初リリース → 現在は v.0.6.2

ライセンス ➡ Mozilla Public license, version 2.0

新機能の追加も一段落し、最近は割と細かなバグ修正が中心。安定してきた印象があります。

http://serfdom.io/�

Serf は 3 つの特長

※参考 http://www.serfdom.io/intro/

メンバ管理障害検知カスタムイベント

機能はこの３つだけです。以降のページで１つ１つ見ていきます。

http://www.serfdom.io/intro/�

1. メンバ管理

クラスタ参加・離脱を管理

マスターサーバが無い（全て並列）

ロールとタグ機能を持つ

クラスタをゴシッププロトコルで構成

A B

ノード A とノード B でクラスタを構成

「A」「B」２つの Serf ノードがあとします。実際のサーバ上では、 serf エージェントが動作しています。

A B

serf join

Agent joining: [B] Initiating push/pull sync with: B

initiating push/pull sync

ノード A とノード B でクラスタを構成

クラスタ構成時、“serf join” というイベントを起こします。何かしら、特別なプログラムを起動させる必要はありません。 A が B に対してクラスタの参加 ( push と pull の同期初期化 ) を要請。要は友達リクエストです。

A B

serf join



Responding push/pull sync

Responding to push/pull sync with: A

B は A の要求に応答すると、A に対してレスポンスを返します。 ※ serf は暗号化設定すると、暗号鍵が一致しないノードとは繋がりません。

A B

serf join




Responding to push/pull sync with: A

EventMemberJoin: B EventMemberJoin: A

A B

A に B の応答が届くと、メンバー参加 ( MemberJoin ) というイベントが同時に発生します。 A は B を、B は A を認識します。

A B Initiating push/pull sync with: B Responding to push/pull sync with: A



そしてお互いをメンバとして認識したクラスタが構成されます。友達同士、ふたりはプ… Serf ☆ クラスタ！

A B Initiating push/pull sync with: A Responding to push/pull sync with: B



クラスタ構成後は、

A B Initiating push/pull sync with: B Responding to push/pull sync with: A



相互にお互いの情報を確認しあいます。

A B

Agent joining: [?]

C

ノード C が仲間になりたがってこっちを見ている！

serf join では、新しいノード C がクラスタに参加するとき、A と B 、どちらに join 宣言をしたらいいでしょうか？答えは、A ・ B どちらでも大丈夫。なぜなら、A と B でイベントを同期するので「友達の友達は友達」になるからです。

?

A B

Agent joining: [A] Initiating push/pull sync with: A


C


serf join

ここでは C が Aに join を試みます。

A B

Agent joining: [A] Initiating push/pull sync with: A

Responding to push/pull sync with: C

initiating push/pull sync Responding push/pull sync

C


serf join

A が C に応答すると・・・

A B

Agent joining: [A] Initiating push/pull sync with: B

Responding to push/pull sync with: C

initiating push/pull sync Responding push/pull sync

C


serf join

EventMemberJoin: B

EventMemberJoin: A

EventMemberJoin: C EventMemberJoin: C

メンバ参加のイベントが、3ノード同時に発生

A … C は新しい友達 B … C は新しい友達 C … A ・B は新しい友達

A B

C

ノード C が仲間に加わった！

EventMemberJoin: B

EventMemberJoin: A

EventMemberJoin: C EventMemberJoin: C

これでクラスタが構成されました。あとは、ノードが何台増えようとも、同じような動作で十数台、百台とスケールしていきます。

A B

C


initiating push/pull sync 以後はランダムに相互監視

A B

C



以後はランダムに相互監視

A B

C



以後はランダムに相互監視

A B

C


initiating push/pull sync 以後はランダムに相互監視

A B

C

これが基本動作

2. 障害検知

イベントが直ちにに伝わる

イベントハンドラで何か実行する仕組み

障害検知の仕組みを見ていきます。

A B

C

B は死んでしまった！突然の死！

クラスタを構成する1台に障害が発生。

A B

C


Initiating push/pull sync with: B


死んでも直ぐに検出できません。 B に対するチェックが応答しなくなるまでは、まだクラスタ上では生きているとみなされています。このタイムラグは、秒単位で変更可能です。

STATUS: 死野球しようぜ！

A B

C


Initiating push/pull sync with: B


返事が無い。ただの屍のようだ

EventMemberFailed: B

EventMemberFailed: B

STATUS: 死

B の応答がないため、A と C は、B の障害が発生したとみなすイベント member-failed を発行します。

A B

C

復活の時を待ち続けます

serf: attempting reconnect to


STATUS: 死

fail した段階では、まだクラスタとして認識されます。A・C 双方から、定期的に B に対してチェックが走ります。ネットワーク障害の可能性もありますし、B が復活したら、B は何もしなくてもクラスタに復旧します。

一番良いザオリクを頼む…

A B

C

反応が無い場合は切り離します



もうだめかも分からんね

EventMemberLeap: B

EventMemberLeap: B

STATUS: 死

一番良いザオリクを頼む…

規定時間(初期値は 24 時間後、変更可能) の応答がなければ、対象メンバをノードから削除する member-leap イベントが発生します。

A

B

C

残った2台でクラスタを構成します Responding push/pull sync

initiating push/pull sync ここまでがメンバーシップの基本動作です

野球しようぜ！

素振りは基本

監視ツールで対象ノードの自動削除を行うなら、この member-leap イベントの発生をトリガにします。何時削除するの？今しょ！

3. カスタムイベント

任意のイベントを自分で定義できる

・標準イベント … メンバ参加, 離脱時に

自動発生する

・カスタムイベント … いつでも実行可最後に重要なのは、このイベントを複数台同時に（数秒以内で）実行できるという点です。

ハンドサイン画像ジェネレーター http://bzmm.jp/hs_gene/

Serf 標準のイベントハンドラは6つ。

http://bzmm.jp/hs_gene/�


Serf 標準のイベントハンドラは、クラスタ形成 (メンバーシップ)の管理。一方、‘event’ や ‘query’ は、任意のタイミングで発生させることが出来ます。



しかも、それを3台同時に実行可能。クラスタは並列なので、どのノードが起点になってイベントを発行しても構いません。



それが、もっと増えても・・・



やっぱり Serf ! 100 ノード同時実行でも大丈夫！

※理論値 1秒で 95% 、2秒でほぼ100%伝播 ( 物置かな？ )


もう少しkwsk

ここから先は座学的なところ。実際に使うときに参考にしていただければと思います。

適用例

ウェブサーバとロードバランサ ➡ ウェブサーバの稼働状況に応じて、ロードバランサの適用・除外を行う

Memcached や Redis クラスタ ➡ Serf のメンバーシップと、それぞれのクラスタを連携

デプロイ時のトリガ ➡ Serf の ‘event’ システムを用いて、ノードがメッセージ受信時、ただちにデプロイ開始

DNS レコードの更新 ➡ ノードの参加・離脱のタイミングで即時にレコードを更新

単純な監視 ➡ ‘query’ を用いて、uptime を全ノードに対して同時実行し、結果を表示

サービス検出のための基礎部分を構築 ➡ 上記の例を実現するための仕組みを、Serf は内包している。 ➡ いずれも中央集権型ではなく、マスターは不要。耐障害性を持っている。

※ http://www.serfdom.io/intro/use-cases.html

日々、私たちが運用現場で使っている「手作業」にあたる部分を自動実行し、省力化につながります。

http://www.serfdom.io/intro/use-cases.html�

他ツールとの比較

Zookeepr, doozerd, etcd ➡ Serf と同様のクライアント・サーバ型のアーキテクチャ

• これらは、（ツールとして使うには）比較的複雑な分散システム

➡ Serf が提供する機能は、メンバーシップ管理、障害検知、ユーザイベントのみ。

Chef, Puppet 等々 ➡ 構成管理ツールは、メンバシップ管理までは行う。 ➡ ツールの目的は、タスクを処理することで、迅速な実行や障害検知意識されていない。 ➡ Serf は、これらツールと並行利用出来る。

Fabric ➡ Fabric は、デプロイ・システム管理ツール。

• Serf より優れている点がいくつか（例：コマンド実行エラー時に、何か処理を実行） • 実行速度の遅さや、ノード検出に関する課題がある。

➡ Serf は、何かしら実行結果(output_が必要なときに連携する使い方 • Fabric が Serf ノードに対して問い合わせを行い、Serf は一斉に実行

Serf クラスタを維持するための手間が、他のツールよりもかからず、既存のシステム構成を変えるひつようもありません。

Serf の基本的な使い方

セットアップと実行

エージェントの起動

$ cd /tmp $ wget -O 0.5.0_linux_amd64.zip https://dl.bintray.com/mitchellh/serf/0.5.0_linux_amd64.zip $ unzip 0.5.0_linux_amd64.zip # mv ./serf /usr/local/bin

$ serf agent 動かすのは超簡単。バイナリをダウンロードして実行するだけ。シンプルなのが、Serf の魅力の一つかなと思います。

※参考：Serf設定オプションまとめ http://pocketstudio.jp/log3/2014/03/29/serf_configuration_quick_guide/

http://pocketstudio.jp/log3/2014/03/29/serf_configuration_quick_guide/�

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 ) 7. イベントが届きます 2013/12/05 19:36:17 [INFO] agent: Received event: user-event: Hello world!

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!

同時にイベントが発行されるのがポイントです。 ※どのサーバからもイベントを送ることが出来ます。このタイミングで、任意のコマンドを実行することが出来るのが serf の面白い所ではないでしょうか。

イベントハンドラ

イベントで、任意のコマンドを実行 ➡ メンバーシップに関連するイベント

• member-join • member-failed • member-leave • member-reap • member-update

➡ カスタムイベント・クエリ • event • query

データは環境変数や標準入力から取得 ➡ イベント名称は、${SERF_EVENT} ( bash )

※参考【Serf】イベントハンドラを整理してみる

http://pocketstudio.jp/log3/2014/04/01/serf_event_handlers/

このイベント処理が肝心です

http://pocketstudio.jp/log3/2014/04/01/serf_event_handlers/�

Serf CLI

CLI の主な管理コマンド ➡ serf members メンバ一覧の表示

➡ serf monitor ログ表示

➡ serf join <ホスト名> ノードに参加

➡ serf force-leave <ホスト名> ノード強制切り離し

‘serf’ はエージェントとして稼働するときに使うほか、コマンドライン・ツールとしても使用します。

serf agent コマンドを実行していなくても、serf のログ状況を確認することができます。デバッグ時は必見。

慣れてくると、agent 起動時に ‘serf agent –join=xxx’ と指定したり、設定ファイルを用意した方が楽です。

間違いなく対象ホストがダウンしている場合など使うようです。force-leaveされた側から接続しようとしても、タイムアウトして接続できなくなります。

node1 192.168.10.1 alive dev node2 192.168.10.2 alive dev node3 192.168.10.3 left standby ホスト名 IPアドレス状態ロール名

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

[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 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 agent 起動時に指定 ➡ $ serf agent -encrypt=cg8StVXbQJ0gPvMd9o7yrg==

➡ 同じ encrypt のノード間でのみ、通信が可能に

Serf v0.2.0 から対応しました。

16byte, base64 エンコード。詳細は

http://www.serfdom.io/docs/internals/security.html

接続しようとしても、エラーになります。勿論、ログにも残ります。

==> 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

$ 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

暗号化対応によって、実環境で使えるようになったと思います。

http://www.serfdom.io/docs/internals/security.html�

http://www.serfdom.io/docs/internals/security.html�

Serf Agent 起動時オプション

コマンドラインの主要なもの ➡ 自ホスト名の指定

$ serf agent –node=nyanpasu

➡ 自動ジョイン先の指定 $ 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/

実際は複数のコマンドを組みあわせます。 $ serf agent –node=nyanpasu ¥ -join=192.168.10.2 ¥ -role=webapp ¥ -encrypt=XXXX でも、これは都度実行すると大変です。そこは、外部ファイルを使うと楽になります。

ディレクトリの場合は､拡張子 .json のみ参照するので注意。

http://www.serfdom.io/docs/agent/options.html�

イベントハンドラの指定

イベントをトリガとしてコマンドを実行 ➡ 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/event-handlers.html

http://www.serfdom.io/docs/agent/event-handlers.html�

http://www.serfdom.io/docs/agent/event-handlers.html�

設定ファイルの書き方

起動オプションを設定ファイルに ➡ JSON 形式 ➡ serf agent –config-file=/etc/serf.conf

自分の場合は /etc/serf.conf にファイルを置いています。中身が JSON なので、本来であれば /etc/serf-conf.json のほうが分かりやすいかもしれません。

{ "role": "web", "node_name": "ap3", "encrypt_key": "ukmr3yRhM39ONNWAQOAH8w==", "log_level": "debug", "start_join": [ "192.168.10.1" ], "event_handlers": [ "user=/opt/serf/foo.sh" ] }

JSON 形式なので、基本は「”key”:”value”」の記述、複数データは「,」区切りです。 ’start_join’と’event_handlers’は例外で、配列として記述する必要があります。

SysVinitスクリプト対応が楽かも

設定法や設置方法 ➡ Serf用のinitスクリプトを書いてみた

http://pocketstudio.jp/log3/2013/11/25/sysv_init_script_for_serf

使い方 ➡ 設定ファイルを /etc/serf.conf に JSON で記述 ➡ 起動

# service serf start ➡ 停止

# service serf stop ➡ 再起動

# service serf restart

GitHubに置いてあります ➡ https://gist.github.com/zembutsu/7640108

正直、stop は単に serf の PID を kill しているだけ。そのため他のノードからすると ‘failed’ と表示されるのがイマイチ…

やはり、都度 kill したり色々面倒。なので普段の操作環境に統一すると色々楽ですしおすし。

http://pocketstudio.jp/log3/2013/11/25/sysv_init_script_for_serf/�

https://gist.github.com/zembutsu/7640108�

クエリとイベント

違い ➡ クエリは結果を取得できる ➡ イベントは一方的に処理する（結果問わず）

指定方法は、イベントハンドラで ‘query’ ➡ $ serf agent -iface=eth1 -discover=serf ¥

-event-handler=query=uptime

出力結果は、標準出力の他に JSON も選択できます。

$ serf query test Query 'test' dispatched Ack from 'node2.pocketstudio.net' Response from 'node2.pocketstudio.net': 23:52:55 up 5:23, 2 users, load average: 0.00, 0.00, 0.00 Ack from 'node1.pocketstudio.net' Response from 'node1.pocketstudio.net': 23:52:55 up 5:08, 2 users, load average: 0.04, 0.01, 0.00 Total Acks: 2 Total Responses: 2

軽量簡単なオーケストレーションツール

システム全体を統括する「何か」

自分の中では、

「日々の運用業務の面倒な事を」

よしなに処理するための仕組み

Serf のまとめ

http://pocketstudio.jp/log3/tag/serf/

定期メンテに活躍しそう。一年前に欲しかった。。

http://pocketstudio.jp/log3/tag/serf/�

LVS への応用

LVS Web1 Web2

192.168.39.0/24

192.168.39.1 192.168.39.11 192.168.39.12

DSR 型の構成を考えてみます。 HTTP のロードバランサを作ります。

LVS Web1 Web2

192.168.39.0/24

192.168.39.1 192.168.39.11 192.168.39.12

サーバ側 # yum -y install ipvsadm # /sbin/chkconfig ipvsadm on $ /sbin/chkconfig --list ipvsadm ipvsadm 0:off 1:off 2:on 3:on 4:on 5:on 6:off # sysctl -w net.ipv4.ip_forward=1 # sysctl -w net.ipv4.conf.default.rp_filter=0

ノード側 # iptables -t nat -A PREROUTING -d 192.168.39.1 -j REDIRECT

こんな風に初期設定を済ませます。

LVS Web1 Web2

192.168.39.0/24

192.168.39.1 192.168.39.11 192.168.39.12 # ipvsadm -A -t 192.168.39.1:80 -s rr # ipvsadm -a -t 192.168.39.1:80 -r 192.168.39.11:80 -g # ipvsadm -a -t 192.168.39.1:80 -r 192.168.39.12:80 -g # ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.39.1:80 rr -> 192.168.39.11:80 Route 1 0 0 -> 192.168.39.12:80 Route 1 0 0

追加：ipvsadm –a 削除： ipvsadm –d

ノードの追加や削除には、こんな作業が必要ですが、Serf があれば …

#!/bin/sh while read line do echo ${line} HOSTNAME=ècho ${line} | cut -d ' ' -f 1` ADDRESS=ècho ${line} | cut -d ' ' -f 2` ROLE=ècho ${line} | cut -d ' ' -f 3` case ${SERF_EVENT} in "member-join") if [ "${ROLE}" = "webapp" ] ; then ipvsadm -a -t 192.168.39.1:80 -r ${ADDRESS}:80 -g fi;; "member-leave" | "member-failed") if [ "${ROLE}" = "webapp" ] ; then ipvsadm -d -t 192.168.39.1:80 -r ${ADDRESS}:80 fi;; ¥?) echo "other";; esac break done exit 0

イベントハンドラ発生で実行するスクリプト例

標準入力からホスト名 IP アドレスロール名を取得

環境変数で判別 ${SERV_EVENT} クラスタ参加時

‘ipvsadv –a’ を実行し LVS に登録する

クラスタ離脱・障害時 ‘ipvsadv –d’ を実行し LVS から削除する Serf が起動している

間は、常に待ち受け

これはシェルスクリプトですが、もちろん、他の言語も利用可能ですし MessagePack-RPC を経由した制御も行う事が出来ます。

ノード自身が停止←わかる

HTTP だけ止まった場合は？

Consul http://www.consul.io/

そこで、Consul の登場です。 Serf がノード単位であるのに対し、Consul はサービス単位で監視します。 Serf を作った Hashicorp から、今年 4月にリリースされました。

Consul は Serf の仕組みにサービス検出を乗せたもの

Consul を支える基礎技術メッセージング ( Messageing ) … SWIM , Serf

リーダー選出 ( Leader Election ) … Raft

セキュリティ ( Security ) … TLS

データストレージ ( Data Storage ) … UMDB

Understand Distributed Consensus http://thesecretlivesofdata.com/raft/

Consul の追加技術が Serf を内包。

http://thesecretlivesofdata.com/raft/�

Consul のサービス監視非中央集権型の Consul サーバ

ノードが主体の監視（サービスや間隔）

リアルタイムに動作する

現状を知るだけ、時系列データは保持しない

監視の役割に注視すると、障害発生など、サービスが変更したタイミングで、任意の動作を行えます。

従来ツールとの比較・従来ツールによる障害検出は、監視サーバ主体

・サーバまたはノードが異常を検知するまでのタイムラグがあった

・ Consul による障害検出は、ノード主体

・異常をただちに検出する。

( 正確には、サービスを定義した監視時間間隔、またはノードダウン )

・ envconsul と連携することで、障害発生後のアクションを行える

障害対応の自動化に繋げることも

・対象ノードでアクション不要なら、エージェントレスの構成も

マシン層：ノードの死活監視（追加・削除）・何らかのコマンドを処理する実行部隊

・自己完結指向

サービス単位と、ノード単位の監視・Consul サーバはデータを溜め、他のプログラムを仲介

・Consul ノードは実行部隊

では、Consul と Serf の関係は？

ハードウェア

ミドルウェア

ミドルウェア

サービスサービス

OS

ハードウェア

ミドルウェア

ミドルウェア


OS

ハードウェア

ミドルウェア

ミドルウェア


OS

非中央集権型中央集権型

サービス指向

インフラ指向

従来ツールとの関係共存できる … 微妙に異なる監視レイヤ

機能的には相互補完

導入時、既存システムを変える必要がない例１： Consul はノード内のサービス状況を取得し、Consul Serverに送る ZABBIX Sender で Consul の KVS からデータを取得し、時系列データ収集必要に応じてアラートの送信や、更に他のツールとの連携をする例２：Munin プラグインが Consul Server の KVS から情報を取得し、 munin-node を入れなくても、Munin でグラフを表示し、管理も自動化

むしろ、既存の監視ツールが出来なかった「何か」を可能にしてくれる、ドラ○もんのような存在！

consul の監視結果を様々なインターフェスで参照

・ Web UI

・ HTTP API

・ DNS interface

・ Blocking Query ( via RPC )

・ envconsul

Consul のデータは Consul Server が機能として持つキーバリューストア(KVS) 上に保管されています。このデータは、どのインターフェースを使っても参照する事ができます。

http://demo.consul.io/ Web UI のデモサイトがあります。

http://demo.consul.io/�

{ "service": { "name": "web", "tags": [ "httpd" ], "port": 80, "check": { "script": "curl localhost:80 >/dev/null 2>&1", "interval": "10s" } } }

$ curl -s http://127.0.0.1:8500/v1/catalog/services | jq '.' { "web": [ "httpd" ], "consul": [] }

HTTP API のデータは JSON です。 RESTful な API が実装されています。

http://qiita.com/zembutsu/items/ea05fbeff06cafb5ec2e

ローカルに DNS サーバをたてて、サービスの切り替えや管理をしている場合も、DNS サーバと連携が可能。既存のシステムに手を加える必要はありません。

http://qiita.com/zembutsu/items/ea05fbeff06cafb5ec2e�

$ dig web.service.sakura.consul (略) ;; QUESTION SECTION: ;web.service.sakura.consul. IN A ;; ANSWER SECTION: web.service.sakura.consul. 30 IN A 192.168.39.13 web.service.sakura.consul. 30 IN A 192.168.39.11 ―――――――――――――――――――――――――― ;; ANSWER SECTION: web.service.sakura.consul. 21 IN A 192.168.39.11 web.service.sakura.consul. 21 IN A 192.168.39.13 ―――――――――――――――――――――――――― ;; ANSWER SECTION: web.service.sakura.consul. 30 IN A 192.168.39.11

TLD “.consul” で名前解決できます。 DNS をキャッシュするTTL 機能も実装されており、サービス単位で、任意の秒数を指定できます。

サービス ‘web’ は二台見えています TTL は 30 秒

TTL が 0 になるまでは2台の情報ですがこの間、サーバの一台が落ちるとします

最後は1台の情報しか返さなくなりました

Blocking Query $ curl -v 'http://192.168.39.5:8500/v1/health/state/critical?wait=30m&index=2000' - 30m ( 30 分 ) のタイムアウトが発生した（リクエストから 30 分後)

- 異常が発生した

- RAFT index は 2000 実際に使うには Consul API https://github.com/armon/consul-api または、同様の仕組みは envconsul で参考【Consul】ブロッキング・クエリ(blokcing query)とは | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2014/04/29/blocking_query_at_consul/

$ consul info raft: applied_index = 2226 commit_index = 2226 fsm_pending = 0 last_log_index = 2226

指定した条件に一致するまで、応答を返さない（ブロックする）仕組みです。逆に変化があれば、直ちに応答します。

https://github.com/armon/consul-api�



http://pocketstudio.jp/log3/2014/04/29/blocking_query_at_consul/�

様々なインターフェースは KVS を通して同期している

Raft プロトコルに基づく KVS が Consul に実装されています。

Consul の性質 Anti-Entropy

本家のドキュメントには、しばしば「アンチ・エントロピー」という言葉が出ます。これは、Consul の性質を一言であらわしたものです。

Consul における Anti-Entropy とは「Consul ノードとサーバの矛盾した状態を、随時比較し、差分があれば自動的に解消する自己修復的な同期機能」である。と思います。より安定した状態を目指すという意味で、エントロピーという言葉が用いられているのでは。現実世界にアンチ・エントロピーを例えると、小型自律掃除機ではないか。ル○バが散らかった部屋の中を自動的に綺麗にするのは、エントロピーが低い状態を保とうという機能を持っている。

アンチ・エントロピー

Consul の情報同期は Anti-Entropy ➡ クライアント・サーバ間の情報伝達で

クライアント ( Consul Agent ) に定義の権威 ➡ クライアントは、サーバで定義された情報を、

いつでも上書きすることが出来る

役割 ➡ クライアント ( consul node )

• 既知のノード状態を承認する • 定期的にローカル内部の状況をサーバに伝える

➡ サーバ ( consul server ) • 問い合わせ ( querying ) の役割 • そのために、データを保管し、回答するホスト役

エージェントがローカルの情報を持ちサーバは保持しない

エントロピーは、情報理論では確率変数が持つ情報の量を表す尺度であり「情報量」とも呼ばれる。情報量とは、確率変数が大きければ大きいほど、情報量が大きくなる傾向。つまり、アンチ・エントロピーは、変化（情報量の増加）に対して、不正確さ（クライアントとサーバの矛盾した状態）を自動的に同期させようとする性質。これを使って、変化を検出し、ただちに様々な処理を実行できる。

クライアント ( consul node)

サーバ ( consul server)

では、クライアントとサーバの関係を図を使って見てみます。重要なのは、権威があるのはクライアントです。ボトムアップなのです。



A B C

新しいサービスが追加される

まだサーバは何も知らない



A B C

エージェントはサーバに情報を伝えると

新しいサービスが追加される



A B C

エージェントはサーバに情報を伝えると

はじめて同期する

A B C



A B

もし、サービスが消えると

A B C



A B

クライアントはサーバと情報を比較サーバに“C”は不要と伝える

A B C



A B


A B あいよ



A B


A B あいよ

クライアントとサーバで情報が同期。この性質がアンチエントロピー



A B


A B あいよ

クライアントとサーバで情報が同期。この性質がアンチエントロピー

決定権を持つのはクライアント側。サービス状況の「変化」をトリガとし様々な動作を起こすことができる。



A’ B

A B

サービスのステータス、たとえば障害になったとしても、サーバが知るまではタイムラグがあります。



A’ B

A B

比較を行い、相違点があれば



A’ B

A’ B あいよ

クライアントがサーバに命令します。このような一連の動作が、Consul の Anti-Entropy です。更に、KVS の値の変化をトリガとし、様々なアクションを起こせます。

Consul の 4 つの特長

ここから先も、座学的です。実際に使うとき以外であれば、読み飛ばしていただいて構いません。Zzz..

サービス検出障害検知

マルチデータセンタキーバリューストレージ

サービス検出 Service Discovery

‘api’ や ‘mysql’ という service 名を定義

検出は、consul ノードで自動的に開始

HTTP API または DNS で結果を返す





$ curl -s http://192.168.39.5:8500/v1/catalog/nodes | jq '.' [ { "Address": "192.168.39.5", "Node": "consul1.pocketstudio.net“ }, { "Address": "192.168.39.6", "Node": "consul2.pocketstudio.net“ } ]





$ dig @192.168.39.5 -p 8600 consul1.node.consul any ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @192.168.39.5 -p 8600 consul1.node.consul any (snip) ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;consul1.node.consul. IN ANY ;; ANSWER SECTION: consul1.node.consul. 0 IN A 192.168.39.5

障害検知 Failure Detection

サービスやノードのヘルスチェック

‘ping’ や ‘curl’ 等、コマンドレベルで指定

任意の監視間隔 (秒単位 )







$ curl http://192.168.39.5:8500/v1/health/state/critical | jq '.' [ { "ServiceName": "web", "ServiceID": "web", "Notes": "", "Status": "critical", "Name": "Service 'web' check", "CheckID": "service:web", "Node": "consul1" } ]





HTTP API または DNS で結果を返すスクリプト実行可＝監視用プログラムのデプロイにも…？

# mkdir /etc/consul.d/ # echo ‘{“service”: {“name”: “web”, “tags”: ["rails"], “port”: 80, “check”: {“script”: “curl localhost:80 >/dev/null 2>&1″, “interval”: “10s”}}}’ >/etc/consul.d/web.json

キーバリューストレージ Key/Value Storage

HTTP API を通して RESTful に操作

Consul server 間でデータを複製・保全

Consel システム機能が内部で利用

ユーザによる任意データの利用も可能






$ curl -XPUT -d 'hello, world!‘ ¥ http://192.168.39.5:8500/v1/kv/hello/key true # curl -s http://192.168.39.5:8500/v1/kv/hello/?recurse | jq '.' [ { "Value": "b3BlbiB0aGUgbmV4dA==", "Flags": 0, "Key": "hello/key2", "ModifyIndex": 16, "CreateIndex": 16 }, ]






$ curl -s http://192.168.39.5:8500/v1/kv/hello/key | ¥ jq '.[].Value | .' -r | base64 -d hello, world!

マルチデータセンタ Multi Datacenter

複数のデータセンタにまたがって通信

LAN 側と WAN 側で別々のゴシッププール

ローカルクラスタにない問い合わせは転送

Consul Architecture - Consul http://www.consul.io/docs/internals/architecture.html

http://www.consul.io/docs/internals/architecture.html�





強い基礎技術メッセージング ( Messageing ) … SWIM , Serf

リーダー選出 ( Leader Election ) … Raft

セキュリティ ( Security ) … TLS

データストレージ ( Data Storage ) … UMDB

Serf との違い

Serf vs. Consul http://www.serfdom.io/intro/vs-consul.html

Serf Consul

目的サービス検出とオーケストレーションサービス検出と設定

ヘルスチェック低レベル（ノード死活監視）サービス単位で高度な調整

キーバリューストアなしあり

メンバーシップノード単位サービス単位

Web API なしあり

DNS インターフェースなしあり

アーキテクチャ AP 型 ( 一貫性重視、可用性を犠牲 ) CP 型 ( 可用性より一貫性重視 )

http://pocketstudio.jp/log3/2014/04/19/translation_consul_related_documents/Serf vs. Consul http:/www.serfdom.io/intro/vs-consul.html�



試してみた RHEL6/CentOS6 は、そのままでNG ( glibc の version )

Serf に慣れていれば、ほぼ同じような捜査感

Serf のような Consul の振る舞いだけど、別モノ

Consulを使ってみた | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2014/04/18/what_is_consul/

http://pocketstudio.jp/log3/2014/04/18/what_is_consul�

利用方法


$ wget -O 0.1.0_linux_amd64.zip ¥

https://dl.bintray.com/mitchellh/consu/0.1.0_linux_amd64.zip

$ unzip ./0.1.0_linux_amd64.zip

# mv ./consul /usr/bin/

$ consul


利用方法


$ wget -O 0.1.0_linux_amd64.zip ¥

https://dl.bintray.com/mitchellh/consu/0.1.0_linux_amd64.zip

$ unzip ./0.1.0_linux_amd64.zip

# mv ./consul /usr/bin/

$ consul

$ consul agent -server -bootstrap -client=192.168.39.5 -dc=local ¥ -node=consul1 -data-dir=/tmp/consul -bind=192.168.39.5 $ consul agent -dc=local -node=consul2 -data-dir=/tmp/consul2 ¥ -bind=192.168.39.6 -join=192.168.39.5


ドキュメント公式サイト

http://www.consul.io/intro/index.html

GitHub

https://github.com/hashicorp/consul

Consul関連文書の参考訳、Serfとの違い等 | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2014/04/19/translation_consul_related_documents/

http://www.consul.io/intro/index.html�

https://github.com/hashicorp/consul�

http://www.consul.io/intro/index.html�

http://pocketstudio.jp/log3/2014/04/19/translation_consul_related_documents/�

envconsul

あと一つ、重要な役割をするツールがこちらです。

envconsulとは

https://github.com/hashicorp/envconsul ➡ The Twelve-Factor App

• http://12factor.net/config • “Apps sometimes store config as contain in the

code. This is a violation of tweleve-factor, which requires strict separation of config from code” コードから設定を厳密に分離することが必要

機能 ➡ 環境変数の取得・設定が出来る

• 例：アプリケーション展開時、ホスト名取得

➡ バックエンドに consul の KVS を使用 ➡ KVS のデータ変更をトリガに任意コマンドを実行

• 例：zabbix.conf の Server を書き換え agent restart

Heroku ライクなものを、自分の環境でも実現しようとするもの。設定変更と同時に、アプリケーションの再起動まで。

Hashicorp 社では、自社利用のアプリに対して環境変数のセットアップに使用している（blogより)

https://github.com/hashicorp/envconsul�

http://12factor.net/config�

envconsulを使うには

Golang 開発環境 ➡ $ git clone [email protected]:armon/consul-kv.git ➡ $ git clone [email protected]:hashicorp/envconsul.git ➡ $ go build

現時点ではバイナリは配付されていません。ソースからの構築が必須です。

build 時に consul-kv が必要です。

$ ./envconsul Usage: envconsul [options] prefix child... Sets environmental variables for the child process by reading K/V from Consul's K/V store with the given prefix. Options: -addr="127.0.0.1:8500": consul HTTP API address with port -dc="": consul datacenter, uses local if blank -errexit=false: exit if there is an error watching config keys -reload=false: if set, restarts the process when config changes -sanitize=true: turn invalid characters in the key into underscores -upcase=true: make all environmental variable keys uppercase

$ envconsul -addr=“127.0.0.1:8500" foo env | grep ENABLED ENABLED=false

$ curl -X PUT -d 'false' http://127.0.0.1:8500/v1/kv/foo/enabled true Web UI から情報の書き換え

KVS

envconsul envconsul

envconsul

• Web UI

• HTTP API

• DNS

更新

Consul が、KVS のデータ変化をトリガに、envconsul を使役する

参照

インターフェース

Consul Server

Consul Node Consul Node Consul Node

KVS 上のデータを参照

環境変数を更新

$ envconsul -addr="sakura1.pocketstudio.net:8500“ ¥ -reload envtest /bin/sh -c "/bin/env; echo "---"; /bin/sleep 1000“ 例：環境変数が変わる度に結果を画面に出力する。 envconsul には 2 つの役割

1. 環境変数を consul の KVS から取得する事

2. 環境変数に変化が発生したタイミングで何らかの処理を行う事

KVS の値変化をトリガに、任意のコマンド読み込みを

対象ノードに対して一斉に行う事が出来る。

Serf, Consul, Envconsul これらを組みあわせて

色々な処理をさせられる

いずれも単体のバイナリ依存関係もなく

軽量かつ簡単な操作感

ここまでのまとめ・学習コストが低い・既存の仕組みを変更しない


導き出される結論は・・・


導き出される結論は・・・

業務の自動化対応が容易であり、作業効率を向上させられる。


3 ● ● ● ○

実践 – ZABBIX 連携 PRACTICAL ORCHESTRATION

最近の運用現場

ニンゲンヤメマスカ? Do you resign as human being?

It is necessary to answer the following questions to start OPERATION.

YES はいはい YES

運用を続けるためには、イカの質問に答える必要があります。

Before After

ZABBIX の監視を自動化

今時の課題

スケールアップ・ダウンに連動し、

ホスト登録・削除を自動対応したい

グラフの登録・削除も自動対応したい

ZABBIX の管理を仕事にしたくない

対象ホストやサービスの自動登録に加え、自動削除も可能となります。 API を使いこなせば、 ZABBIX 設定は人間が行わなくとも、Consul だけで完結できそうです。

Serf と ZABBIX 連携

動機 ➡ ZABBIX 管理の自動化

仕組み ➡ Serf のイベント ( ノード参加・離脱 ) と ZABBIX 連携

• 既定の role に従って、 ZABBIX のグループや監視対象を制御

➡ ZABBIX サーバには ZABBIX API ( JSON ) でリクエスト ➡ Serf のタグ機能でホスト情報 ( hostid ) を記憶

特長 ➡ ZABBIX ホスト管理の自動化（迅速かつフレキシブル）

今後の展開 ➡ Chef 等の構成管理ツールとの連携 ➡ クラウド事業者が提供する API と連携した仕組み

1.join

Serf クラスタ

3. Monitoring

Serf のクラスタ参加・離脱のタイミングで、ZABBIX サーバに API をリクエストします。

Workflow orchestration

serf manager ( cluster )

Zabbix Server join to cluster serf agent

event: member-join

call: zabbix-add role:web

name:web1

JSON Request

LVS Server

ipvsadm –A –t <LVS> -s <NODE> -g

host.create

interfaces, group, templates

JSON Return event: settag

hostid

user HTTP/HTTPS

zbx-screen-add screen.get

hsize

screen-update screen.update

graph-update graph.get graphitem.get

graphids

graph-update graph.update

graphid, gitems

以降は ZABBIX API に特化した話題なのでこちらのスライドをご覧ください。

ZabbixのAPIを使って運用を楽しくする話 http://www.slideshare.net/zembutsu/serf-orchestration-with-zabbix-operation

http://www.slideshare.net/zembutsu/serf-orchestration-with-zabbix-operation�













もっと他のツールにも応用ができるはず…!

応用例 Consul のサービス監視と LVS・HAProxy 連携

Consul , serf で Docker と Sensu の連動した自動監視

Consul の取得したデータを Munin に格納

定時処理 ( cron や serverspec のチェック )

これらを、リモートからログインすることなく実施

楽しい楽 Fun Easy

≒

今日ご紹介したツールを組みあわせることによって、”楽しい”と”楽”が近づくかもしれませんね。


4 ● ● ● ●

まとめ CONCLUSION



Conclusion

今日のまとめ











今日のまとめ








Conclusion




この時間で得られたもの





Conclusion

簡単軽量なオーケストレーションツールであり、 APIを使ってツールを結びつけ、自動化を支援する。




この時間で得られたもの





Conclusion

簡単軽量なオーケストレーションツールであり、 APIを使ってツールを結びつけ、自動化を支援する。




質疑応答

Conclusion

本日の資料は、コマンドの reference などを追記し、後日公開します。 http://slideshare.net/zembutsu/




本日のフォローアップ

・ twitter @zembutsu mention 下しあ

・ Google Plus https://plus.google.com/+MasahitoZembutsu

・ Google Group

“オーケストレーション技術の部屋”

Conclusion

本日の資料は、コマンドの reference などを追記し、後日公開します。 http://slideshare.net/zembutsu/


“Listen, kid... You’ve got a ghost, and a brain... And you can access an e-brain... Create your own future...”

「お前にだってゴーストがあるだろ脳だってついてる電脳にもアクセスできる未来をつくれ」――攻殻機動隊草薙素子

Re: ご注文は自動化ですか？[2] オーケストレーションで仕事を楽しくする話

Masahito Zembutsu @zembutsu Technology Evangelist (Creationline, Inc) Jul20, 2014 , #hbstudy Shinjyuku, Tokyo IS THE ORDER AN AUTOMATION? v1.02


ノシ