Docker

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

http://www.docker.io/

>>130
なるほど。わかってきたよ。ようするに使い方の違いの問題だ。
俺が今Dockerを使ってやろうとしているのは主に開発の効率化で

各個人専用の独立した開発環境を作りたいから
> ただ、その場合例えば会社の 172.17.0.0/16 などに繋がらなくなるよね。
これとは逆に外が見えたり、外から見えない方が好ましい。

閉じた環境のネットワークの中に軽量なサーバーを複数台、
例えば構成が少し違ったり、アプリのバージョンが違うものを
立てて実験したりしたい時に、いちいちポートフォワーディングの設定を〜
とかをするのが面倒なんだ。

だがDocker社も含めてDockerを使っている人達の多くはインフラ系で開発系ではないのだろう。
（この二つで担当者を分けるのはナンセンスだと俺は思っているが）
だからそういう情報が少ないんだろうな。

Dockerを使って実運用のサーバーを作る時にルーティングがありえないっていうのはわかるよ。
その場合はpipework等を使って任意のIPアドレスを割り振るって話だ。

ただ（開発用に）ルーティングを使った使い方の話が少ない理由がよくわからなかったんだ。

Dockerを使ってる人の多くはプログラマーな場合が多い。
なのでルーティングの知識は無い。
ポートフォワードならローカルからサーバーのMySQLにつなぐとか要件があってそこそこの知識がある。

>>132
１行目と2行目がどう関連してるのかよくわからないな。
今時ならなおのことネットワークに疎いプログラマなんぞ
いないだろうに。

>>132がプログラムに疎いインフラ屋なのだろう。

インフラ屋っていうのは取りあえず動くコードさえ
かければいいので、アプリを作れるレベルにない事が多いからさ。

なんでも屋と分業しているチームの違いじゃね

>>132 は分業しか知らない上に、
ルーティングひとつまともに知らない人ばかりの場所で働いてると
まれによくある話だ

そんな奴らが回収率の高いビジネスに持ってけるわけないので、放っておけば良い

DockerってDockefileに書いた順番に
イメージをコミットしていくだろう？

その時、Dockerfileの上のほうを修正すると
その下のコマンドを全部再実行することになる。

その時間を節約するには、Dockerfileは常に追記していくことになる。
でもそうするとDockerfileが見づらくなる。
だからといって並び替えると、コマンドを再実行することになって時間がかかる。

このジレンマどうにかならないもんかね。

Dockerって最後にCMDとかでapacheをフォアグラウンドで起動したりするけどさ、
あれって普通に起動してスリープで止めたほうが楽だよな？
Docker自体にそういう機能があってもいいと思うけど。

CMD service apache2 start && sleep 36500d

これならapache起動前の環境変数の設定とかやらなくて済む
欠点としては標準出力の内容を見れないところだけど、
普通はログファイルに出力できるからsleepの代わりにtailを使えばいいし。

CMD service apache2 start && tail -f /var/log/apache2/error.log

CoreOSとかinit.dを使った起動方法が存在しないなら直接起動するしか無いけど、
普通のディストリ使ってるなら普通に起動したほうが楽だと思う。

Redhat Enterprise Linux 6.6でDockerを動作させようとしたのですが、
dockerサービスを起動すると、ログに
kernelを3.8.0にアップグレードしろと出て動作しません。
kernel2.6のままで、
Dockerを動作させる方法はないでしょうか？

RH純正のrpmなら、動作するのでは？

動かないなら、RHEL v7.1で試した方がいいかと。

#6系よりもkernelのバージョンは上だし、Dockerの正式サポートがされているし > v7.1

>>139
RHEL7系はアーキテクチャが大きく変わって枯れていないので、
運用管理者が嫌がっているのです。
昨年12月位にCentOS6.6でDockerを試した時は動いたので、
RHEL6.6でも大丈夫かと思ったのですが。
今はCentOS6.6でもDockerは動作しないようです。
GitLabやDockerHub,Mavenリポジトリ,Jenkins,Sourceスタティックチェックサービス
など最新の開発サービスを、コンテナで分けて管理しようと思ったのですが
まだ共通に使われるサービスに、Dockerを利用するのは時期尚早みたいですね。

Atomic Host もリリースされたし、硬くdockerを運用したいなら、RHELはいいディストリビューションだと思いますけどね〜

枯れてないことを言い訳にしても、新しい仕組みであるdockerを活用できるとは思えない…

今作ったCentOS6.6で普通に動くが

>>142
EPELのdocker-io？それとも、別のパッケージ？

>>143
EPELの

>>118-120

> ・結局のところ、VOLUME指定は、ホストの/var/lib/docker/vfs/dir/配下に置かれてるボリュームを
> VOLUMEコマンドで指定した名前で、データボリュームコンテナ本体とそれを--volumes-fromで参照するコンテナから
> 　参照できるようになる仕組みでしかない
>
> というのがわかってないと、ハマると思う。

見事にハマったよ。そのレス読んでたけど具体的に触るまで
聞いてても頭にはいらないもんだな。

そもそも、ボリュームを確認するためのdocker volumesコマンドがまだ未実装なんだな？
ボリューム”コンテナ" と言ってるし、コマンドないし、これハマって当然だろ。
https://github.com/docker/docker/pull/8484

未実装のdocker volumesの代わりに、docker-volumesというのがある。
https://github.com/cpuguy83/docker-volumes

これ使ったら、どのコンテナがどういうふうに参照しているかわかったよ。
docker-composeと組み合わせたときの挙動とか。

試してないけど、そこに書いてあるボリュームのデータの吸い出しは
docker-volumes exportでできるんじゃないかな？

もう少しまともに使えるようになってから使えばいいのだ
慌てるなんちゃらは稼ぎが悪い

そんなこと言ってたら手遅れになるよｗ

あれよあれよという間に Docket が肥大してしまったので、
もっと軽量でコンパクトなコンテナ実装が出るのを期待してる。

Dockerの周辺技術が増えただけで
別にDocker自体は肥大化してないと思うけどね。

どうせどんな技術も
肥大化 → 機能を限定した軽いもの登場 → それもバージョンアップで肥大化
の流れになってるしｗ

結局、軽いものっていうのは、当初は機能が少ないから軽いだけで
どちらにしろ肥大化の道をたどる。

まあRocketでも使えば？

Docker がシンプルじゃなくなってるから coreOS が Rocket 作ったんじゃないっけ？

>>151
Dockerも反論してるよ。

両方読んで思ったのが、どっちもこの業界で
勝利者になりたいって考えてるんだろうなってこと。

CoreOSが主張している「Dockerが肥大化している」は正しくないと思う。
ただしDockerがオーケストレーションとか周辺技術にまで手を出しているから、
CoreOSが本当に懸念しているのは周辺技術の方だろう。CoreOSもその分野だし。

Dockerがコンテナから始まって周辺技術に手を出しているのと反対に
CoreOSは周辺技術から始まってコンテナに手を出している。
スタート地点が逆なだけで、両者がやろうとしていることは同じだと思うよ。

評価するのは正式版になってからだろうね。初期の段階がシンプルなのは当たり前なので
十分な機能を持った時にシンプルさを保てているかどうかが重要。

CRATE使ってみたいDOCKERて何状態

docker stopが固まる事がある。
CTRL Cで止めると、docker killばできず、docker rm -fもできない状態となるが、docker psで実行中の状態のまま。
dockerデーモンを止めて、コンテナのディレクターを手で削除して、dockerデーモンを止めると回復する。
dockerデーモンを止めずに、回復する方法はないだろうか？

>>154
Boot2Docker使ってるでしょ？

それBoot2Dockerのバグだから。
TinyCoreLinuxの問題かもだけど。

普通に仮想マシンにUbuntuとか入れてやれば安定するよ。
止まらないことなんて一回も起きてない。

そもそもDockerしか入ってなくて、まともにCLI使えない
貧弱なBoot2Dockerは使いづらいだけ。さっさと捨てた方がいい。

>>155
仮想OSでなく、
xeonの物理サーバーにCentOS6.6を入れてdocker-ioの1.4.1-3.el6で使ってます。
終了処理が10秒以上かかる
いろいろ調べた所、docker1.4のバグらしく、1.5だと直っているらしい。
1.5はまだ公式のepelリポジトリに入っていないので待ってみます。

1.6がでたのに、公式とか言ってるのは可愛そうだなｗ

まあLinuxディストリシステムの欠点とも言えるが、
そんなのに頼らないで、本当に欲しいものは
公式サイトからインストールした方がいい。

1.5と何が変わったのかというか、ブログっぽく書いてたページってトップから行けなかったっけ？
久しぶりだからよくわからなくなった

>>158
blogで検索しろ

>>159
すまんな完全に耄碌してた

結局、windowsで動かすdockerはvmwareでcolinuxじゃないということかなぁ
あと、リソースのリミットやcgroupはより実利用に向けてだね。あとは、レジストリのメモリサイズ減っててほしいな減ってたら使いたい
何よりもラベル助かる。というか必須にしようや

と、食いつきにくい餌をばらまく

>>157
公式から実行ファイル落としてきて差し替えるだけでアップデートできるしねえ

> 結局、windowsで動かすdockerはvmwareでcolinuxじゃないということかなぁ

誰か解読してくれ

スマン。俺では読解不能。

>>161
Windowsを使うなっていうことだよ。　

>>164
それをいうのならMacOSXもじゃね？
Docker動かんし。

>>162
colinuxは仮想マシンじゃないってことじゃないの？

ああ、「Winだと仮想経由になっちゃってコンテナとは言い難いな」ってことか？
それ踏まえて読み直すとやっと腑に落ちた

しかし読解レベルで食いつきにくいのは勘弁してもらいたいなw

とはいえコンテナが増えてくるとVMでモジュール化しないと管理しきれなくなる

モジュール化するのはいいが、
なんでVMでなんだ？
もっと軽いものでモジュール化しろよ

その軽いものでホスト環境ごと分離できるなら

>>170
Docker in Docker

>>170
それがコンテナ（プロセス）のグループ化って考え方なんだろうけどね。

ようするのpsコマンドの表示の仕方が悪いって話でしょ？
psした時に、特定のグループは一つにまとまって見れて
そのグループ単位で起動とか停止できればいいんでしょ？

複数のコンテナをまとめて管理するなら、docker-composeが使えるし
イメージやコンテナにラベルが付けられるようになったから
自分でコマンド作ればいい。

最終的にはsystemdと連携してプロセスグループとして管理される。
これが現在進行中の流れだよ。

今すぐ使いたかったら、
GoogleのKubernetes等のコンテナ管理ツールを使えば良い

>>171-172
実行状態もだけどコンテナ間通信のためのポート構成のカプセル化が目的
今度試してみる

DebianでDockerを使いたい

>>173
コンテナ間の通信であればポートを気にすることはない。
普通にコンテナ間でIPアドレス指定してアクセスできる。

ポートを気にするのはコンテナの外から
アクセスする部分だけ。

どっかの馬鹿がDockerに関しての話題をここじゃなくて、
こっちでやれって言ったからこっちに書いてるよ。

興味があったらどうぞ

プログラムに詳しくなりたい
http://peace.2ch.net/test/read.cgi/tech/1346595505/

ドッカーポエムが繰り広げられていますね。

DockerでCentOS7使おう思ったら
systemctlが無いやら(7.0)、B-Busがなんやら（7.1）出てしまうので
先人の教えを請うて次の魔法の言葉を打ったらsystemctl使えたけど
docker run --rm -v /usr/local/bin:/target jpetazzo/nsenter
docker run -p 80:80 centos:centos7 /sbin/init
sudo nsenter -t $(sudo docker inspect --format '{{.State.Pid}}' centos) -m -u -i -n -p /bin/sh
なんですの？これ

どこが魔法なんだ？。/sbin/initか？。

>>179
たぶんnsenterがゲストのCentOS7でsystemctl使えるようにする魔法の言葉だと思うんだけど
なにしてるの、これ？
（ちなみに-p 80:80はいらなかったのかも知れないがとりあえず入れただけ）

普通に、CentOSを起動した時に動くデーモンを全部起動してるだけ。
必要なものだけに厳選するなら、supervisordとか他の手段を使ったほうが良いと思う。

これを会社のシステムに使おうとしてる俺の会社って狂ってるよね
社内にLinuxに精通した奴なんておらんし

>>181
ありがと、
とりあえず/sbin/initでコンテナ上げとけばsystemctlが使えるようになるから
あとはnsenterとかsupervisordやらでコンテナのshに入ればいいってことなのかな？

>>182
Dockerを使おうって会社っていうとNTTデータ？IBM？
大きな会社だね。

>>183
今のコンテナに入る方法はdocker execだよ。
nsenterとか使わない。

あとコンテナの中でsystemdも使わない。
そもそも使い方が間違っていて
コンテナは仮想マシンじゃない。

コンテナは原則として一つのアプリを動かすもの。
その一つのアプリを動かすのに必要なものを
固めたのがコンテナ。

動かすのは一つのアプリだけなのだからsystemdもいらない。

>>185
なるほどハイパーバイザーみたいに使うのは違うんか
VPS借りてさらにその上で仮想化したくて
KVMはQEMUしか動かなくて糞遅く、VBは32bitしか使えず、
Dockerもsystemd使えなくて駄目かと思っていたら使えてウハウハしてしまった

>>185
最初はdocker execでCentOS7コンテナの/bash/shに入ったらsystemctl使えなくて
ホストのUbuntu14.04自体に無いからかな？と14.10に上げてsystemctlあるなと思ったが駄目で
インターネッツ探したらnsenterでごにょごにょ書いていたからやってみたら出来たっていきさつです

何を動かしたいんだ？。
webserverか？。
開発環境？。

>>188
Clamdscanを動かしたよ、試験で

これってWindowsでいうApp-Vみたいなもん？

>>186
実際マシンの仮想化はしてないからね。
ハードウェアのエミュレートなどはしていない。
chrootの技術の延長

WindowsでDLL Hell とかいう言葉を知っていればわかりやすけど
アプリAとアプリBがあります。どちらもOSのDLL（ダイナミックライブラリ）を使います。
アプリAをバージョンアップするために、OSのDLLのバージョンアップも必要です。
OSのDLLのバージョンアップしたら互換性がなくて、アプリBが動かなくなりました。
というのがDLL Hellというやつで、Linuxでも同じことは起きる。

この対策としてアプリAのディレクトリにOSのDLLを含めました。
などとアプリAのディレクトリに、OSのDLLすべてをコピーしちゃう。

更にプロセス空間やネットワーク関連も独立させて、完全に隔離された状態で
アプリケーションを動かすっていうのがアプリケーションコンテナ。

あくまで一つのアプリを動かすために、そのアプリに必要なものを
すべてまとめてしまってるだけなので、ホストOS上で
（コンテナ化された）アプリを動かすという考え方をする。

同じコンテナ技術を使って仮想マシンのように使うOpenVZとかあるけど
あれとは考え方が違うので注意。

一つのコンテナの中で動かすターゲットは一つ（＋それを動かすために必要物）なので
わざわざsystemd使う必要もないってわけ。

>>190
これか。
http://www.atmarkit.co.jp/ait/articles/1006/24/news108_2.html

ざっと見た感じだとかなり似ているな。
なんだかんだでWindowsは既に実現してるんだなｗ

仮想マシンの使い方だと、マシンを新たに作って
OSのインストールを終わらす。そこまでが仮想マシンを作る段階で、
それから、よーしこれからアプリケーションをインストールするぞーって
考え方だと思うけど、

Dockerの場合、アプリケーションが使えるようにする所までが一連の作業になる。
Dockerfileに定義した内容に従って、すぐに使えるDockerイメージを作る。
そのイメージを共有することで、

あ、あのアプリ使いたいな。って思った時にyumやapt-getでインストールする代わりに、
イメージをpullしてきてそれを起動する。
（Dockerイメージを起動して作られるのがDockerコンテナ、実行ファイルと起動したプロセスのような関係）

Dockerコンテナの中にはアプリを動かすため必要なカーネル以外のすべてのものが
含まれているから、Dockerさえ動く環境があれば、すぐにアプリが使えるようになる。

ちなみに、CentOSとかUbuntuの違いというのは

* カーネル + CentOS独自のパッケージと設定
* カーネル + Ubuntu独自のパッケージと設定

であるため、Dockerコンテナにはカーネル以外のすべての部分が含まれているということは
ホストOSがCentOSであっても、Ubuntuベースで作られたコンテナが使えるということ。
カーネル部分は多少のバージョンの差があるにしろ同じものだからね。

>>186
＞VPS借りてさらにその上で仮想化したくて
＞KVMはQEMUしか動かなくて糞遅く、VBは32bitしか使えず、

そういう用途だとLXCそのまま使うのが良いかもよ
http://knowledge.sakura.ad.jp/tech/2108/

>>194
そうなの？結構前だけどLXC使おう思ったが面倒そうでOpenVZに逃げたんだがｗ
（その時はホストがCentOSだったから面倒だった気もするけど）
今やDockerでまとまってウハウハ

そうか？。CoreOSと喧嘩したり、色々きな臭い感じじゃん。

和解しとるやん。
情報遅いな。

CRIU使ってマイグレーション辺り、やってる人いる？

>>193
お前まだそんな事言ってるのか
Dockerは小さな単位の仮想環境だよ

>>199
理由書かないと何の説得力もないよ。

仮想環境と書いているが曖昧で、俺が言ってるのは
アプリを仮想化したものだと言ってる。
Dockerで作るのは仮想マシンではない。

この二つをごっちゃにすると、
仮想マシンの中でDockerを作るのは意味が無い。などと勘違いしてしまう。

仮想マシンの中であっても、アプリをインストールして起動する。
Dockerを使うと、このアプリのインストールと起動が簡単になる。

使い方が全く違うんだよ。

アプリを特定の環境 (/usr/lib/libなんちゃらの特定のバージョンがある、など) で動かすための仕組みが仮想環境じゃねーの？

仮想環境をポイっと用意されたらその中で案件毎に複数のアプリをインストールしたりして、
ただ単に分離されたフルのOS環境として使うのが従来の仮想化の一般的な使い方だったけど、
KVMやESX, Hyper-Vなんかよりcgroup/namespace使ったコンテナはとっても軽いので
特定の仮想環境と特定のアプリ(nginx)をワンパッケージとして管理したら良いんじゃない？
ってことで出て来たのがDockerってことと思ってるが

>>201
仮想環境と言われると曖昧だが、
仮想マシンではないということ。

> 仮想環境をポイっと用意されたらその中で案件毎に複数のアプリをインストールしたりして、

「複数のアプリをインストールしたりして」の部分ね。
これがDockerコンテナ化された複数のアプリに変わる。

仮想マシンの中に複数アプリを入れると言っても、
そのアプリには設定が必要。何も設定しないでもいいアプリはあまりない。
つまりアプリのインストールというのは面倒な作業といえる。

それを軽減するためにChefなどのツールを使ったり、
AmazonのAMI（仮想マシンイメージ）を作ったりするが、
それは、アプリとアプリの依存関係を定義しているようなもので、
【「仮想マシンの中に入れる複数のアプリ」で構成されたもの】を作ることになる。
言い換えると、アプリの設定 と アプリ間の連携の設定が結びついてしまう。

Dockerコンテナの場合、単体のアプリを作るものだから、アプリのみの設定を行う。
そのアプリの連携はDockerコンテナの起動オプション（またはdocker-compose等）で行う

だから軽いっていうのもあるけど、新しいアプリのインストール・デプロイの方法なんだよ。
Dockerを導入した場合、仮想マシンというのはマシンスペックを増やすために作るもので、
その中で動かすアプリは柔軟に変更できる。

今のサービスは複数のアプリで構成されるのは普通だけど、その構成を決め打ちで定義してしまうものではなく、
Dockerコンテナで設定済みのアプリを作っておき、そのアプリの配置を好きに変更できる。
1仮想マシン、1アプリでもいいし、ハイスペックな1仮想マシンで全アプリにするのも自由自在

ようはOSすら１アプリって言えるってことでしょ？

>>203
ニュアンスの違い程度な気もするけど、
俺が言ってることを正確に表現するなら、
OSをアプリに内包するってこと。

（カーネル以外の）OSがアプリの一部になる。
Windowsで言えば、C:\Windows以下にある各種DLL全てを
アプリのディレクトリに入れたようなものかな。

メインはアプリであって、OSを使っているわけじゃないので。

オブジェクト指向信者みたいな奴だな
ただの軽量な仮想環境なんだから、使いたいように使えばいいだろ

パフォーマンスチューニング考えると複数のアプリを1つのコンテナにまとめた方が良い、という話もあるしな

パフォーマンス的にも専用OSにDocker載せたほうが軽い

>>205
いや、軽いだけの仮想マシンとして考えると使いづらいところが多いんだよ。
間違ってそう考えたがゆえにDockerは使えないと判断する人もいるしね。
違うものとして考えないと。

>>206
例えばSQLiteというデータベースライブラリ（サーバーではなくて）があるけど
これと同じようにデータベースをアプリに内蔵するという考え方で
MySQLを一つのアプリに内蔵するというやり方はある。

でもパフォーマンスチューニングという点で、一つのコンテナに
まとめたほうが良いという意見は聞かないな。どこで聞いたの？

>>207
さすがに物理マシンでそのまま動かしたほうが速いでしょｗ
もちろん仮想マシンよりかは速いけどさ。

>>208
http://thinkit.co.jp/story/2015/05/26/6037

コンテナ内のチューニングは面倒だな
環境でころころ変わって統一的にコンテナを扱えなくなるのはうまくない

> 環境でころころ変わって統一的にコンテナを扱えなくなるのはうまくない
具体的に言うと、何がダメなの？

一部の環境でのみバグったり劣化したりするリスクが増える

具体的にどの環境でのみバグった？

普通のアプリであれば、アプリ以外の部分、
つまりカーネル、OS、libc等の基本的な
ライブラリ、アプリの言語のバージョン、
その言語用のライブラリと依存するものが多い。

OSのアップグレードなんかしたら、それらが
変わってしまうから、一部の環境のみでバグったりするね？

でもDockerコンテナ化すれば、アプリにアプリが適切に
動く環境そのものを同梱できるから、
アプリ以外の部分は、カーネルのみになる。

だから一部の環境のみでバグるということが少ないはずなんだが？
もう少し、具体的な事例が聞きたいね。

dockerコマンド自体にバージョン違いがあるのだから、
管理側が2つを操作するよりは、1つをまとめておいた方がいい場合もあるやろ
面倒なやっちゃなー…

>>214
ホストOS上で、二つのアプリを操作するのが面倒だってこと？
何を言っているのかよくわからない。

>>212
しばらく待ってみましたが、やはりそんなリスクは
想像だけのもので、具体例は出せないようですね。

>>214
こちらも結局説明なしのようですね。
想像で言ってみたけど外れてたという類

>>217
オプション指定一つとってもバージョン違いあるやろ
外れてるのはお前の頭のネジやで

>>218
そっちじゃない。

> 管理側が2つを操作するよりは、1つをまとめておいた方が
これが意味不明という話

Dockerって、chrootみたいなもの？

>>220
「chrootの機能を継承した技術」を使いやすい形に統合したものかな。

知っているとは思うけど、chrootは単に
プロセスから見えるルートディレクトリを変更しただけ。

それを更に発展させてルートディレクトリだけではなく
プロセスやネットワークも分離させて、プロセスに対して
そのプロセスに独立した環境を作り出すのがコンテナ（LXC等）

ちなみに古いバージョンのDockerはLXCを利用していた。
今はlibcontainerを使ってカーネルのコンテナAPIを直接呼び出している

でDockerはそのカーネル提供しているコンテナAPIを応用して作られたソフトウェア
コンテナのビルド（作成）とその実行を行うための環境を提供している。

コンテナAPI自体は昔からあったわけだが、従来は使うためのツールが不足していて大変だった。
Dockerを使うとDockerfileというテキストファイルを用意することでコンテナイメージを
簡単に作成でき、コンテナが利用するリソース（CPU、メモリ、メットワーク）を
コマンドライン等で指定しつつ簡単に起動や停止が行えるようになる。

chroot+jailの発展形という説明があったな

>>221
昔流行りかけたXenみたいな感じでいいのかね？
コンテナイメージってファイル群じゃなくてでかい単一ファイル？

>>223
Xenはマイクロソフトに魂売ってHyper-Vでしょ？ｗハイパーバイザー部類だしょ？
コンテナは単一じゃなくてホストの１プロセスでは？

>>223
> 昔流行りかけたXenみたいな感じでいいのかね
ぜんぜん違う

chrootを知っていて、なんでそう勘違いするのかよくわからんが、
同じカーネルで動く1プロセスのルートディレクトリと
プロセス空間その他を隔離しただけ。

違いの一例を上げるとXenもKVMも仮想マシンを作るから
仮想的なハードウェアの一つとして仮想ディスクも必要になる。
だけどDockerはchrootと同じようにルートディレクトリを変えるだけだから
カーネルから認識されている同じディスクを使用する。

Dockerのコンテナはカーネルから見れば、単なる1アプリにすぎない。

> コンテナイメージってファイル群じゃなくてでかい単一ファイル？
chrootと同じようにファイル群。

1つのイメージは複数のレイヤーから構成されレイヤーにはファイルシステムの差分が記録される
1つのレイヤー = 1つのディレクトリ、通常イメージの最初のレイヤーにはchrootと同じく
OSのシステムファイルのほぼ全てが、次のレイヤーには差分だけが記録される。
このレイヤーはコンテナイメージの修正時に再利用/共有されるため、時間とディスクの節約になる。

訂正
× レイヤーにはファイルシステムの差分が記録される
○ レイヤーにはファイル単位で差分が記録される

別にディスクイメージが記録されてるわけじゃない。
レイヤー=ディレクトリに普通にファイルがある

こういう仕組みを提供しているのが
Dockerなわけだね。

>>225
ネットワークってどうやって別空間にしてるの？
chrootのときはしかたないからエイリアス使ってたけど
あとchrootのときみたいにやたらマウントポイント汚す？

chrootが謎の技術で/dev,/procを別物にした上で
上にaufsみたいなのが被さってるイメージでいいの？

k8sを使うと同一ホスト上の複数のコンテナに同じポートを割り当てられるんでしょうか？

Dockerで同じイメージを冗長化のために
A,B、2台のプライベートレジストリにpushしたとします。

Dockerfileでベースイメージを指定する時、
Dockerfileを書き換えずに、ベースイメージを取得する
プライベートレジストリのサーバーを変更する方法ありますか？

ただし2台のプライベートレジストリ（サーバー）はホスト名が異なり
DNSの変更は行わないものとします。

ぶっちゃけDockerfileのFROMに
プライベートレジストリのURLを含めることが気持ち悪いです。

いったんローカルに持ってきてからtag付けたら