Docker

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

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

http://www.docker.io/

311 ：login:Penguin：2016/01/14(木) 14:16:32.94 ID:GYrwUcVN.net

>>310
だから？

312 ：306：2016/01/15(金) 00:07:27.60 ID:K3C/Pi7v.net

>>306-309
すごく参考になりました。
わからないことも多いですが、ざっくりと雰囲気はつかめました。
右も左もわからず暗中模索してましたが少し霧が晴れた感じです。
いただいたレスをよく読み返して学習の指針とさせていただきます。
ありがとうございました。

313 ：293：2016/01/15(金) 01:08:34.20 ID:kfmWKxvv.net

>>306-309

質問者と同じく開発スタイルで迷っていたので参考になりました。

> ただしビルドで生成するものがバイナリ実行ファイル等の場合は、ホストOSとDockerコンテナで
> 使うOSが違いすぎると動かない可能性があるので、Dockerコンテナでビルドする必要がある。

ただ、これに関してはホスト OS と Docker コンテナで使う OS を同じにすればいいと思うので
ホスト OS でビルドして、Docker コンテナにはコンパイラなどのビルド環境を入れないように
してもいいかなと思ってます。

314 ：293：2016/01/15(金) 01:14:51.11 ID:kfmWKxvv.net

boot2docker は罠ですね。

docker-machine create する場合も、Docker ホストは自動的に boot2docker になりますが、
ここを任意の OS に切り替えられると話が早そうです。

315 ：login:Penguin：2016/01/15(金) 01:30:22.80 ID:eyDykv1a.net

>>313
理屈上はそうなんだけどね。

でもそうすると、ホストで開発しやすいOSを使う＝コンテナも同じものに
制限されてしまうので、分けるほうが好ましい。

Dockerイメージのサイズを減らすためにAlpine Linuxを使いたいし、
開発ではホストOSにUbuntuを使っていても、awsで動かすときは
CoreOSを使うかもしれないし、柔軟に変更可能にするためにも分離さておいたほうがいい。

まあ別に開発中であれば自己責任で適当に使っていいと思うよ。
アプリ開発のためのインフラとしてDockerを使って開発環境を整備するんじゃなくて
開発作業の一貫としてDockerというツールを使うという使い方。
Dockerの中で開発するのは面倒なだけだからさ。
（あくまで ”アプリ開発" スタイルの話。インフラ・運用の話ではない）

316 ：login:Penguin：2016/01/15(金) 01:40:21.56 ID:eyDykv1a.net

>>314
boot2dockerは、アプリ開発者がWindowsで開発している時に
Dockerを簡単に使うためのものではなくて、

アプリは完成したものとして、そのアプリを動かしたい時に
ホストがWindowsの場合に使う手段だと思ったほうがいいよ。

わざわざWindowsをサーバーに使う人は居ないだろうから
実運用向きではなく、Docker自体の勉強で使うときとか、
Windows上にDockerコンテナでサービスを動かしてそのサービスを
個人的に使うのを目的とするとか。
（例えばHTML Validatorをローカルで動かすとか）

317 ：293：2016/01/15(金) 02:16:23.93 ID:kfmWKxvv.net

> Dockerイメージのサイズを減らすためにAlpine Linuxを使いたいし、
> 開発ではホストOSにUbuntuを使っていても、awsで動かすときは
> CoreOSを使うかもしれないし、柔軟に変更可能にするためにも分離さておいたほうがいい。

なるほど。そういう観点ですね。
だとすると以下の引用のようにビルド用のイメージを作るってことになると思いますが、

> ビルドのたびにパッケージのインストールとか時間的にやってなれないので、
> （実行用のDockerイメージとは別の）ビルドをするためのDockerイメージを作る必要がある。

この場合、ホスト OS とビルド用の Docker コンテナは -v でフォルダ共有してから対象ファイルをビルド。
そして、実行用のコンテナを作る際には、ホスト OS から （実行用コンテナに）ビルド済みバイナリを ADD すればいいということですね。

318 ：login:Penguin：2016/01/15(金) 02:49:11.46 ID:eyDykv1a.net

>>317
なので、基本的にアプリ開発中はDockerを使わない。
で、どうしても必要だと思ったときは使うけど・・・
うーん、その場合はいくつかやり方が考えられるんだけど、どれも一長一短

・docker buildでビルドする
完全に動くDockerイメージを作る途中で、ビルドも行う方法。
ビルドツールは入れて消すのでサイズも小さいし実運用でも使える。
だけど毎回ビルドツール入れるので時間がかかる。

・docker buildでビルドする（その2）
サイズは諦めてビルドツールを入れたイメージからイメージを作る。
サイズは最小にはならないが、それが問題になることは少ないだろうから一番楽かも

・実行用イメージとビルド用イメージを分ける
>>317で書いてあるやり方ね。実行用イメージは小さくて実運用でも使え
ビルドの時間も少なくなるけど、作るのが面倒くさい。
ビルド済みファイルを受け渡しする方法を作らないといけないし、
特にフレームワークがビルドとかもしてくれる仕組みだと
なんか二度手間感がある

・docker runした時にビルドする。
必然的にビルド環境も含めたイメージになる。
ファイル更新時に自動的にビルドしてくれるようなフレームワークを
使っている場合、この方が便利かもしれない。テストも実行できるし、
実運用用は別で作ることになるだろう。

ちゃんと作るならおそらく3番目が良さそうではあるけど、開発にとって便利か？
って考えると4番目かなーとも思うけど、そこまでやるのが面倒なので
開発中はDocker使わんでいいやんって思ってるわけ。

319 ：login:Penguin：2016/01/15(金) 02:59:40.17 ID:eyDykv1a.net

一つのDockerfileで開発にもデバッグにもテストにも実運用にも使える
万能な方法があればいいんだけど、

そういやテスト実行環境っていうのもあるんだよね。

実行環境は、実行出来るだけで良い。
デバッグは、最低限デバッグモードで起動できればいいから、その場合は実行環境用と
共通化できるがデバッグのためのツールを入れるならば、追加でなにか必要。
ビルド環境は、ビルドツールが必要。
テスト実行環境は、実行環境に加えてテスト用ライブラリやツールが必要


やっぱり、それぞれわけないとだめだよなーっていうのが現時点の俺の結論。

320 ：293：2016/01/15(金) 03:24:51.98 ID:kfmWKxvv.net

> なので、基本的にアプリ開発中はDockerを使わない。

まあ結局そういうことですね。今のところは運用環境として割り切って使っていこうと思います。
諸々のノウハウありがとうございました。