加速 Docker Build 构建过程

改写文件
最简单的加速是改写 Dockerfile,
因为 Dockerfile 中的一些命令 (ADD/COPY/RUN) 会产生新的 layer,
而 Docker 会自动跳过已经构建好的 layer。
所以一般优化的原则基于以下几点：

变动越小的命令，越靠前，增加 cache 使用率。
合并目的相同的命令，减少 layer 层数。
使用国内源，或者内网服务加速构建。
少装些东西，不是代码依赖的就尽量别装了…
记得加上合适的注释，以便日后的维护。

改过以后的版本，
开发者小周发现，
每次本地改完代码 build 调试都飞快，
他很满意。

但是用公司的分布式 gitlab runner 构建以后，
他发现：
有时镜像没用到 cache，又跑了一遍漫长的构建过程。

分布式构建
在 codebase 足够大的情况下，
CI/CD 一般都是分布式多台机器的，
默认的 docker build 只会从本地寻找 cache layer,
无法应对如此复杂的场面。

简单的办法是使用 docker build –cache-from 指定镜像，
我们会在 ci 脚本中这么写：

docker pull LKI/code:latest || true
docker build . -t LKI/code:latest –cache-from LKI/code:latest
docker push LKI/code:latest
但是这样手写的弊端是逻辑比较臃肿，
比如要完美适配多分支构建 (dev/master/hotfix/release) 的话，
往往就要自己实现一套判断究竟 cache from 哪个版本的逻辑。

更通用的办法是使用类似 GoogleContainerTools/kaniko 这样的工具来构建。

https://zhuanlan.zhihu.com/p/134810126

https://github.com/GoogleContainerTools/kaniko

https://github.com/golang/go/issues/35702

https://stackoverflow.com/questions/64462922/docker-multi-stage-build-go-image-x509-certificate-signed-by-unknown-authorit

https://blog.csdn.net/weixin_43983808/article/details/117661315

https://blog.csdn.net/zhangka002/article/details/107867356

https://www.cnblogs.com/YYRise/p/11589335.html