docker - 为什么需要 Docker 多架构(而不是 Docker 引擎抽象差异)

Question

简洁版本

我想知道为什么需要为多种架构创建 Docker 镜像的技术原因。此外，尚不清楚这里的重点是为每个 CPU 架构还是为操作系统创建镜像。操作系统不应该抽象架构吗？

长版

我可以理解为什么 Docker Engine 必须移植到多个架构。它是一个将与操作系统交互、进行系统调用的软件，最终它只是表示为特定指令集中的一系列指令的代码，用于特定的架构。因此，必须将 Docker 引擎移植到多个操作系统/体系结构，就像必须移植 Microsoft Word 一样。

同样的事情也会发生在——比如说——JVM，或者VirtualBox。

但是，与 Docker 不同的是，为 Windows 上的 JVM 编写的软件可以在 Linux 上运行。 JVM 将抽象底层操作系统/架构的差异，并在两个平台上运行相同的代码。

为什么 Docker 镜像不是这种情况？为什么 Docker 引擎不能仅仅抽象出差异，并提供一个通用的接口(interface)，这样镜像本身就不需要与特定的操作系统/架构兼容？

这是一个决定(比如“让我们为每个架构制作不同的图像，因为它对于原因 X 更好”)，还是 Docker 工作方式的结果(比如“我们需要这样做，因为 Docker 需要 Y”)？

笔记

我不是在哭“天哪，为什么？？”。这不是咆哮或批评，我只是在为不同架构需要不同图像寻找技术解释。

我不是在问如何创建多架构图像。

我不是在寻找诸如“需要多架构图像以便您可以在各种平台上运行图像”之类的答案，而是回答“为什么？”，而不是“为什么需要这样？” (这是我的问题)。

除此之外，当你看到一张图片时，它通常有一个 os/arch在摘要中，如下所示:



图片的具体目标是什么？操作系统、架构，还是两者兼而有之？操作系统不应该抽象底层架构吗？

编辑:我开始假设每个架构都需要不同的图像:图像将包含其中的应用程序。假设它将包含 Go 编译器。 Go 编译器本身是一个二进制文件，必须已经编译到不同的架构。 x86-64 的图片将包含编译为 x86-64 的 Go 编译器， 等等。它是否正确？如果这是正确的，这是唯一的原因吗？

Answer 1

Why can't the Docker Engine just abstract the differences, and provide a common interface

性能将是一个主要因素。通过模拟一些不直接映射到 Windows API 的 POSIX 事物，考虑在 Windows 之上提供 POSIX API 时 Cygwin 对某些事物的速度有多慢。 (例如 fork()/单独执行，而不是 CreateProcess)。

这只是源兼容性；生成的二进制文件特定于 Windows 上的 Cygwin。如果您想在运行时这样做(二进制兼容而不是源兼容)，那就更糟了。

Docker 还需要在各种操作系统之上提供高效的可移植 JIT 编译 VM 所需的复杂性，尤其是跨各种 CPU ISA，例如 x86-64 与 AArch64，它们甚至不共享通用机器代码。

如果 Docker 走这条路，它实际上只是重新发明了一个基于 JVM 或 .NET CLR 字节码的 VM。

或者更有可能的是，它不会重新发明那个轮子，而是使用现有的虚拟机并在其之上添加图像管理。但是它不能与用 C 编写的 native 程序一起工作，除非将它们转换为 Java 或 CLR 字节码。