4

精简版

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

长版

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

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

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

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

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

笔记

  • 我不是在哭“天哪，为什么？？”。这不是咆哮或批评，我只是在为不同架构需要不同图像寻找技术解释。
  • 我不是在问如何创建多架构图像。
  • 我不是在寻找诸如“需要多架构图像以便您可以在各种平台上运行图像”之类的答案，而是回答“为什么？”，而不是“为什么需要这样？” （这是我的问题）。

除此之外，当您看到图像时，它通常os/arch在摘要中有一个，如下所示：

码头工人图像摘要

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

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

4

1 回答 1

1

为什么 Docker Engine 不能只是抽象出差异，并提供一个通用的接口

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

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

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

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

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

于 2020-06-10T11:14:02.183 回答