Docker容器内的进程是什么样的？
Answers:
Docker进入虚拟化桶，因为人们认为它以某种方式虚拟化了下面的硬件。这是一个不恰当的说法，主要来自Docker使用的术语，主要是术语容器。
但是，对于虚拟化系统硬件，Docker并没有做任何神奇的事情。而是利用Linux内核围绕关键设施构建“围栏”的能力，这使进程可以与资源（例如网络，文件系统和权限）进行交互，从而给人以您正在交互的错觉具有完整功能的系统。
这是一个示例，说明了启动Docker容器并通过调用进入容器时发生的情况/bin/bash。
$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#
现在从这个容器中，如果我们运行ps -eaf：
切换到另一个终端选项卡，在该选项卡上我们登录到托管Docker容器的主机系统，我们可以看到该容器“实际上”已占用的进程空间：
现在，如果我们回到Docker选项卡并在其中启动几个进程并将它们全部作为背景，我们可以看到我们现在有几个子进程在主要Bash进程下运行，该进程最初是作为Docker容器启动的一部分启动的。
注意：该进程是4个sleep 1000正在后台运行的命令。
请注意，如何在Docker容器内部为进程分配48-51的进程ID（PID）。ps -eaf在它们的输出中也可以看到它们：
但是，在下一张图片中，显示了Docker正在执行的许多“魔术”。
看看这四个sleep 1000流程实际上是我们原始Bash流程的子流程吗？还请注意，我们原始的Docker容器/bin/bash实际上也是Docker守护程序的子进程。
现在，如果我们要等1000秒钟以上sleep 1000才能完成原始命令，然后再运行4个新命令，然后像这样启动另一个Docker容器：
$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#
主机的输出ps -eaf如下所示：
其他Docker容器都将全部显示为Docker守护程序下的进程。
因此，您会看到，Docker确实不是在虚拟化（传统意义上），它是围绕各种内核资源构建“围墙”，并限制了给定进程+子级对其的可见性。
内容器，您的进程应隔离（隔离）。实际上，除了指定的进程外，您应该看不到任何进程（至少是一个shell）。它不用于“社交性”测试。与chroot的唯一相似之处在于使用了主机内核。如果您需要隔离某些东西或使用与主机上运行的版本不同的平台体系结构软件，则Docker非常有用。（非常旧的Java版本或Python的不同版本）。要特别注意要处理的文件夹和二进制文件可能与主机上的文件夹和二进制文件不同。/ bin文件夹不一样，等等。
编辑：与chroot而不是VM的相似性。