同じ docker イメージに基づく多数の docker コンテナーを開始しているとします。これは、各 Docker コンテナーが同じアプリケーションを実行していることを意味します。アプリケーションが十分に大きく、多くのハード ドライブ メモリを必要とする場合があります。
ドッカーはどのように対処していますか？
すべての Docker コンテナーは、Docker イメージで定義された静的部分を共有していますか?
そうでない場合、docker コンテナーを実行するために使用されるマシン上のディレクトリにアプリケーションをコピーし、各 docker コンテナーにこのアプリ ディレクトリをマウントすることは理にかなっていますか?
Docker はカーネル レベルでリソースを共有します。これは、アプリケーション ロジックが実行時にレプリケートされないことを意味します。メモ帳を 1000 回起動しても、ハードディスクに保存されるのは 1 回だけですが、docker インスタンスについても同じことがカウントされます。
同じ docker イメージの 100 インスタンスを実行する場合、実際に行うことは、RAM 内の同じソフトウェアの状態を 100 の異なるタイムラインで保持することだけです。ホスト プロセッサは、これらの各コンテナ インスタンスのインメモリ状態を、それを制御するソフトウェアに対してシフトするため、アプリケーションの実行に必要な RAM メモリの 100 倍を消費します。アプリケーションのこの部分は常に静的で決して変更されないため、ソフトウェアのまったく同じバイトコードを物理的に 100 回保存しても意味がありません。(クレイジーな自己変更ソフトウェアを作成するか、コンテナーのイメージを再構築して再デプロイすることを選択しない限り)
これが、コンテナーがそのままでは永続化を許可しない理由であり、docker が仮想ハード ディスクを使用する通常の VM とどのように異なるかです。ただし、これはコンテナー内の永続性にのみ当てはまります。ハードディスク上の docker ソフトウェアによって変更されるファイルは、docker ボリュームを使用してコンテナーに「マウント」されるため、実際には docker 環境の一部ではなく、コンテナーにマウントされるだけです。(これについて詳しくは、https ://docs.docker.com/userguide/dockervolumes/ を参照してください)
これについて考えるときに尋ねたいと思うかもしれないもう 1 つの質問は、docker が実行時にディスクに加えた変更をどのように保存するかということです。チェックアウトするのが本当に楽しいのは、ドッカーが実際にこれを機能させる方法です。コンテナのハードディスクの元の状態は、イメージから与えられたものです。このイメージに書き込むことはできません。イメージに書き込む代わりに、docker イメージと比較して、コンテナーの内部状態で変更された内容の差分が作成されます。Docker は、Dockerイメージの初期状態の上に diff レイヤーを作成する「 Union Filesystem 」と呼ばれるテクノロジーを使用します。
この「差分」(下の画像では書き込み可能なコンテナーとして参照) はメモリに保存され、コンテナーを削除すると消えます。(ただし、コマンド「docker commit」を使用しない限り: これはお勧めしません。新しい docker イメージの状態は dockerfile には表されず、再構築から簡単に再生成することはできません)
