kikumotoのメモ帳

インフラ・ミドル周りを中心に、興味をもったことを適当な感じで。twitter : @takakiku

Nginx+SiteGuard LiteのRPM作成Docker - ngx_mruby を添えて -

さくらインターネットの環境でSiteGuard Liteが無償で使えますが、特に今年の6月にはNginx版も提供されるようになっていますね。

それまではApacheのみの対応であったので、Nginxを使っている身としてはちょっと縁がないかなぁと思っていたわけですが、Nginxが出たので利用し始めています。

ただ、仕方ないのですが、Nginxをソースからビルドしてインストールする、という手順となるのでそこが複数台のサーバにインストールするときに面倒だったり、一応バージョン管理もしたいので、イマイチでした。

なので、CentOS7限定(自分が必要だったので)ですが、SiteGuard Lite付きNginx RPMをビルドするためのDockerfileを作ったので公開します。RPM作成となるベースのNginxは、CentOS7向けに公開されているSRPMを使っています。

ついでに、ngx_mrubyも必要であったので ngx_mruby 付きです。公開リポジトリには、ngx_mruby なしも公開しています。

上記リポジトリのREADMEの通りですが、そもそもさくらインターネットの環境でSiteGuard Liteを利用できる条件を満たしていることが前提です。

その上でリポジトリをcloneして

make

すれば build ディレクトリ配下にRPMが作成されます。

このRPMを使えば、SiteGuard Lite公式のドキュメントにてNginxをビルドする箇所を、RPMインストールに読み替えればOKです。

誰かの参考になれば幸いです。

感動で始まり、(良い意味で)悲しみで終わった三日間

悲しみで終わった、ってタイトルに書くと、なにかよくない印象かもしれないけれどそうではないです。

iOSDC JAPAN 2017 f:id:kikumoto:20170916090800j:plain に、昨年に続いて今年も当日スタッフとして参加させてもらいました。

いろんな方のブログやTweetを見る限りは、大成功といって良いと思っています。

スポンサーの皆様、スピーカーの皆様、来場者の皆様、当日スタッフの皆様、ネットワークチームの皆様、コアスタッフの皆様本当にありがとうございました。

特に、コアスタッフの方々には大きな感謝しかないです。大変な準備をしていただいたおかげで当日は大きなトラブルもなく色々なことが無事に進みました。ありがとうございました!

以下は完全に個人的なポエムですね。興味あればどうぞ。あとは、カンファレンススタッフやってみたいなぁと思うかたに、何か感じてもらえれば。


で、何が感動の始まりだったかというと、こちらの Tweet の通り。

昨年も当日スタッフだったので、この事前MTGで1年ぶりにあう人が結構いました。スタッフの中には時折他の勉強会などで会う人も多少はいたのですが、1年ぶりのひとも結構いました。

なんでしょうね、昨年同じ時間をわずかながら共有しただけなのに、いろんな記憶が呼び起こされるし、あーこの人たちいたからとてもうまくいったなぁとかあって、この人たちとまた一緒だから今年も安心だぁ、などなど、今年もスタッフやってよかったぁ、と感動してしまったわけですね。これは2年目じゃないと味わえない感覚なんだろうなと。


さて、三日間はほぼ受付に張り付いてました。たいていの個人スポンサー・スピーカーの方の対応はさせていただいたんじゃないかなと思います。

まぁ今年のスタッフの方々も大変すごくて、総勢800人の方々を無事に迎え入れることができたんじゃないかと思います。本当に感謝です。

そんなこんなで前夜祭の準備から含めて3日間、このようなすばらしい仲間たちとずっと仕事ができると楽しいだろうなぁ(カンファレンスのような日々が毎日あるのはさすが体が持たないけどw)と思いつつ、有意義な時間を過ごせました。


「夜の」は私は参加しなかったので、スタッフ打ち上げも終わって帰路についたのですが、なんと電車に乗って座ったところで、こみ上げて来るものがあって、涙がでてきたんですよねぇ。

またあと1年はスタッフとして同じ時間を過ごした多くの人たちとは合わないのだろうなぁ、と思ったらなにかこう悲しくなってしまって。

ただ、これも2年目だからだと思います。再会の感動を知ってしまったので、また1年会えないんだなぁと思うことで、涙になったんだろうと。

スタッフとして充実し、普段味わうことのない三日間を過ごせたからこそですね。


とにかく、こういう感情ってのはそうそう日常にあることではなく、本当にカンファレンススタッフというのはいろんな意味で良い経験ができるので、スピーカー登壇とは別な意味でオススメしたいです。

iOSDC以外にもカンファレンス・勉強会はたくさんあるので、ぜひやってみると良いと思います。

そこから新しい感動が始まるはずです。


以上駄文でした。

はやく1年すぎないかぁ〜。その前に振り返り会があえれば、多少の人は会えるか。

知らなかったを知った - BBQ::builderscon 2017 #1

builderscon といえば肉ですね(違う

ということで、

peatix.com

に参加してきました。

これは builderscon のテーマ「「知らなかった、を聞く」にある意味沿っているイベントでした。 今まで知らなかった「肉」の世界を知ってしまった感じです。

「肉」はあの塊でもって「肉」なわけですね。一つレベルがあがりましたw

ちょっと下の写真では肉の塊感が足りてないので、不十分ですね。手持ちがなかった。

f:id:kikumoto:20170603105319j:plainl

冗談のように書いてますが、本当に肉はどの肉も素晴らしかったです。

元来雨男なので当初の天気予報(曇り時々雨)を見たときは、やってしまった、と思ってましたが当日は快晴で、いろんな方ともお会いできて最高の1日となりました。

次回もタイミングあえば是非参加したいですね。

では、最後に本編もよろしくお願いいたします。

builderscon.io

Y8 2017 spring in Shibuyaに参加してきました

Y8 2017 spring in Shibuyaに参加してきました y8-2017-spring.hachiojipm.org

資料は connpass の方に上がってきているようですね。 connpass.com

諸々あって今年最初のコミュニティ型のカンファレンス参加。しかも久しぶりにスタッフではなく純粋に一参加者として行ってきました。

それなりのまとめはだれか書いてくれるだろうからそこは書かないですが、個人的には朝一の @oza_shu さんいよる speakerdeck.com

がよかったですね。

自分はデスクトップアプリ・Webサービスのプログラミング業をしてからインフラに移っていった勢ですが、@oza_shu さんが気になったようところはやはり同じように気になってそこからいろいろ学べたので、@oza_shu さんのあげているポイントは特にこれから学ぼうとする人は参考にすると良いんじゃないかなと思った。

その他のトークもどれもためになりました。全てを理解できるほどのスキルはないですが、それなりに参考・得るものがあり Y8 のトーク選定がすばらしいと感じました。スタッフのみなさまありがとうございます!

今回コンパクト開催ということでしたが、これは結構良いですね。トラックが複数あって選ぶのも良いですが、厳選されたもののみの1トラックだと、自分のとりあえずの興味分野外でも聞くことになって、結局はそこからも得るものがあることになり、これまでより興味・知識の幅が広がるように思いました。 Y8 はこのスタイルが良いのかもしれない(あくまで個人の感想です)。

また、次回があるだろう、ということで楽しみにしています。(あ、状況許せば当日スタッフはしたいかな。嫌じゃないですよw)

builderscon tokyo 2016への感謝

f:id:kikumoto:20161204200949j:plain

YAPC::Asia Tokyoが一区切りを終えた 2015。いろんな枠を超えていたエンジニアのお祭りがなくなるのは、毎年同窓会のような感じでここでしか会っていなかった人たちと会う機会がなくなるのかと思うと、寂しい気持ちでした。 しかし、そのクロージングで @lestrrat さんより builderscon というの発表。 これがどうなるのかなと、すごい期待していました。

そして、2016年になって medium.com というアナウンスが。 この時からなにか自分にできることはないかと思い始めました。

その後、

に参加して、その縁で

とスタッフをさせてもらったりしました。

やはり、builderscon には何か貢献したいという思いは強くなり、またタイミング的に会社的にはエンジニア系イベント(特定範囲に縛られすぎない)のスポンサーを探していたので、一石二鳥(もっとだけど)ということで、会社にふって、まずはスポンサーという形で関わらさせていだきました。

個人的にはもっと関わりたかったので、当日スタッフに応募させていただいて、運良く採用されました。

メインは受付まわりでして、多くの方にスムーズに入場いただけたのはご来場者のご協力あってのものでした。ありがとうございました!

今回はすこしだけセッション担当もさせていただき、また1つスタッフ経験値を得られたかと思います。

当日スタッフごときですが、スタッフするといろいろな経験ができ、いろいろな人と知り合えて、貢献したいといいながらなんだかんだで、自分に戻ってくるものが多いのが素敵です!

とにかく、builderscon 第1回が無事に開催され、いろんな枠を超えてのエンジニアのお祭りとなったのはとても嬉しく、@lestratt さん、そしてコアスタッフのみなさん、当日スタッフのみさなん、もちろん来場者の皆さん、そしてスポンサーの各社様にはとてもとても感謝です!!!

スタッフして思うのは本当に毎回、「感謝!」ということです。

そして、すでに次回の開催に向けて動き始めていますね。

2017.tokyo.builderscon.io

www.slideshare.net

コアスタッフ募集ということなので、それに興味もありつつ、一応会社的なことも踏まえて思案中。でも、最低当日スタッフはまたやりたい!

その前に自分の体力と相談ですね。これだけはもはや気力でカバーできる年齢でもないのがつらいところ。

一来場者としての参加となるかもしれませんが、builderscon 2017 tokyo でみかけたら是非声をかけてください。

もう一度、builderscon に関わったすべての方に感謝!


余談

今回懇親会でのケータリングは、かなり美味しかった。個人的にはこれまでの No.1 だった。

ただし、ビールの No.1 は、iOSDC 2016

この2つが足しあわさって欲しいな。

古いLinux Kernelでfluent-agent-hydraを動かす

誰得な記事ですが、晒しておきます。

背景

ワンバイナリで動作するfluent-agent-hydraが適する状況があったので採用することにしました。

が、いざ動作させようとすると、https://github.com/fujiwara/fluent-agent-hydra/blob/master/hydra/in_tail.go#L41 で、fsnotify.Watcher を作成できずに失敗しました。

hydraで使われているfsnotifyはGitHub - fsnotify/fsnotify at v1.4.2で、

とあります。

確かに動作環境は、CentOS/RHEL 5で、カーネルのバージョンが古いです。

こんな環境使うなというご指摘はごもっともですが、そこは闇の世界ということで、これを動かそうとしたのがこの記事です。

対策

inotify自体は Man page of INOTIFY_INIT によると kernel 2.6.13 からあります。で、CentOS/RHEL 5系は 2.6.18 なので inotify はあるはず。

が、 fsnotify は 2.6.27 で追加された inotify_init1() を呼び出しています( https://github.com/fsnotify/fsnotify/blob/v1.4.2/inotify.go#L39 ) 。

一方で、fsnotify の一つ前のバージョン fsnotify.v0 - gopkg.in/fsnotify.v0 では、https://github.com/fsnotify/fsnotify/blob/v0.9.3/fsnotify_linux.go#L111 のように inotify_init() を使っていいます。

ということで、hydra を gopkg.in/fsnotify.v0 を使うように修正してみました。

ビルド方法

ソースは、

github.com

です。

パッケージ名は修正していないので、go get ではインストールできません。また CentOS/RHEL 5 ではSSLの問題ぽくて(詳細未調査)、gopkg.in から clone できないので、別な環境でクロスコンパイルなりをする感じとなります。

以下、手順です。goのインストール、GOPATHの設定は済んでいるものとします。

gox をインストール。

$ go get github.com/mitchellh/gox

ディレクトリを用意して、移動。

$ mkdir -p $GOPATH/src/github.com/fujiwara
$ cd $GOPATH/src/github.com/fujiwara

ソースを取得

$ git clone git@github.com:kikumoto/fluent-agent-hydra.git
$ cd fluent-agent-hydra
$ git checkout el5

ビルド

$ make get-deps
$ make binary

これで、pkg ディレクトリ以下にバイナリができるので、適切なものを実行環境に持っていけば完了です。

とりあえず、これで動作しているぽいです( make test も通りました )。

まとめ

fluent-agent-hydra を CentOS/RHEL 5 といった古いカーネルで動かすようにしました。

GitHub - kikumoto/fluent-agent-hydra: A Fluentd log agent.

これから hydra、とても重宝しそうです。ありがたい。

なお、さすがにこれはPRするようなものではないので、このままにしておくつもりです。

この記事が必要な人が他にいないことを祈ります。

ISUCON6敗退から一週間たってからの振り返り

早いもので、ISUCON6(土曜参戦)から早くも一週間過ぎた。 結果は敗退で、流れは @Leko がまとめてくれているので、基本はそちらをどうぞ。

leko.jp

まぁ今年も悔しい結果に終わったので、その悔しい気持ちのまま書いてもよかったのだけど、少しおついてから来年(?)に向けて振り返りをしてみることにする。

自分の役割は、インフラメインで、あとは全体方針を Leko と考えつつ、ボトルネックがどう変わっていくのか見ていく的な感じでした。

Keep

  • 使われるインフラの事前勉強
  • なんらかのISUCON問題をメンバーと一緒にする。
    • 今回は Pixiv さんの問題 をやった。これと去年の反省を含めて、局所最適化ではなく、大きく変更するための思考回路が多少は身についたと思う。
  • 最低限のタレの準備
    • 必要なツール類(Kataribe とか pt-query-digest とか)やアカウント作成を Ansible ですぐ入れるようにしていた。
    • また、M/W 類は状況に応じてという気がしていたので、基本のインストールスクリプトだけ用意。
  • M/W、OS関連のチューニングはすぐに着手せず、まずは準備が出来次第、自分もコードを読んで作戦面を考える。

Problem

  • Redisをわかってなかった
    • Redis は入れたものの、デフォのまま放置してしまい、アプリ側の挙動を変な状態にしてしまった。これがなければ早いうちに3、4万点台に乗せれていたのでとても悔やまれる。
    • 普段使っていないものは、その場しのぎではダメっていう良い(?)見本です!(申し訳ない)
  • アプリ実装に肩入れしすぎた
    • 今回はベンチがひたすら 0 点が続いて気持ち的な余裕がなくなって、上記 Redis の問題時に自分の本業側の方をきちんと見ずにアプリ実装側を見過ぎていた。
    • 作戦・実装方針以外はまかせて、自分の見るべきところを見るべきであった。

Try

  • ISUCONで使いそうなM/Wは使い込む
    • 普段から使えれば良いが、ISUCONで使いそうなM/Wについては使い込んで、どういう問題が発生するのか特徴を理解しておく。
  • 社内ISUCONの実施
    • いろんな意味で、社内ISUCONをすることでそもそもエンジニアとしての地力をつけたい。
  • 問題の意味することろから攻める
    • 単に重いところをどう軽くするかの方針だけでなく、問題の本質から全体最適化を考えられるようにしたい。

まとめ

今年もよい刺激となり、実力のなさを痛感しました。それでも昨年よりは、点数的にはよくなったと思うので、逆に悔しい気持ちは大きいです。これをバネに日々精進したいです。

ISUCON6の運営のみなさま、今年も楽しい場を設けていただきありがとうございます!

一方で、ISUCON6自体はまだ本線が控えているので、ぜひ諸々頑張ってください!特になにかできるわけではありませんが、応援しています!