事情是这样的。
我从上星期开始,修改项目的源代码,然而提交了多次,容器代码并没有改变
后来在一遍文章上发现,还是要重新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
这里告诉我们两点,
- dockerfile就是本地的仓库链接(这里想说的形象点),有了它,本地修改的记录才能更新
- dockerfile最后构建过程形成文件和官方远程拉取是差不多一样的
- docker-compose build时候,可以指定一个或者多个,而它采用覆盖更新,dev.yml在后面,它的build就覆盖了compose.yml的image