谷歌是如何解决Docker镜像体积太大的问题的

Matthew Moore是谷歌公司的资深工程师，专注于谷歌 Docker技术的应用，他是谷歌最早落地 Docker技术团队的核心成员。在 2017 swampUP大会的演讲上，他为大家介绍了谷歌使用 Docker技术的心得。本文对演讲视频进行了整理和归纳，原视频地址：

https://www.youtube.com/watch?v=lviLZFciDv4&list=PLY0Zjn5rFo4MFIwbYtQx4wD1KK7HleIzk&index=15

虚拟机的问题

最初，大家都使用虚拟机作为软件的运行环境，对外提供服务。为了在虚拟机上运行你的 Service，你不得不运行一大堆程序：

系统进程
定时任务
SSH
安装 Agent
安装 Bash
安装一大堆 libs

其实，你仅仅只是想让你的 Service运行起来，但你不得不维护一个 40GB的虚拟机。

然后你开始试用 Docker

开始试用 Docker，你毫不犹豫选择了和之前虚拟机一样的镜像：Ubuntu 1404，将之前的虚机的内容复制到了 Docker镜像，安装了一堆软件，最后发现你的 Docker镜像有 8GB。

谷歌的 Docker镜像构建实践

找到最小的基础镜像

Alpine Linux是基于 musl和 BusyBox的操作系统，目的是为了为用户提供更高效的资源使用效率。它的特性是体积小，最小的 Alpine Linux体积可以只有 5MB。谷歌某些团队使用 Alpine Linux作为 Docker Build的基础镜像。

目的：仅仅为了运行 Service

谷歌认为，为了运行一个 Service，并不需要将那些无关联的包、程序打包到容器里，换句话说，Docker镜像里只留下需要用到的，其他的都删除，从而得到一个最小的镜像。这需要考虑以下几点：

1、程序编译后的二进制文件（从 Artifactory获取）

2、程序的所有依赖（从 Artifactory获取）

3、程序语言的运行时（libc，JRE，node，…）

4、任何程序和 Kernel之间的中间件

其实这一切的信息，构建工具都已经知道。

谷歌的构建工具 Bazel

介绍 Bazel之前，先介绍下谷歌的开发模式，对于服务器端代码库，谷歌的开发流程如下：

1、所有的服务器端代码库都在一个巨大的版本控制系统里

2、每个人都用 Bazel构建软件

3、不同的组负责源码树的不同部分，所有的组件都是作为 BUILD目标来用

4、分支主要是用来管理发布，所以每个人都在最新版本上开发软件

Bazel（https://bazel.build/）是 Google内部用来构建自己的服务器端软件的工具。目前变成谷歌公司贡献的一个开源项目，目的是帮助开发者将软件的构建和测试变得更快、更可靠。

从上图可以看到，Bazel有 WORDSPACE的概念，WORDSPACE文件用来准备 Docker镜像构建所依赖的所有材料和来源。BUILD文件用来告诉 Bazel这个镜像应该使用什么命令进行构建，以及如何构建、如何测试。

使用 Bazel的声明式语言: WORKSPACE和 BUILD，开发者可以用文件描述整个构建和部署的环境。谷歌使用 Bazel进行 Docker的构建已经很多年，它为谷歌带来以下收益：

1、支持跨平台构建，分布式缓存，优化依赖解析，并行构建，增量构建。

2、支持多语言（Java, C++, Android, iOS, Go等等）。

3、跨平台。

4、水平扩展和自定义扩展。

Bazel是以下理念的奠基石：由于 Bazel需要所有的依赖都被完整地指定，我们可以预测改动影响了哪些程序和测试，并在提交前执行他们。

谷歌提供的 Distroless镜像构建文件

Distroless (https://github.com/GoogleCloudPlatform/distroless)是谷歌内部使用的镜像构建文件，包括 Java、Node、Python等镜像构建文件，Distroless仅仅只包含运行服务所需要的最小镜像，不包含包管理工具、shell命令行等其他功能。

为什么你需要这些镜像？这些镜像是谷歌和其他大公司的最佳实践的产物，经过了漏洞扫描，镜像会持续更新，保持安全性。

如何使用？Distroless提供的构建镜像的 BUILD文件，通过 Bazel可以直接进行构建。