Dockerイメージ/コンテナーの内部には何がありますか？
Dockerイメージ/コンテナーには、Ubuntu、CentOS、CoreOSなどのさまざまなフレーバーがあるという事実を考慮します。実際にイメージ/コンテナーを構成するものと、ホストOSと共有されるものについて知りたいのですが。境界線はどこにありますか？
たとえば、ベースのUbuntuイメージをダウンロードして、CentOSホストで起動できます。次に、Ubuntuコンテナー内をざっと見てみると、Ubuntuサーバー（ファイルシステムレイアウトなど）のように見え、感じていることがわかります。しかし、unameコマンドを実行すると、CentOSホストのカーネルなどが表示されます。
明らかに、基盤となるカーネルが同じホスト上のすべてのコンテナーによって共有されていることを理解しています。しかし、他に何がホストOSと共有され、イメージ/コンテナーの一部は何ですか？
例えば。カーネルはホストの一部であり、ファイルシステムのレイアウトはイメージ/コンテナの一部です...これを定義する仕様はありますか？
Dockerは [〜＃〜] lxc [〜＃〜] Linuxコンテナのラッパーであり、そのドキュメントでは、共有されているものと共有されていないものについて詳しく説明しています。
一般に、ホストマシンは、ファイルシステムからプロセスなど、コンテナ内のすべてを表示/格納します。ホストvmでpsコマンドを発行して、コンテナ内のプロセスを表示できます。
DockerコンテナはVMではないため、すべてが実際にはホスト上でネイティブに実行され、ホストカーネルを直接使用していることに注意してください。各コンテナには独自のユーザー名前空間があります（古いルートjailと同様）。コンテナが独自のプロセスのみを認識し、ホストファイルシステムに階層化された独自のファイルシステムと、ホストネットワークスタックにパイプするネットワークスタックを確実に表示するツール/機能があります。
imagesとcontainers（ docs ）。 imageは静的であり、ディスク上にのみ存在します。 containerはimageの実行中のインスタンスであり、独自のインスタンスが含まれていますプロセスツリー、RAMおよびその他のランタイムリソース。
imageは、レイヤーの論理グループに加えて、コンテナーを作成するときに何をするか、およびレイヤーを組み立てる方法に関するメタデータです。そのメタデータの一部は、各レイヤーがその親のIDを知っていることです。
では、何がレイヤーに入りますか？親に追加したファイル（およびディレクトリ）。親から何かが削除されたことを示す特別なファイル（「ホワイトアウト」）もあります。
あなたがdocker runイメージ、dockerはコンテナを作成します。コンテナはすべてのレイヤーを正しい順序で解凍し、ホストとは別の新しい「ルート」ファイルシステムを作成します。 dockerはまた、イメージメタデータを読み取り、イメージの作成時に指定された「エントリポイント」または「コマンド」のいずれかを開始します。これにより、新しいプロセスサブツリーが開始されます。コンテナの内部からは、その最初のプロセスはツリーのルートのように見えますが、ホストからは、プロセスのサブツリーであることがわかります。
ルートファイルシステムは、あるLinuxディストリビューションを別のディストリビューションとは異なるものにします（カーネルモジュールの違いや、ブートローダー/ブートファイルシステムの違いもありますが、これらは通常、実行中のプロセスからは見えません）。カーネルはホストと共有されており、実際には、コンテナー内で通常の責任を管理しています。ただし、ルートファイルシステムは異なるため、コンテナ内にいると、Dockerイメージにあるディストリビューションのように見えます。
コンテナには、独自のファイルシステムとプロセスツリーがあるだけでなく、独自の論理ネットワークインターフェイスがあり、オプションで、RAMとCPU時間）の独自の割り当てがあります。ただし、コンテナーはオペレーターとして、ホストのネットワークインターフェイスをコンテナーと共有することを決定できるため、RAMおよびCPUへの無制限のアクセスを許可し、ホストからデバイス、ファイル、およびディレクトリをマウントすることもできます。デフォルトでは物事を分離しておくことですが、必要なだけ分離モデルを破ることができます。