如何使用Dockerfilepipe理特定版本的版本
普遍接受的做法是在干净的目录中有一个名为Dockerfile的文件，其中任何我可能需要COPY到我的图像驻留。 对于单一的版本，工作得很好。
但是，如果我有我的图像的多个版本，我需要编译？ 我可能有1.2,1.4和2.0的stream，其中任何一个都可以有补丁发布。 我的Dockerfile本身会根据版本安装各种二进制文件：1.2安装mybin 1.2; 1.4安装mybin 1.4; 等等
所以二进制文件的版本实际上在Dockerfile中。
那么如何控制版本，而不是扩散的Dockerfiles？
我看到几个选项：
- 有一个单一的，编辑它，然后检查回到混帐。 好的，但是我怎样才能build立1.4.2和1.2.7呢？
- 有多个目录，例如
myimage/1.4/包含1.4（包括一个Dockerfile，二进制文件等）的所有安装，而myimage/2.0/包含myimage/2.0/所有安装。 - 每个点发行版甚至是补丁发行版都有单一的目录（先前的解决scheme已经到了极致）。 这感觉非常多余。
- 有一个单一的目录为所有版本与一些自动化的过程来确定我的内部版本号，例如一个脚本，调用
docker build和一些脚本被安装在图像。 似乎非常混乱。 - 有一个单独的目录，但个别的dockerfiles，例如
Dockerfile.1.4.2和Dockerfile.2.0.7。
它似乎下降了1.2和1.2.7或1.2和1.4和1.0之间有多less相似之处。 换句话说，我是否要将发行版硬编码到Dockerfile中，或者尝试自动化呢？
在这里pipe理版本有什么理智的方法？
虽然这很麻烦，但我会select＃2（多个目录），或者使用git分支的扩展版本来代替目录。
docker库（创build/维护像debian，wordpress，gcc等基本图像）的人使用不同目录的方法（例如参阅GitHub上的GCC dockerfile ）。 这样你可以很好地集成到Docker Hub（例如自动构build）。 另一个select是使用不同的分支，如果你使用的是git。 所以你会有你的仓库myimage ，然后分支为1.0,1.2,1.4等等。 现在你也可以标记你的补丁。 再次，Docker Hub的Automated builds可以用于这种方法。
我想说，从软件工程/发布pipe理的angular度来看，基于分支的选项是最干净的解决scheme。 您可以从专用分支构build不同版本的应用程序，然后通过适当版本的Dockerfile发布。 这也意味着您可以将更改从一个分支合并到另一个分支，并将其正确logging在历史logging中。
顺便说一句，最好的做法是将Dockerfile放在应用程序源代码的根文件夹中。