如何将镜像体积海量缩减
点击上方蓝色字体，选择“设为星标”
回复”云原生“获取基础架构实践
镜像的传统构建
我们随便找个Golang代码项目作为案例，来开始构建一个镜像。下面我们以我的一个实战项目开始讲解：https://gitee.com/damon_one/uranus。
第一步：我们把项目代码克隆到本地：
git clone https://gitee.com/damon_one/uranus第二步，书写其编译的Dockerfile：
FROM golang:1.20
WORKDIR /opt/app
COPY . .
go build -o hz-zeus ./zeus
CMD ["/opt/app/hz-zeus"]这个 Dockerfile 描述的构建过程非常简单，我们首选 Golang:1.20 版本的镜像作为编译环境，将源码拷贝到镜像中，然后运行 go build 编译源码生成二进制可执行文件，最后配置启动命令。
第三步，构建镜像：
docker build -t hz-zeus -f Dockerfile .这样编译构建的镜像会很大，这里就不展示最后的镜像信息了。
Dockerfile 优化
从上面的 Dockerfile 可以看出，我们在容器内运行了 go build -o hz-zeus ./zeus，这条命令将会编译生成二进制的可执行文件，由于编译的过程中需要 Golang 编译工具的支持，所以我们必须要使用 Golang 镜像作为基础镜像，这是导致镜像体积过大的直接原因。
既然依赖基础镜像比较大，那么我们是否可以替换为轻量级的镜像呢？发现可以将 Golang:1.20 基础镜像替换为 golang:1.20-alpine 版本。
但，这样的构建之后，发现镜像还是很大。毕竟是在镜像内镜像编译二进制文件后构建镜像。那是否可以在外部进行构建后再同步到镜像内部呢？
$ CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o hz-zeus ./zeus
$ ls -lh
...最简单的办法就是在本地先编译出可执行文件，再将它复制到一个更小体积的 ubuntu 镜像内。具体做法是，首先在本地使用交叉编译生成 Linux 平台的二进制可执行文件。接下来，使用 Dockerfile 文件构建镜像。
FROM ubuntu:latest
WORKDIR /opt/app
COPY hz-zeus ./
CMD ["/opt/app/hz-zeus"]因为不再需要在容器里进行编译，所以我们直接引入了不包含 Golang 编译工具的 ubuntu 镜像作为基础运行环境，接下来使用 docker build 命令构建镜像。
这种构建方式生成的镜像在体积上比最初的缩小了几乎 90% 。镜像的最终大小就相当于 ubuntu:latest 的大小加上 Golang 二进制可执行文件的大小。不过，这种方式将应用的编译过程拆分到了宿主机上，这会让 Dockerfile 失去描述应用编译和打包的作用，不是一个好的实践。
多阶段构建
多阶段构建的本质其实就是将镜像构建过程拆分成编译过程和运行过程。第一个阶段对应编译的过程，负责生成可执行文件；第二个阶段对应运行过程，也就是拷贝第一阶段的二进制可执行文件，并为程序提供运行环境，最终镜像也就是第二阶段生成的镜像。
FROM golang:1.20 as builder
WORKDIR /opt/app
COPY . .
RUN go build -o hz-zeus ./zeus
FROM ubuntu:latest
WORKDIR /opt/app
COPY --from=builder /opt/app/hz-zeus ./hz-zeus
CMD ["/opt/app/hz-zeus"]这段内容里有两个 FROM 语句，所以这是一个包含两个阶段的构建过程。
第二阶段，它的作用是将第一阶段生成的二进制可执行文件复制到当前阶段，把 ubuntu:latest 作为运行环境，并设置 CMD 启动命令。
最后，我们执行docker build后会发现镜像大小与上面的先编译后copy到镜像种的操作生成的镜像一样大小。
到这里，对镜像大小的优化已经基本上完成了，镜像大小也在可接受的范围内。在实际的项目中，我也推荐你使用 ubuntu:latest 作为第二阶段的程序运行镜像。
如何复用构建缓存
在第一阶段的构建过程中，我们先是用 COPY . . 的方式拷贝了源码，又进行了编译，这会产生一个缺点，那就是如果只是源码变了，但依赖并没有变，Docker 将无法复用依赖的镜像层缓存。在实际构建过程中，你会发现 Docker 每次都会重新下载 Golang 依赖。
这就引出了另外一个构建镜像的小技巧：尽量使用 Docker 构建缓存。
要使用 Golang 依赖的缓存，最简单的办法是：先复制依赖文件，再下载依赖，最后再复制源码进行编译。基于这种思路，我们可以将第一阶段的构建修改如下：
FROM golang:1.20 as builder
WORKDIR /opt/app
COPY go.* ./
RUN go mod download
COPY . .
RUN go build -o hz-zeus ./zeus这样，在每次代码变更而依赖不变的情况下，Docker 都会复用之前产生的构建缓存，这可以加速镜像构建过程。
下面给大家介绍几本好书，目前销售火热，有原理加实战，感兴趣可以点击下方链接购买。
开源项目
实践项目代码开源：https://gitee.com/damon_one/microservice-k8s
欢迎大家star、fork，欢迎联系我，一起学习。
号内回复“云原生”，获取云原生基础架构实践
云原生社区合肥站
云原生社区合肥站正式启动啦，欢迎Base合肥、关注云原生、长期从事云原生的同志们踊跃加入，云原生社区合肥站会因为你们的加入而变得更加美好~
详情参见Issue：https://github.com/cloudnativeto/community/issues/107
联系号主
欢迎关注个站
往期回顾
微服务自动化部署CI/CD
如何利用k8s拉取私有仓库镜像
个站建设基础教程
ArrayList、LinkedList 你真的了解吗？
大佬整理的mysql规范，分享给大家
如果张东升是个程序员
微服务架构设计之解耦合
浅谈负载均衡
Oauth2的认证实战-HA篇
Oauth2的授权码模式《上》
浅谈开发与研发之差异
浅谈 Java 集合 | 底层源码解析
基于 Sentinel 作熔断 | 文末赠资料
基础设施服务k8s快速部署之HA篇
今天被问微服务，这几点，让面试官刮目相看
Spring cloud 之多种方式限流（实战）
Spring cloud 之熔断机制（实战）
面试被问finally 和 return，到底谁先执行？
Springcloud Oauth2 HA篇
Spring Cloud Kubernetes之实战一配置管理
Spring Cloud Kubernetes之实战二服务注册与发现
Spring Cloud Kubernetes之实战三网关Gateway
点击 "damon8.cn" 获取更好的阅读体验！
❤️给个「在看」，是对我最大的支持❤️