PackerでAMIを作ると流れるようにできるしChefの確認も流れるようにできた
HashiCorpのPackerの使い勝手の良さはすごくいい。
AWS環境でしか使っていないが、とても手軽にAMIをbakeできる。(bakeという単語を公式で使っていた)。 特に、Windows機のAMIをbakeするのに威力を発揮してくれた。
そもそも、Windowsに限らずだが、後のインスタンス構築の手間を省く目的でpre-bakedなAMIを作るとき、 本当にとっかかりの段階ではだいたい以下のようなサイクルを手元で回したくなるはずである(自分だけ?)。
Chefなどのプロビジョニングツールのレシピを書く ↓ ( Chef Serverにレシピをupload ) ↓ EC2インスタンス再作成して適用 ↓ 失敗。。。調査。。 ↓ Chefなどのプロビジョニングツールのレシピを書く ↓ ( Chef Serverにレシピをupload ) ↓ EC2インスタンス再作成して適用 ↓ 失敗。。。調査。。 ↓ ・・・ ・・・ ↓ 成功 ↓ AMI化して完了
この時、Windowsだと圧倒的に困るのが、とにかくterminate/startが遅いことで、インスタンス再作成だけで数分とか数十分とか必要なことも。 せめて、terminateくらいは素早くやらせてほしい。
すばやく環境を構築/破棄するという観点では、Terraformを使っていると環境の構築/破棄がコマンド1つでとても簡単に行えるが、それでもapplyとdestroyを繰り返すのは、ずっと続けているとなんかアホらしくなってくる。
あと、applyしている途中で誤りに気づいてCtrl-cとかしたくても怖くてできない。 だいたい、applyのログ追ってれば、こりゃダメだって途中で気づくことも経験上よくある。しかし、Ctrl-cしたくてもterraformだと少し怖いし変にリソースが残るのが嫌なので、それはできない。
Packerだとこうだ。
簡単なtemplate(example.json)を用意する。
{
"variables":{
"home": "{{env `HOME`}}"
},
"builders": [
{
"type": "amazon-ebs",
"region": "ap-northeast-1",
"access_key": "{{user `aws_access_key`}}",
"secret_key": "{{user `aws_secret_key`}}",
"source_ami": "ami-d34f47b4",
"instance_type": "t2.small",
"ami_name": "hoge {{timestamp}}",
"communicator": "winrm",
"winrm_username": "Administrator"
}
],
"provisioners": [
{
"guest_os_type": "windows",
"type": "chef-client",
"server_url": "https://chef-server",
"chef_environment": "production",
"run_list": "recipe[example]",
"encrypted_data_bag_secret_path": "/path/to/secret",
"validation_client_name": "client",
"validation_key_path": "/path/to/key"
},
{
"type": "powershell",
"inline": [
"C:\\PROGRA~1\\Amazon\\Ec2ConfigService\\Ec2Config.exe -sysprep"
]
}
]
}
これで、 packer build example.json を実行する。
Packer Builderというなぞのインスタンスがおもむろに立ち上がり、それに対しprovisionerが適用されていく。
よくあることだが作成途中にダメだと気づいたら、Ctrl-cすれば以下のようにちゃんと後始末してくれる。そしたらレシピを修正するなりpackerのログを見るなりして、またbuildすればよい。
・・・ ^C==> amazon-ebs: Terminating the source AWS instance... ==> amazon-ebs: Cleaning up any extra volumes... ==> amazon-ebs: No volumes to clean up, skipping ==> amazon-ebs: Deleting temporary security group... ==> amazon-ebs: Deleting temporary keypair... Build 'amazon-ebs' finished. Cleanly cancelled builds after being interrupted.
terraformとの些細な違いは、自分でdestroyしなくて済むということだが、試行錯誤してる時には、これが体感として非常に利いてくる気がしている。 なんというか、カジュアルさが違う。terraformのように重おもしくない。
さらに、packerには、このように環境構築に対する圧倒的カジュアルさのほかに、非常に便利な機能がある。 それが、ステップ実行である。
packer build -debug example.json だけでそれは起動する。
まさにコードをデバッグするときのあの挙動そのままであり、breakpointは打てないが、各種provisionerとかoptionとかの実行直前でbreakしてくれて、 プロンプトが返るようになっている。
break中に例えば対象のインスタンスにssh/rdpして中を確認したりできる。あたかも、コード実行中にデバッガで特定の変数の値を確認しているかのよう。 ターミナルに戻ってEnterすれば後続の処理がされていく。
ちなみにこの時点でCtrl-cしても、やはり先ほど同様後始末して終わってくれる。使いやすさ。
このように、Packerには、個別のインスタンスを作ってプロビジョニングして壊すのに最適な機能がたくさんあることに最近気づいた。
いままで考えもしなかったけど、 Packerは手元でのユニットテストに、TerraformはbakeしたAMIやその他クラウドリソース等の結合テストにというように、テスト工程に無理やりマッピングすると意外としっくりくるように思う。
そう考えると、それぞれにそれぞれの役割の機能がちゃんと備わっているように見えてきた。
すごいぜ、HashiCorp。
しかし、軽くググっても、Chef Server、しかもPackerとかTerraform + Cher Serverという例が全然ないよな。 そもそもChef Serverって世の中的に使われてるのかな。。
ALBログのためのInput Plugin
ALB (https://aws.amazon.com/jp/blogs/aws/new-aws-application-load-balancer/) がリリースされてから半年以上経っているけれど、 明示的にサポートしているfluendプラグインがあまりないようなので書くことにした。
先人には、id:yomon8 さんのここのような記事があったけど、 自分の環境ではこれではなく以下のプラグインをずっと使っているため、こちらを修正することになる。
GitHub - winebarrel/fluent-plugin-elb-access-log: Fluentd input plugin for AWS ELB Access Logs.
とにかくテストが書けていないのであれだけど、一応動くものとしては以下のforkにpushしている。
ポイントとしては、id:yomon8 さんのを参考に、multiple_files_gzip_reader を使っている点だ。
あと、CLBとALBではログのフォーマットが変わっているのでそこの細かい対応をしている。
テストまで書ければ完璧なのだけど、pluginディレクトリに置いて起動し問題なく稼働しているしとりあえずOK。
簡単な修正で済んだ。
Elasticsearch + Kibana 5.0のDockerImage
ここ最近、会社のログ収集基盤周りばかりと向き合っているので、 上記エントリを参考に手元のKitematicで5.0-betaを起動するところまでの記録です。
環境: MacOS El Capitan 10.11.6, VirtualBox 5.0.16, Docker Kitematic 0.10.0, boot2docker 1.10.3
エントリ通り、以下のdocker-compose.ymlを用意。
---
version: '2'
services:
kibana:
image: docker.elastic.co/kibana/kibana
links:
- elasticsearch
ports:
- 5601:5601
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch
cap_add:
- IPC_LOCK
volumes:
- esdata1:/usr/share/elasticsearch/data
ports:
- 9200:9200
environment:
- -Xms2g
- -Xmx2g
volumes:
esdata1:
driver: local
できたら、コマンド一発で起動するはずが、Elasticsearch側コンテナでエラー
% docker-compose up ・・・ elasticsearch_1 | max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144] elasticsearch_1 | [2016-09-24T13:34:47,265][INFO ][o.e.n.Node ] [RaJ4T2F] stopping ... elasticsearch_1 | [2016-09-24T13:34:47,343][INFO ][o.e.n.Node ] [RaJ4T2F] stopped elasticsearch_1 | [2016-09-24T13:34:47,344][INFO ][o.e.n.Node ] [RaJ4T2F] closing ... elasticsearch_1 | [2016-09-24T13:34:47,383][INFO ][o.e.n.Node ] [RaJ4T2F] closed ・・・
docker-machineのカーネルパラメータを変更する必要があります。(https://github.com/elastic/elasticsearch-docker)
docker-machine ssh sudo sysctl -w vm.max_map_count=262144
デフォルト設定としたいなら、/etc/sysctl.confに書いときます。
再度起動コマンドを実行。
% docker-compose up
・・・
elasticsearch_1 | [2016-09-24T14:05:07,637][WARN ][o.e.d.s.g.GroovyScriptEngineService] [groovy] scripts are deprecated, use [painless] scripts instead
・・・
kibana_1 | {"type":"log","@timestamp":"2016-09-24T14:05:21Z","tags":["status","plugin:elasticsearch@5.0.0-beta1","info"],"pid":6,"state":"green","message":"Status changed from red to green - Kibana index ready","prevState":"red","prevMsg":"Elasticsearch is still initializing the kibana index."}
kibana_1 | {"type":"log","@timestamp":"2016-09-24T14:05:21Z","tags":["status","ui settings","info"],"pid":6,"state":"green","message":"Status changed from red to green - Ready","prevState":"red","prevMsg":"Elasticsearch plugin is red"}
kibana_1 | {"type":"log","@timestamp":"2016-09-24T14:05:21Z","tags":["license","info","xpack"],"pid":6,"message":"Imported license information from Elasticsearch: mode: trial | status: active | expiry date: 2016-10-23T17:22:33+00:00"}
kibana_1 | {"type":"log","@timestamp":"2016-09-24T14:05:21Z","tags":["status","plugin:xpack_main@5.0.0-beta1","info"],"pid":6,"state":"green","message":"Status changed from red to green - Ready","prevState":"red","prevMsg":"Elasticsearch is still initializing the kibana index."}
kibana_1 | {"type":"log","@timestamp":"2016-09-24T14:05:21Z","tags":["status","plugin:graph@5.0.0-beta1","info"],"pid":6,"state":"green","message":"Status changed from red to green - Ready","prevState":"red","prevMsg":"Elasticsearch is still initializing the kibana index."}
kibana_1 | {"type":"log","@timestamp":"2016-09-24T14:05:21Z","tags":["status","plugin:reporting@5.0.0-beta1","info"],"pid":6,"state":"green","message":"Status changed from red to green - Ready","prevState":"red","prevMsg":"Elasticsearch is still initializing the kibana index."}
kibana_1 | {"type":"log","@timestamp":"2016-09-24T14:05:21Z","tags":["status","plugin:security@5.0.0-beta1","info"],"pid":6,"state":"green","message":"Status changed from red to green - Ready","prevState":"red","prevMsg":"Elasticsearch is still initializing the kibana index."}
kibana_1 | {"type":"log","@timestamp":"2016-09-24T14:05:21Z","tags":["status","plugin:monitoring@5.0.0-beta1","info"],"pid":6,"state":"green","message":"Status changed from red to green - Ready","prevState":"red","prevMsg":"Elasticsearch is still initializing the Monitoring indices"}
・・・
groovyはdeprecatedで、painlessを使っていきましょうよというメッセージが。
先日のElastic社のブログで触れられていたPainlessというElasticsearch組み込みスクリプトのこと。
あとは、上記起動メッセージから、5.0から標準内臓のX-Packプラギンがロードされていることが確認できます。
ともかく正常に起動できてそうなので、http://192.168.99.100:5601にアクセス(192.168.99.100はdocker-machineのipアドレス)
すると、Shieldの認証フォームが。デフォルトの認証情報でログインします。
おお、なんかKibana4までしか触ったことがないとちょっと感動するくらい様変わりしたUIだ。。
せっかくなので、Painless書いてみるかと思っているところ。
mruby-hibariとmruby-rack-r3でWeb API フレームワークを書いた
まだ表現力は乏しいですが、一応mrubyのWeb APIフレームワークのfirst commitを書きました。
書き味は、CRubyのGrapeやその他のRESTライクなAPIを書くフレームワークのような感じになっています。mruby-hibariやmuby-rack-r3など巨人の肩の上に乗ってる感が満載ですが。
試しにmod_mrubyで使ってみます。 まず、インストールは通常のようにbuild_config.rbに依存mrbgemを追記します。
MRuby::Build.new do |conf| # ... (snip) ... conf.gem :github => 'ujun/mruby-webapi' end
そして、mod_mrubyをビルド => インストール。
cd /path/to/mod_mruby sh build.sh make && make install
例えば、以下のようなフックの設定を書き、mrubyスクリプトを参照します。
そして、参照先スクリプトは以下のように書きます。 Rack::WebAPIを継承して、応答する内容をmruby-rack-r3のDSLで書きます。
Apacheを起動して、定義したエンドポイントにアクセスしてみます。
curl http://localhost/fuga #=> "Fuga World!" curl http://localhost/hoge/22 #=> your id is 22
以上のように、直感的にmrubyでWebAPIを書けるようになりました。
mrubyでがっつりWebアプリケーションを書くことはあまりないかも知れませんが、WebAPIサーバならアリなんじゃないかと思えてきました。これと同じようなことが、以下のエントリの最後のほうにも書いてありました。
mod_mruby を使った Web アプリ - Qiita
mrubyでWebAPI、楽しそうなネタです。
NorikraのAPIを叩くmrbgemを書いて、mod_mrubyで使う
FluentdからNorikraにサーバの各種ログを流し込んで解析する、というのは、 割とよくあるNorikraのユースケースかと思います。
Norikra+FluentdでDoS攻撃をブロックする仕組みを作ってみた ｜ Developers.IO
FluentdとNorikraで異常アクセス検知を行う | ピコもん開発ブログ
これらは、テキストとして出力されているログファイルをFluentdで取り込んで送信となりますが、 ApacheやNginxのアクセスログをNorikraに溜め込むのなら、 以下のmrbgemをmod_mrubyやnginx_mrubyに組み込んでおけばできますよ!
READMEにも書いていますが、CRuby版からのポートなので詳しいAPI情報はそちらをご参照ください。
インストール
インストールは、通常通りbuild_config.rbに依存gemを追記します。
git clone https://github.com/matsumoto-r/mod_mruby cd mod_mruby vim build_config.rb
sh test.sh sh build.sh make && make install
使ってみる
まずは、Norikaraサーバのほうに、アクセス時間とメソッドとURIを受け取る簡単なTargetおよびそれらをselectするQueryをていぎします。
次に、以下のような感じのmod_mrubyの設定を書いて、Apacheを立ち上げます。 情報を投げる先のNorikraサーバのホスト名とポート番号を指定して、アクセス時間/メソッド/URIをNorikraに投げています。
このように、イベントを投げる際にmod_mrubyで取れる種々の情報を利用することができるので、 様々な側面から分析する際に役立つように思っています。
あとは、なんらかの手段でApacheにアクセスしてみます。
curl http://localhost/
このあと、Norikraのコンソールからイベント数を確認!!
アクセス数分増加していました!
(以下のスクリーンショットでは、50。)
mod_mrubyは本当に多くのサーバ情報が手軽に取れますので、 mruby-norikra-clientと組み合わせて、工夫次第で興味深い分析ができるかも。
mruby-hibari on mod_mrubyが動いた。
mruby-hibariというmrbgemがあり、主要なWebサーバならなんとM/WレベルでRackテイストなWebアプリを書けるようです。
Apacheでやってみたところ、少し修正して、なんとか動きました!!
まず、通常通り以下のようにmod_mrubyをビルド。
$ git clone https://github.com/matsumoto-r/mod_mruby $ cd mod_mruby $ vim build_config.rb # 依存gemにkentaro/mruby-hibariを追加します。 $ sh test.sh $ sh build.sh
で、こうして生成されたmod_mruby.soモジュールをApacheにて利用します。
サンプルにならえば、以下のようにLocationとmrubyHandlerMiddleCodeでhello, world!!ができます。
curl!!
$ curl http://lcoalhost/rack_base?hoge=fuga
$
と思いましたが、なにも返ってきません。
でもH2OでもNginxでもうまくいってるっぽいんだけどと思いつつ、mruby.confで何をやってもうまくいってくれない。。
さんざん見直した末、以下が種明かしだと気付きました。
'nginx' || 'apache' は 'nginx'と評価されるようですね。なので、
case engine when 'nginx' || 'apache' # => when 'nginx'
となるため、caseの中に'apache'がマッチする条件がなくなってしまうということのよう。
複数条件に正しくマッチさせるには、
case engine when 'nginx', 'apache'
とする必要があるようです。
このPR、送ったら即座にmergeしていただけました!
curl!!
$ curl http://localhost/rack_base?hoge=fuga
Hello, World!hoge: fuga
ちゃんと出ました。
自分が普段お世話になっているmrubyとそのmrbgems達のコントリビュータの末席を汚すことになり、鼻血がとまりません。
続 mod_mrubyでmrubyのビルドサーバを書いた
この記事で、mod_mrubyで数行書くとmrubyのビルドサーバが書けるということをやっていたのですが、@matsumotoryさんが以下のようなコメントをされていたので、対応をしました。
libmruby.flags.makのような情報も返せるとさらによいなぁ / すごい！便利！！ / “mod_mrubyでmrubyのビルドサーバを書いた - ujunのブログ” http://t.co/M8kNFQW86t
— MATSUMOTO, Ryosuke (@matsumotory) 2015, 9月 16@matsumotory 有難うございます！取急ぎレスポンスヘッダに該ファイルの内容を積むようにしたのですが、他に方法が思付きませんでした。。https://t.co/IiKZSwC9lq RT @matsumotory: libmruby.flags.makのような情報も
— Jun Uchino (@u3jun) 2015, 9月 21libmruby.flags.makはmrubyビルド時にlibmruby.aと同パスに生成されますが、以下のようなフォーマットになっていて、libmruby.aをスタティックリンクする際にこのファイルからオプションを得るみたいな用途で必要になります(参考：人間とウェブの未来 - マルチプラットフォームでmrubyを使ってHTTP通信する方法)。
MRUBY_CFLAGS = -g -std=gnu99 -O3 -Wall -Werror-implicit-function-declaration -Wdeclaration-after-statement -Wwrite-strings -I\"/path/to/mruby/include\" MRUBY_LDFLAGS = -L/path/to/mruby/lib MRUBY_LDFLAGS_BEFORE_LIBS = MRUBY_LIBS = -lmruby -lm -lreadline -lncurses
この情報をサーバから返すにはどうしたらいいか。。。
現状、libmruby.aをレスポンスボディで返しているので、さらにボディに追加するのは難しいってことで、 無理やりレスポンスヘッダに設定することで乗り切ることにしました!!
生成されたlibmruby.flags.makを読み込み、(左辺)=(右辺)のような形でマッチした部分をキャプチャし、 (key, value) = (左辺, 右辺) としてレスポンスヘッダに突っ込んでいます。
@@ -8,6 +8,16 @@ # build mruby `cd /var/www/html/mruby; rake` +# set values in libmruby.flags.mak to response headers +File.open("/var/www/html/mruby/build/host/lib/libmruby.flags.mak") do |file| + reg = Regexp.compile("([^=]+)\s=(.*)\n") + file.each do |line| + if reg =~ line + r.headers_out[$1] = $2 + end + end +end + # return the generated static library r.filename = "/var/www/html/mruby/build/host/lib/libmruby.a"
ということで、このサーバに対してcurlすると、レスポンスヘッダの中に欲しい情報が入るようになりました。 (以下の、MRUBY_CFLAGS, MRUBY_LDFLAGS, MRUBY_LDFLAGS_BEFORE_LIBS, MRUBY_LIBS)
$ curl -v -d "`cat /path/to/build_confg.rb`" -o libmruby.a http://hostname:8080/mruby-build ・・・ > POST /mruby-build HTTP/1.1 > User-Agent: curl/7.37.1 > Host: hostname:8080 > Accept: */* > Content-Length: 848 > Content-Type: application/x-www-form-urlencoded > } [data not shown] * upload completely sent off: 848 out of 848 bytes 100 848 0 0 100 848 0 13 0:01:05 0:01:04 0:00:01 0< HTTP/1.1 200 OK < Date: Mon, 21 Sep 2015 13:04:40 GMT * Server Apache/2.4.7 (Ubuntu) is not blacklisted < Server: Apache/2.4.7 (Ubuntu) < MRUBY_CFLAGS: -g -std=gnu99 -O3 -Wall -Werror-implicit-function-declaration -Wdeclaration-after-statement -Wwrite-strings -I\"/var/www/html/mruby/include\" < MRUBY_LDFLAGS: -L/var/www/html/mruby/build/host/lib < MRUBY_LDFLAGS_BEFORE_LIBS: < MRUBY_LIBS: -lmruby -lm -lcrypto < Last-Modified: Mon, 21 Sep 2015 13:05:44 GMT < ETag: W/"6fbc80-520418a0948d2" < Accept-Ranges: bytes < Content-Length: 7322752 < ・・・
@matsumotoryさん有難うございます!!
