细心的冤家会发现我这里有指定 Alpine 版本，而下面都是用的 latest 版本，由于就在刚刚发现有个坑需求留意下，就是我们选择 Alpine 版本的时分，最好不要选择 latest 版本，由于前面要装的软件版本能够会在 Alpine 的 latest 版本没有对应软件的版本号，就会安装错误，我刚刚就翻车了，点击查看 Alpine 版本下的包信息。
build 后，我们看看镜像大小，上次的是 174M 再次降到 73.4M，极致压榨。镜像：“放过我把，我真的没有了”。
解说：
我把这个构建分红了三个阶段：
第一阶段：构建基础镜像安装依赖、编译、运转等等阶段，就是一切阶段共用的东西都在第一阶段封到一个基础镜像里供其它阶段运用，比如设置环境变量、设置任务目录、安装 nodejs、yarn 等等。
第二阶段：装依赖阶段在这个阶段，装依赖，假设项目需求编译，可以在这个阶段装依赖编译好。
这里在说下装依赖的小细节，就是执行 yarn --production 加个 production 参数或许环境变量 NODE_ENV 为 production，yarn 将不会安装 devDependencies 中列出的任何软件包，点我查看官方文档阐明，由于我设置了环境变量所以就没加这个参数
第三阶段：最终运用镜像拷贝第二阶段安装的好的依赖文件夹，然后在拷贝代码文件就任务目录，执行启动命令，第二阶段装依赖多出的一些渣滓我们不需求，我们就只拷贝我们要用的东西，大大增加镜像的大小。
假设项目需求编译，在拷贝编译后的文件夹，不需求拷贝编译前的代码，有编译后的代码和依赖就可以跑起项目。
多阶段构建，最后生成的镜像只能是最后一个阶段的结果，但是，可以将前置阶段中的文件拷贝到后边的阶段中，这就是多阶段构建的最大意义。
最终优化成果：
大小从 1.06G 到 73.4M
构建速度从 29.6 秒到 1.3 秒(比照的是第二次构建的速度)
至此，压榨镜像手腕就完了，假设各位老板还有压榨手腕可以分享分享。
镜像内心独白：“你礼貌吗?还来”
GitHub 的 actions 构建镜像成绩
GitHub 提供的 actions，每次都是一个洁净的实例，什么意思，就是每次执行，都是洁净的机器，这会招致一个成绩，会招致 Docker 没法运用缓存，那有没有处置办法呢，我想到了三种处置办法：
1、 Docker 官方提供的 action 缓存方案
我用的是 Github cache 方案。
2、自托管 actions 运转机器
相当于 GitLab 的 runner 一样，本人提供运转器，本人提供的就不会每次都是洁净的机器，概略看 actions 官方文档。
3、先构建一个曾经安装好依赖包的镜像，然后基于此镜像再次构建，相当于多阶段构建，把前两个阶段构建的镜像产物推送到镜像仓库，再以这个镜像为基础去构建后续部分。借助镜像仓库存储基础镜像从而到达缓存的效果。
# 以这个镜像为基础去构建，这个镜像是曾经装好项目依赖的镜像并推送到镜像仓库里，这里从镜像仓库拉上去
FROM project-base-image:latest
COPY . .
CMD yarn start
参考材料：https://evilmartians.com/chron ... ching
最后项目仓库地址：https://github.com/iamobj/wechat-bot
文章有错误的中央欢迎指正，避免误人子弟。
(责任编辑：admin)