有人能向我解释一下为什么通常 Docker 的流程是从 Dockerfile 构建镜像，然后将其上传到仓库，而不是直接将 Dockerfile 移动到仓库吗？
假设我们有一台开发笔记本电脑和一台安装了 Docker 的测试服务器。
如果我们构建镜像，那就意味着上传和下载 Dockerfile 中所有的软件包。有时这可能非常大（例如 PyTorch > 500MB）。
与其将大型镜像文件传输到服务器中，不如在本地编译镜像以验证其是否正常工作，然后在服务器上传输较小的 Dockerfile 并构建镜像，这样做更有意义，你觉得呢？
这篇文章最初是一条评论，但内容过长。虽然可能不是全面的答案，但包含的信息仍然有用。
通常 Dockerfile 是构建过程的一部分，之前阶段的输出文件会被复制到最终镜像中。如果你想托管 Dockerfile 而不是最终镜像，你还需要托管（通常是临时的）处理文件或整个源代码库和构建脚本。
对于开源项目，后者经常被采用，但为了方便起见，预构建的 Docker 镜像也经常可用。
解决这个问题的一个简洁方法是使用多阶段构建在 Dockerfile 中编写整个构建过程（在 Docker CE 17.05 和 EE 17.06 中引入）。但即使使用单个 Dockerfile 以平台无关的方式描述完整的构建过程，仍然必须提供完整的源代码库。
TL,DR：把 Docker 镜像看作一个普通的二进制文件。它很方便下载和安装，而不必操纵源文件。如果为您的系统提供了二进制文件，您可以下载 C 应用程序的源代码并使用提供的 Makefile 进行构建，但为什么要这样做呢？
与其将大型图像文件来回传输到服务器，不如在本地编译图像以验证其是否有效，但主要是传输小型Dockerfile并在服务器上构建图像，这样做是否有意义？
当然可以！例如，您可以在Docker Hub上设置一个自动构建，每次您向GitHub存储库提交更新版本的Dockerfile时，它都会执行此操作。
或者您可以根据需要设置自己的构建服务器/ CI流程。
在我看来，构建图像概念并将其放入存储库的原因之一是与人们共享。例如，我们称Python的开箱即用图像可执行所有与Python相关的任务以使Python程序运行在Dockerfile中。同样地，我们可以创建自定义代码（例如我为带有某些自定义步骤（如端口更改和其他一些步骤）的Apache安装所做的示例），我创建了其图像，最后将其放入公司的存储库。
几天后我得知许多其他团队也在使用它，现在当他们分享时，无需进行任何更改，只需使用我的图像就可以完成。
rpm或deb，而不是静态链接的二进制文件（虽然对于多阶段构建来说稍微逊色一些），但除此之外，这个说法是正确的。 - Matt Schuchard