SlideShare a Scribd company logo

ご注文は監視自動化ですか?

『ご注文は監視自動化ですか?』 Serf と Consul を使って運用を楽しくする話 Serf とか Consul とか聞くけど、イマイチわからん!という疑問はありませんか。 どのような働きをするのかや、使いどころを、皆さんと共有したいなと思っています。 1. はじめに 2. 基本編  ・ Serf  ・ Consul  ・ envconsul 3. 実践編 ・ API 連携 4. まとめ July Tech Festa 2014 June 22, 2014, @ AITT Shinagawa, Tokyo, Japan #techfesta #jtf2014

1 of 181
Download to read offline
IS THE ORDER AN AUTOMATION OF OPERATION AND MONITORING?
Masahito Zembutsu @zembutsu
Jun 22, 2014 , July Tech Festa #jtf2014 #techfesta
AITT Shinagawa Seaside, Tokyo
ご注文は
監視自動化ですか?
S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話
おきのどくですが
ぼうけん の しょは
きえて しまいました
先日”Monitoring Casual Talks #6”に参加したの
ですが、作成中の資料が未保存だっため、半日
の成果が吹っ飛びました\(^o^)/オワタ 予定し
ていた Munin 資料は作り直して、どこかで公開
したいと思っています。
ctrl + S で保存
(震え声
この悲劇を繰り返さないよう、みなさんもパワポを
お使いであれば、自動保存が有効になっているか、
確認しましょう…。
きゃんぱすー
すげぇ(小波感
あと、AITT さんのウェブサイト、
ポスターが格好いいですね。
!
WARNING
このスライドには過激な表現やネットスラング、
アニメなどアキバ的文化の演出が含まれています。
IS THE ORDER AN AUTOMATION OF OPERATION AND MONITORING?
Masahito Zembutsu @zembutsu
Technology Evangelist
Jun 22, 2014 , July Tech Festa#jtf2014, AITT Shinagawa Seaside, Tokyo
ご注文は
監視自動化ですか?
S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話
15:00からです
ゆっくりしていってね!
Ad

Recommended

今日から業務で使える17の運用系Linuxツール、そして円環の理
今日から業務で使える17の運用系Linuxツール、そして円環の理今日から業務で使える17の運用系Linuxツール、そして円環の理
今日から業務で使える17の運用系Linuxツール、そして円環の理Masahito Zembutsu
 
Serf2Excel - Serf を実運用に活かす話 + Consul もあるよ
Serf2Excel - Serf を実運用に活かす話 + Consul もあるよSerf2Excel - Serf を実運用に活かす話 + Consul もあるよ
Serf2Excel - Serf を実運用に活かす話 + Consul もあるよMasahito Zembutsu
 
Serfが面白いと俺の中で話題にwwwwww
Serfが面白いと俺の中で話題にwwwwwwSerfが面白いと俺の中で話題にwwwwww
Serfが面白いと俺の中で話題にwwwwwwMasahito Zembutsu
 
Re: ご注文は自動化ですか?[2]
Re: ご注文は自動化ですか?[2]Re: ご注文は自動化ですか?[2]
Re: ご注文は自動化ですか?[2]Masahito Zembutsu
 
Serfが面白いと俺の中で話題にwwwwww 【改訂版】
Serfが面白いと俺の中で話題にwwwwww 【改訂版】Serfが面白いと俺の中で話題にwwwwww 【改訂版】
Serfが面白いと俺の中で話題にwwwwww 【改訂版】Masahito Zembutsu
 
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introduction
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai@kyoto terraform introductionMasahito Zembutsu
 
Consulを頑張って理解する
Consulを頑張って理解するConsulを頑張って理解する
Consulを頑張って理解するMasakazu Watanabe
 
Serf という Orchestration ツール #immutableinfra
Serf という Orchestration ツール #immutableinfraSerf という Orchestration ツール #immutableinfra
Serf という Orchestration ツール #immutableinfraNaotoshi Seo
 

More Related Content

What's hot

Serf / Consul 入門 ~仕事を楽しくしよう~
Serf / Consul 入門 ~仕事を楽しくしよう~Serf / Consul 入門 ~仕事を楽しくしよう~
Serf / Consul 入門 ~仕事を楽しくしよう~Masahito Zembutsu
 
運用に自動化を求めるのは間違っているだろうか
運用に自動化を求めるのは間違っているだろうか運用に自動化を求めるのは間違っているだろうか
運用に自動化を求めるのは間違っているだろうかMasahito Zembutsu
 
インフラ自動化とHashicorp tools
インフラ自動化とHashicorp toolsインフラ自動化とHashicorp tools
インフラ自動化とHashicorp toolsUchio Kondo
 
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介cloudconductor
 
Infrastructure as Codeの取り組みと改善
Infrastructure as Codeの取り組みと改善Infrastructure as Codeの取り組みと改善
Infrastructure as Codeの取り組みと改善Takashi Honda
 
次世代Webコンテナ Undertowについて
次世代Webコンテナ Undertowについて次世代Webコンテナ Undertowについて
次世代Webコンテナ UndertowについてYoshimasa Tanabe
 
2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについてMasahito Zembutsu
 
Rancher使ってみたよ(初心者向け)
Rancher使ってみたよ(初心者向け)Rancher使ってみたよ(初心者向け)
Rancher使ってみたよ(初心者向け)Shun Sumiya
 
Drone.io のご紹介
Drone.io のご紹介Drone.io のご紹介
Drone.io のご紹介Uchio Kondo
 
20170111 macnica networks-nohara_rancher_usecase
20170111 macnica networks-nohara_rancher_usecase20170111 macnica networks-nohara_rancher_usecase
20170111 macnica networks-nohara_rancher_usecaseMinehiko Nohara
 
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化Gosuke Miyashita
 
Elixir-Conf-Japan-2017-session-ohr486
Elixir-Conf-Japan-2017-session-ohr486Elixir-Conf-Japan-2017-session-ohr486
Elixir-Conf-Japan-2017-session-ohr486Tsunenori Oohara
 
Infrastrucure as a CodeにおけるJenkinsの役割
Infrastrucure as a CodeにおけるJenkinsの役割Infrastrucure as a CodeにおけるJenkinsの役割
Infrastrucure as a CodeにおけるJenkinsの役割Takashi Honda
 
Ruby way-openstack.keynote
Ruby way-openstack.keynoteRuby way-openstack.keynote
Ruby way-openstack.keynoteUchio Kondo
 
実環境にTerraform導入したら驚いた
実環境にTerraform導入したら驚いた実環境にTerraform導入したら驚いた
実環境にTerraform導入したら驚いたAkihiro Kuwano
 
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-賢 秋穂
 
RUNNING Smalltalk - 実践Smalltalk
RUNNING Smalltalk - 実践SmalltalkRUNNING Smalltalk - 実践Smalltalk
RUNNING Smalltalk - 実践SmalltalkSho Yoshida
 
Pythonユーザのための構成管理入門 #pyconapac
Pythonユーザのための構成管理入門 #pyconapacPythonユーザのための構成管理入門 #pyconapac
Pythonユーザのための構成管理入門 #pyconapacTakeshi Komiya
 
はじめての CircleCI
はじめての CircleCIはじめての CircleCI
はじめての CircleCIYosuke Mizutani
 
itamae + Serverspecで テスト駆動インフラやってみた #shibuyarb
itamae + Serverspecで テスト駆動インフラやってみた #shibuyarbitamae + Serverspecで テスト駆動インフラやってみた #shibuyarb
itamae + Serverspecで テスト駆動インフラやってみた #shibuyarbGo Sueyoshi (a.k.a sue445)
 

What's hot (20)

Serf / Consul 入門 ~仕事を楽しくしよう~
Serf / Consul 入門 ~仕事を楽しくしよう~Serf / Consul 入門 ~仕事を楽しくしよう~
Serf / Consul 入門 ~仕事を楽しくしよう~
 
運用に自動化を求めるのは間違っているだろうか
運用に自動化を求めるのは間違っているだろうか運用に自動化を求めるのは間違っているだろうか
運用に自動化を求めるのは間違っているだろうか
 
インフラ自動化とHashicorp tools
インフラ自動化とHashicorp toolsインフラ自動化とHashicorp tools
インフラ自動化とHashicorp tools
 
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
 
Infrastructure as Codeの取り組みと改善
Infrastructure as Codeの取り組みと改善Infrastructure as Codeの取り組みと改善
Infrastructure as Codeの取り組みと改善
 
次世代Webコンテナ Undertowについて
次世代Webコンテナ Undertowについて次世代Webコンテナ Undertowについて
次世代Webコンテナ Undertowについて
 
2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて
 
Rancher使ってみたよ(初心者向け)
Rancher使ってみたよ(初心者向け)Rancher使ってみたよ(初心者向け)
Rancher使ってみたよ(初心者向け)
 
Drone.io のご紹介
Drone.io のご紹介Drone.io のご紹介
Drone.io のご紹介
 
20170111 macnica networks-nohara_rancher_usecase
20170111 macnica networks-nohara_rancher_usecase20170111 macnica networks-nohara_rancher_usecase
20170111 macnica networks-nohara_rancher_usecase
 
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
 
Elixir-Conf-Japan-2017-session-ohr486
Elixir-Conf-Japan-2017-session-ohr486Elixir-Conf-Japan-2017-session-ohr486
Elixir-Conf-Japan-2017-session-ohr486
 
Infrastrucure as a CodeにおけるJenkinsの役割
Infrastrucure as a CodeにおけるJenkinsの役割Infrastrucure as a CodeにおけるJenkinsの役割
Infrastrucure as a CodeにおけるJenkinsの役割
 
Ruby way-openstack.keynote
Ruby way-openstack.keynoteRuby way-openstack.keynote
Ruby way-openstack.keynote
 
実環境にTerraform導入したら驚いた
実環境にTerraform導入したら驚いた実環境にTerraform導入したら驚いた
実環境にTerraform導入したら驚いた
 
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
 
RUNNING Smalltalk - 実践Smalltalk
RUNNING Smalltalk - 実践SmalltalkRUNNING Smalltalk - 実践Smalltalk
RUNNING Smalltalk - 実践Smalltalk
 
Pythonユーザのための構成管理入門 #pyconapac
Pythonユーザのための構成管理入門 #pyconapacPythonユーザのための構成管理入門 #pyconapac
Pythonユーザのための構成管理入門 #pyconapac
 
はじめての CircleCI
はじめての CircleCIはじめての CircleCI
はじめての CircleCI
 
itamae + Serverspecで テスト駆動インフラやってみた #shibuyarb
itamae + Serverspecで テスト駆動インフラやってみた #shibuyarbitamae + Serverspecで テスト駆動インフラやってみた #shibuyarb
itamae + Serverspecで テスト駆動インフラやってみた #shibuyarb
 

Viewers also liked

Datadog fastly yamagoya_summit2017
Datadog fastly yamagoya_summit2017Datadog fastly yamagoya_summit2017
Datadog fastly yamagoya_summit2017Masahiro Hattori
 
Datadog jawsfesta2017 20171104
Datadog jawsfesta2017 20171104Datadog jawsfesta2017 20171104
Datadog jawsfesta2017 20171104Masahiro Hattori
 
クラウドネイティブなAWSの監視におけるモニタリング理論 - Datadog, Inc.
クラウドネイティブなAWSの監視におけるモニタリング理論 - Datadog, Inc.クラウドネイティブなAWSの監視におけるモニタリング理論 - Datadog, Inc.
クラウドネイティブなAWSの監視におけるモニタリング理論 - Datadog, Inc.Masahiro Hattori
 
ZabbixのAPIを使って運用を楽しくする話
ZabbixのAPIを使って運用を楽しくする話ZabbixのAPIを使って運用を楽しくする話
ZabbixのAPIを使って運用を楽しくする話Masahito Zembutsu
 
Zabbixを使った効果的な運用管理の実現
Zabbixを使った効果的な運用管理の実現Zabbixを使った効果的な運用管理の実現
Zabbixを使った効果的な運用管理の実現Daisuke Ikeda
 
リクルートのWebサービスを支える「RAFTEL」
リクルートのWebサービスを支える「RAFTEL」リクルートのWebサービスを支える「RAFTEL」
リクルートのWebサービスを支える「RAFTEL」Recruit Technologies
 
Amazon Web Services (AWS) のご紹介
Amazon Web Services (AWS) のご紹介Amazon Web Services (AWS) のご紹介
Amazon Web Services (AWS) のご紹介崇之 清水
 
サーバレス構成の運用・監視と自社製Data○ogもどきの話 公開用
サーバレス構成の運用・監視と自社製Data○ogもどきの話 公開用サーバレス構成の運用・監視と自社製Data○ogもどきの話 公開用
サーバレス構成の運用・監視と自社製Data○ogもどきの話 公開用Takashi Kozu
 
Dockerを活用したリクルートグループ開発基盤の構築
Dockerを活用したリクルートグループ開発基盤の構築Dockerを活用したリクルートグループ開発基盤の構築
Dockerを活用したリクルートグループ開発基盤の構築Recruit Technologies
 
リクルートにおけるデータのインフラ化への取組
リクルートにおけるデータのインフラ化への取組リクルートにおけるデータのインフラ化への取組
リクルートにおけるデータのインフラ化への取組Recruit Technologies
 
リクルート流Elasticsearchの使い方
リクルート流Elasticsearchの使い方リクルート流Elasticsearchの使い方
リクルート流Elasticsearchの使い方Recruit Technologies
 
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operationYasuhiro Araki, Ph.D
 
20140726 jaws-ug chiba AWS operation best practice
20140726 jaws-ug chiba AWS operation best practice20140726 jaws-ug chiba AWS operation best practice
20140726 jaws-ug chiba AWS operation best practiceKazuki Ueki
 
Jtfハンズオン資料(公開版)
Jtfハンズオン資料(公開版)Jtfハンズオン資料(公開版)
Jtfハンズオン資料(公開版)亮介 山口
 
コンテナ型仮想化とはなんだったのか
コンテナ型仮想化とはなんだったのかコンテナ型仮想化とはなんだったのか
コンテナ型仮想化とはなんだったのかえむ ばーど
 
HyClops for Zabbix紹介資料
HyClops for Zabbix紹介資料HyClops for Zabbix紹介資料
HyClops for Zabbix紹介資料Daisuke Ikeda
 
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーションOperation Lab, LLC.
 
No Monitoring, No Life on AWS
No Monitoring, No Life on AWSNo Monitoring, No Life on AWS
No Monitoring, No Life on AWSMasahito Zembutsu
 
AWSを含めたハイブリッド環境の監視の実現 ~zabbixのクラウド対応モジュールHyClops~
AWSを含めたハイブリッド環境の監視の実現 ~zabbixのクラウド対応モジュールHyClops~AWSを含めたハイブリッド環境の監視の実現 ~zabbixのクラウド対応モジュールHyClops~
AWSを含めたハイブリッド環境の監視の実現 ~zabbixのクラウド対応モジュールHyClops~Daisuke Ikeda
 
第4回コンテナ型仮想化勉強会@東京 Oracle Solaris のコンテナ技術「Solaris Zones」
第4回コンテナ型仮想化勉強会@東京 Oracle Solaris のコンテナ技術「Solaris Zones」第4回コンテナ型仮想化勉強会@東京 Oracle Solaris のコンテナ技術「Solaris Zones」
第4回コンテナ型仮想化勉強会@東京 Oracle Solaris のコンテナ技術「Solaris Zones」Kazuyuki Sato
 

Viewers also liked (20)

Datadog fastly yamagoya_summit2017
Datadog fastly yamagoya_summit2017Datadog fastly yamagoya_summit2017
Datadog fastly yamagoya_summit2017
 
Datadog jawsfesta2017 20171104
Datadog jawsfesta2017 20171104Datadog jawsfesta2017 20171104
Datadog jawsfesta2017 20171104
 
クラウドネイティブなAWSの監視におけるモニタリング理論 - Datadog, Inc.
クラウドネイティブなAWSの監視におけるモニタリング理論 - Datadog, Inc.クラウドネイティブなAWSの監視におけるモニタリング理論 - Datadog, Inc.
クラウドネイティブなAWSの監視におけるモニタリング理論 - Datadog, Inc.
 
ZabbixのAPIを使って運用を楽しくする話
ZabbixのAPIを使って運用を楽しくする話ZabbixのAPIを使って運用を楽しくする話
ZabbixのAPIを使って運用を楽しくする話
 
Zabbixを使った効果的な運用管理の実現
Zabbixを使った効果的な運用管理の実現Zabbixを使った効果的な運用管理の実現
Zabbixを使った効果的な運用管理の実現
 
リクルートのWebサービスを支える「RAFTEL」
リクルートのWebサービスを支える「RAFTEL」リクルートのWebサービスを支える「RAFTEL」
リクルートのWebサービスを支える「RAFTEL」
 
Amazon Web Services (AWS) のご紹介
Amazon Web Services (AWS) のご紹介Amazon Web Services (AWS) のご紹介
Amazon Web Services (AWS) のご紹介
 
サーバレス構成の運用・監視と自社製Data○ogもどきの話 公開用
サーバレス構成の運用・監視と自社製Data○ogもどきの話 公開用サーバレス構成の運用・監視と自社製Data○ogもどきの話 公開用
サーバレス構成の運用・監視と自社製Data○ogもどきの話 公開用
 
Dockerを活用したリクルートグループ開発基盤の構築
Dockerを活用したリクルートグループ開発基盤の構築Dockerを活用したリクルートグループ開発基盤の構築
Dockerを活用したリクルートグループ開発基盤の構築
 
リクルートにおけるデータのインフラ化への取組
リクルートにおけるデータのインフラ化への取組リクルートにおけるデータのインフラ化への取組
リクルートにおけるデータのインフラ化への取組
 
リクルート流Elasticsearchの使い方
リクルート流Elasticsearchの使い方リクルート流Elasticsearchの使い方
リクルート流Elasticsearchの使い方
 
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation
 
20140726 jaws-ug chiba AWS operation best practice
20140726 jaws-ug chiba AWS operation best practice20140726 jaws-ug chiba AWS operation best practice
20140726 jaws-ug chiba AWS operation best practice
 
Jtfハンズオン資料(公開版)
Jtfハンズオン資料(公開版)Jtfハンズオン資料(公開版)
Jtfハンズオン資料(公開版)
 
コンテナ型仮想化とはなんだったのか
コンテナ型仮想化とはなんだったのかコンテナ型仮想化とはなんだったのか
コンテナ型仮想化とはなんだったのか
 
HyClops for Zabbix紹介資料
HyClops for Zabbix紹介資料HyClops for Zabbix紹介資料
HyClops for Zabbix紹介資料
 
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
 
No Monitoring, No Life on AWS
No Monitoring, No Life on AWSNo Monitoring, No Life on AWS
No Monitoring, No Life on AWS
 
AWSを含めたハイブリッド環境の監視の実現 ~zabbixのクラウド対応モジュールHyClops~
AWSを含めたハイブリッド環境の監視の実現 ~zabbixのクラウド対応モジュールHyClops~AWSを含めたハイブリッド環境の監視の実現 ~zabbixのクラウド対応モジュールHyClops~
AWSを含めたハイブリッド環境の監視の実現 ~zabbixのクラウド対応モジュールHyClops~
 
第4回コンテナ型仮想化勉強会@東京 Oracle Solaris のコンテナ技術「Solaris Zones」
第4回コンテナ型仮想化勉強会@東京 Oracle Solaris のコンテナ技術「Solaris Zones」第4回コンテナ型仮想化勉強会@東京 Oracle Solaris のコンテナ技術「Solaris Zones」
第4回コンテナ型仮想化勉強会@東京 Oracle Solaris のコンテナ技術「Solaris Zones」
 

Similar to ご注文は監視自動化ですか?

DevOpsのはじめの一歩 〜監視の変遷〜
DevOpsのはじめの一歩 〜監視の変遷〜DevOpsのはじめの一歩 〜監視の変遷〜
DevOpsのはじめの一歩 〜監視の変遷〜Akihiro Kuwano
 
2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション
2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション
2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクションTakahiro Okumura
 
あなたの安心を高速に守る Container-based CI
あなたの安心を高速に守る Container-based CIあなたの安心を高速に守る Container-based CI
あなたの安心を高速に守る Container-based CIWataru MIYAGUNI
 
Automation with SoftLayer and Zabbix
Automation with SoftLayer and ZabbixAutomation with SoftLayer and Zabbix
Automation with SoftLayer and Zabbixsoftlayerjp
 
AWSによるサーバーレスアーキテクチャ
AWSによるサーバーレスアーキテクチャAWSによるサーバーレスアーキテクチャ
AWSによるサーバーレスアーキテクチャ真吾 吉田
 
Fluxflex meetup 2011 in Tokyo
Fluxflex meetup 2011 in TokyoFluxflex meetup 2011 in Tokyo
Fluxflex meetup 2011 in TokyoKyosuke Inoue
 
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform拓将 平林
 
サーバ擬人化ユーザ会キックオフ資料 Slideshare ver
サーバ擬人化ユーザ会キックオフ資料 Slideshare verサーバ擬人化ユーザ会キックオフ資料 Slideshare ver
サーバ擬人化ユーザ会キックオフ資料 Slideshare verSeiichiro Ishida
 
Practical migration from JSP to Thymeleaf
Practical migration from JSP to Thymeleaf Practical migration from JSP to Thymeleaf
Practical migration from JSP to Thymeleaf Toshiki Iga
 
Re: 運用に自動化を求めるのは間違っているだろうか
Re: 運用に自動化を求めるのは間違っているだろうかRe: 運用に自動化を求めるのは間違っているだろうか
Re: 運用に自動化を求めるのは間違っているだろうかMasahito Zembutsu
 
Swiftからlibuvを呼び出すTIPS
Swiftからlibuvを呼び出すTIPSSwiftからlibuvを呼び出すTIPS
Swiftからlibuvを呼び出すTIPSjugemjugemjugem
 
Apache CloudStack コントリビューション
Apache CloudStack コントリビューションApache CloudStack コントリビューション
Apache CloudStack コントリビューションSatoshi KOBAYASHI
 
コンソールゲームを世界展開してみた - JAWS DAYS 2015
コンソールゲームを世界展開してみた - JAWS DAYS 2015コンソールゲームを世界展開してみた - JAWS DAYS 2015
コンソールゲームを世界展開してみた - JAWS DAYS 2015Ryo Nakamaru
 
災害監視無人機システムと 災害監視無人機システムとFOSS4Gとの関わり ((独)宇宙航空研究開発機構 都甲 様)
災害監視無人機システムと 災害監視無人機システムとFOSS4Gとの関わり ((独)宇宙航空研究開発機構 都甲 様)災害監視無人機システムと 災害監視無人機システムとFOSS4Gとの関わり ((独)宇宙航空研究開発機構 都甲 様)
災害監視無人機システムと 災害監視無人機システムとFOSS4Gとの関わり ((独)宇宙航空研究開発機構 都甲 様)OSgeo Japan
 
fluxflex meetup in Tokyo
fluxflex meetup in Tokyofluxflex meetup in Tokyo
fluxflex meetup in TokyoKyosuke Inoue
 
Tizen 2.0 alpha でサポートされなかった native api
Tizen 2.0 alpha でサポートされなかった native apiTizen 2.0 alpha でサポートされなかった native api
Tizen 2.0 alpha でサポートされなかった native apiNaruto TAKAHASHI
 
20120317 IT系勉強会 in 神戸
20120317 IT系勉強会 in 神戸20120317 IT系勉強会 in 神戸
20120317 IT系勉強会 in 神戸Takahiro Iwase
 

Similar to ご注文は監視自動化ですか? (20)

DevOpsのはじめの一歩 〜監視の変遷〜
DevOpsのはじめの一歩 〜監視の変遷〜DevOpsのはじめの一歩 〜監視の変遷〜
DevOpsのはじめの一歩 〜監視の変遷〜
 
2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション
2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション
2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション
 
あなたの安心を高速に守る Container-based CI
あなたの安心を高速に守る Container-based CIあなたの安心を高速に守る Container-based CI
あなたの安心を高速に守る Container-based CI
 
Automation with SoftLayer and Zabbix
Automation with SoftLayer and ZabbixAutomation with SoftLayer and Zabbix
Automation with SoftLayer and Zabbix
 
PHPにおけるI/O多重化とyield
PHPにおけるI/O多重化とyieldPHPにおけるI/O多重化とyield
PHPにおけるI/O多重化とyield
 
AWSによるサーバーレスアーキテクチャ
AWSによるサーバーレスアーキテクチャAWSによるサーバーレスアーキテクチャ
AWSによるサーバーレスアーキテクチャ
 
Ansible勉強会 #1 LT
Ansible勉強会 #1 LTAnsible勉強会 #1 LT
Ansible勉強会 #1 LT
 
Fluxflex meetup 2011 in Tokyo
Fluxflex meetup 2011 in TokyoFluxflex meetup 2011 in Tokyo
Fluxflex meetup 2011 in Tokyo
 
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
 
Jenkinsのある生活
Jenkinsのある生活Jenkinsのある生活
Jenkinsのある生活
 
サーバ擬人化ユーザ会キックオフ資料 Slideshare ver
サーバ擬人化ユーザ会キックオフ資料 Slideshare verサーバ擬人化ユーザ会キックオフ資料 Slideshare ver
サーバ擬人化ユーザ会キックオフ資料 Slideshare ver
 
Practical migration from JSP to Thymeleaf
Practical migration from JSP to Thymeleaf Practical migration from JSP to Thymeleaf
Practical migration from JSP to Thymeleaf
 
Re: 運用に自動化を求めるのは間違っているだろうか
Re: 運用に自動化を求めるのは間違っているだろうかRe: 運用に自動化を求めるのは間違っているだろうか
Re: 運用に自動化を求めるのは間違っているだろうか
 
Swiftからlibuvを呼び出すTIPS
Swiftからlibuvを呼び出すTIPSSwiftからlibuvを呼び出すTIPS
Swiftからlibuvを呼び出すTIPS
 
Apache CloudStack コントリビューション
Apache CloudStack コントリビューションApache CloudStack コントリビューション
Apache CloudStack コントリビューション
 
コンソールゲームを世界展開してみた - JAWS DAYS 2015
コンソールゲームを世界展開してみた - JAWS DAYS 2015コンソールゲームを世界展開してみた - JAWS DAYS 2015
コンソールゲームを世界展開してみた - JAWS DAYS 2015
 
災害監視無人機システムと 災害監視無人機システムとFOSS4Gとの関わり ((独)宇宙航空研究開発機構 都甲 様)
災害監視無人機システムと 災害監視無人機システムとFOSS4Gとの関わり ((独)宇宙航空研究開発機構 都甲 様)災害監視無人機システムと 災害監視無人機システムとFOSS4Gとの関わり ((独)宇宙航空研究開発機構 都甲 様)
災害監視無人機システムと 災害監視無人機システムとFOSS4Gとの関わり ((独)宇宙航空研究開発機構 都甲 様)
 
fluxflex meetup in Tokyo
fluxflex meetup in Tokyofluxflex meetup in Tokyo
fluxflex meetup in Tokyo
 
Tizen 2.0 alpha でサポートされなかった native api
Tizen 2.0 alpha でサポートされなかった native apiTizen 2.0 alpha でサポートされなかった native api
Tizen 2.0 alpha でサポートされなかった native api
 
20120317 IT系勉強会 in 神戸
20120317 IT系勉強会 in 神戸20120317 IT系勉強会 in 神戸
20120317 IT系勉強会 in 神戸
 

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

20240222_Neko_IoTLT_vol9_kitazaki_v1.pdf
20240222_Neko_IoTLT_vol9_kitazaki_v1.pdf20240222_Neko_IoTLT_vol9_kitazaki_v1.pdf
20240222_Neko_IoTLT_vol9_kitazaki_v1.pdfAyachika Kitazaki
 
AWS (Amazon Web Services) を勉強してみる おさらい 2024/02/16の勉強会で発表されたものです。
AWS (Amazon Web Services) を勉強してみる おさらい 2024/02/16の勉強会で発表されたものです。AWS (Amazon Web Services) を勉強してみる おさらい 2024/02/16の勉強会で発表されたものです。
AWS (Amazon Web Services) を勉強してみる おさらい 2024/02/16の勉強会で発表されたものです。iPride Co., Ltd.
 
HarukiShinkawa_果樹農家が期待する行動への変容を促す仕掛け設計のための収穫作業体験者の行動観察とモデル化_仕掛学2024.pdf
HarukiShinkawa_果樹農家が期待する行動への変容を促す仕掛け設計のための収穫作業体験者の行動観察とモデル化_仕掛学2024.pdfHarukiShinkawa_果樹農家が期待する行動への変容を促す仕掛け設計のための収穫作業体験者の行動観察とモデル化_仕掛学2024.pdf
HarukiShinkawa_果樹農家が期待する行動への変容を促す仕掛け設計のための収穫作業体験者の行動観察とモデル化_仕掛学2024.pdfMatsushita Laboratory
 
解説: Token Extensions - Solana Developer Hub Online #SolDevHub
解説: Token Extensions - Solana Developer Hub Online #SolDevHub解説: Token Extensions - Solana Developer Hub Online #SolDevHub
解説: Token Extensions - Solana Developer Hub Online #SolDevHubK Kinzal
 
scikit-learn以外の分類器でpipelineを作ってみた! いずみん
scikit-learn以外の分類器でpipelineを作ってみた! いずみんscikit-learn以外の分類器でpipelineを作ってみた! いずみん
scikit-learn以外の分類器でpipelineを作ってみた! いずみんtoshinori622
 
オリジナルNFTを発行するブロックチェーン開発ハンズオン(NFTの発行に必要なツールから実装まで)
オリジナルNFTを発行するブロックチェーン開発ハンズオン(NFTの発行に必要なツールから実装まで)オリジナルNFTを発行するブロックチェーン開発ハンズオン(NFTの発行に必要なツールから実装まで)
オリジナルNFTを発行するブロックチェーン開発ハンズオン(NFTの発行に必要なツールから実装まで)Kanta Sasaki
 

Recently uploaded (6)

20240222_Neko_IoTLT_vol9_kitazaki_v1.pdf
20240222_Neko_IoTLT_vol9_kitazaki_v1.pdf20240222_Neko_IoTLT_vol9_kitazaki_v1.pdf
20240222_Neko_IoTLT_vol9_kitazaki_v1.pdf
 
AWS (Amazon Web Services) を勉強してみる おさらい 2024/02/16の勉強会で発表されたものです。
AWS (Amazon Web Services) を勉強してみる おさらい 2024/02/16の勉強会で発表されたものです。AWS (Amazon Web Services) を勉強してみる おさらい 2024/02/16の勉強会で発表されたものです。
AWS (Amazon Web Services) を勉強してみる おさらい 2024/02/16の勉強会で発表されたものです。
 
HarukiShinkawa_果樹農家が期待する行動への変容を促す仕掛け設計のための収穫作業体験者の行動観察とモデル化_仕掛学2024.pdf
HarukiShinkawa_果樹農家が期待する行動への変容を促す仕掛け設計のための収穫作業体験者の行動観察とモデル化_仕掛学2024.pdfHarukiShinkawa_果樹農家が期待する行動への変容を促す仕掛け設計のための収穫作業体験者の行動観察とモデル化_仕掛学2024.pdf
HarukiShinkawa_果樹農家が期待する行動への変容を促す仕掛け設計のための収穫作業体験者の行動観察とモデル化_仕掛学2024.pdf
 
解説: Token Extensions - Solana Developer Hub Online #SolDevHub
解説: Token Extensions - Solana Developer Hub Online #SolDevHub解説: Token Extensions - Solana Developer Hub Online #SolDevHub
解説: Token Extensions - Solana Developer Hub Online #SolDevHub
 
scikit-learn以外の分類器でpipelineを作ってみた! いずみん
scikit-learn以外の分類器でpipelineを作ってみた! いずみんscikit-learn以外の分類器でpipelineを作ってみた! いずみん
scikit-learn以外の分類器でpipelineを作ってみた! いずみん
 
オリジナルNFTを発行するブロックチェーン開発ハンズオン(NFTの発行に必要なツールから実装まで)
オリジナルNFTを発行するブロックチェーン開発ハンズオン(NFTの発行に必要なツールから実装まで)オリジナルNFTを発行するブロックチェーン開発ハンズオン(NFTの発行に必要なツールから実装まで)
オリジナルNFTを発行するブロックチェーン開発ハンズオン(NFTの発行に必要なツールから実装まで)
 

ご注文は監視自動化ですか?

  • 1. IS THE ORDER AN AUTOMATION OF OPERATION AND MONITORING? Masahito Zembutsu @zembutsu Jun 22, 2014 , July Tech Festa #jtf2014 #techfesta AITT Shinagawa Seaside, Tokyo ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話
  • 2. おきのどくですが ぼうけん の しょは きえて しまいました 先日”Monitoring Casual Talks #6”に参加したの ですが、作成中の資料が未保存だっため、半日 の成果が吹っ飛びました\(^o^)/オワタ 予定し ていた Munin 資料は作り直して、どこかで公開 したいと思っています。
  • 3. ctrl + S で保存 (震え声 この悲劇を繰り返さないよう、みなさんもパワポを お使いであれば、自動保存が有効になっているか、 確認しましょう…。
  • 6. IS THE ORDER AN AUTOMATION OF OPERATION AND MONITORING? Masahito Zembutsu @zembutsu Technology Evangelist Jun 22, 2014 , July Tech Festa#jtf2014, AITT Shinagawa Seaside, Tokyo ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話 15:00からです ゆっくりしていってね!
  • 7. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? この先生きのこるには 我々は何処から来たのか、 我々は何者か、 我々は何処へ行くのか、
  • 8. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? タイトルは、 いろいろ旬なので・・・
  • 9. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話 Agenda  流れ 1. はじめに 2. 基本編 ・ Serf, Consul, envconsul 3. 実践編 ・ API 連携、ZABBIX など 4. まとめ
  • 10. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話 Agenda  今日のまとめ Serf や Consul は軽量シンプルでありながら、 様々なシーンに利用できる。また、他の類似 ツールを使うよりも利用の敷居が低い。 そのため、運用・開発にかかわらず、日々の 煩雑な業務から解放されるので、各々が取り 組む本来業務、とりわけ人間しかできない事 に集中できる。結果、仕事が楽しくなる。
  • 11. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話 Agenda  この時間で得られるもの ・Serf や Consul とは ○○ です(キリッ と言える ・Serf や Consul の使い所をイメージできる ・運用や開発における自動化のための仕組み (ロジック)を自分で考えることができる
  • 12. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話 Agenda  この時間で得られるもの ・Serf や Consul とは ○○ です(キリッ と言える ・Serf や Consul の使い所をイメージできる ・運用や開発における自動化のための仕組み (ロジック)を自分で考えることができる
  • 14. 質問 「 Serf や Consul を知っていますか? 」 1. とても使ってる バッチリ使ってます 2. 使ってる 検証したことあり 3. ふつう 聞いたことはある 4. しらん 食えるのか? 5. 花不可避 1. とても使ってる バッチリ使ってます 会場では、使って いる方と検証が数 名で、大半の方が 「3」聞いたこと がある、でした。
  • 17. 1. 運用 2. 開発 3. 両方 4. どちらでもない 5. ごらく部 アンケートへのご協力ありがとうございました 両方という方が 多かったです。 2割 2割 5 割
  • 18. 1● ○ ○ ○ はじめに
  • 19. @zembutsu 前佛 雅人 ・Technology Evangelist クリエーションライン株式会社 ・経歴;ホスティングの運用部隊 10年近く, 物理 10,000 台の環境 メインは Linux 系運用監視・サポート 所謂インフラエンジニア的な 運用保守(一次,二次)データセンタ常駐企画営業広報宣伝検証開発 http://slideshare.net/zembutsu 自己紹介 Why am I here? Munin LOVE!!
  • 24. ・いずれ実家で農業をするが、その時は Cloud Computing や 監視、自動化等周辺技術を積極導入し、生産効率を上げたい ・ Open Source や Open Computing のように、農業生産情報化 3Dプリンタやロボット運用技術、様々なデータをネット通じ オープンに共有できるように ・現在の農業情報化ソリューションは高価 ささやかなモチベーション
  • 29. 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 ) API resouce mangagement API orchestration tools こんな応用が
  • 30. 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 importantphysical 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 出来ないかな?
  • 31. 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 APIAPI API API migration IPMI っと、思っています。
  • 32. この辺は、またどっかーで話しを。 そこに至る道として、今日ご紹介す る Serf や Consul は第一歩になるの ではと考えています。 千里の道も、一歩から!
  • 33. 2● ● ○ ○ 基礎編 1. Serf 2. Consul 3. envconsul
  • 37. Serflと Consul は Immutable Infrastructure の 文脈で登場 でも、オーケストレーションツールを 使えば、仕事が「楽しく」かつ「楽」 にできるのでは? という事を本日は 共有できれば、とっても嬉しいなって。
  • 38. 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 この資料を読んで、ようやくイミュータブ ルなインフラについてイメージが湧いてき たような。。←出遅れています。
  • 40. Serf の概要  軽量なオーケストレーションツール  全ノードで秒単位のイベント同期  メンバ一覧とイベントの発生を管理  障害検知、フェイルオーバー機能
  • 42. 軽量簡単  バイナリファイル一個で動作  Linux, MacOS, Windows  ロールとタグ機能を持つ 重要なのは、非常に軽い点。実メモリ の使用も 8KB 程度で、さほど負担に なりません。同じ仕組みは、たとえば Zoo Keeper でも出来るかもしれませ んが、環境構築・維持が負担です。
  • 43. 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 新機能の追加も一段落し、最近は割と 細かなバグ修正が中心。安定してきた 印象があります。
  • 44. Serf は 3 つの特長
  • 45. ※参考 http://www.serfdom.io/intro/ メンバ管理 障害検知 カスタムイベント 機能はこの3つだけです。 以降のページで1つ1つ見ていきます。
  • 46. 1. メンバ管理  クラスタ参加・離脱を管理  マスターサーバが無い(全て並列)  ロールとタグ機能を持つ  クラスタをゴシッププロトコルで構成
  • 47. A B ノード A と ノード B でクラスタを構成 「A」「B」2つの Serf ノードがあと します。実際のサーバ上では、 serf エージェントが動作しています。
  • 48. 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 の同期初期 化 ) を要請。要は友達リクエストです。
  • 49. A B serf join Agent joining: [B] Initiating push/pull sync with: B initiating push/pull sync Responding push/pull sync Responding to push/pull sync with: A B は A の要求に応答すると、A に対し てレスポンスを返します。 ※ serf は暗号化設定すると、暗号鍵 が一致しないノードとは繋がりません。
  • 50. A B serf join Agent joining: [B] Initiating push/pull sync with: B initiating push/pull sync Responding push/pull sync Responding to push/pull sync with: A EventMemberJoin: B EventMemberJoin: A A B A に B の応答が届くと、メンバー参加 ( MemberJoin ) というイベントが同時 に発生します。 A は B を、B は A を認識します。
  • 51. A BInitiating push/pull sync with: B Responding to push/pull sync with: A initiating push/pull sync Responding push/pull sync そしてお互いをメンバとして認識した クラスタが構成されます。友達同士、 ふたりは プ… Serf ☆ クラスタ!
  • 52. A B Initiating push/pull sync with: AResponding to push/pull sync with: B initiating push/pull sync Responding push/pull sync クラスタ構成後は、
  • 53. A BInitiating push/pull sync with: B Responding to push/pull sync with: A initiating push/pull sync Responding push/pull sync 相互にお互いの情報を確認しあいます。
  • 54. A B Agent joining: [?] C ノード C が仲間になりたがってこっちを見ている! serf join では、新しいノード C がクラスタに 参加するとき、A と B 、どちらに join 宣言をしたらいいでしょうか? 答えは、A ・ B どちらでも大丈夫。 なぜなら、A と B でイベントを同期 するので「友達の友達は友達」にな るからです。 ?
  • 55. A B Agent joining: [A] Initiating push/pull sync with: A initiating push/pull sync C ノード C が仲間になりたがってこっちを見ている! serf join ここでは C が Aに join を試みます。
  • 56. 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 ノード C が仲間になりたがってこっちを見ている! serf join A が C に応答すると・・・
  • 57. 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 ノード C が仲間になりたがってこっちを見ている! serf join EventMemberJoin: B EventMemberJoin: A EventMemberJoin: CEventMemberJoin: C メンバ参加のイベント が、3ノード同時に発生 A … C は新しい友達 B … C は新しい友達 C … A ・B は新しい友達
  • 58. A B C ノード C が仲間に加わった! EventMemberJoin: B EventMemberJoin: A EventMemberJoin: CEventMemberJoin: C これでクラスタが構成 されました。あとは、 ノードが何台増えよう とも、同じような動作 で十数台、百台とス ケールしていきます。
  • 59. A B C Responding push/pull sync initiating push/pull sync 以後はランダムに相互監視
  • 60. A B C Responding push/pull sync initiating push/pull sync 以後はランダムに相互監視
  • 61. A B C Responding push/pull sync initiating push/pull sync 以後はランダムに相互監視
  • 62. A B C Responding push/pull sync initiating push/pull sync 以後はランダムに相互監視
  • 64. 2. 障害検知  イベントが直ちにに伝わる  イベントハンドラで何か実行する仕組み 障害検知の仕組みを見ていきます。
  • 65. A B C B は死んでしまった! 突然の死! クラスタを構成する1台に障害が発生。
  • 66. A B C B は死んでしまった! 突然の死! Initiating push/pull sync with: B initiating push/pull sync 死んでも直ぐに検出できません。 B に対するチェックが応答しなくなる までは、まだクラスタ上では生きてい るとみなされています。このタイムラ グは、秒単位で変更可能です。 STATUS: 死野球しようぜ!
  • 67. A B C B は死んでしまった! 突然の死! Initiating push/pull sync with: B initiating push/pull sync 返事が無い。 ただの屍のようだ EventMemberFailed: B EventMemberFailed: B STATUS: 死 B の応答がないため、A と C は、B の 障害が発生したとみなすイベント member-failed を発行します。
  • 68. A B C 復活の時を待ち続けます serf: attempting reconnect to serf: attempting reconnect to STATUS: 死 fail した段階では、まだクラスタとし て認識されます。A・C 双方から、定 期的に B に対してチェックが走りま す。ネットワーク障害の可能性もあ りますし、B が復活したら、B は何も しなくてもクラスタに復旧します。 一番良い ザオリクを 頼む…
  • 69. A B C 反応が無い場合は切り離します serf: attempting reconnect to serf: attempting reconnect to もうだめかも 分からんね EventMemberLeap: B EventMemberLeap: B STATUS: 死 一番良い ザオリクを 頼む… 規定時間(初期値は 24 時間後、変更可 能) の応答がなければ、対象メンバを ノードから削除する member-leap イ ベントが発生します。
  • 70. A B C 残った2台でクラスタを構成します Responding push/pull sync initiating push/pull sync ここまでが メンバーシップの 基本動作です 野球しようぜ! 素振りは基本 監視ツールで対象ノードの 自動削除を行うなら、この member-leap イベントの 発生をトリガにします。 何時削除するの?今しょ!
  • 71. 3. カスタムイベント  任意のイベントを自分で定義できる ・ 標準イベント … メンバ参加, 離脱時に 自動発生する ・ カスタムイベント … いつでも実行可 最後に重要なのは、このイベントを複 数台同時に(数秒以内で)実行できる という点です。
  • 76. ハンドサイン画像ジェネレーター http://bzmm.jp/hs_gene/ やっぱり Serf ! 100 ノード同時実行でも大丈夫! ※理論値 1秒で 95% 、2秒でほぼ100%伝播 ( 物置かな? )
  • 78. 適用例  ウェブサーバとロードバランサ ➡ ウェブサーバの稼働状況に応じて、ロードバランサの適用・除外を行う  Memcached や Redis クラスタ ➡ Serf のメンバーシップと、それぞれのクラスタを連携  デプロイ時のトリガ ➡ Serf の ‘event’ システムを用いて、ノードがメッセージ受信時、ただちにデプロイ開始  DNS レコードの更新 ➡ ノードの参加・離脱のタイミングで即時にレコードを更新  単純な監視 ➡ ‘query’ を用いて、uptime を全ノードに対して同時実行し、結果を表示  サービス検出のための基礎部分を構築 ➡ 上記の例を実現するための仕組みを、Serf は内包している。 ➡ いずれも中央集権型ではなく、マスターは不要。耐障害性を持っている。 ※ http://www.serfdom.io/intro/use-cases.html 日々、私たちが運用現場で使っている 「手作業」にあたる部分を自動実行し、 省力化につながります。
  • 79. 他ツールとの比較  Zookeepr, doozerd, etcd ➡ Serf と同様のクライアント・サーバ型のアーキテクチャ • これらは、(ツールとして使うには)比較的複雑な分散システム ➡ Serf が提供する機能は、メンバーシップ管理、障害検知、ユーザイベントのみ。  Chef, Puppet 等々 ➡ 構成管理ツールは、メンバシップ管理までは行う。 ➡ ツールの目的は、タスクを処理することで、迅速な実行や障害検知意識されていない。 ➡ Serf は、これらツールと並行利用出来る。  Fabric ➡ Fabric は、デプロイ・システム管理ツール。 • Serf より優れている点がいくつか(例:コマンド実行エラー時に、何か処理を実行) • 実行速度の遅さや、ノード検出に関する課題がある。 ➡ Serf は、何かしら実行結果(output_が必要なときに連携する使い方 • Fabric が Serf ノードに対して問い合わせを行い、Serf は一斉に実行 Serf クラスタを維持するための手間が、 他のツールよりもかからず、既存のシ ステム構成を変えるひつようもありま せん。
  • 80. 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/
  • 81. 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
  • 82. イベントを送ってみよう 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 の面白い所ではないでしょうか。
  • 83. イベントハンドラ  イベントで、任意のコマンドを実行 ➡ メンバーシップに関連するイベント • 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/ このイベント処理が肝心です
  • 84. 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
  • 85. 暗号化にも対応  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 暗号化対応によって、実環境で 使えるようになったと思います。
  • 86. 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 のみ 参照するので注意。
  • 87. イベントハンドラの指定  イベントをトリガとしてコマンドを実行 ➡ 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
  • 88. 設定ファイルの書き方  起動オプションを設定ファイルに ➡ 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’ は例外で、配列として記述す る必要があります。
  • 89. 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 したり色々面倒。 なので普段の操作環境に統一する と色々楽ですしおすし。
  • 90. クエリとイベント  違い ➡ クエリは結果を取得できる ➡ イベントは一方的に処理する(結果問わず)  指定方法は、イベントハンドラで ‘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
  • 91.  軽量簡単なオーケストレーションツール  システム全体を統括する「何か」  自分の中では、 「日々の運用業務の面倒な事を」 よしなに処理するための仕組み Serf のまとめ http://pocketstudio.jp/log3/tag/serf/ 定期メンテに活躍しそう。 一年前に欲しかった。。
  • 93. LVS Web1 Web2 192.168.39.0/24 192.168.39.1 192.168.39.11 192.168.39.12 DSR 型の構成を考えてみます。 HTTP のロードバランサを作ります。
  • 94. 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 こんな風に初期設定を済ませます。
  • 95. 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 があれば …
  • 96. #!/bin/sh while read line do echo ${line} HOSTNAME=`echo ${line} | cut -d ' ' -f 1` ADDRESS=`echo ${line} | cut -d ' ' -f 2` ROLE=`echo ${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 を経由した制御も 行う事が出来ます。
  • 98. Consul http://www.consul.io/ そこで、Consul の登場です。 Serf がノード単位であるのに対し、 Consul はサービス単位で監視します。 Serf を作った Hashicorp から、今年 4月にリリースされました。
  • 99. Consul は Serf の仕組みに サービス検出を乗せたもの
  • 100. Consul を支える基礎技術  メッセージング ( Messageing ) … SWIM , Serf  リーダー選出 ( Leader Election ) … Raft  セキュリティ ( Security ) … TLS  データストレージ ( Data Storage ) … UMDB Understand Distributed Consensus http://thesecretlivesofdata.com/raft/ Consul の追加技術が Serf を内包。
  • 101. Consul のサービス監視  非中央集権型の Consul サーバ  ノードが主体の監視(サービスや間隔)  リアルタイムに動作する  現状を知るだけ、時系列データは保持しない 監視の役割に注視すると、障害発生な ど、サービスが変更したタイミングで、 任意の動作を行えます。
  • 102. 従来ツールとの比較 ・ 従来ツールによる障害検出は、監視サーバ主体 ・ サーバまたはノードが異常を検知するまでのタイムラグがあった ・ Consul による障害検出は、ノード主体 ・ 異常をただちに検出する。 ( 正確には、サービスを定義した監視時間間隔、またはノードダウン ) ・ envconsul と連携することで、障害発生後のアクションを行える  障害対応の自動化 に繋げることも ・ 対象ノードでアクション不要なら、エージェントレスの構成も
  • 106. ハードウェア ミドル ウェア ミドル ウェア サービス サービス OS  非中央集権型 中央集権型   サ ー ビ ス 指 向 イ ン フ ラ 指 向 
  • 107. 従来ツールとの関係  共存できる … 微妙に異なる監視レイヤ  機能的には相互補完  導入時、既存システムを変える必要がない 例1: Consul はノード内のサービス状況を取得し、Consul Serverに送る ZABBIX Sender で Consul の KVS からデータを取得し、時系列データ収集 必要に応じてアラートの送信や、更に他のツールとの連携をする 例2:Munin プラグインが Consul Server の KVS から情報を取得し、 munin-node を入れなくても、Munin でグラフを表示し、管理も自動化 むしろ、既存の監視ツールが出来な かった「何か」を可能にしてくれる、 ドラ○もんのような存在!
  • 109. ・ Web UI ・ HTTP API ・ DNS interface ・ Blocking Query ( via RPC ) ・ envconsul Consul のデータは Consul Server が 機能として持つ キーバリューストア (KVS) 上に保管されています。この データは、どのインターフェースを 使っても参照する事ができます。
  • 111. { "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 が実装されています。
  • 113. $ 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台の情報しか返さなくなりました
  • 114. 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 指定した条件に一致するまで、応答を 返さない(ブロックする)仕組みです。 逆に変化があれば、直ちに応答します。
  • 117. Consul における Anti-Entropy とは 「Consul ノードとサーバの矛盾した状態を、 随時比較し、差分があれば自動的に解消する 自己修復的な同期機能」である。 と思います。 より安定した状態を目指すという意味で、エントロピーという言葉が用い られているのでは。 現実世界にアンチ・エントロピーを例えると、小型自律掃除機ではないか。 ル○バが散らかった部屋の中を自動的に綺麗にするのは、エントロピーが 低い状態を保とうという機能を持っている。
  • 118. アンチ・エントロピー  Consul の情報同期は Anti-Entropy ➡ クライアント・サーバ間の情報伝達で クライアント ( Consul Agent ) に定義の権威 ➡ クライアントは、サーバで定義された情報を、 いつでも上書きすることが出来る  役割 ➡ クライアント ( consul node ) • 既知のノード状態を承認する • 定期的にローカル内部の状況をサーバに伝える ➡ サーバ ( consul server ) • 問い合わせ ( querying ) の役割 • そのために、データを保管し、回答するホスト役  エージェントがローカルの情報を持ち サーバは保持しない  エントロピーは、情報理論では確率変数 が持つ情報の量を表す尺度であり「情報 量」とも呼ばれる。情報量とは、確率変 数が大きければ大きいほど、情報量が大 きくなる傾向。 つまり、アンチ・エントロピーは、変化 (情報量の増加)に対して、不正確さ (クライアントとサーバの矛盾した状 態)を自動的に同期させようとする性質。 これを使って、変化を検出し、ただちに 様々な処理を実行できる。
  • 119. クライアント ( consul node) サーバ ( consul server) では、クライアントとサーバの関係を 図を使って見てみます。 重要なのは、権威があるのはクライア ントです。ボトムアップなのです。
  • 120. クライアント ( consul node) サーバ ( consul server) A B C 新しいサービスが追加される まだサーバは何も知らない
  • 121. クライアント ( consul node) サーバ ( consul server) A B C エージェントは サーバに情報を伝えると 新しいサービスが追加される
  • 122. クライアント ( consul node) サーバ ( consul server) A B C エージェントは サーバに情報を伝えると はじめて同期する A B C
  • 123. クライアント ( consul node) サーバ ( consul server) A B もし、サービスが消えると A B C
  • 124. クライアント ( consul node) サーバ ( consul server) A B クライアントはサーバと情報を比較 サーバに“C”は不要と伝える A B C
  • 125. クライアント ( consul node) サーバ ( consul server) A B クライアントはサーバと情報を比較 サーバに“C”は不要と伝える A B あいよ
  • 126. クライアント ( consul node) サーバ ( consul server) A B クライアントはサーバと情報を比較 サーバに“C”は不要と伝える A B あいよ クライアントとサーバで情報が同期。この性質がアンチエントロピー
  • 127. クライアント ( consul node) サーバ ( consul server) A B クライアントはサーバと情報を比較 サーバに“C”は不要と伝える A B あいよ クライアントとサーバで情報が同期。この性質がアンチエントロピー 決定権を持つのはクライアント側。 サービス状況の「変化」をトリガとし 様々な動作を起こすことができる。
  • 128. クライアント ( consul node) サーバ ( consul server) A’ B A B サービスのステータス、たとえば障害 になったとしても、サーバが知るまで はタイムラグがあります。
  • 129. クライアント ( consul node) サーバ ( consul server) A’ B A B 比較を行い、相違点があれば
  • 130. クライアント ( consul node) サーバ ( consul server) A’ B A’ B あいよ クライアントがサーバに命令します。 このような一連の動作が、Consul の Anti-Entropy です。 更に、KVS の値の変化をトリガとし、 様々なアクションを起こせます。
  • 131. Consul の 4 つの特長 ここから先も、座学的です。 実際に使うとき以外であれば、読み飛 ばしていただいて構いません。Zzz..
  • 133. サービス検出 Service Discovery  ‘api’ や ‘mysql’ という service 名を定義  検出は、consul ノードで自動的に開始  HTTP API または DNS で結果を返す
  • 134. サービス検出 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“ } ]
  • 135. サービス検出 Service Discovery  ‘api’ や ‘mysql’ という service 名を定義  検出は、consul ノードで自動的に開始  HTTP API または DNS で結果を返す $ 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
  • 136. 障害検知 Failure Detection  サービスやノードのヘルスチェック  ‘ping’ や ‘curl’ 等、コマンドレベルで指定  任意の監視間隔 (秒単位 )  HTTP API または DNS で結果を返す
  • 137. 障害検知 Failure Detection  サービスやノードのヘルスチェック  ‘ping’ や ‘curl’ 等、コマンドレベルで指定  任意の監視間隔 (秒単位 )  HTTP API または DNS で結果を返す $ 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" } ]
  • 138. 障害検知 Failure Detection  サービスやノードのヘルスチェック  ‘ping’ や ‘curl’ 等、コマンドレベルで指定  任意の監視間隔 (秒単位 )  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
  • 139. キーバリューストレージ Key/Value Storage  HTTP API を通して RESTful に操作  Consul server 間でデータを複製・保全  Consel システム機能が内部で利用  ユーザによる任意データの利用も可能
  • 140. キーバリューストレージ 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 }, ]
  • 141. キーバリューストレージ Key/Value Storage  HTTP API を通して RESTful に操作  Consul server 間でデータを複製・保全  Consel システム機能が内部で利用  ユーザによる任意データの利用も可能 $ curl -s http://192.168.39.5:8500/v1/kv/hello/key | ¥ jq '.[].Value | .' -r | base64 -d hello, world!
  • 142. マルチデータセンタ Multi Datacenter  複数のデータセンタにまたがって通信  LAN 側と WAN 側で別々のゴシッププール  ローカルクラスタにない問い合わせは転送
  • 143. Consul Architecture - Consul http://www.consul.io/docs/internals/architecture.html
  • 144. Consul Architecture - Consul http://www.consul.io/docs/internals/architecture.html
  • 145. Consul Architecture - Consul http://www.consul.io/docs/internals/architecture.html
  • 146. 強い基礎技術  メッセージング ( Messageing ) … SWIM , Serf  リーダー選出 ( Leader Election ) … Raft  セキュリティ ( Security ) … TLS  データストレージ ( Data Storage ) … UMDB
  • 147. Serf との違い Serf vs. Consul http://www.serfdom.io/intro/vs-consul.html Serf Consul 目的 サービス検出とオーケストレーション サービス検出と設定 ヘルスチェック 低レベル(ノード死活監視) サービス単位で高度な調整 キーバリューストア なし あり メンバーシップ ノード単位 サービス単位 Web API なし あり DNS インターフェース なし あり アーキテクチャ AP 型 ( 一貫性重視、可用性を犠牲 ) CP 型 ( 可用性より一貫性重視 )
  • 148. 試してみた  RHEL6/CentOS6 は、そのままでNG ( glibc の version )  Serf に慣れていれば、ほぼ同じような捜査感  Serf のような Consul の振る舞いだけど、別モノ Consulを使ってみた | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2014/04/18/what_is_consul/
  • 149. 利用方法 Consulを使ってみた | Pocketstudio.jp log3 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
  • 150. 利用方法 Consulを使ってみた | Pocketstudio.jp log3 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 $ 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
  • 151. ドキュメント  公式サイト  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/
  • 153. 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より)
  • 154. envconsulを使うには  Golang 開発環境 ➡ $ git clone git@github.com:armon/consul-kv.git ➡ $ git clone git@github.com: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
  • 155. $ 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 から情報の書き換え
  • 156. KVS envconsul envconsul envconsul • Web UI • HTTP API • DNS 更新 Consul が、KVS のデータ変化をトリガに、envconsul を使役する 参照 インターフェース Consul Server Consul Node Consul Node Consul Node KVS 上のデータを参照 環境変数を更新
  • 157. $ envconsul -addr="sakura1.pocketstudio.net:8500“ ¥ -reload envtest /bin/sh -c "/bin/env; echo "---"; /bin/sleep 1000“ 例:環境変数が変わる度に結果を画面に出力する。 envconsul には 2 つの役割 1. 環境変数を consul の KVS から取得する事 2. 環境変数に変化が発生したタイミングで何らかの処理を行う事 KVS の値変化をトリガに、任意のコマンド読み込みを 対象ノードに対して一斉に行う事が出来る。
  • 163. 3● ● ● ○ 実践編
  • 165. ニンゲンヤメマスカ? Do you resign as human being? It is necessary to answer the following questions to start OPERATION. YES はい はい YES 運用を続けるためには、イカの質問に答える必要があります。
  • 168. 今時の課題  スケールアップ・ダウンに連動し、 ホスト登録・削除を自動対応したい  グラフの登録・削除も自動対応したい  ZABBIX の管理を仕事にしたくない 対象ホストやサービスの自動登録に 加え、自動削除も可能となります。 API を使いこなせば、 ZABBIX 設定は 人間が行わなくとも、Consul だけで 完結できそうです。
  • 169. Serf と ZABBIX 連携  動機 ➡ ZABBIX 管理の自動化  仕組み ➡ Serf のイベント ( ノード参加・離脱 ) と ZABBIX 連携 • 既定の role に従って、 ZABBIX のグループや監視対象を制御 ➡ ZABBIX サーバには ZABBIX API ( JSON ) でリクエスト ➡ Serf のタグ機能でホスト情報 ( hostid ) を記憶  特長 ➡ ZABBIX ホスト管理の自動化(迅速かつフレキシブル)  今後の展開 ➡ Chef 等の構成管理ツールとの連携 ➡ クラウド事業者が提供する API と連携した仕組み 1.join Serf クラスタ 3. Monitoring Serf のクラスタ参加・離脱のタイミングで、 ZABBIX サーバに API をリクエストします。
  • 170. 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
  • 171. 以降は ZABBIX API に特化した話題なので こちらのスライドをご覧ください。 ZabbixのAPIを使って運用を楽しくする話 http://www.slideshare.net/zembutsu/serf-orchestration-with-zabbix-operation
  • 173. 応用例  Consul のサービス監視と LVS・HAProxy 連携  Consul , serf で Docker と Sensu の連動した自動監視  Consul の取得したデータを Munin に格納  定時処理 ( cron や serverspec のチェック )  これらを、リモートからログインすることなく実施
  • 175. 4● ● ● ● まとめ
  • 176. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話  今日のまとめ Serf や Consul は軽量シンプルでありながら、 様々なシーンに利用できる。また、他の類似 ツールを使うよりも利用の敷居が低い。 そのため、運用・開発にかかわらず、日々の 煩雑な業務から解放されるので、各々が取り 組む本来業務、とりわけ人間しかできない事 に集中できる。結果、仕事が楽しくなる。 Conclusion
  • 177. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話  この時間で得られたもの ・Serf や Consul とは ○○ です(キリッ と言える ・Serf や Consul の使い所をイメージできる ・運用や開発における自動化のための仕組み (ロジック)を自分で考えることができる Conclusion 簡単軽量なオーケストレーションツールであり、 APIを使ってツールを結びつけ、自動化を支援する。
  • 178. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話  質疑応答 Conclusion 本日の資料は、コマンドの reference などを追記し、 後日公開します。  http://slideshare.net/zembutsu/
  • 179. Dedicated to Our Future Pioneers. Where Do We Come From? What Are We? Where Are We Going? ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話  本日のフォローアップ ・ twitter @zembutsu  mention 下しあ ・ Google Plus https://plus.google.com/+MasahitoZembutsu ・ Google Group とか・・? なにか作ります・・・? Conclusion 本日の資料は、コマンドの reference などを追記し、 後日公開します。  http://slideshare.net/zembutsu/ Google Gropups に作りました! “オーケストレーションツールの部屋”
  • 180. IS THE ORDER AN AUTOMATION OF OPERATION AND MONITORING? Masahito Zembutsu @zembutsu Jun 22, 2014 , July Tech Festa#jtf2014 AITT Shinagawa Seaside, Tokyo ご注文は 監視自動化ですか? S e r f と C o n s u l を 使 っ て 運 用 を 楽 し く す る 話
  • 181. ノシ