この記事は tech.kayac.com Advent Calendar 2014 24日目です。
tech.kayac.com アドベントカレンダー、いかがでしたか?
こんにちは、@acidlemon です。今日はクリスマスイブ! 今年のtech.kayac.com Advent Calendar はお楽しみいただけたでしょうか? Unityあり、Golangあり、Rubyあり、Javascript/ECMAScriptあり、Perlありとバラエティに富んだ内容でしたね。個人的にはSwiftがなかったのが心残りなのですが…。まぁ来年若者にがんばってもらいます。
また、1日目でご紹介した、ぼくがノリで11月末にIKEAで買ってきたリアルアドベントカレンダーも無事ぼくの手元に帰ってきました。チョコおいしいです。
※心に余裕がなかったらしく、「書いたら」が「買いたら」になっている…
さて、今年も残すところあと1週間あまりとなりました。先週金曜日まで仕事が多忙を極めて個人的にたいへんあらぶっておりましたが、ようやく落ち着きを取り戻して平穏なクリスマスイブを過ごしています(ひとりです)。
mirageがコンテナ内で動くようになりました
本日の記事は、今年の8月くらいにこのブログで記事にした、mirageの話の続きです。
あの記事以来社内でじわじわと使われ始めまして、先行プロジェクトによるバグ出しもおおよそ終わって安定期に入りました。弊社では主にCentOS6を使っていたため、CentOS6でのDockerは色々ハマリどころが多いという外部の知見から、なかなか開発環境のDocker化が進んでいませんでした。ただ、ちょうど来年上半期にいくつかのプロジェクトのdevサーバが移転するのに合わせて普及が進んでいきそうです。
今ぼくが考えてたのは導入を楽にするというところでして、当初はrpmパッケージを作ったらいいのではないかと思っていました。ただ、その後考え直しまして、お手軽に試すならDockerの中でmirageが動けばよいのでは? ということでこのたびDockerfileを用意してみました。
Dockerコンテナを管理するのをDockerコンテナ内からやるというのはだいぶ不思議な感じではありますが、DockerにアクセスするためのUnix Socketをdocker run -v /var/run/docker.sock:/var/run/docker.sockでコンテナに渡してやれば普通に管理できます。
あと、mirageはcgo要らずのPure Go実装な簡易データベースとしてleveldb-goを使っていますので、これの永続化も必要です。そこで、あらかじめサンプルとして用意したdocker_run.shでは-v /mirageでData Volumeを指定してDockerさんに/mirageを永続化するようにお願いしてあります。
この辺は昨日ドキュメントとにらめっこしてこれでいけるはず! という感じでスクリプトにしましたが、実際の細かい検証はインフラチームの頼れる若者、@tkuchikiにお願いしてやってもらいました。まいどありがとうございます。
その検証結果によると、docker run -v /mirageで永続化したものはdocker rm <container id>でコンテナを削除しても消えないが、docker rm -v <container id>で-v(–volume=true)を指定すると消えるとのことです。ご留意ください。
mirageは来年以降も任意のパラメータ渡せるようにするなどのアップデート計画があります。引き続きよろしくおねがいします。
mirage 開発秘話
さて! 事務的な話がやっと終わったので、ここからはなぜmirageが生まれたのかという小話をお届けします。クリスマスの読み物としてお楽しみください。
弊社の開発フローはチームごとに異なりますが、開発からリリースまでの流れで言うと、大体devサイトにまずデプロイして開発者(デザイナーなども含みます)が自分で確認し、stagingサイトにデプロイしてチームチェック/QAなどを行い、最後に本番サーバにデプロイしてリリース、という流れになっています。
devサイトは複数用意してあり、複数の開発ラインが同時で走っても大丈夫というような感じになっています。gitを利用していますので、gitでブランチを切り替えればすぐdevサイトもそのブランチの内容に切り替わるのでgit便利ですね。
しかし、いくつか問題もあります。一番大きいのはDBのスキーマが変わるときでしょうか。コマンド一発でスキーマをマイグレーションできるようにはなっていますが、そうはいってもテストデータを毎回クリアしているわけではないためマイグレーションに失敗してエンジニアが時間を取られることもしばしばあります。
また、いくつかのdevサイトを使い回して利用するのにはもう一つ問題があり、「最後に使ったのは誰か」「このdevサイトまだその人が使ってるのか」という非常に人間くさい問題があります。
新しい機能/デザインを作ったクリエイターがサーバで確認するために「dev01使ってるひといますかー?」「13時までに返事がなかったら使いますよー」などと毎回やるので、非効率です。常に全員がチャットを見ているわけでもないので、リアルタイムに「あ、今使ってます」と反応できないことも多いです。
この問題の解決のために、社内ではいろいろ策が講じられてきました。たとえばコレです。
映っているのは弊社の技術部長の庄司です。背中になにか②と書かれた風船をつけていますね…。そうです。これは「オレが今dev02サーバを使ってるぞ風船」なのです。
なるほど! 風船置き場に風船があればそのdevサーバは使われていない、誰かの背中に風船がついていればその人がそのdevサーバを使っている! すばらしい! アナログ! エレガント!
しかしこの方法には問題がありました。
「風船は、いつか、しぼむ」
この写真は9月のチャレンジのときで、ちゃんとしたヘリウムの漏れづらい風船なのですが、それでもやっぱりそのうちしぼみます。
また、これに先立ち7月にトライラルしたときはちゃんとした風船では無く、デカイビニール袋にヘリウム入れて浮かせてみた、みたいな感じだったためこんな会話もありました。
17:03:08 fujiwara: ゴミ袋浮かんでるのは美観的にどうなのw 17:09:52 handlename: 頭いい方法ではありますねw 17:09:56 handlename: リーズナブルで目立つ 17:10:46 acidlemon: |'-')? 17:10:57 fujiwara: 今ヘリウム高いんだけどなw 17:11:24 acidlemon: 猿山より目視にて浮くゴミ袋を確認 17:11:40 acidlemon: 割り箸鉄砲で撃墜したい 17:12:08 syoji: 真下に俺いるから辞めてｗ 17:12:14 gs: w 17:12:22 acidlemon: 余計にやる気がUP
しかし、翌日にはゴミ袋はしぼみました。噂ではfujiwaraさんが会社に来ると空気の抜けた風船がインフラチームに流れ着いて落ちていたとかなんとか…
16:35:47 acidlemon: 風船作戦1日で終了か 16:36:00 gs: 全部沈没しました 16:37:18 fujiwara: ドメインを [username].dev.lobi.co みたいにして 16:37:33 fujiwara: 一人ずつdevを起動できるようにしたい… 16:38:07 acidlemon: さっきXXくん(PM)とDockerの話したらYYY(当時のプロジェクト)でも同じようにカジュアルにDockerで自分のdev建てたいって話になった 16:38:26 handlename: テストしてると人依存じゃなかったりするので、各自複数台用意できるようにしないと・・・
そうです! この会話がmirageの開発のきっかけでした。
そんなわけで生まれたmirage、意外とこういった悩みはどこのチームにもあるのではないかと思います。どうぞご利用ください。
