如何使用Dockerfile管理特定版本的构建

Question

普遍接受的做法是在一个干净的目录中有一个名为Dockerfile的文件，我可能需要COPY进入我的图像。对于一个运行良好的单个版本。

但是，如果我需要编译多个版本的图像怎么办？我可能有1.2,1.4和2.0的流，其中任何一个都可以有补丁版本。我的Dockerfile本身会在图像中安装各种二进制文件，具体取决于版本：1.2安装mybin 1.2; 1.4安装mybin 1.4;等

所以二进制文件的版本实际上是在Dockerfile中。

那么如何在没有Dockerfiles扩散的情况下控制版本呢？

我看到了几个选项：

• 有一个并编辑它，然后检查回git。好的，但是我该如何构建1.4.2和1.2.7？
• 有多个目录，例如myimage/1.4/包含1.4的所有安装（包括Dockerfile，二进制文件等），而myimage/2.0/包含2.0的所有安装。
• 每个点发布单个目录甚至补丁发布（以前的解决方案都是极端的）。这感觉非常多余。
• 为所有版本制作一个目录，并使用一些自动流程来确定我的版本号，例如：调用docker build的脚本和一些脚本安装在映像中。看起来非常混乱。
• 只有一个目录，但有一个独立的dockerfiles，例如Dockerfile.1.4.2和Dockerfile.2.0.7。

似乎归结为在1.2和1.2.7之间，或1.2和1.4和1.0之间存在多少相似性。换句话说，我是否将该版本硬编码到Dockerfile中，或尝试自动化它？

在这里管理发布的有效方法是什么？

Answer 1

虽然很麻烦，但我会使用选项＃2（多个目录）或使用git branches而不是目录的扩展版本。

docker库中的人（创建/维护基本图像，如debian，wordpress，gcc，...）使用带有单独目录的方法（参见例如GCC dockerfile on GitHub）。这样您就可以很好地与Docker Hub集成（例如自动构建）。 另一种选择是使用不同的分支，如果你使用git。所以你将拥有你的存储库myimage，然后分支1.0,1.2,1.4等等。现在，您还可以标记补丁。来自Docker Hub的Automated builds再次可以与此方法一起使用。

我想说从软件工程/发布管理的角度来看，基于分支的选项是最干净的解决方案。您可以从专用分支构建应用程序的不同版本，然后通过适当版本的Dockerfile发送它。这也意味着您可以将更改从一个分支合并到另一个分支，并在历史记录中正确记录。

顺便说一句，将Dockerfile放在应用程序源代码的根文件夹中似乎是最佳做法。