Docker

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

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

http://www.docker.io/

291 ：login:Penguin：2015/12/10(木) 16:06:29.45 ID:710xIGyw.net

ググれば全部出てるぞ
日本語訳されてるであろうArchwikiでも読んでこい

292 ：login:Penguin：2016/01/12(火) 12:32:49.44 ID:3vUodtEW.net

OS イメージをベースにして Docker コンテナを作るメリットって、
ホストOS に縛られずにコンテナを配置できるって理解であってる？

ただ、サーバーのメモリやストレージの節約を考えると
ホスト OS は決め打ちにして、コンテナには OS イメージを含めない方がいいと思うけどどうなの？
実際の運用でもサーバーごとに OS やバージョンが異なるなんてことはないはずだしね。

293 ：293：2016/01/12(火) 13:57:44.54 ID:3vUodtEW.net

ごめんなさい。すぞい勘違いをしていました。

DockerHub に登録されてる Dockerfile を見ていて気がついたのですが、
Docker イメージは、基本的に何らかの OS イメージをベースにして作るんですね。

FROM scratch となってるものもいくつかありましたが、
FROM を遡っていくとほとんどが何らかの OS イメージをベースにしていました。

294 ：login:Penguin：2016/01/12(火) 14:01:15.29 ID:7BqknXNc.net

OSのイメージはDebianで100MBを切る。
Alpine Linuxならわずか5MBだ

コンテナは仮想マシンじゃない。だからホストOSのカーネルを使用する。
コンテナで起動したアプリ以外の、各種デーモンも起動しない。
だからメモリ使用量もアプリを直接動かすのと大差ない。

つまりサーバーのメモリやストレージの節約は考える必要が無い。

実際の運用ではサーバーごとに OS やバージョンが異なる。
アップデートをすることで日々更新され続けるからだ。
LinuxのLTS（長期サポート）なんて5年しかない

295 ：login:Penguin：2016/01/12(火) 14:03:45.85 ID:8K/vPWgV.net

>>292
ホストに縛られないというかコンテナをコピーするだけでそのまま実行環境を別のホストに移せる
あと1つのホストに複数の実行環境を構築できる
これらは従来のVMでも出来ることだけどまるまる1台分を仮想化するのと違ってリソースをより効率よく使うことができる

296 ：login:Penguin：2016/01/12(火) 14:28:49.52 ID:7BqknXNc.net

Dockerを仮想マシンの一種として考えてしまうとインフラよりの発想となってしまう。
これではDockerがもてはやされている理由を理解できない。
Dockerはアプリ開発者の立場で考えるとわかる。

まず（ホスト）OSのアップデートで勝手にライブラリのバージョンが
変わってしまうと困る。例えばRubyのライブラリを勝手に
アップデートされたらアプリが動かなくなる可能性がある。

また、逆にディストリが提供しているパッケージよりも新しいバージョンの
ライブラリを使いたいこともある。1つのホストに複数のアプリを実行する時
アプリごとに使うバージョンを変えたいこともある。
だからアプリ開発者はディストリのパッケージでインストールするライブラリは使わない。
rbenvなどを使ってアプリの一部としてアプリごとにインストールする。
（注 Dockerを使えばrbenvを使う必要はない）

これはRubyライブラリだけの話に限らない。ネイティブライブラリやCLIコマンドなど
アプリから使用するあらゆるものはアプリ独自に入れたい。

アプリはアプリだけで動くのではない。動的リンクライブラリやCLIコマンドまで含めて
1つの動作するアプリとして完全体となる。つまりアプリとアプリを正しく動かすのに
必要なものを含めた完全体がコンテナ。コンテナさえあればアプリは完全に動くので、
ホストOSはDockerさえ動けば良くなる。

これがDockerを使う目的なのだから、その目的を達成できない方法はそもそも代替案にはならない。
ホストOSのリソースの効率化とかそういう話じゃないんだよ。

297 ：293：2016/01/12(火) 17:02:16.51 ID:3vUodtEW.net

>>294

ただ、DockerHub で配布されてる centos:6.7 に
yum install git すると image size が 190.6 MB → 323.3 MB
yum groupinstall "Development Tools" などとすると image size が 190.6 MB → 693.9 MB

となり、やはりストレージは食うのかなと。

根本的に使い方が間違っているのかもしれませんが、
通常は git とか コンパイラはコンテナに含めないのでしょうか？

298 ：293：2016/01/12(火) 17:20:35.11 ID:3vUodtEW.net

>>296

> アプリはアプリだけで動くのではない。動的リンクライブラリやCLIコマンドまで含めて
> 1つの動作するアプリとして完全体となる。つまりアプリとアプリを正しく動かすのに
> 必要なものを含めた完全体がコンテナ。

なるほど参考になります。

コンテナ =
Ruby で言うところの（ 例にあげて頂いた rbenv というよりは）bundler とか、
Node.js の npm (のローカルインストール) の延長で、
OS のストレージにあるものすべて（動的リンクライブラリやCLIコマンドなども含む）を
1つのアプリ環境としてパッケージできるもの

という理解で落ち着きました。

299 ：login:Penguin：2016/01/12(火) 17:43:43.68 ID:7BqknXNc.net

>>297
> 通常は git とか コンパイラはコンテナに含めないのでしょうか？
含めない。

もちろんコンテナイメージ作成中は適当にやっていいし、
利便性を考えて入れておくのもありだけど、

例えばgitを使ってソースコードを配置したいなら、
RUN apt-get install git & git clone 〜 & apt-get remove git (例なので適当）
のようにしてgitを入れて必要な処理が終わったら削除する。

（注 1つのRUNでインストールとアンインストールを実行すること。
複数に分けると、それぞれで中間イメージが保存されるのでサイズが減らない）

300 ：293：2016/01/12(火) 19:52:14.22 ID:n7gMyE/1.net

> RUN apt-get install git & git clone 〜 & apt-get remove git (例なので適当）
> のようにしてgitを入れて必要な処理が終わったら削除する。
>（注 1つのRUNでインストールとアンインストールを実行すること。
> 複数に分けると、それぞれで中間イメージが保存されるのでサイズが減らない）

確かにおっしゃる通りになりましたが、「複数に分けると〜」のところは
なぜサイズが変わらないのかいまいち理解できません。