构建更小的容器镜像
发表于2022-04-13 15:51
浏览 1.5k
本文是我们容器技术系列文章的一部分：
- 构建更小的容器镜像（本文）
容器在现代应用环境中无处不在。开发人员正在以多种方式使用它们：构建容器，将它们推送到仓库，然后让应用在容器中运行。
在本文中，我将会探讨有关容器镜像的内容，具体就是如何让容器镜像变得更小，以及这样做有何意义。同时，我将展示一些示例代码和命令，它们可构建一个极小的容器镜像（用于测试）。
什么是容器镜像？
我看过有关容器镜像的最好定义是：
镜像存在无需容器，但容器需要运行镜像才能存在。
镜像定义部署应用的方式——例如，要公开哪些端口、应用运行时启动（或入口点）等。
为什么镜像越小越好？
较小的容器镜像有三个主要优点：
- 缩短应用的构建时间。构建时间不仅包括容器构建时间，而且还包括将容器推送到仓库的时间。
- 内存占用量更小。镜像越小，最终使用的内存就越少。如果使用公共云提供商，这可能不是一个问题；但如果使用笔记本电脑进行开发，这肯定会是一个问题。
- 更小的攻击面和更少的依赖项（尤其在容器不使用基础镜像的情况下）。由于镜像内的无关库、依赖项和其他内容更少，安全面就更小，占用空间也更小。
较小的容器镜像包含的组件通常较少。这意味着镜像中的非应用代码数量会减少。通常容器镜像中最大数量的“非应用”代码来自于共享库。共享库是一系列软件，用于实施已被（或可能被）多个应用用到的功能。使用共享库意味着无需为每个新应用重复编码相同的功能。一般情况下，共享库是一件好事，因为它们可以将共享代码外部化，因此可以使应用二进制文件变得更小。
容器中运行单个应用时，无需共享库。毕竟，没有其他应用可以共享代码！
共享库会占用空间，需将其生命周期作为构建过程的一部分单独进行管理。共享库通常随操作系统一起提供，并与使用它们的应用完全分开进行维护。
如果在容器中运行，则无需进行这一常见的分离工作。不分离共享库意味着，作为一名开发人员，您只需包含运行应用所需的组件，仅此而已。在容器环境中，这意味着没有共享库。
缩小镜像大小的工具
传统的容器镜像构建方法是包含并使用预构建的操作系统。如果使用更常用的基础镜像之一，在 Ubuntu 里就会看到类似下面的列表（为了便于阅读，此处分为多行）：
# podman images
REPOSITORY TAG IMAGE ID ...
docker.io/library/ubuntu latest 9873176a8ff5 ...
docker.io/library/fedora latest 055b2e5ebc94 ...
registry.fedoraproject.org/f33/fedora-toolbox latest af1f279fed20 ...
... CREATED SIZE
... 3 weeks ago 75.1 MB
... 7 weeks ago 184 MB
... 6 months ago 351 MB正如您所看到的，镜像大小的差异较大：从 Ubuntu 仅 75 MB 到整个 fedora-toolbox 镜像的 351 MB。每次运行其中一个镜像时，启动和加载都需要花费时间，这还不包括重新编译应用，并将镜像推送到仓库所花费的构建时间。
减少镜像大小有两种常见的选择：Alpine Linux 和 Red Hat 通用基础镜像 (UBI)。
Alpine Linux 基于 C 标准库 (libc) 的 musl 实现和 BusyBox，后者是一个最小内核，但仍包含大量工具。使用 musl-libc 意味着，您必须重新编译应用代码才能使用 Alpine Linux，如果您无法访问应用源代码就不行了。
来自 Red Hat 的 UBI 采用的是另一种方法。UBI 是一组标准化容器镜像，包含一组供开发人员使用的运行时。
使用 Alpine Linux 开发的镜像通常更小，在本列表中仅有 5.87 MB：
# podman images
REPOSITORY TAG IMAGE ID ...
registry.access.redhat.com/ubi8/ubi latest 8215cb84fa58 ...
registry.access.redhat.com/ubi8/ubi-minimal latest 3f32499d4f3a ...
docker.io/library/alpine latest d4ff818577bc ...
... CREATED SIZE
... 2 weeks ago 234 MB
... 2 weeks ago 105 MB
... 3 weeks ago 5.87 MBAlpine 和 UBI 解决的是同一问题（如何构建更小的镜像？），但从不同的起点着手。Alpine 从一个极小的代码库开始，仅添加所需的工具。而 UBI 则从一个更大的操作系统开始，并将其精简到最基本的部分。
使用最小镜像构建
构建最小镜像之前，您当然需要一个应用。在本文中，我用 C 编写了以下简单应用（事实上，我为一位同事写过此应用，他想要部署数千个容器来进行 Istio 测试，因此需要一个微型容器镜像）。
也许最值得注意的是，它实际上什么都没做！它仅调用了 pause() 函数并等待信号。
# more pausle.c
#include
int main(void) {return pause(); } 作为一个示例，这似乎是一个很奇怪的应用，但它恰好能够很好地说明我有关镜像大小的观点。由于应用很小，所以它对容器的大小只有非常小的影响。
一般情况下，我会运行此 gcc 命令来编译应用，并进行几个优化：
# gcc -Os -fdata-sections -ffunction-sections -fipa-pta -W1,--gc-sections -W1,-O1 -W1,--as-needed -W1,--strip-all pausle.c -o pausle-dynamic结果是一个非常小的二进制文件 （仅有 15 KB）：
# ls -lh pausle-dynamic
-rwxr-xr-x. 1 root root 15K Jul 22 22:00 pausle-dynamic此应用采用动态链接。也就是说，它需要操作系统上的共享库才能运行。这一点可以通过运行 ldd 命令来检查。
# ldd pausle-dynamic
linux-vdso.so.1 (0x00007fffafbe3000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb193983000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb193b5d000)为了将其构建到容器中，需要使用包含共享库的基础镜像。我使用了 podman 和 Dockerfile 来进行构建，因为它们的使用非常广泛。
# more Dockerfile
FROM registry.access.redhat.com/ubi8/ubi-minimal
ADD pausle-dynamic /
CMD ["/pausle-dynamic"]我使用了 RedHat UBI 最小镜像（步骤1），并添加了我自己预编译的应用，让容器在开始后运行它（步骤3）。
# podman build --tag=pausle-dynamic .
STEP 1: FROM registry.access.redhat.com/ubi8/ubi-minimal
STEP 2: ADD pausle-dynamic /
--> 344589591c7
STEP 3: CMD ["/pausle-dynamic"]
STEP 4: COMMIT pausle-dynamic
--> 1f72538cf84
1f72538cf84c10ae525e545fb5596840f09d277eccaffae46f6b6a3815339c8bPodman 镜像命令显示新镜像的大小 (105 MB) 没有超过 ubi-minimal 基础镜像，因为我的应用仅增加了 adds 15 KB。
# podman images
REPOSITORY TAG IMAGE ID ...
localhost/pausle-dynamic latest 1f72538cf84c ...
registry.access.redhat.com/ubi8/ubi-minimal latest 3f32499d4f3a ...
docker.io/library/alpine latest d4ff818577bc ...
... CREATED SIZE
... About a minute ago 105 MB
... 4 weeks ago 105 MB
... 5 weeks ago 5.87 MB运行此镜像时，可以看到它是可用的并且正在运行。
# podman run -d pausle-dynamic
5905d1ae4dc00b37f47ae4dlef4c7d99d8d5e1bd781da3b1decc436b10f5663b
# podman ps -a
CONTAINER ID IMAGE COMMAND ...
5905d1ae4dc0 localhost/pausle-dynamic:latest /pausle-dynamic ...
... CREATED STATUS
... 4 seconds ago Up 4 seconds ago可以在新容器内执行 shell，查看我的二进制文件：
# podman exec -it 5905d1ae4dc0 /bin/bash
# ldd pausle-dynamic
linux-vdso.so.1 (0x00007ffd89762000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa65a658000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa65aa1d000)该应用与我编译并构建到容器中的应用相同。因为它是动态链接的，所以需要在操作系统中运行共享库。这意味着，我的应用需要包含这些库的基础镜像才能运行。这增加了容器的大小，所以它仍然不是我想要的最小值。
无镜像构建
可以做两件事来使这个容器镜像小得多。可以静态链接我的代码，意味着我的应用将共享库“捆绑”到二进制文件中。
运行此命令来静态链接：
# gcc -Os -s static -ffunction-sections -fipa-pta -W1,--gc-sections pausle.c -o pausle-dynamic
# strip pausle-static
# ls-lh pausle-static
-rwxr-xr-x. 1 root root 697K Jul 22 22:31 pausle-staticls 命令显示由此生成的应用二进制文件大小为 697 KB ，比动态链接的应用大很多，原因是库被捆绑到应用中。
现在，如果运行 ldd 命令来显示共享库，将会收到消息，提示可执行文件不是动态的。
# ldd pausle-static
not a dynamic executable在 Dockerfile 中，使用特殊 no-op 关键字 scratch 来表明没有使用基础镜像。
# more Dockerfile
FROM scratch
ADD pausle-static /
CMD ["/pausle-static"]现在，运行 podman build 命令，
# 按与之前相同的方式构建镜像：
STEP 1: FROM scratch
STEP 2: ADD pausle-static /
--> 7fb16e85314
STEP 3: CMD ["/pausle-static"]
STEP 4: COMMIT pausle-static
--> f7f7c833975
f7f7c83397545aef51e0ad665def03040d5a06adf50651133184864bd1adaed4容器的构建方式与动态可执行文件完全相同，但生成的镜像比动态镜像小得多 – 只有 716 KB, 仅比静态编译的二进制文件本身 (697 KB) 大一点。
# podman images
REPOSITORY TAG IMAGE ID ...
localhost/pausle-static latest f7f7c8339754 ...
localhost/pausle-dynamic latest 1f72538cf84c ...
... CREATED SIZE
... 2 minutes ago 716 kB
... 20 minutes ago 105 MB初始化容器并确认它正在运行：
# podman run -d pausle-static
1748d59be199a797aa01f569b10445787d3f40439fb0b404b22e4226f4f44e09
# podman ps -a
CONTAINER ID IMAGE COMMAND ...
1748d59be199 localhost/pausle-static:latest /pausle-static ...
... CREATED STATUS
... 5 seconds ago Up 6 seconds ago如果尝试在容器内执行 shell 或运行 ls 命令，将会收到错误消息，提示容器中没有其他应用。这是因为容器不包含操作系统或基础镜像。
# podman exec -it 1748d59be199 /bin/bash
Error: executable file `/bin/bash` not found in $PATH: No such file or directory: OCI not found
# podman exec -it 1748d59be199 /bin/ls
Error: executable file `/bin/ls` not found in $PATH: No such file or directory: OCI not found结语
构建小型容器镜像在各种场景中都很有用，例如开发和测试。它可显著缩短新镜像的构建时间，包括将镜像推送到远程仓库所花费的时间。
如前所述，较小的容器镜像（尤其是在不使用基础镜像的情况下）也具有更小的攻击面和更少的依赖项，减少了镜像内无关库、依赖项和其他内容的占用空间。而且在大多数情况下，创建小镜像会带来一种整洁匀称的感觉，这让它成为一件非常酷的事情！
更多资源
想要更及时全面地获取NGINX相关的技术干货、互动问答、系列课程、活动资源？
请前往NGINX开源社区：
- 官网：nginx.org.cn
已修改于2023-03-08 17:09
写下您的评论
全部评论（0）
按点赞数排序
按时间排序
相关文章
介绍nginx网页配置工具QQ技术交流群1:1106758598QQ技术交流群2:560797506邮箱: cym1102@qq.com官网地址: http://www.nginxwebui.cn码云: https://gitee.com/cym1102/nginxWebUIgithub: https://github.com/cym1102/nginxWebUI功能特点nginxWebUI也可管理多个nginx服务器集群,随时一键切换到对应服务器上进行nginx配置,也可以一键将某台服务器配置同步到其他服务器,方便集群管理.部署此项目后,配置nginx再也不用上网各种搜索配置代码,再也不用手动申请和配置ssl证书,只需要在本项目中进行增删改查就可方便的配置和启动nginx。技术说明本项目是基于springBoot的web系统,数据库使用sqlite,因此服务器上不需要安装任何数据库项目启动时会释放一个.sqlite.db到系统用户文件夹中,注意进行备份本系统通过Let'sencrypt申请证书,使用acme.sh脚本
点赞 6
浏览 6.4k 前三周学习了陶辉老师的“NGINX基础培训系列课程”，感觉受益良多，在这里想把一些知识点记录一下，和大家分享一下知识点，也方便日后的随手查看，温故知新。 首先，我们了解到了Nginx的版本，Nginx发布版本分为主线版本和稳定版本，区分两个版本也非常简单，主线版本版本号为单数，比如1.19，稳定版本为双数，比如1.18，今天我要说的是稳定版本，这个版本会尽量少的减少Nginx的bug问题，适用于生产环境，这里我不建议使用Nginx和其他软件一样在生产环境中落后一个或多个大版本使用，之前生产环境做过漏扫，发现我们编译自带的Nginx版本为：nginx/1.13.3（查询命令为nginx-V），结果出现了多个漏洞，四个高危和一个中危漏洞： 通过升级Nginx到稳定版最新版本后修复！ 其次，是Nginx发行版本的选择，目前比较流行的有：nginx、nginxplus、Tengine、openresty、ope
点赞 1浏览 3.5k感谢您参加“NGINX从入门到精通进阶系列培训”！以下为培训的问答、课件和录像，希望您能通过此培训学有所得，祝学习进步！>问与答：- 基础篇+高级篇 - 应用篇+实战篇（New）>课件（PPT）：基础篇：-NGINX概要、安装、配置：https://interact.f5.com/rs/653-SMC-783/images/CNFEB22-NginxCoreCourse-Setup.pdf-NGINX日志、运维：https://interact.f5.com/rs/653-SMC-783/images/cnfeb22-nginxcorecourse-maintenance.pdf高级篇：-NGINX变量、API：https://interact.f5.com/rs/653-SMC-783/images/CNFEB22-NginxCoreCourse-API.pdf-NGINXSSL、NJS：https://interact.f5.com/rs/653-SMC-783/images/CNFEB22-NginxCoreCourse-SSL.pdf
点赞 10浏览 4.9k
保持联系
微信公众号
加入微信群
开放 · 包容 · 沟通 · 贡献
Copyright © F5, Inc. All Rights Reserved. F5 版权所有
