Dockerを使い始めて半年弱ぐらい経ったような気がする。
Dockerを知ったきっかけは、はてブやTwitterのTLに流れていたのを見たのがきっかけだと思う。
（みんな新しい技術どうやって知ってるの？と思う人はそういうところをこまめに見ればよい。気に入ったブログはFeedlyに登録すればいい。）
仕事では開発サーバにDocker on Ubuntu on KVM on Ubuntu on BM(Bare Metal)な状態で、JenkinsやRedmineなどの開発用サービスコンテナとして使ってる。
（Dockerを使ってJenkinsでビルドとか面白いことは残念ながらやってません。:-P ）
Docker meetup Tokyo #3でもあったんだけれども、開発用サーバに使う人は1マシン複数コンテナが普通のようだ。
逆に不確定要素を排除したいプロダクションだと1マシン1コンテナだったりもするらしい。
私が、なぜ開発用サーバにDockerを使っているかといえば、私が以前立てていた開発用サーバは、私が便利とあらば、生産性をあげるために、ガンガン新しいサービスやアプリを入れてしまっていた。結果、そいつらの構成が1つのOS上でぐちゃぐちゃになってしまい、何がどう絡んでいるのか把握しづらいというプチ問題に発展した。
だから、とりあえず各開発用サービスがコンテナとして明確に分離されれば、少しはこのカオス状態がまともになると思い、Dockerを使った。Dockerfileがクソみたいになっても、Dockerが1.0に達していなくて不安な夜を過ごしても、このメリットを何度も自分に言い聞かせた。
やはり良い垣根というのはソフトウェアにおいては大事である。
また、一つの開発用サービスを用途ごとに複数立てたいという要求もあり、Dockerを使えばコンテナイメージを環境変数etcをかえて使い回しすればいいので、そういう意味でもDockerは役に立った。
たとえば、普通にJenkinsをYUMやらで入れたとして、これを複数インスタンス立ち上げるのはちょっと苦痛だろう。
そういう場合はDockerを使って、Jenkinsのイメージを使いまわせばいいのである。細かい要件はJenkinsスレーブ（こちらもDockerイメージ）に吸収させれば少なくともJenkinsマスタのイメージは複数インスタンスで使いまわせる。
Dockerfileは多くの開発者が慣れ親しんでいるCentOSベースに、ある程度万能な状態のコンテナを派生させて色々作ったが、今思えばもっとフラットに構成すればよかったと思っている。結局、万能層なんて置くと外から見て何がどうなっているのかわかりづらい。
docker pullして済むようなものについては、特に自分でイメージもつくらずに使っている。ただ、そんなことができるのはレアケースで、大概本格的に使うなら、自分でケツを拭けるコンテナじゃないと行き詰まることが多いはずだ。
既存のLinuxソフトウェアはDockerなんぞ知らんという作りになっているので、うまくイメージに落とせないことも多いし、開発用メールサーバとしてpostfixとdovecotをコンテナに閉じ込めるのは私にとっては非常に苦痛だった。
この類の苦痛の回避策として、アプリをうまく事前準備なしで初期化動作をさせようとすると、コンテナに起動用シェルが待ち構えて本丸を最後にforkかexecかするケースが多い気がする。
タイムゾーンとかズレたり、好きなDNS見させるのに苦労したり、ログの吐き場所とか苦労したりなんか色々苦労した。
そもそもDockerを扱っていて、これLinuxの知識割りと要るよねと思うこと多数。今Dockerを自由自在につかえている人はLinuxに相当詳しいはず。
まあこういう雑魚が引っかかる問題はバージョン上がったら古い人しか知らないアホみたいな問題になっているのかもしれないけど。
それとプロキシを噛ませないといけない環境だと死ぬほど苦労した。
コンテナのyumやaptがそのままじゃプロキシ見ないので、じゃあ、どうするかっていう…。Dockerのデーモン自体がプロキシ見るのは簡単なんですけどね。プロキシの設定がコンテナに残るとか気持ち悪すぎる。
そもそもプロキシがなくてもビルド中のインターネットアクセスが割りと苦痛だったりする。キャッシュプロキシは不可避だろうか。
Dockerとは何か？
Docker初心者が口にする最も多い質問だと思う。
（Linux専門の）VMの1種というと分かりやすいけど、違う。
（ただ、初心者にとってはSSHDをDockerで立てれば、それがたぶんいっぱしのサーバに見えてくる的な感覚？はあると思う。）
Dockerの哲学をあらわすのはアプリケーションコンテナという言葉だと思う。
たとえばJavaで何かのアプリケーションを作っていたとして、それがどんなJREで動くのか非常に曖昧だったり、どういうディレクトリ構造が実際にあるのか曖昧だったりで、やる気のある人はサーバ環境をChefとかで構成してみるものの、やや実環境の構成の不明瞭さに一抹の不安感が漂ったりすると思う。
そういった場合に、アプリケーションがどこかのディレクトリにインストールされ、どこかの/usr/binにあるバイナリが存在するのを期待するという受け身のアプリという姿勢から、1段階引き上げて、OSの環境ごとアプリを封じ込めて、それをそのままいろんな環境に持っていければ、あまり実環境の構成の不明瞭さを気にしなくてもよくなる。
これがDockerのアプリケーションコンテナという考え方であると思うし、Dockerfileもそれに準拠する形で作れば、そうそう狂ったものにならない、と思っている。
ただ、Dockerはあくまで道具だし、綺麗にならないものもいっぱいあるし、時間は有限だし、私イジけちゃうしってことで、まあただのアプリの檻として好きに使っても後ろ指さされることはないと思います。
Dockerの檻としてのセキュリティはどうなんですかね～。Dockerチームは確かそういうのにケアしているとか言っていたような気が1mmぐらいはしますが、セキュリティ確保は副次的なものだと思ってます。
信用できないコンテナとかは動かせないんじゃないんでしょうか。
Dockerで個人的に消化不良起こしているもの
- Ambassadorパターン
- supervisordという存在
- ロールベース
