Dockerコンテナー内のプロセスはどのように見えますか？

最近、Dockerコンテナの内部、つまり、Dockerコンテナ内で呼び出すコマンドとプロセスに関して、Dockerコンテナとは何か、より具体的には内部で何が起こっているのかについて、混乱が何度か起きていると聞きました。

誰かが何が起こっているのかについての高レベルの概要を提供してください

Dockerは仮想化バケットに投げ込まれます。これは、Dockerがその下のハードウェアを何らかの形で仮想化していると想定しているためです。これは、Dockerが使用する用語、主にコンテナという用語から浸透する誤った名称です。

ただし、Dockerはシステムのハードウェアの仮想化に関して魔法のようなことをしていません。むしろ、重要な機能の周りに「フェンス」を構築するLinuxカーネルの機能を利用して、プロセスがネットワーク、ファイルシステム、パーミッションなどのリソースとやり取りできるようにして、やり取りしているような錯覚を与えます完全に機能するシステムで。

以下は、Dockerコンテナーを起動し、の呼び出しを介してDockerコンテナーに入るときに何が起こっているかを示す例です/bin/bash。

$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#

実行すると、このコンテナ内からps -eaf：

Dockerコンテナーをホストしているホストシステムにログインしている別のターミナルタブに切り替えると、コンテナーが「実際に」占有しているプロセススペースを確認できます。

Dockerタブに戻ってその中のいくつかのプロセスを起動し、それらすべてをバックグラウンドにすると、Dockerコンテナー起動の一部として最初に開始したプライマリBashプロセスの下で実行されているいくつかの子プロセスがあることがわかります。

注：プロセスsleep 1000は、バックグラウンド化されている4つのコマンドです。

Dockerコンテナ内で、プロセスに48-51のプロセスID（PID）が割り当てられていることに注意してください。それらのps -eaf出力でもそれらを参照してください。

ただし、この次の画像では、Dockerが実行している「魔法」の多くが明らかになっています。

4つのsleep 1000プロセスが実際に元のBashプロセスの単なる子プロセスである様子をご覧ください。また、元のDockerコンテナ/bin/bashは、実際にはDockerデーモンの子プロセスでもあることに注意してください。

元のsleep 1000コマンドが完了するまで1000秒以上待ってから、さらに4つの新しいコマンドを実行し、次のように別のDockerコンテナーを起動する場合：

$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#

ホストコンピューターの出力ps -eafは次のようになります。

そして、他のDockerコンテナーは、すべてDockerデーモンの下のプロセスとして表示されます。

つまり、Dockerは実際には仮想化されておらず（従来の意味で）、さまざまなカーネルリソースの周りに「フェンス」を構築し、特定のプロセス+子の可視性を制限しています。

コンテナ内では、プロセスを分離（隔離）する必要があります。実際、指定したプロセス（少なくともシェル）以外のプロセスは表示されません。「社交性」テスト用ではありません。chrootとの唯一の類似点は、ホストカーネルが使用されることです。Dockerは、何かを分離したり、ホストで実行されているものとは異なるバージョンのプラットフォームアーキテクチャソフトウェアを使用したりする必要がある場合に最適です。（Javaの非常に古いバージョンまたはPythonの別のフォークが言う）。扱っているフォルダーとバイナリーがホスト上のフォルダーとバイナリーとは異なる場合があることを強く意識してください。同じ/ binフォルダーなどではありません。

編集：VMではなくchrootとの類似性。