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

Question

通常接受的做法是在一个干净的目录中保存一个名为Dockerfile的文件，在其中存放我可能需要将COPY放入图像的任何内容。对于运行良好的单个版本。

但是，如果我需要编译镜像的多个版本怎么办？我可能有一个针对1.2、1.4和2.0的流，其中任何一个都可以包含补丁程序版本。我的Dockerfile本身确实将各种二进制文件安装到镜像中，具体取决于版本:1.2安装mybin 1.2； 1.4安装mybin 1.4;等等

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

那么如何在不增加Dockerfile的情况下控制版本呢？

我看到一些选择:

只编辑一个，然后将其检回到git。好的，但是那我该如何同时构建1.4.2和1.2.7？

有多个目录，例如myimage/1.4/包含1.4的所有安装(包括Dockerfile，二进制文件等)，而myimage/2.0/包含2.0的所有安装。

每个点发行版或什至补丁发行版都具有一个目录(以前的解决方案是极端的)。这感觉非常多余。

为所有构建提供一个目录，并通过一些自动化过程来确定我的构建编号，例如调用docker build的脚本，并且在图像中安装了一些脚本。似乎极为混乱。

有一个目录，但是有单独的dockerfile，例如Dockerfile.1.4.2和Dockerfile.2.0.7。

似乎可以归结为1.2和1.2.7或1.2和1.4和1.0之间的相似度。换句话说，我是将发行版硬编码到Dockerfile中，还是尝试对其进行自动化？

在这里管理发布的明智方法是什么？

Answer 1

尽管很麻烦，但我会选择选项2(多个目录)，或者使用git分支而不是目录使用它的扩展版本。

docker库中的家伙(创建/维护基本镜像，如debian，wordpress，gcc等)使用带有单独目录的方法(例如，参见GCC dockerfile on GitHub)。这样，您就可以与Docker Hub很好地集成(例如，自动构建)。
如果您正在使用git，则另一个选择是使用不同的分支。因此，您将拥有存储库myimage，然后分支到1.0、1.2、1.4等。现在，您也可以标记您的补丁了。同样，来自Docker Hub的Automated builds可以与这种方法一起使用。

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

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