搜索

emm,如题所示,那个人就是我。

背景

事情是这样的。
我从上星期开始,修改项目的源代码,然而提交了多次,容器代码并没有改变
后来在一遍文章上发现,还是要重新build,本以为找到了救星了。
奈何发现执行docker-compose build,容器并没有重写,明明我是写了的,为什么会这样呢?

不知道自己已经几次看了Dockerfile文件,明明有copy命令,可就是不执行,或者说,这个文件就是不执行。。。

于是在今晚,重新阅读官方安装文档的时候,发现了问题。
它告诉我(官方文档真的得仔细读!),

Alternative: if you want to build the images locally with unreleased changes run the following command. It will take some time to build CVAT images.
docker-compose -f docker-compose.yml -f docker-compose.dev.yml build

进展

虽然第一次没有完全理解这句话的意思,抱着试一试的心态,运行了它。
结果真的重新build了容器!

以现在差不多理解的思想去读,这句话其实就是告诉我们,如果我们要运行二次开发的版本就要重新build。
哈哈,这个时候,你可能又懵了,那原理是什么?

解释

如果你懂得这个命令的意思,你可以跳过这里。
我不是,我今晚才知道这个命令。
这里,我以我理解的知识讲述一遍。

我们平常使用docker-compose 最熟悉的命令就是,docker-compose build
这个命令十分常见,它默认执行的是docker-compose.yml
我说到这里,你可能就知道上面命令的意思了,
没错,你可能猜对了。
上面的命令是指定文件进行build

这里又同时指定了两个文件,那也是可以的。
这也是为什么我前期一直build没有反应的原因。

结束

为什么上面还有个docker-compose.dev.yml
其实你去百度,你以为又是某某规范的时候,那就错了,这就是作者自己自定义的。

而这里面在docker-compose基础上,又增加了build参数。

(总算点题了)

services:
  cvat:
    build:
      context: .

有了这个参数,我们才能使用我们目录下的dockerfile文件。
如果没有这个,如果你写了image,指定了仓库的话,那么就会跳过这个文件,直接拉取仓库里的

又回到上面的问题,为什么指定了两个,因为官方在docker-compose.yml,就是写了image,拉的是官方远程仓库,而在docker-compose.dev.yml写了build

这里告诉我们两点,

  1. dockerfile就是本地的仓库链接(这里想说的形象点),有了它,本地修改的记录才能更新

    • dockerfile最后构建过程形成文件和官方远程拉取是差不多一样的
  2. docker-compose build时候,可以指定一个或者多个,而它采用覆盖更新,dev.yml在后面,它的build就覆盖了compose.yml的image

终于可以正常修改代码了,太棒了

docker

版权属于:染念
作品采用:本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
11
查看目录

目录

来自 《竟有人因为docker-compose build参数搞垮了1星期》
评论

博主很懒,啥都没有