Docker

1 ：login:Penguin：2013/07/27(土) NY:AN:NY.AN ID:5oaw2wHS.net

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

461 ：login:Penguin：2016/06/05(日) 18:54:05.70 ID:RcCc+B29.net

>>458
なるほど
インフラとアプリどっちもかじってないと良さが分からないってことは

462 ：login:Penguin：2016/06/05(日) 19:08:53.36 ID:KDYCG9Kq.net

>>458
話を聞いてdrootは無いなって思った。

あれ思想がどうこういうより、
dockerを使った→ちょっとした問題点があった→普通のコンテナでいいんじゃね？
という単純な発想で作られたものだよ。その他の理由は後づけ。

古いやり方を引きずってるだけで、それでいてイメージのビルドツールとして
dockerを使おうとしているから、結局dockerの知識が必要になって、
さらにdrootを使うことで使えないdockerの知識と
drootそのものの知識が必要になる。

dockerの問題点は、dockerのバージョンアップで解決するし、
drootはdockerに依存しつつ、dockerとは全く違う劣化版を
個人で作ろうとしているから、将来性も感じられない。

現時点では、drootは確かにこの点ではdockerよりもメリット有るね。
だけど、dockerのメリットを随分と失っているよね。という感想で、
そして時が経てば、dockerのバージョンアップで、
drootのメリットってもう無いよね。になっていくと思う。

463 ：login:Penguin：2016/06/05(日) 22:50:37.49 ID:Fz4BjGDf.net

>>458
インフラ屋のおもちゃってのはよく聞くけど、それを開発するにもネットワーク、マシン、OS、プラットフォームが必要(とそこに至るまでの知識)じゃない？

俺は配線〜アプリまで全部やるけど、正直dockerのimage起動するからよろ！って渡されたら中身がカオスってたりしそうで怖い。glibcってナンデスカ？って人が古いまま使ってるとか容易に想像できる

なんというか、

464 ：login:Penguin：2016/06/05(日) 23:04:59.28 ID:fwpw71Y/.net

途中でおくってしまった、、
OSI参照モデルとかだと下位レイヤーの知識は必要ないんだが、現状そう上手くいかないよな。

あと、dockerと関係のツールの分裂と乱立っぷりを見るととても不安になる

465 ：login:Penguin：2016/06/05(日) 23:09:47.70 ID:KDYCG9Kq.net

>>463
> 正直dockerのimage起動するからよろ！って渡されたら中身がカオスってたりしそうで怖い。glibcってナンデスカ？って人が古いまま使ってるとか容易に想像できる

意味がわからん、Dockerfileみれば中身なんてわかるし、
最新にしたければDockerfileからイメージビルドしなおせばいいだけじゃん。

466 ：login:Penguin：2016/06/06(月) 00:28:13.53 ID:WsFVzHYP.net

>>465
人から渡された物をいちいち中身検証して最新にするのかよ。
なんでそんな面倒なことをしなければならんの？

467 ：login:Penguin：2016/06/06(月) 00:55:48.67 ID:3HrdhjQZ.net

上から下まで知ってるとか書くわりには
dockerについてぜんぜん知らずに
よくそこまで否定するな

468 ：login:Penguin：2016/06/06(月) 01:02:44.13 ID:x4rn+e32.net

>>466
Dockerfile見るのがそんなに手間になると思えんのだが…

469 ：459：2016/06/06(月) 01:14:34.99 ID:58//efTR.net

インフラ屋としては Dockerfile の中身は当然見るし、
今ならばプルリクきたら「Docker Security Scanning」や「Vuls」あたりで
CIなりで自動でチェックを入れることを検討する。

そういうのが面倒なら docker 使うのやめたほうがいいよ。向いてない。

Docker 社も今以上にインフラ屋に使いやすくするつもりはないはず。
アプリ屋やデザイナー、プロデューサーには Kitematic や Docker for Windows/Mac で
便利にしていくという方向性があるけどね。

使ってて楽しいからエンジニアの自分としては「おもちゃ」という表現でいいけど、
Siri のバックエンドとして使われてたり、クックパッドで使われてるのを見ると
揶揄するつもりで使ってるなら自分のプライドを保つ以外に意味は無いよ。

IT系でないお客さんの人事/経理などを扱うSI系だとデプロイは1月に1回とか、
サーバも数ラック入れてインフラの設定は年に1回変えるかどうかだし変えるときは
レビューなど含めて1月かかるとかざらだから Docker なんて苦労して使う意味ないしね

470 ：login:Penguin：2016/06/06(月) 01:39:12.53 ID:58//efTR.net

>>462
docker を手元で使う多くのアプリ屋としては docker は便利なんだけど
本番の運用として使うインフラ屋としては docker は便利すぎて面倒なんだよね。
docker は「1 から10のうち 1から9 までやってくれる」けど、
私達の欲しいのは「8から10」なんですという場合にdocker を使うのかって話。

自分としては"本番で使うなら" docker の差分ファイルシステムは必要ないし、
docker daemon が提供する REST API も必要ない、Network も iptables とか触ってほしくないし
Host と一緒でいいから Network plugin もいらない。
でも、docker で出来たイメージ(というか今なら OCI フォーマット）や Dockerfile を
アプリ屋と共通の言語として使いたい。

これらはdrootを作った"はてな"やペパボあたりの今までオンプレで運用してたところは
同じように不満を持つんじゃないかなと思う。
オンプレだとクラウドのように動的にサーバを追加したリしないので Mesos のようなスケジューラに
依存せず自分たちで割当固定したほうが扱いやすいしね。
（docker が 1 から 10 までできるようになってもこの辺のツールを作ってる会社は変わらないと思う）

その結果 droot やら haconiwa やら apr などオリジナルコンテナエンジンを作ろうかなとなるだけ。
droot は他の会社が使うものじゃない。あれははてなが必要だから作ったものだし。
ただ似たようなものを作る会社は今後出てくると思う。

または、うちの会社みたいに machinectl(systemd-nspawn)つかったり、 CoreOS の rkt や
OCI の runc を直接使う会社も出てくると思う。
どっちの場合でも共通言語は Dockerfile で、細かな仕様は runc の SPEC.md あたりを参考にしてね。

docker とオリジナルツールについて知識が必要なのはそのとおりだけど、結局コアの技術は今のところ
コンテナ（Namespaces/Capabilities/cgroup）+差分FSなのでオリジナルツールは docker を理解する方法として
デメリットには感じないね。