Dockerが隠れたレイヤーを破壊しないのはなぜですか？

Question

Docker's Unionファイルシステムを考えると、現在の画像（最前面のレイヤー）上で実際に変更が行われ、前のレイヤーでは変更されません。問題は、これらのレイヤーがDockerによって破壊されず、隠されている理由です。何か特別な理由はありますか？

Answer 1

キャッシング

個別に各レイヤを保存することにより、ドッキングウィンドウは、結果をキャッシュすることができますし、それが以前の変更によって無効化されていない場合は、後でそれを再利用します。複数の画像を有する場合

過すべてのファイルシステムの使用をより速くビルドになり、より小さな

Answer 2

ドッカーは、ユニオンファイルシステムであるAUFS上に構築されたのと同じ基本イメージから構築。

画像がAUFSを経由して互いの上に変化を積層して作成されている（他の方法は、それ以来追加されている）

典型的なビルドしますRUNいくつかのデータを作成し、それが層に保存何か。

RUN touch a -- L1  a 
RUN touch b -- L2   b 
RUN touch c -- L3   c 

各レイヤーには、それ自身の変更セットのみが格納されます。

これらのAUFSレイヤーの合計は、コンテナの基礎となる仮想ファイルシステムになるように1つずつマウントされます。 「画像」は、下にあるレイヤー内のデータのビューです。

イメージ自体にはデータは保存されません。データを格納するレイヤーのみを参照します。

*image view    a b c 
L3       c 
L2      b 
L1      a 

コンテナの変更は、このすべての上にレイヤーで行われます。適切なレイヤーから既存のデータをコピーして、変更する必要がある場合は新しいデータをレイヤーに追加するか、下位レイヤーの実際のデータではなくデータへの参照を削除するデータを「削除」します。

私は層は次のようになり

echo test >> a 
touch d 
rm c 

、ファイルを変更したファイルを作成し、ファイルを削除した場合：あなたは下位層の1を破壊した場合

Lcontainer    a * d 
L3       c 
L2      b 
L1      a 

コンテナに表示されるビューにはそのデータが存在しません。 Derick Bailey mentionsとして

*image view    a c 
L3       c 
L1      a 

これは全く同じ層を再び使用する場合、層が画像間で共有することを可能にするいくつかの巧妙な画像の構築時間キャッシングを可能にします。これは通常、既存の画像FROMをビルドするときです。

decivemapperとzfsのような新しいストレージドライバは、同じ戦略を実装しますが、各層のファイルシステムスナップショットまたはクローンを使用してブロックレベルで実行します。下位レイヤ/スナップショットから変更されていないディスクブロックは、元のレイヤ/スナップショットから読み込まれます。コンテナレイヤー/スナップショットは、変更または削除されるまで元のデータに戻ってポインタを保持します。