详解容器镜像优化.docx

对于刚接触容器的人来说，很容易被自己制作的DoCker镜像大小所吓到,我只需要个几MB的可执行文件而已,为何镜像的大小会达到TGB以上？卜面将从两方面来进行货像大小优化,一种是通过多阶段构建处理一种是使用不同的基础镜像进行特定优化与精简.1减少镜像大小这部分着于介绍多阶段构建(multi-stagebuilds),因为这是慢像精简之路至关至要的一环.在这部分内容中，我会解秣静态链接和动态琏接的区别,它们对愤像带来的影响.以及如何避免那些不好的影响。我们还是从helloworid的程序开始，用C语营实现如下：hdkc7intmain()putsCHelk>.world!");return0：然后为其编写Dockerfile.如下:SROM9«COFYheIIox.RUNgcc-CKdloKdloxCMDeHowl执行Dockerbuild-theldgcc.进行构建后，发现偏像大小超过了1GB.因为该镜像包含了整个gcc镜像的内容,但其实编译好的代码可执行文件只有8.4KB,这显然不科学.Enr1o11>us<roppusr65M1016:3DodrtrHUrxnrx1OPPVMrppuscr8.4KJul116:47MUorwEr10ppuserOppuser67Jul1016:40hello.c23d2e3fb52199inutes090pPusefchenqongdevde*oSdockerIaOQeSIgrtphelloIrepgcc19G换个安装了C编译器的UbUntU镜像看看会得到一个大概300MB大小的潢像.缩小了3倍，但还是比8.4KB大太多了.类似地，Go语言版本的helloworld会得到相同的结果：pad09em3inimportfmfncmain0fmtPrintl11fHeo.WOddr)使用基础镜像golang构建的镜像大小是800MB,而编译后的可执行文件只有2MB大小，看来这个起决定性因素的还是基础镜像，那我们如何减小呢？谙采用多阶段构建的方法.我们还是以C语言的来看看，要想大幅度减少镜像的大小，多阶段构建是必不可少的.多阶段构建的想法很简单："我不想在最终的镜像中包含一堆C或G。编译器和整个编译工具链，我只要一个编译好的可执行文件！"。多阶段构建可以由多个FROM指令识别，每一个FROM语句表示一个新的构建阶段，阶段名称可以用AS参数指定，例如：FROM9ccASFbUildstageCOFYhdtax.RUNgcc-ohdlohdlcFROMubuntuCOFY-frofnrnybuilchUgehello.CMD(whelloJ这里使用基础镜像gcc来编译程序hello.c,然后启动一个新的构建阶段，它以UbUntU作为基础境像，将可执行文件hell。从上一阶段拷贝到最终的镜像中.最终的镜像大小是73.9MB,比之前的1.19GB减少了95%.o392218feed23d2e3fbS2196>11nutes09032mnuteogo在声明构建阶段时，可以不必使用关域词AS,最终阶段拷贝文件时可以直接使用序号表示之前的构建阶段（从零开始）,也就是说，下面两行是等效的：COPY-from三mytjiIdstagchello.COPY-from三Ohello.如果Dockerfile内容不是很豆杂，构建阶段也不是很多，可以直接使用序号表示构建阶段。一旦Dockerfile变聂杂了，构建阶段增多了，最好还是通过关燧词AS为每个阶段命名,这样也便于后期维护.细心的你，可能会发现上面以ubuntu为基础镜像还是大了些，能不能选择一个更小的潦像呢？当然可以，我们可以采用busybox或alpine镜像来替代该ubuntu镜像.2精简策略这部分将会针对不同的基咄镜像进行精简，比如scratch,alpine,slim等，还可以从语言层面进行精简，会以golang语言为例进行分析.2.1 golang精筒Go语言程序编译时会将所有必须的依赖编译到二进制文件中，但也不能完全肯定它使用的是静态链接，因为G。的某些包是依赖系统标准库的，例如使用到DNS解析的包。只要代码中导入了这些包，编译的二进制文件就需要调用到某些系统库，为了这个需求，Go实现了一种机制叫CgO,以允许Go调用C代码，这样编译好的二进制文件就可以调用系统库。也就是说，如果Go程序使用了net包，就会生成一个动态的二进制文件，如果想让镜像能够正常工作，必须将需要的库文件苴制到或像中，或者直接使用busybox:glibc镜像.当然,你也可以禁止ego,这样Go就不会使用系统库使用内置的实现来替代系统南例如使用内者的DNS解析器），这种情况下生成的二进制文件就是静态的。可以通过设置环境变量CGo_ENAB1.ED=O来禁用ego,例如:ROMgolangPYwhatsmyipoENVCG0-ENAB1.ED-0RUNgobuildwhatsmyip.90FROMSaatChCOPYfrom三Ogowhatsmyip.CMD"whatsmyip由于编译生成的是岸态二进制文件，因此可以直接跑在scratch镜像中（下面会介绍）当然，也可以不用完全禁用ego,可以通过-tags参数指定需要使用的内建库，例如-tagsnetgo就表示使用内建的net包，不依赖系统库：$gobuild-tagsnetgoWhatSmyipe90这样指定之后，如果导入的其他包都没有用到系统库，那么编译得到的就是静态二进制文件.也就是说，只要还有一个包用到了系统库，都会开启ego,最后得到的就是动态二进制文件.要想一劳永逸，还是设因环境变量CGe1.ENAB1.ED=O吧.2.2 使用scratch镜像SCratCh镜像很小，因为它基本上是空的,除了D。Cker给它额外添加的metadata（元数据：描述数据的数据）。它是一个虚拟镜像，不能被pu,也不能运行，因为它表示空！scratch镜像不可以直接从Docker官方拉取下来，但可以用以下命令构建这个scratch潦像：Starcv-files-fromdevnulldockerimport-Saateh$dockerimageIsREPOSITORYTAGIMAGEIDCREATEDSIZEscratchlatest775bfce214293minutesagoOB从钱像大小可知，scratch镜像大小为0,scratch构建钱像时，可精简到只在scratch上面加一层代码生成的二进制可执行文件.可以用于构建busybox等超小镜像，可以说是真正的从零开始构建届于自己的碗像。在构建二进制可执行文件的时候，需要进行薛态编译链接，因为scratch中没有我们需要的动态镇接库.比如：CGO_ENAB1.ED=0GOOS=IinuxGOARCH=arm64gobuild-oempty-a-IdfIags'-s'emptyImageProject/所以如果您追求镜像极小的话，可以使用scratch潼像配合多阶段处理来构建业务镜像.其缺点是：缺少shell,缺少调试工具、缺少Iibc等基础库.2.3 使用scratch镜像AlPine是众多1.inUX发行版中的一员，和CentoS、UbuntuxArChlinUX之类一样，只是一个发行版的名字，号称小巧安全，有自己的包管理工具apk.与CentoS和Ubuntu不同，Alpine并没有像RedHat或Canonical之类的大公司为其提供维护支持，软件包的数量也比这些发行版少很多（如果只看开箱即用的默认软件仓库，Alpine只有100OO个软件包，而Ubuntu、Debian和Fedora的软件包数量均大于50000.）容器娓起之前，AlPine还是个无名之辈，可能是因为大家并不是很关心操作系统本身的大小，毕竟大家只关心业务数据和文档，程序、库文件和系统本身的大小通常可以忽略不计.容器技术席卷整个软件产业之后，大家都注意到了一个问SS,那就是容器的穗像太大了，浪费磁盘空间，拉取镜像的时间也很长.于是，人们开始寻求适用于容器的更小的镜像.对于那些耳熟能详的发行版（例如Ubuntu、Debian.Fedora）来说,只能通过删除某些工品例如ifconfig和netstat网镜像体积控制在100M以下。而对于Alpine而言,什么都不用删除，镜像大小也就只有5M而已。AlPine镜像的另一个优势是包管理工具的执行速度非常快，安装软件体验非常烦滑.诚然，在传统的虚拟机上不需要太关心软件包的安装速度，同一个包只需要装一次即可，无需不停生且安装,容器就不一样了，你可能会定期构建新镜像，也可能会在运行的容器中临时安装某些调试工具，如果软件包的安装速度很慢，会很快消磨掉我们的耐心.为了更直观，我们来做个简隼的对比测试，看看不同的发行版安装tcpdump需要多长时间，测试命令如下：$timedockerrun<image><pxkag<mana9er>installtcpdump测试结果如下：BaseimageSizeTimetoinstalltcpdumpalpine.115.6MB1-2sarchlinux202106409MB7-9sEtOS由237MB5-Gsdcbian:10114MB5-7SNdoraSI194MB35-60$ubuntu:!8.044MB6-8$既然apline镜像除了小之外，工具包的安装速度也快，那我们在挑选各种语言版本的基础镜像时,可以优先选择带alpine的tag的镜像,比如golang:alpine就提供了基于Alpine构建的Go工具链.FROMgolanglpinePYhellogo.RUNgobuildhellooFROMalpinePY-from=0gohcllo.CMD(hello-)生成的镜像大小为7.5M对于一个只打印hell。World的程序来说确实有点大了.但我们可以换个角度：即使程序很红杂，生成的镜像也不会很大.包含了很多有用的调试工具.即使运行时缺少某些特殊的调试工具，也可以迅速安装.Go语言搞定了.C语言呢？并没有gcc:alpine这样的镜像啊。只能以Alpine镜像作为基础镜像，自己安装C编译器了,Dockerfile如下:FROMalpineRUNapkXdbuild-teeCOrrKello.C.RUNget-ohelloKHaCFROMalpineCOPYfrom三0hdlo.CMDhcow展后来对比一下不同构建方法得到的helloworld潦像大小：使用基础镜像golang构建：805MB多阶段构建，b3ld阶段使用基础镜像golang,run阶段使用基础镜像ubuntu:66.2MB多阶段构建，build阶段使用基咄镜像golang:alpine,run阶段使用基础镜像alpine:7.6MB多阶段构建,build阶段使用基咄镜像golang,run阶段使用基础镜像scratch:2MB最终镜像体积减少了99.75%,相当惊人了。2.4 slim镜像如果实在不想折腾,可以选择一个折衷的镜像xxx:SIim。slim镜像一般都基于Debian和glibc,删除了许多非必需的软件包，优化了体积.如果构建过程中需要编译器，那么slim镜像不适合.除此之外