优化 Docker 镜像大小常见的方式

优化Docker镜像大小常见的方式

本文详细介绍了如何提高docker的图片大小，帮助大家更好的理解和应用Docker容器。有兴趣的盆友可以掌握一下。

通常大家搭建的Docker镜像一般都比较大，占用了很多存储空空间。随着容器的大规模部署，也会消耗宝贵的网络带宽资源。本文将详细介绍几种常用的提高Docker图像尺寸的方法。在这里，我们用DockerHub官网上的Redis图片来说明。

人工管理方式

你能立刻想到的是，立刻更改官网RedisimageDockerfile文档， *** 作后手动删除容器不用的部分，然后重新构建一个新的镜像。这种方法理论上可行，但是非常容易失败，实际效果也不是特别显著。主要是不能和官网镜像同步。

多链接结构

Docker已经在17.05版本中展示了多链接构造的作用来处理这个问题。这种方法是通过扔掉内层来完成的，根据内层来展示如何构建最终的图像和内容信息内容。只需要保存集装箱化所需的零件。顶层的完成如下所示:

拿一些镜子作为建造的基础。

照常运行命令来构建您的应用程序。

将所需产品复制到另一个独立镜像中

发行版

在严重依赖容器化技术，尤其是Docker之后，Google很早就意识到了应用松散图像的缺点。因此，他们展示了自己处理这个问题的方法，即distrolessmirror。与典型的Linux基本映像(与大量手机软件相关联)不同，您的应用程序是dockerondistroless，最终映像只包括应用程序和运行期间的依赖关系。大多数Linux发行版中包含的标准手机软件，比如包管理工具，甚至shell，都将被清除出去。同样，要应用Google的distroless映像，必须应用上面提到的多链接构造，如下所示:

FROMredis:latestASbuild ARGTIME_ZONE RUNmkdir-p/opt/etc&&\ cp-a--parents/lib/x86_64-linux-gnu/libm.so.*/opt&&\ cp-a--parents/lib/x86_64-linux-gnu/libdl.so.*/opt&&\ cp-a--parents/lib/x86_64-linux-gnu/libpthread.so.*/opt&&\ cp-a--parents/lib/x86_64-linux-gnu/libc.so.*/opt&&\ cp-a--parents/usr/local/bin/redis-server/opt&&\ cp-a--parents/usr/local/bin/redis-sentinel/opt&&\ cp/usr/share/zoneinfo/${TIME_ZONE:-UTC}/opt/etc/localtime FROMgcr.io/distroless/base COPY--from=build/opt/ VOLUME/data WORKDIR/data ENTRYPOINT["redis-server"]

使用redis:latest作为基本镜像，然后保存一些必要的二进制文件(redis-server二进制文件以及所有相关的依赖项)，然后使用distroless镜像作为最终构建的镜像的基础，将opt文件目录的内容复制到镜像文件目录。

然后，您只需再次构建镜像:

$dockerbuild-tredis:distroless.$dockerimagesREPOSITORYTAGIMAGEIDCREATEDSIZEredisdistroless7d50bd873bea15secondsago28.2MBredislatest1319b1eaa0b73daysago104MB

我们可以看到图像从104MB变成了28.2MB，大大缩小了图像的大小。

注意:在Linux下，我们可以使用ldd专用工具搜索特定二进制文件的必要依赖项，比如$ldd$(whichredis-server)。

使用分布式图像来减小Docker图像的大小是一种非常合理的方法。但是，那种方式有一个显著的缺陷，就是最终的镜像中没有shell程序流，这使得Docker容器的调整非常非常困难。自然，这也降低了黑客攻击的风险，使其更加安全。如果我们将它部署到Kubernetes集群，我们可以使用像kubectl-debug这样的特殊工具来帮助调整。

AlpineLinux

另外，比较常见的方法是选择AlpineLinux基本构建应用镜像。AlpineLinux是一个特别适合构建最低Docker映像的发行版。APLinux使用更小的muslC库代替glibc，并连接其静态数据，这意味着musl编译器的程序流将多次变成可重定位的二进制文件，从而不需要包含共享资源目标，从而显著减小镜像的大小。

Redis:alpineimage大概30MB。那样的缺点是一般musl的特点比不上glibc。自然还有一个好处，那就是和上面的distroless相比，Alpine是一个完美的Linux发行版，展现了基本的shell浏览，调整Docker容器更加方便。在DockerHub上，你还可以找到基本上所有时尚手机软件的Alpine版本号，比如Redis、Nginx、MySQL等。

GNUGuix

最后可以应用智能包可视化工具GNUGuix，其中会有构建Docker镜像的功能。Guix区分了包的运行时依赖和构建依赖，所以Guix构建的Docker镜像将只包括特定程序流的建立，加上它们的运行时依赖，就像distroless的方法一样。但是和distroless不一样，distroless要你自己检查程序流的运行，并且互相依赖(自然要写Dockerfile)，而Guix只需要 *** 作一条指令:$guixpack-fdockerfedis。

根据上面的说明，Redis图像的大小约为70MB，明显低于原图。虽然它比distroless和Alpine方法创建的图像略大，但Guinx的应用确实显示了一些其他优势。例如，如果您希望在最终图像中包含一个shell，它像Alpine一样易于调整，那么您只需要在古曦包的情况下指定它:$guixpack-fdockerredisbash。如果要收录第三方软件，可以在后面再添加一次。

Guix的功能特点代表了包构造可以100%复用，所以我们可以把Guix加入到CI/CD生产线中，这样整个构造的过程会非常流畅。

有些人可能认为Guix听起来很帅，但他们不想为了构建一个更小的Docker映像而安装和下载另一个特殊工具。况且Guix只在Linux下工作，很多开发者都是MacOS的客户，装备Guix还是挺不方便的。其实我很担心这个。Guix本身在DockerHub上有Docker镜像，应用起来不会太复杂。您只需要简单地应用$dockerrunguix命令。

除了Guix之外，值得一提的是还有一个名为Nix的包可视化工具，同样合理，适用于Guix的以上几点。

以上是提高Docker图像尺寸的一般方法的详细内容。关于提高Docker图像大小的资料很多，请关注其他相关文章！