利用构建缓存机制缩短Docker镜像构建时间利用构建缓存机制缩短Docker镜

在使用Docker部署PHP或者node.js应用时，常用的方法是将代码和环境镜像打包成一个镜像然后运行，一些云厂商提供了非常便捷的操作，只需要把我们的代码提交到VCS上，然后它们就会帮我们拉取代码并根据代码包内的Dockerfile构建我们的镜像然后部署到集群里。
PHP和node.js都有非常不错的生态，有各种各样的包，但是一旦引入的包多了我们的项目内的文件就会变得非常多，所以在使用VCS协作的时候我们都会忽略掉依赖包目录(node_modules / vendor）。但是我们忽略了包目录后在构建镜像的时候就要使用composer或者npm把包重新装回去，所以Dockerfile大概长这样

FROM node COPY . /src RUN cd /src && npm install

这样看起来没什么问题，但是如果包一旦多起来安装的时候需要花费很长的时间，修复紧急bug的情况下等待的时间就是煎熬，那我们有没有什么办法能让这个过程更快一些呢？
我们知道Docker构建是分层的，一条指令一层，在没有带--no-cache=true指令的情况下如果某一层没有改动，Docker就不会重新构建这一层而是会使用缓存，先来看看Docker官方文档的描述

Starting with a parent image that is already in the cache, the next instruction is compared against all child images derived from that base image to see if one of them was built using the exact same instruction. If not, the cache is invalidated.
In most cases, simply comparing the instruction in the Dockerfile with one of the child images is sufficient. However, certain instructions require more examination and explanation.
For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.

简单来说就是如果第n层有改动，则n层以后的缓存都会失效，大多数情况下判断有无改动的方法是判断这层的指令和缓存中的构建指令是否一致，但是对于COPY和ADD命令会计算镜像内的文件和构建目录文件的校验和然后做比较来判断本层是否有改动。
最理想的情况下，我们希望package.json或者composer.json变动的时候会重新的安装包，在没有变动的情况下使用缓存缩短构建时间。
了解上面的规则后我们再来看看上面那个Dockerfile，如果我们不修改任何代码的话第二次构建也是能使用缓存的，但是如果我们修改了代码，COPY . /src这层的缓存就会失效，同时下一层的缓存也会失效。但是大多数情况下，重新构建镜像就意味着代码有修改，但是package.json和composer.json这两个文件并不会频繁的修改，所以我们需要把这两个文件以及install的操作分离出来，所以有

FROM nodeCOPY package.json /src/package.json RUN cd /src && npm installCOPY . /src

在package.json里面写一个依赖包

{ "dependencies": { "express": "^4.16.4" } }

然后再写一个index.js

const app = require('express')(); app.listen(8080)

然后我们进行第一次构建，看看docker history的输出

LIN2UR:~ lin2ur$ docker history demo IMAGECREATEDCREATED BYSIZECOMMENT 3c913c9e997b6 seconds ago/bin/sh -c #(nop) COPY dir:e3c12f06720cf5f3b…1.6MB 21373087419a6 seconds ago/bin/sh -c cd /src && npm install3MB 64896ee5240d14 seconds ago/bin/sh -c #(nop) COPY file:87de28b86afd2c1c…53B

把每一层的IMAGE ID和Dockerfile里面的指令对应起来就是
64896ee5240d => COPY package.json /src/package.json
21373087419a => RUN cd /src && npm install
3c913c9e997b => COPY . /src
现在我们来修改一下index.js模拟我们业务代码变动然后再进行构建

LIN2UR:~ lin2ur$ docker history demo IMAGECREATEDCREATED BYSIZECOMMENT 5d697905ad0a6 seconds ago/bin/sh -c #(nop) COPY dir:d698db67dac047bd2…1.6MB 21373087419a4 minutes ago/bin/sh -c cd /src && npm install3MB 64896ee5240d4 minutes ago/bin/sh -c #(nop) COPY file:87de28b86afd2c1c…53B

可以看到除了最上一层外其他两层的IMAGE ID是没有变化的，再来看看docker build命令的输出

LIN2UR:~ lin2ur$ docker build --rm -f "Dockerfile" -t demo . Sending build context to Docker daemon1.902MB Step 1/4 : FROM node ---> c63e58f0a7b2 Step 2/4 : COPY package.json /src/package.json ---> Using cache ---> 64896ee5240d Step 3/4 : RUN cd /src && npm install ---> Using cache ---> 21373087419a Step 4/4 : COPY . /src ---> 5d697905ad0a Successfully built 5d697905ad0a Successfully tagged demo:latest

可以看到步骤2和3都使用了缓存，比第一次构建的时间缩短不少。现在我们在package.json里面再加一个包模拟依赖包变动

LIN2UR:~ lin2ur$ docker history demo IMAGECREATEDCREATED BYSIZECOMMENT 020ce95b198729 seconds ago/bin/sh -c #(nop) COPY dir:ea4d7afd475895520…1.6MB d9697dfc702231 seconds ago/bin/sh -c cd /src && npm install3MB 71d8a2fb458a38 seconds ago/bin/sh -c #(nop) COPY file:87bd25345a96e6b3…51B

这次底下两层的IMAGE ID都变了，意味着没有使用缓存，再来看看docker build命令的输出

LIN2UR:~ lin2ur$ docker build --rm -f "Dockerfile" -t demo . Sending build context to Docker daemon1.902MB Step 1/4 : FROM node ---> c63e58f0a7b2 Step 2/4 : COPY package.json /src/package.json ---> 71d8a2fb458a Step 3/4 : RUN cd /src && npm install ---> Running in ce424d6af936 Step 4/4 : COPY . /src ---> 020ce95b1987 Successfully built 020ce95b1987 Successfully tagged demo:latest

【利用构建缓存机制缩短Docker镜像构建时间】由于第二层的package.json改动导致这层及后续的缓存失效，然后重新安装包，实现了我们希望的结果。