根据this和this GitHub的问题,目前还没有一种原生的方法,可以在使用docker-compose
构建一个或多个镜像时为服务的镜像提供多个标签。
我的用例是构建在docker-compose.yml
文件中定义的图像,并使用一些自定义的标签(例如一些建筑物没有。或日期或类似),并且一次为latest
。
虽然使用docker tag可以很容易地通过普通docker
实现,但docker-compose
只允许在图像键中设置一个标签。对我来说,将docker tag
与docker-compose
一起使用不是一个选择,因为我想将所有与docker相关的定义保存在docker-compose.yml
文件中,而不是将它们复制到构建脚本中。
什么是一个体面的解决方案,以实现设置多个标签与docker-compose
,而不必硬编码/复制图像名称第一?
6条答案
按热度按时间omhiaaxx1#
我有一些使用环境变量的漂亮而干净的解决方案(默认变量值的bash语法,在我的例子中是
latest
,但你可以使用任何东西),这是我的compose:使用默认标签构建并推送(如果您需要推送到注册表),使用环境变量更改版本并再次构建并推送:
ghhkc1vu2#
您还可以采取以下方法:
然后,您只需运行
docker-compose build
和docker-compose push
,即可构建并推送正确的标记映像集。3bygqnnd3#
正如@JordanDeyton所建议的那样,
extends
不能再用于编写文件格式> 3
,而3.4
版本中添加的扩展字段功能可以取代它来实现相同的目标。这里有一个例子。现在可以使用所有已定义的标记构建图像
cidc1ykv4#
我想出了几个不同复杂程度的变通方法。它们都依赖于
${IMAGE_TAG}
存储表示例如构建号我们希望用这个标签以及latest
来标记所有服务的图像。grep
docker-compose.yml
文件中的镜像名称但是,如果有人在
docker-compose.yml
中添加了注解,例如:看起来像# Purpose of this image: do something useful...
。构建两次
使用
${IMAGE_TAG}
作为docker-compose.yml
文件中的环境变量,如here in the first example所述。然后,简单地运行构建过程两次,每次用不同的值替换
${IMAGE_TAG}
:第二个构建过程应该比第一个快得多,因为所有图像层仍然应该从第一次运行中缓存。
这种方法的缺点是,它会用每个服务的两个后续构建过程淹没日志输出,这可能会使搜索有用的东西变得更加困难。
此外,如果您在
Dockerfile
中有任何命令总是刷新构建缓存(例如:ADD
命令从远程位置获取,并自动更新last-modified
头文件,添加由外部进程不断更新的文件等),那么额外的构建可能会显着减慢速度。使用一些内联Python代码解析
docker-compose.yml
文件中的图像名称在Python(或任何其他语言,如
Ruby
或perl
或任何安装在您系统上的语言)中使用真实的的yaml
解析器比第一次提到的grep
方法更健壮,因为它不会被注解或奇怪但有效的yml
文件编写方法所迷惑。在Python中,它可能看起来像这样:
这种方法的缺点是执行构建的机器必须安装Python3沿着PyYAML库。如前所述,此模式可以类似地用于Python 2或安装的任何其他编程语言。
结合一些
docker
命令获取镜像名称下面的方法使用了一些原生的
docker
和docker-compose
命令(使用go-templates),编写起来稍微复杂一些,但也能很好地工作。虽然这种方法没有任何外部依赖项,并且比
grep
方法更安全,但在创建和删除容器的大型设置上可能需要多几秒钟的时间(通常不是问题)。h4cxqtbf5#
现在有一个使用buildx bake的内置解决方案,在v.0.7.0中发布。这个特性是根据我在https://github.com/docker/buildx/issues/396中的建议实现的。
Docker附带安装了
buildx
,但是,如果您在Mac上运行Docker Desktop,则在撰写本文时捆绑的buildx
版本较旧,您需要安装正确版本的buildx
以及Docker。将
x-bake
扩展字段添加到docker-compose.yaml
:要构建并标记映像,请运行:
要构建、标记和推送映像到存储库甚至多个存储库,请执行以下操作:
7uhlpewt6#
像许多人建议的那样使用extends是次优的,因为它会为生成的每个图像产生不同的校验和。这通常是不好的,因为您可以确保在生产环境中使用一致的映像。