Consul 0.6でユーザのいるshardを探す(Prepared Queryを使う)
この記事は HashiCorp Advent Calendar 2015 - Qiita の第21日目です。(大人な事情により Hamee Advent Calendar 2015 - Qiita の第20日目でもあります。なので微妙な時間に公開)
概略
ユーザIDをベースにDBを分割(sharding)しているのですが、プログラムからユーザのいるshardを探すのにConsulを使えないかなぁと思って試している話。
Consul0.6のPrepared Queryを使って解決してみました。
目次
ユーザIDをベースにDBを分割(sharding)していると、プログラムからユーザのいるshardを探す必要があります。 これをどこかのメタDBサーバにするってのも良いんだけど、Consul使ってDNSで引っ張ってこれると使う側にとって扱いやすいかなと思って調べてます。 ・Node設定 各DBではconsulのServiceが下記JSONの定義のように登録されています。 なので以下のような感じでDNSでひける状態です。
ちなみに試している環境にはdnsmasqを入れています。 Consul0.6で導入されたPrepared Query(以下PQ)を使う方法です。 PQに下記のような情報を登録します。(user1.jsonとします) これを以下のように登録します。 IDが発行されるので、これは後で必要になります。もしくは /v1/query にGETでリクエストすれば一覧が取れるので、そこから必要ものを探せばOKです。 このようにすると、以下のようにDNSでひけて、ユーザが収容されているmaster DBのIPが取得できます。 ・slave昇格 db01-aが死んでdb01-bがmasterになるときは、db01-bで のようにmasterのタグをもたせて これで、同じようにDNSをひくと、昇格したノードのIPが取得できます。 なお、db01-aがmasterのタグを持って起動しないようにする必要はあります。今回は、マシンブート時にconsulを自動起動させないようにして逃げてます。 ・shard移動 user1のいるshardがdb02になれば、 というJSONを用意して、このPQのIDを指定してPUTします。 これで、同じようにDNSをひくと、今度はdb02のmasterのIPが取得できます。 Consul0.6より前だとPQがないので、外部サービス(ノード)を登録することで同じようにことできると思います。 この場合、外部サービスとして以下のようなJSONを登録します。 こうすると、以下のようにDNSがひけます。 外部サービス(ノード)なので、CNAMEで解決されて、その後Aレコードを得るような形となります。 shardの移動は、Nodeの定義を更新することで対応することとなります。 Consul0.6より前ではこの方法かなぁとは思うのですが、Consul0.6だとPQによりCNAMEを介さずにひけるので方法1を採用予定です。 ・タグだけで のようにタグだけで解決することも可能は可能かと。 ただ、shard移動するときとか、userの追加・削除時には必要なタグをして指定して更新するのでちょっと大変そう。 ・サービスだけで みたいなサービスをユーザ数分だけ登録することでもできそう。 この場合、slave昇格でユーザ数分だけServiceを更新・登録とかしないといけなのでこれも大変そう。 ユーザIDをベースにDBを分割(sharding)しているような場合に、それをDNSでひけるようにするには、Consul0.6のPrepared Queryを使うとなんとかなりそうでした。 ちなみに、PQを1万ほど突っ込んでみた範囲では、DNSをひくことにパフォーマンス的な影響は特に見られませんでした。 Consulでやる場合のもっと良い方法とか、そもそもConsul使うべきじゃないとかありましたら教えてください。背景
前提
{
"Service": {
"name": "db01",
"tags": [ "master" ]
}
}
# dig master.db01.service.consul.
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> master.db01.service.consul.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53317
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;master.db01.service.consul. IN A
;; ANSWER SECTION:
master.db01.service.consul. 30 IN A 192.168.0.11
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 18 14:11:33 2015
;; MSG SIZE rcvd: 94
方法1(今回採用予定)
{
"Name": "master-db-user1",
"Service": {
"Service": "db01",
"Tags": ["master"]
},
"DNS": {
"TTL": "30s"
}
}
$ curl -X POST http://localhost:8500/v1/query --data-binary @user1.json
{"ID":"66804426-8e5f-427b-caa7-d896c9328910"}
$ dig master-db-user1.query.consul.
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.2 <<>> master-db-user1.query.consul.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14375
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;master-db-user1.query.consul. IN A
;; ANSWER SECTION:
master-db-user1.query.consul. 30 IN A 192.168.0.11
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 18 14:44:21 2015
;; MSG SIZE rcvd: 94
{
"Service": {
"name": "db01",
"tags": [ "master" ]
}
}
consul reload
すればよいです。$ dig master-db-user1.query.consul. +short
192.168.0.12
{
"Name": "master-db-user1",
"Service": {
"Service": "db02",
"Tags": ["master"]
},
"DNS": {
"TTL": "30s"
}
}
$ curl -X PUT http://localhost:8500/v1/query/66804426-8e5f-427b-caa7-d896c9328910 --data-binary @user1.json
$ dig master-db-user1.query.consul. +short
192.168.0.21
方法2
{
"Node": "master-db-user1",
"Address": "master.db01.service.consul"
}
$ curl -X PUT http://localhost:8500/v1/catalog/register --data-binary @user1-node.json
$ dig master-db-user1.node.consul.
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.2 <<>> master-db-user1.node.consul.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29792
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;master-db-user1.node.consul. IN A
;; ANSWER SECTION:
master-db-user1.node.consul. 30 IN CNAME master.db01.service.consul.
master.db01.service.consul. 30 IN A 192.168.0.11
;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 18 15:20:49 2015
;; MSG SIZE rcvd: 166
その他の方法
{
"Service": {
"name": "db01",
"tags": [ "master", "user1", "user2", ・・・ ]
}
}
{
"Service": {
"name": "user1",
"tags": [ "master"]
}
}
まとめ
fluentdのプルリク#696へのフィードバックを求めています
下記は、https://github.com/fluent/fluentd/pull/775 で2016/01/18にマージされたました!
Fluentd Advent Calendar 2015 - Qiita の10日目がまだ空いていたので、入れさせてもらいました!
今、in_tailに関して下記PRを出させてもらっています。
fluentd v0.12.18 が出ましたが、これはまだ取り込まれていません(想定内)。
な状況です。
in_tailのmultilineモードでは、Fluentdのin_tailプラグインで複数行のログをよむ方法 - Boost Your Programming! で説明されているように
つまり、メッセージがログに出力されてもすぐにそのログがFluentdのメッセージとして送信されるわけではなく、次のログが出てくるまで遅延することになります。
という問題があります。
頻繁にログが流れるような状況であると問題にはならないのですが、ログをfluentdでとりあえず集めているとそんなに頻繁に出力されるないようなログも対象としいたりして、その際にmultilineで取り込んでいるとこの仕様では困ることがあります。
そこで、上記PRを出している感じです。
とりあえず、同じことができるものを in_tail_multiex.rb · GitHub に起きました。
これを /etc/td-agent/plugin 配下に置いて conf に
<source> type tail_multiex path /path/to/logfile tag my.tag pos_file /var/log/td-agent/my.log.pos format multiline format_firstline /^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d / format1 /^(?<time>\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d) (?<message>.*)$/ multiline_flush_interval 1s </source>
のようにmultiline_flush_interval
を指定してもらえればよいです。この指定した期間、ログに出力がないと、fluentdのメッセージとして送信されます。
問題や、コメントなどありましたら、上記PRなり、そもそもの issue
などにご意見をいただければ幸いです。
実際問題としてはとりあえず、gistにあげたような独自プラグインで当面のニーズは満たしていますが、本体に取り込まれるとより嬉しいかな、ということで。
pixzでケチケチバックアップ(もしくはGCS Nearlineで節約バックアップ)
この記事は qiita.com の7日目です。
TL;DR
pixzでCPUマルチコアを使って高速かつ、高圧縮することで、バックアップの保存料金節約をしました。
GCS Nearlineなら、GB単価も安いし、取り出すときも高圧縮してあれば取り出し料金、データ転送料金も安く抑えられて一石二鳥でした。
目次
日々多数あるオンプレミスなサーバ内の種々なデータを gzip 圧縮して AWS S3($0.0330/GB/Month)に保存しているのですが、1TBを超えてきたのもあるし所詮バックアップで取り出すことはたまにしかないので、より安い GCS Nearline($0.01/GB/Month)に移行することにしました。 ついでに、gzip圧縮するのと同じ実時間程度でより高圧縮にすると、保存料金も取り出し料金も安くできるので、圧縮方法について簡単に評価することにしました。 すでに最初に書いているように、最終的には pixz を選択したのですが、評価対象・内容を書いておきます。圧縮対象や用いるサーバ(CPU)によってこのあたりは判断が分かれることになるので、参考程度にしてもらえると良いです。 ・圧縮対象 を使用しました。 ・環境 ファイルを一度readして、キャッシュにのせての評価です。 Writeについても各コマンドが終了するまでの時間で、Diskへの同期までは含んでいません(のはず)。 ・結果 結果は下記のとおりです。time コマンでの計測です。 logrotate で pixz を使いたい場合は logrotate.d 配下に作るファイルで のような記述を入れればよいです。 CentOS5/6 で使う必要があったので、そのビルド方法を下記に記しておきます。 pixzをビルドするには liblzmaやlibarchiveが必要となる。特に liblzma については xz-devel パッケージでインストールされたものではpixzのビルドが通らない。
そこで、liblzmaおよblibarchiveについてもソースからビルドし、pixzはそれらを static link するようにする。 ・ビルド用ディレクトリの準備 ビルド作業用にディレクトリを作成しておく。 ・libarchiveビルド http://www.libarchive.org/downloads/ より最新のソースを取得し、ビルドする。 ・liblzmaビルド http://tukaani.org/xz/ より最新のソースを取得し、ビルドする。 ・pixzビルド https://github.com/vasi/pixz/releases より最新のソースを取得し、ビルドする。 libarchiveを認識するための設定 configure make これで、ldd でダイナミックリンクしているライブラリを確認し、liblzmaとlibarchiveがないことを確認する。 こうして出来上がった pixz を /usr/bin なり /usr/local/bin なりにコピーして使えばよい。 結局、バックアップに必要な領域にかかる費用は 1/5 くらいになって幸せです! pixzとGCS Nearlineでバックアップ保存料を大幅に削減できました。 注意1:pixzはデフォルトでは全Coreを全力で使うので適宜パラメータを調製しましょう。 注意2:AWS EC2にあるデータなんかはS3に保存しています(pixzは使ってます)。AWSからGCS Nearlineに転送するとその料金が高いので。背景
評価
MySQLのダンプファイル:サイズ 1863439430 byte
CPU E5-2407 2.20GHz(4Core)
Memory 16GB
software
time real
time user
圧縮ファイルサイズ
gzip
41.381s
40.158s
132994340
bzip2
9m7.662s
9m6.532s
86384870
pbzip2
2m23.181s
9m18.850s
86384870
pbzip2 -1
1m36.440s
6m22.965s
139260027
xz -1
1m17.306s
1m15.626s
105005636
pixz -2
26.569s
1m43.460s
87629204
pixz -3
38.820s
2m30.649s
84229748
pixz -2
が圧縮率や処理時間からするとベターに見えるので、これを採用した。logrotate
compress
compresscmd /usr/local/bin/pixz
compressoptions -2
compressext .xz
pixzのビルド
$ mkdir $HOME/pixz_build
$ cd $HOME/pixz_build
$ wget http://www.libarchive.org/downloads/libarchive-3.1.2.tar.gz
$ tar xzf libarchive-3.1.2.tar.gz
$ cd libarchive-3.1.2
$ ./configure --prefix="$HOME/pixz_build"
$ make
$ make install
$ cd $HOME/pixz_build
$ wget http://tukaani.org/xz/xz-5.2.2.tar.gz
$ tar xzf xz-5.2.2.tar.gz
$ cd xz-5.2.2
$ ./configure --prefix="$HOME/pixz_build"
$ make
$ make install
$ export PKG_CONFIG_PATH=$HOME/pixz_build/lib/pkgconfig
$ pkg-config --exists --print-errors "libarchive"
$ cd $HOME/pixz_build
$ wget -O pixz-1.0.5.tar.gz https://github.com/vasi/pixz/releases/download/v1.0.5/pixz-1.0.5.tar.gz
$ tar xzf pixz-1.0.5.tar.gz
$ cd pixz-1.0.5
$ LIBARCHIVE_LIBS=$HOME/pixz_build/lib/libarchive.a LZMA_LIBS=$HOME/pixz_build/lib/liblzma.a ./configure --prefix="$HOME/pixz_build"
$ make CFLAGS="-I$HOME/pixz_build/include/"
$ ldd src/pixz
linux-gate.so.1 => (0x00302000)
libm.so.6 => /lib/libm.so.6 (0x00ca9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00c8d000)
libc.so.6 => /lib/libc.so.6 (0x00b28000)
/lib/ld-linux.so.2 (0x00b09000)
結果・まとめ
カジュアルにMySQLスローログ可視化with Fluentd+Elasticsearch+Kibana
この記事は
- MySQL Casual Advent Calendar 2015 - Qiita
- Elasticsearch Advent Calendar 2015 - Qiita
- Hamee Advent Calendar 2015 - Qiita
の第4日目です。
TL;DR
開発者の皆さんに、CasualにMySQLスローログを分析しもらうために、Fluentd + Elasticsearch + Kibana でMySQLスロークエリを下図のようにビジュアライズしました。(Kibana上で EXPLAIN の結果も確認できるようにしてあります)
ついでに、以下の Fluentd の filter plugin を作成しました。
目次
MySQLのスローログの一覧をくれ、と言われたのがきっかけですが、せっかくなので EXPLAIN の情報も渡したいし、発生状況を随時確認できるほうがうれしいかなということで、可視化する方向にしました。 最初は nata2 を使えばいいやと思っていたのですが、スロークエリとなっているSQLが巨大過ぎて nata2 が作るURIが長大になりすぎる問題に当たったたり、EXPLAINがないしってところでそのまま使うことは諦めました。 他には、 というやり方もありましたが、nata2のようにSQLのfingerprintでまとめるようになってないし、やはりEXPLAIN情報もないしってことで、結局、以上の情報をMIXして Fluentd(+自作プラグイン) + Elasticsearch + Kibana で可視化することにしました。
その方法をこのエントリーで書きます。 環境、バージョンは下記の通りです。 Java, Elasticsearch は yum でインストールしています。
Kibana は kibana4セットアップ - Qiita を参考にしました。 Elasicsearch では文字列の解析をされると困るので、下記のコマンドで文字列を解析しないように設定してあります。 fluentdでの処理の流れとしては下記のようなイメージとなっています。 実際には、filter_record_transformer より後、out_elasticsearch 前で、out_foward, in_forward を使ってデータを1箇所に集約する感しています。 以下に、使用している一部のプラグインについてコメントします。 MySQL のスローログファイルをfluentdに取り込むプラグインには yuku-t/fluent-plugin-mysqlslowquery · GitHub もあるのですが、 studio3104/fluent-plugin-nata2 · GitHub の方が できれば、nata2のプラグインに同梱ではなくて、昔のように分離しておいてくれるとPRとか出しやすいかなぁと思っています。 自作プラグイン kikumoto/fluent-plugin-mysql_explain · GitHub です。 このプラグインは、in_mysqlslowquery_ex で取得されたJSONの 自作プラグイン kikumoto/fluent-plugin-sql_fingerprint · GitHub です。 このプラグインは、in_mysqlslowquery_ex で取得されたJSONの 標準入力にSQLを受け取り、標準出力に抽象化された SQL (fingerprint) を出力する外部ツールに依存しています。実際のところは Percona Toolkitに含まれる pt-fingerprint を利用していますが、条件を満たすものであればなんでもOKです。 以下、td-agent.conf の設定例です。 これで、Elasticsearch に EXPLAIN もついたデータが登録されるようになります。 初回 Kibana にアクセスすると Index の設定を求められるので、上記の設定であるなら、 して、 グラフを出すには、
あとは、グラフ幾つかつくって適当にDashboardに登録してお好みにレイアウトすれば、冒頭に貼ってあるようなものができあがります。 Fluentd(+自作フィルタープラグイン) + Elasticsearch + Kibana でMySQLスロークエリを可視化しました。 ログをカジュアルに取り込める Fluentd、データをカジュアルに放り込める Elasticsearch、カジュアルにグラフを作ることのできる Kibana、どれも大変便利! 世の中から背景
Elasticsearch + Kibana 環境
名前
バージョン
OS
CentOS 6
Java
Open JDK 1.8
Elasticsearch
1.7.3
Kibana
4.1.2
curl -XPOST 127.0.0.1:9200/_template/strig_not_analyzed_template -d '{
"template": "*",
"mappings": {
"_default_": {
"dynamic_templates": [
{
"string_template": {
"mapping": {
"index": "not_analyzed",
"type": "string"
},
"match_mapping_type": "string",
"match": "*"
}
}
]
}
}
}'
Fluentd
in_mysqlslowquery_ex (fluent-plugin-nata2同梱)で、スロークエリログファイルをparse
↓
filter_record_transformer でホスト名設定
↓
filter_mysql_explain (自作プラグイン)で、EXPLAIN 結果取得
↓
filter_sql_fingerprint (自作プラグイン)で、sql の fingerprintを取得
↓
out_elasticsearch で Elasticsearch にデータ登録
in_mysqlslowquery_ex
SET timestamp
をあらかじめ除外してくれたりとか、アクセスしているDB情報も保持してくれたりして、すぐ使うに便利だったのでこちらを選択しました。filter_mysql_explain
sql
属性に保持されている SQL に対して EXPLAIN を実行して、その結果を explain
属性に保持する filter plugin となっています。filter_sql_fingerprint
sql
属性に保持されている SQL 文のパラメータ部分を抽象化するものです。抽象化されたSQLは fingeprint
属性に保持されます。設定例
<source>
type mysqlslowquery_ex
path /var/log/mysql/mysql-slow.log
tag mysqlslowquery.myapplication
pos_file /var/log/td-agent/mysql-slow.log.pos
last_dbname_file /var/log/td-agent/mysql-slow.log.lastdb
</source>
<filter mysqlslowquery.**>
type record_transformer
<record>
hostname ${hostname}
</record>
</filter>
<filter mysqlslowquery.**>
type mysql_explain
host 127.0.0.1
port 3306
database mydb
username dbuser
</filter>
<filter mysqlslowquery.**>
type sql_fingerprint
fingerprint_tool_path /usr/bin/pt-fingerprint
</filter>
<match mysqlslowquery.**>
type elasticsearch
type_name myapp-mysqlslowquery
host 127.0.0.1
port 9200
logstash_format true
logstash_prefix mysqlslowquery
include_tag_key true
</match>
Kibanaのグラフ作成例
Index contains time-based events
にチェックIndex name or pattern
に mysqlslowquery-*
を入力Create
すれば OK です。Visualize
で例えば、Vertical bar chart を選んで、下図のようのな設定を入れれば、fingerprint 単位で各ホストごとに色分けされたグラフが出力できます。まとめ
クソスロークエリがなくなることに貢献できれば幸いです!
当日朝に繰り上がって次世代Webカンファレンスに行ってきた!
なんとか当日朝に繰り上がって、次世代Webカンファレンス
に行ってきました。 参加したセッションは下記です。
- server_perf
- server_arch
- webrtc
- https
- monitoring
各セッション内容の録画やまとめは別途公開されるということですし、まとめ系はいろんな方がしてくれるでしょうからそこは書きません。
ざっくり感想を。
このイベントは全セッション、トークセッションというちょっとあまりないパターンでしたが、登壇さらた方々すごすぎるのもあって、参加した身としては非常に充実した1日を過ごさせていただきました。 Jackさんはじめ、運営・登壇者の皆様ありがとうございました!
Webという題材で各テーマに応じて、今何が起こっているか?」と「これからどうなっていくのか?」について様々な議論・意見を、まさにこの人たちから聞きたいというのを聞くことが、しかもまとめてというのはそうそうあることではないので、というか今までなかったので、とてもよいイベントでした。感謝しかないです。 また、よくある事前打ち合わせありきのものではなく、話したいレベルで話すというスタンスも非常に良かったと思います。
まぁ、スタッフは登壇者以外でボランティアあたりは募っても良かったのかもしれませんね。
また次回があることを期待しつつ、その時にはなにか協力できるくらいになれればと思いながら帰宅しましたぁ。 いやぁ、充実した1日でした。
あらためて、皆様ありがとうございました。
GCPサービスアカウントでgsutilを利用したりAPIアクセスする方法
GCPのリソース、例えばGoogle Cloud Storageにアクセスする際に個人のアカウントを使って gcloud auth login
などで認証すればgsutilでアクセスできるけれど、サーバーサイドのアプリケーションなどからアクセスする場合は個人のアカウントで認証したくはないですね。
このような用途のためにGCPにはサービスアカウントというのがあるようです。このサービスアカウントを使ってGCPリソースにアクセスする方法についてメモっておきます。
サービスアカウントの取得
Google Developer Consoleの "APIs & auth" -> "Credentials" -> "Add credentials" から "Service account" を選択します。
そうすると Key type として "JSON" か "P12" を選択できるので、"JSON"を選択して "Create" します。そうすると、json ファイルがダウンロードされます。
過去の情報ではJSONファイルを利用した認証にはバグがあってP12で回避しているものがありますが、今では解消されておりJSONを推奨しているようなので、JSONを利用します。
取得したJSONファイル内にも記載されていますが、コンソールにもEmail addressが表示されるのでこれは後で使います。このEmail addressで認証してアクセスするような感じとなっているようです。
APIアクセスでの使い方
Goであれば、
go-docs-samples/listbuckets.go at master · GoogleCloudPlatform/go-docs-samples · GitHub
にサンプルがあります。これを動かすにはまず以下のように go get
します。
$ go get golang.org/x/oauth2/google $ go get google.golang.org/api/storage/v1
ビルド後、
を指定して、実行します。以下のような感じです。
$ GOOGLE_APPLICATION_CREDENTIALS=/path/to/myproject-9999-9c82deb7e430.json TEST_PROJECT_ID=myproject-9999 ./listbuckets
これで、Google Cloud Storage のBucketが表示されます。
gcloud(gsutil)での使い方
gcloud(gsutil)の場合、
$ GOOGLE_APPLICATION_CREDENTIALS=/path/to/myproject-9999-9c82deb7e430.json gsutil ls -p myproject-9999
でいけるかと思いきや、これは認証を通りませんでした(jsonファイルを読んでいない感じ)。
なので、以下のようにして key file を使ってサービスアカウントをActivateします。Mail Address部分は上記で出てきたメールアドレスです。JSONファイル内にも記載されています。
$ gcloud auth activate-service-account XXXXXXX-zzzzzzzzzzzzzzzzzzzzzzzzzz@developer.gserviceaccount.com --key-file /path/to/myproject-9999-9c82deb7e430.json --project myproject-9999
これで、gcloud auth list
で確認すると
$ gcloud auth list Credentialed accounts: - XXXXXXX-zzzzzzzzzzzzzzzzzzzzzzzzzz@developer.gserviceaccount.com (active) To set the active account, run: $ gcloud config set account ``ACCOUNT''
のようになっています。
この状態で
$ gsutil ls
とすれば、Bucket一覧が表示されます。
参考にした情報
Rundeckで始めるstretcherによるPull型デプロイ
オートスケールとかもろもろの理由からPull型デプロイに変えていきたいと思い、そうすると
を使いたいなぁとか思うわけです。 でも、Consul やら Serf まで今必要ないよなぁ、ということで Rundeck と組み合わせてみるといい感じになるのではと思いやってみました。
stretcher 作者である id:sfujiwara さんのエントリー YAPC::Asia 2015で発表してきました & ConsulとStretcherについて - 酒日記 はてな支店 にもある通り、stretcher は Consul / Serf なしに使えます。
Rundeck はインストール済みとします。Rundeck については下記リンクあたりをご参照いただくのがよいかと。
- 痒いところに手が届くバッチコントローラ「Rundeck」をご紹介! | 株式会社ロックオン社員ブログ
- ジョブスケジューラ「Rundeck」を試してみる | Developers.IO
- Cronの代わりに『Rundeck』を使ってみたら良い感じですよ!
上記あたりを参照して、まず適当にProjectを作成しておきます。
ノード
ここでのノード構成は以下のような感じです。各デプロイ先にはRundeckで設定したSSHキーを使ってログインできる状態にしておきます。
- 10.240.0.2 - Rundeckサーバ
- 10.240.0.3 - デプロイ先その1
- 10.240.0.4 - デプロイ先その2
- 10.240.0.5 - デプロイ先その3
Projectを作成すると /var/rundeck/projects/<プロジェクト名>/etc/resources.xml というファイルができているはずなので、これにデプロイ先のノード情報を登録します。以下のような感じ。
<?xml version="1.0" encoding="UTF-8"?> <project> <node name="localhost" description="Rundeck server node" tags="" hostname="localhost" osArch="amd64" osFamily="unix" osName="Linux" osVersion="3.19.0-28-generic" username="rundeck"/> <node name="node1" description="app node 01" tags="" hostname="10.240.0.3" username="appuser"/> <node name="node2" description="app node 02" tags="" hostname="10.240.0.4" username="appuser"/> <node name="node3" description="app node 03" tags="" hostname="10.240.0.5" username="appuser"/> </project>
各デプロイ先に、stretcher をインストールしておきます。おおよそ下記手順です。
$ go get github.com/fujiwara/stretcher $ cd $GOPATH/src/github.com/fujiwara/stretcher $ make get-deps $ make $ make install
なお、ここではmakeしてできたバイナリファイル:stretcherを、/usr/bin にコピーしてあることを前提としています。
Job 登録
実際に Job を作成していきます。
Options
マニフェストファイルを指定できるように Options を使います。
"Required" も "Yes" にしておきます。
Workflow
Step を追加します。ここでは inline script を追加います。 以下はスクリプトの内容です。
echo $1 | AWS_CONFIG_FILE=/path/to/aws_credentials /usr/bin/stretcher
また、"Arguments" には、
${option.manifest_url}
を指定しておきます。これにより、上記の Options で入力されたマニフェストURLが使われます。
Nodes
上記で登録したノードで実行されるようにします。下記のような感じです。
Thread Count
ここで1より大きい値を設定すれば、Rundeckは複数のノードに対して並行で処理を実行してくれます。
ただ、台数が数十台とかそれなりの台数になるなら Consul とかの別な方法で stretcher をキックする方が良さそうな気はします。
If a node fails
これ重要な設定です。これを下記のようにしておかないと、どこかのノードでデプロイが失敗すると、残りのノードで処理が実行されません。
あとは、好みで設定して Job を登録します。
Job 実行
Rundeckを使って stretcher をキックしていればその成否もわかるので、consul-kv-dashboardとかも不要で Rundeckに情報が集約されるのもよいです。
成功例
Job を実行して成功すると、以下のような結果を見ることができます。
"Log Output" に切り替えれば、stretcherの出力も見れます。
失敗例
デプロイに失敗しているホストも、下記のような感じで一目でわかります。
実行中
並列に実行されている様子も下記のようにわかります。(以下は、"Thread Count" を "2" にしています)
と、こんな感じで結構気軽に stretcher の導入ができるので Rundeck との組み合わせはオススメですね。
これに先立ち個人的に IAM Role を割り当てたEC2インスタンスで stretcher を動かしたかったので、その Pull Request を出してマージしてもらいました。id:sfujiwara さん Thanks!
みなさんも stretcher 使って、Pull型デプロイしましょう。