docker build 不使用缓存重建镜像
cache 机制注意事项
可以说,cache 机制很大程度上做到了镜像的复用,降低存储空间的同时,还大大缩短了构建时间。然而,不得不说的是,想要用好 cache 机制,那就必须了解利用 cache 机制时的一些注意事项。
1. ADD 命令与 COPY 命令:Dockerfile 没有发生任何改变,但是命令ADD run.sh /
中 Dockerfile 当前目录下的 run.sh 却发生了变化,从而将直接导致镜像层文件系统内容的更新,原则上不应该再使用 cache。那么,判断 ADD 命令或者 COPY 命令后紧接的文件是否发生变化,则成为是否延用 cache 的重要依据。Docker 采取的策略是:获取 Dockerfile 下内容(包括文件的部分 inode 信息),计算出一个唯一的 hash 值,若 hash 值未发生变化,则可以认为文件内容没有发生变化,可以使用 cache 机制;反之亦然。
2. RUN 命令存在外部依赖:一旦 RUN 命令存在外部依赖,如RUN apt-get update
,那么随着时间的推移,基于同一个基础镜像,一年的 apt-get update 和一年后的 apt-get update, 由于软件源软件的更新,从而导致产生的镜像理论上应该不同。如果继续使用 cache 机制,将存在不满足用户需求的情况。Docker 一开始的设计既考虑了外部依赖的问题,用户可以使用参数 --no-cache 确保获取最新的外部依赖,命令为docker build --no-cache -t="my_new_image" .
3. 树状的镜像关系决定了,一次新镜像的成功构建将导致后续的 cache 机制全部失效:这一点很好理解,一旦产生一个新的镜像,同时意味着产生一个新的镜像 ID,而当前宿主机环境中肯定不会存在一个镜像,此镜像 ID 的父镜像 ID 是新产生镜像的ID。这也是为什么,书写 Dockerfile 时,应该将更多静态的安装、配置命令尽可能地放在 Dockerfile 的较前位置。
使用Dockerfile构建镜像可以利用它的缓存功能:只有在命令已更改的情况下,才会重建已构建的步骤。下面是重新构建之前涉及到的to-do app的示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | $ docker build . Sending build context to Docker daemon 2.56 kB Sending build context to Docker daemon Step 0 : FROM node ---> 91cbcf796c2c Step 1 : MAINTAINER ian.miell@gmail.com ---> Using cache Indicates you’re using the cache Specifies the cached image/layer ID ---> 8f5a8a3d9240 Step 2 : RUN git clone -q https: //github.com/docker-in-practice/todo.git ---> Using cache ---> 48db97331aa2 Step 3 : WORKDIR todo ---> Using cache ---> c5c85db751d6 Step 4 : RUN npm install > /dev/ null ---> Using cache ---> be943c45c55b Step 5 : EXPOSE 8000 ---> Using cache ---> 805b18d28a65 Step 6 : CMD npm start ---> Using cache ---> 19525d4ec794 Successfully built 19525d4ec794 |
缓存非常有用并且省时间,不过有时候docker缓存的行为不都能达到你的期望。
用以上Dockerfile作为示例,假设你更改了代码并push到Git仓库。新代码不会check out下来,因为git clone命令没有更改。在Docker看来git clone的步骤一样,所以使用了缓存。
在这种情况下,你可能不想开启docker的缓存了。
问题
你想不用缓存重建Dockerfile。
解决方法
构建镜像时使用–no-cache参数。
讨论
为了强制docker构建镜像时不用缓存,执行带–no-cache参数的docker build命令。下面的示例是使用了–no-cache构建镜像。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | $ docker build --no-cache . Sending build context to Docker daemon 2.56 kB Sending build context to Docker daemon Step 0 : FROM node ---> 91cbcf796c2c Step 1 : MAINTAINER ian.miell@gmail.com ---> Running in ca243b77f6a1 ---> 602f1294d7f1 Removing intermediate container ca243b77f6a1 Step 2 : RUN git clone -q https: //github.com/docker-in-practice/todo.git ---> Running in f2c0ac021247 ---> 04ee24faaf18 Removing intermediate container f2c0ac021247 Step 3 : WORKDIR todo ---> Running in c2d9cd32c182 ---> 4e0029de9074 Removing intermediate container c2d9cd32c182 Step 4 : RUN npm install > /dev/ null ---> Running in 79122dbf9e52 npm WARN package.json todomvc-swarm@0.0.1 No repository field. ---> 9b6531f2036a Removing intermediate container 79122dbf9e52 Step 5 : EXPOSE 8000 ---> Running in d1d58e1c4b15 ---> f7c1b9151108 Removing intermediate container d1d58e1c4b15 Step 6 : CMD npm start ---> Running in 697713ebb185 ---> 74f9ad384859 Removing intermediate container 697713ebb185 Successfully built 74f9ad384859 |
以上的构建镜像步骤没有使用到缓存,每一层的镜像ID都与之间的不同。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?