Dockerに興味はあっても使ったことのなかった自分ですが、2014/07/04に開催されたDocker Meetup Tokyo #3に行ってきました!

OLYMPUS DIGITAL CAMERA

もらったおみやげ。
Dockerステッカーが欲しかったのですが、どこにあるのかわかりませんでした…
デンシバちゃんかわいいですね。
あとGoogle Cloud Platform starter packの$500クーポンをもらったので、そのうちなんか試してみたいです。

さて、Docker Meetupに行くのは今回が初めてだったのですが、運用やアーキテクチャの話など興味深い話が多かったので、振り返りも兼ねて内容をまとめていきたいと思います。
なお、リアルタイムで参加者がTweetした内容がTogetterにまとまっているようなのでそちらも併せて見ていただくと面白いかもしれません。(@yoshidashingoさん、まとめありがとうございます!)

Orchestration Tools

最初の発表は@philwhlnさんの「Orchestration Tools」。
Stackatoの中の人らしく、如何にDockerを協調動作させるためにツールを使っているか、というお話でした。
カナダの方のようですが、最初の自己紹介やバックグラウンドの説明は日本語で、それ以降もところどころ日本語混じりの発表で面白かったです。
資料は探したけれど見つからなかったので、インターネットには上げられてないのかもしれません。残念。
自分の英語ヒアリング力が低い&前提知識を抑えきれてないので若干怪しいのですが、内容をざっとかいつまむと、

1マシン1コンテナは簡単だけど、1マシン複数コンテナだとコンテナ同士の協調作業が複雑になり、複数マシン複数コンテナでは非常に煩雑になる。
このオーケストレーションを行うために、コンテナを集約して必要なサービス同士をつなぎ合わせるService Discoveryや、隣り合うコンテナがランダムに状態を監視しあうHealth Check、各コンテナで出るログを集約するLog Stash、自身の状態を診断してコンテナ自体の再起動を行うSelf Healingなどの技術がある。
これらを実現するために沢山のテクノロジーがあり、日進月歩で新たなツールが出てきている。
これらを全部把握して使いこなすのは難しいので、もうPaaS使おうよ←結論

といった感じの話をされていた気がします。
…これについては資料見なおせずTweetを頼りに記憶を掘り起こしているので、ほんとに怪しいです。いろいろ間違っていたらすみません。
とはいえコンテナ同士の協調動作のための諸概念とツールの現状が分かり、次以降の発表の前提知識も補完できたのでありがたかったです。

Dockerでデプロイ&モニタリング

続けての発表は@stanakaさんの「Dockerでデプロイ&モニタリング」。
はてなのCTOさんです。偉い人だ!

発表内容はタイトル通りDockerでデプロイとモニタリングをするための知識について。
ただどちらかと言うとモニタリングの話寄りだった気がします。
">こちらも調べた限りでは資料は見当たりませんでした。
2014/07/14 追記:アップロードされました! stanakaさんありがとうございます!

こちらもざっと内容をまとめると、

Dockerモニタリングの基本はcgroupの作法に従う。コンテナ内から見てもコンテナ毎の情報は見えずホスト全体の情報しか見えないので、ホスト側から監視する。
/sys/fs/cgroup/下にコンテナIDのディレクトリがあり、その中にあるcpuacct.statなどでCPU時間を、memory.statなどでメモリ使用率を、共通レポートでdocker topと同様の情報を取得できる。

dockerで環境を構築するには、1ホストに複数コンテナを立てる方法と1ホストに1コンテナのみを立てる方法があり、前者は開発・CIなど、後者はプロダクション向き。
デプロイにはDocker Hubを使い、Githubへdockerfileをpush -> Dockerhubがautomated build -> Hubotがデプロイ、という流れで行う。ただしHubotでのデプロイはまだ実験段階。

実際の監視にはMackerelをつかってモニタリングしている。
サービスとロールの2つの軸でサーバを管理でき、サービスを横断してロールごとの状況をモニタリングできる。これによりコンテナ自体が再起動して別インスタンスになっても継続した状況を見ることができる。
agentの導入は、mackarel-dockerプラグイン(昨日作った)を使えばDockerコンテナのbuild時に自動でagentを起動し監視対象とすることができる。

といった感じでした。
普通にやったらホストごとの状況しか見れないというのは言われてみれば当然なんですが、インフラ寄りの知識がなくcgroupという単語自体初めて聞いたので非常に勉強になりました。

Dive into Dockerネットワーク

続いては@mainyaaさんの「Dive into Dockerネットワーク」。
DockerのネットワークがどうなってるのかDiveしてみてみよう、というお話です。
こちらは発表前から資料が上がっていました。ありがたや。

これまた内容をかいつまむと、

Dockerのコンテナ間通信には「-linkオプションを使う方法」「ホストネットワークで実行する方法」「Open vSwitchを使う方法」の3つがある。
-linkを使うとDockerが環境変数やホスト名を設定してくれるので簡単だが、同一ホスト内でしか通信できず、仮想ブリッジを経由するので若干パフォーマンスが劣る。
一方–net=hostを使うとホストネットワークを使える。ipはホストのものを使うので設定がいらず、ブリッジも経由しないので早いが、ポートが被らないように注意する必要がある。また外にむき出しになるため安全なネットワーク内でしか使えない。
最後のOpen vSwitchではトンネリングなど柔軟に設定できるため安全で、複数ホスト間でも通信できるためスケーリングできる。ただし設定が煩雑なことと、IP割り当て機能はないため別途DHCPサーバを立てるなどする必要がある。
実際にロックインを避けつつスケールさせる話は他の人に任せる。結論としては「すごい時代になったなー」

といった感じ。
コンテナ間通信は(まだ実際に触ってないけど)-linkオプションしか知りませんでしたが、複数ホスト間での通信はプロダクション運用では重要そうですね。
個人的には既存プロダクション環境でredisやmemcacheのポートが被らないように気を払うのと同様、本番ネットワークを切り離した上で–net-hostを使って運用するのが一番手軽そうに感じました。
ConoHaのローカルネットワーク使えばVPSでも試せますしね!(無意味に清楚かわいいConoHaちゃんの宣伝)

どうでもいいけど、この発表で一番盛り上がったのは

この発言だったと思います。
ip -aとか知らなかった…

flynnの時代

休憩前最後は@deeeetさんの">不倫flynnの時代。
Dockerの応用例の一つとして、OSSのflynnというPaasシステムについて細かく解説する発表でした。
こちらもスライドありました。ありがとうございます!

内容は

FlynnはDockerを使ったマルチホスト対応のPaas。Heroku++。dockにマルチホスト機能を足した感じ。Deisと似たような感じ。
コンポーネントはほぼ全部Dockerコンテナなのでスケールする。基盤システムのlayer0(The Grid)とPaasの機能を提供するlayer1から成る。
layer0はサービスディスカバリを行うdiscoveryとコンテナ管理のhostから成る。後者は1つがリーダーとなり、それ以外のコンテナを管理する。
layer1はAPIサーバのcontroler、git pushを受けるgitreceived、ビルドを行いslugを作成するslugbuilder、slugを実行するslugrunnerなどから成る。
今後は数週間以内に社内でのベータリリース、夏の終わりに1.0をリリース予定。その後、Docker以外のコンテナ管理システムも使えるよう拡張する計画がある。

といった感じでした。
この発表についてはスライドがよく出来ているので、スライドの方を見れば大体わかるかと思います。
総じて、Dockerをコアとする大規模なPaasシステムがどう作られているのかを詳しく知ることができ、非常に面白かったです。
実はConoHaにDocker+dockを入れてMini Herokuにして遊ぼうかと思っていたのですが、この話を聞いてFlynnに">不倫乗り換えようかと思ってしまいました。

ちなみに、この発表の間にビアバッシュのピザやお酒が搬入されており、聴衆の関心は完全にそっちに向いておりました。
面白い発表だったのですが

本心はこれな。

ビアバッシュ

通常発表枠が終わり、休憩兼ねたビアバッシュ。
自分はあまり顔が広くない&人見知りなので、同僚としか喋りませんでした…
い、いいもん! Twitterがあるから寂しくないもん!(´;ω;`)

How to Impl lib swarm backend

ビアバッシュ後は怒涛のLTラッシュ。
最初は@mopemopeさんの「How to Impl lib swarm backend」。
AbbyのCTOさんです。偉い人多いな。

libswarmのコードの話。
ちょっと酒の入った頭では理解が追いつきませんでした…
っていうか今素面の状態で見ても結構辛いです…
まとめみると「backendの実装自体はそこまで難しくない」らしいので(基準がわかりませんが)、ちょっとブログ書き終わってからじっくり読み直したいと思います。

Docker+CoreOS+GCEで自動スケール分散レイトレ

続いては@peryaudoさんの「Docker+CoreOS+GCEで自動スケール分散レイトレ」。
ちなみにレイトレはレイトレーシングのことでした。私は最初全くわかりませんでした。

とりあえず分散レイトレがしたい、という話でした。
やり方としてはredisにjobを突っ込んで、workerがそれぞれを実行してredisに結果を戻し、それを集約する、みたいな感じで実装したそうです。
すごいレイトレ推しで面白かったです(小並感)

Porting Docker to FreeBSD

続けて@kzysさんの「Porting Docker to FreeBSD」。
「趣味で」DockerをFreeBSDに移植する話です。
何を言っているのかわからないと思いますが(ry

ちなみに「Dockerを読む」を書かれた方でした。
自分は読んでなかったので今日になってから読んだのですが、ソースコードからガッツリ読んでいる記事で勉強になりました。
…嘘です見栄を張りました、さっと目を通したのですが理解しきれなくて全然学べてないので、後でちゃんと読みなおそうと思います…

発表の方は、もう@nekoruriさんのお言葉をお借りしてまとめたいと思います。

Perfomance Evaluation of Docker

がらっと雰囲気がかわり、@nasunomさんの「perfomance Evaluation of Docker」。
Dockerのパフォーマンスを計測した話です。

正直これはLTではなく発表枠で聞きたかったくらいの重量級の話で、酒の入った頭に細かい数字が入ってきませんでした。
今スライド見返した感じだと、オーバーヘッドはVM使うのと大差ないものの、AUFSを使うと大幅に性能劣化する場合があるので、場合によってはAUFS以外のStorage Driverを使ったほうが良い、という話みたいです。

Docker-flow@Gnossy

最後は@y_matsuwitterさんの「Docker-flow@Gnossy」。
Dockerの開発フローの話。

プロダクションだと1ホスト1コンテナでやりたいけど、そうすると1コンテナに色んな機能を詰め込むことになり、個別のDockerfileと重複が多くなる。
これを解決するために、Chefのrecipeとnodeの関係よろしく、複数のDockerfileを組み合わせてDocker imageをビルドする、「docker-assembler」というツールを昨日(ほぼ今日)がんばって作ったよ、という話。
他にもデプロイの話とかしてたんですが、会場から「おぉー!」と声が上がったのはこのツールの話のところだった気がします。
どうでもいいけどすごいGo推しだったのが印象的でした。

まとめ

長くなりましたが発表ひと通りについてスライドをまとめて、ざっくりと概要&所感を(書いてない奴もあるけど)書きました。
個人的な全体の感想としては、結構前提としている知識レベルが高くて付いていくのが大変でしたが、その分色々勉強になる会でした。
特にログがどこに出てるかやネットワークの低レイヤーの話など、ツールを使ってると意識しなくて良いだろう部分を聞けたのは良かったと思います。
結局Dockerみたいなツールの使い方だけに特化した知識だと、それが廃れた時に役に立たなくなってしまうので、単なるHow Toではなく「どのようにしてその仕組みが実現されているのか」という話が聞けるのはありがたいです。

というわけでDocker Meetup Tokyo #3の個人的まとめでした。
スライド資料についてはざっと見た限りまとまっているところがなかったので、ポインタ代わりにでも使っていただければ幸いです。