Alpine, Slim, Bookworm, Bullseye, Stretch, Jessie — Which Docker Image Should I Choose?
Alpine、Slim、Bookworm、Bullseye、Stretch、Jessie - 我应该选择哪个 Docker Image?
An update to my original article about choosing the right Docker Image for your project.
更新我关于为项目选择合适的 Docker Image 的原创文章。
照片由 Taylor Deas-Melesh 在 Unsplash 上拍摄
A few years back, when I was learning how to use Docker to containerize my applications, I wrote an article on understanding the differences between different versions and image types. I was always confused when I first started out as to which version of an image I should choose.
几年前,当我学习如何使用 Docker 对应用程序进行容器化时,我写过一篇文章,介绍如何理解不同版本和映像类型之间的区别。刚开始的时候,我总是搞不清楚应该选择哪个版本的镜像。
Alpine, slim, bookworm, bullseye, stretch, buster, jessie, slim-bookworm — what does it all mean?
阿尔卑斯、苗条、书虫、靶心、伸展、克星、杰西、苗条书虫--这些都是什么意思?
It was and continues to be my most read article. The confusion is real. But, I’ve learned a lot since I first wrote the article and wanted to provide an update.
这篇文章一直是我阅读次数最多的文章。困惑是真实的。但是,自从我第一次写这篇文章以来,我学到了很多东西,所以想提供最新消息。
In short, the difference between docker images is the still the underlying operating system that it runs. But the question still stands, how do you choose the right one?
简而言之,Docker 镜像之间的区别在于其运行的底层操作系统。但问题依然存在:如何选择正确的系统?
Remember, nothing in programming is permanent. You can try out different options, see what works for you, make changes and redeploy. Always test your images thoroughly before pushing to a production environment.
请记住,编程中没有什么是一劳永逸的。您可以尝试不同的选项,看看哪些适合您,然后进行修改并重新部署。在推送到生产环境之前,一定要彻底测试你的镜像。
Simple vs. Shared Tags
简单标签与共享标签
In my previous article, I didn’t explain simple versus shared tags that you might see on some Docker Image pages.
在上一篇文章中,我没有解释简单标签与共享标签的区别,你可能会在一些 Docker Image 页面上看到这两种标签。
Simple tags are associated with a specific version of an image built for Linux or Windows. Shared tags represent a collection of images. Each image in a collection may be built for a different platform and architecture.
简单标签与为 Linux 或 Windows 构建的图像的特定版本相关联。共享标签代表一组图像。集合中的每个图像都可能是为不同的平台和架构构建的。
Regardless of whether it’s a simple tag or a shared tag, the decision of which image to retrieve is determined by the host docker daemon.
不管是简单标签还是共享标签,主机 docker 守护进程都会决定检索哪个镜像。
The thing to remember is that “simple” tags are used for a single platform (Windows or Linux) and “shared tags” can be used for a combination of multiple platforms.
需要记住的是,"简单 "标签用于单一平台(Windows 或 Linux),而 "共享标签 "可用于多个平台的组合。
Generally, choose simple tags if you know which platform you are building for. If you truly need a portable docker image, you may consider a shared tag. Be careful with this and test thoroughly.
一般来说,如果你知道要为哪个平台构建,就选择简单标签。如果你确实需要一个可移植的 docker 镜像,可以考虑使用共享标签。使用时一定要小心,并进行全面测试。
Full official image
完整官方图片
I’ll use python and node as examples because these are my most used docker images, but these rules apply to most images.
我将以 python 和 node 为例,因为它们是我最常用的 docker 镜像,但这些规则适用于大多数镜像。
According to DockerHub, the full image with no qualifying tags are the de-facto image and the one you should use if you are unsure and just getting started.
根据 DockerHub 的说法,不带限定标签的完整镜像是事实上的镜像,如果你不确定并且刚刚开始使用,就应该使用这种镜像。
For example:
例如
- python:3.11.4
python:3.11.4 - node:20.3.0
节点:20.3.0
These images are based on the most recent stable Debian operating system release. I usually start with one of these when trying to get a project up and running quickly in a development environment, and I am not yet concerned about the size of the resulting image or security.
这些镜像基于最新发布的稳定版 Debian 操作系统。当我试图在开发环境中快速启动并运行一个项目时,通常会从其中的一个开始,而且我还不担心生成镜像的大小或安全性。
In my previous article, I mentioned that the full image is the safest choice, but I’d like to revise that statement. The full image is not the most secure choice, but it’s the one you should use when you are trying to get something up and running quickly in a development environment.
在上一篇文章中,我提到完整镜像是最安全的选择,但我想修改一下这句话。完整镜像并不是最安全的选择,但当你试图在开发环境中快速启动和运行某些程序时,你应该使用完整镜像。
The reason is, is that it likely contains everything you need for your application or script to run.
原因在于,它可能包含了应用程序或脚本运行所需的一切内容。
But, before you deploy to production, make sure to choose the smallest most secure image that works for you. Read more below about security best practices in docker.
但是,在部署到生产环境之前,请务必选择最安全的最小镜像。阅读更多有关 docker 安全最佳实践的内容。
All other image choices are subsets of the full image. So, if you start with a subset, you may find yourself having to install tools that are not available in the smaller images.
所有其他图像选择都是完整图像的子集。因此,如果从子集开始,你可能会发现自己需要安装一些小图像中没有的工具。
If you have more time, and you want to build for a production environment from the start, then study the other image choices outlined below and find the one that works for you.
如果你有更多的时间,并希望从一开始就为生产环境而构建,那么请研究下面列出的其他镜像选择,然后找到适合你的镜像。
-bookworm/-bullseye/-stretch/-jessie
-书虫/牛眼/拉伸/杰西
Images tagged with bullseye, bookworm, stretch, buster, or jessie are codenames for different Debian releases. At the time of this writing, the stable Debian release is 12, and its codename is “Bookworm.” “Bullseye” is Debian 11. “Buster” is 10. “Stretch” was the codename for all version 9 variations, and “Jessie” was the codename for all version 8 variations.
标有 bullseye、bookworm、stretch、buster 或 jessie 的图片是不同 Debian 版本的代号。在撰写本文时,Debian 的稳定版本是 12,其代号是 "书虫"。"牛眼 "是 Debian 11。"巴斯特 "是第 10 版。"Stretch "是所有第 9 版变体的代号,而 "Jessie "是所有第 8 版变体的代号。
Future versions in development, but not yet stable, are “Forky” and “Trixy.” You may start seeing these tags in the list of image versions on DockerHub.
正在开发但尚未稳定的未来版本是 "Forky "和 "Trixy"。你可能会开始在 DockerHub 的镜像版本列表中看到这些标签。
Choose one of these images if your code is compatible with a specific version of the Debian operating system. This is usually the case when you are installing packages beyond what the base operating system provides. In this case, you want to make sure you stay on the same release of Debian so that you don’t break your build in the future.
如果您的代码与特定版本的 Debian 操作系统兼容,请选择其中一个镜像。当您安装的软件包超出基本操作系统提供的版本时,通常会出现这种情况。在这种情况下,你需要确保你使用的是同一版本的 Debian,这样你就不会在将来破坏你的构建。
-slim
-纤细
The slim image is a paired down version of the full image. This image generally only installs the minimum needed to run your particular tool. In the case of Python, that’s the minimum packages to run python and the same for node.js.
超薄镜像是完整镜像的缩小配对版本。该镜像通常只安装运行特定工具所需的最小软件包。就 Python 而言,只安装运行 python 所需的最小软件包,node.js 也是如此。
By leaving out lesser-used tools, the image is smaller. Use this image if you have space constraints and do not need the full version.
由于省去了不常用的工具,图片的尺寸也就更小了。如果空间有限且不需要完整版,请使用此图片。
But be sure to test thoroughly when using this image! If you run into unexplained errors, try switching to the full image and see if that resolves it.
但在使用该镜像时,请务必进行全面测试!如果遇到无法解释的错误,请尝试切换到完整镜像,看看是否能解决问题。
Slim has the added benefit of being the most secure. Smaller images have less points that could be attacked, so using the smallest image is the best option if you just need to run a basic script or your application does not need a lot of the bells and whistles of the full operation system.
薄型图像的另一个好处是最安全。小图像的攻击点较少,因此,如果你只需要运行一个基本脚本,或者你的应用程序不需要完整操作系统的很多功能,那么使用最小图像是最好的选择。
-slim-bookworm/-slim-bullseye
-瘦书虫/-瘦牛眼
When combining slim with a specific Debian version, you get a slim version with only the most essential files to run the operating system, in that specific version.
将 slim 与特定的 Debian 版本结合使用时,您将得到一个 slim 版本,其中只包含运行该特定版本操作系统的最基本文件。
-alpine
-阿尔派恩
Alpine images are based on the Alpine Linux Project, which is an operating system that was built specifically for use inside of containers. For a long time, these were the most popular image variations due to their tiny size.
Alpine 映像基于 Alpine Linux 项目,这是一个专为在容器中使用而构建的操作系统。在很长一段时间里,这些镜像因其体积小而成为最受欢迎的镜像变体。
However, some teams are moving away from alpine because these images can cause compatibility issues that are hard to debug. Specifically, if using Python images, some wheels are built to be compatible with Debian and will need to be recompiled to work with an Apline-based image.
不过,有些团队正在放弃高山映像,因为这些映像可能会导致难以调试的兼容性问题。具体来说,如果使用 Python 映像,有些轮子是为了与 Debian 兼容而构建的,需要重新编译才能与基于 Apline 的映像兼容。
The main reason to use an Alpine image is to make your resulting image as small as possible. The base image will be smaller than 5MB. The python base image (adding python to the base alpine image) is currently 78.9MB. That’s still relatively small.
使用高山图像的主要原因是使生成的图像尽可能小。基础图像将小于 5MB。python 基本映像(在高山基本映像中添加 python)目前为 78.9MB。这还是比较小的。
This image is the most highly recommended if space is a concern.
如果考虑到空间问题,最推荐使用这种图片。
The disadvantage is that it does not contain some packages that you might need. Mainly, it uses a slimmer musl lib instead of glibc. You may run into issues if your application has specific libc requirements.
它的缺点是不包含一些你可能需要的软件包。主要是,它使用的是更小的 musl 库,而不是 glibc。如果你的应用程序对 libc 有特殊要求,你可能会遇到一些问题。
If you find the Alpine image is lacking in something you need, you can always install your package directly in your Dockerfile. This keeps the image to only what you need. Be aware that your Dockerfile will change if you are installing external packages. The main difference is that you will use apk
instead of apt-get
to install packages.
如果你发现 Alpine 镜像缺少你需要的东西,你可以直接在 Dockerfile 中安装你的软件包。这样,映像中就只有你需要的东西了。需要注意的是,如果你安装的是外部软件包,你的 Dockerfile 会发生变化。主要区别在于,你将使用 apk 而不是 apt-get 来安装软件包。
There have been concerns regarding -alpine images, so you need to be aware of them. Read about some of them here and here and do your research. Again, if you are experiencing an unexplained issue in building your Dockerfile, try switching to the full image to see if that cures it.
关于 "松树图像 "的问题一直备受关注,因此您需要了解这些问题。请在此处和此处阅读相关信息并进行研究。同样,如果你在构建 Dockerfile 时遇到无法解释的问题,可以尝试切换到完整镜像,看看是否能解决问题。
-windowsservercore
-窗口服务器核心
I rarely use windows, I am firmly in the Mac / Linux camp now, but if your application runs only on Windows or Windows Server, this is the image for you.
我很少使用 Windows 系统,现在我已坚定地站在 Mac / Linux 阵营中,但如果你的应用程序只能在 Windows 或 Windows Server 上运行,那么这就是适合你的镜像。
In production, always follow best practices for security
在生产过程中,始终遵循最佳安全实践
Choosing the right base image once you are ready to go into production is crucial. When you get past the “make it work” stage, you then want to make sure you are “doing it right”. One thing of huge importance is security.
准备投入生产时,选择正确的基础图像至关重要。当你过了 "让它工作 "的阶段,你就需要确保 "做得正确"。其中最重要的一点就是安全性。
First, make sure you are using an Official image from DockerHub or one that has been built by a Verified Publisher. You can see these badges listed with the image on DockerHub.
首先,请确保您使用的是 DockerHub 的官方镜像或由经过验证的发布者构建的镜像。你可以在 DockerHub 上看到这些徽章与镜像一起列出。
Choose the minimal base image that meets your requirements. Decide which of the above version of the image meets your needs. A smaller image minimizes the number of security vulnerabilities that you expose and is more lightweight.
选择符合您要求的最小基本图像。决定上述哪个版本的映像符合您的需求。较小的镜像可最大限度地减少暴露的安全漏洞数量,而且更加轻便。
Make sure you remove any unnecessary packages from your Dockerfile. You may experiment a bit and install a bunch of packages while developing and testing, but go back through and get rid of anything that’s not being used before deploying to production.
确保从 Dockerfile 中删除任何不必要的软件包。在开发和测试过程中,您可能会做一些实验并安装一堆软件包,但在部署到生产环境之前,请回头检查并删除任何不需要的软件包。
Don’t ever use :latest in a production Dockerfile. Doing this will always pull the latest image, and your application’s dependencies may not be compatible with future versions causing it to possibly break in the future.
千万不要在生产 Dockerfile 中使用 :late。这样做将始终拉取最新的镜像,而您的应用程序的依赖关系可能与未来版本不兼容,导致将来可能出现故障。
So, which one do I choose?
那么,我该选哪一个呢?
Here are some general guidelines I use:
以下是我使用的一些通用指南:
- If I need to get something up and running quickly in a development environment, have no space constraints, and don’t have time to mess around, I start with the de-facto image. My main concern here is that the image has everything I need to work out-of-the-box and I can get my proof-of-concept working. This image, however, will be take up the most space and will be the least secure. Don’t use this in a production environment unless absolutely necessary.
如果我需要在开发环境中快速启动和运行一些东西,没有空间限制,也没有时间瞎折腾,我就会从事实映像开始。我的主要考虑是,该镜像拥有开箱即用所需的一切,我可以让我的概念验证正常工作。不过,这个镜像占用的空间最大,也最不安全。除非万不得已,否则不要在生产环境中使用。 - If space is a concern and I know I need only the minimal packages for running a particular language like python, I go with -slim. Slim provides the bare minimum you need to run Python and have reduced security vulnerabilities. Simple Python scripts are a good candidate for slim images.
如果空间有限,而且我知道我只需要运行特定语言(如 Python)所需的最小软件包,我就会选择 -slim。Slim 提供了运行 Python 所需的最低限度,并减少了安全漏洞。简单的 Python 脚本很适合使用 slim 映像。 - For some projects that I have time to test thoroughly, and have extreme space constraints, I will use the Alpine images. But be aware that this can lead to longer build times and obscure bugs. If you are having trouble porting your docker containers to new environments, or something breaks as you add new packages, try a different image.
对于一些我有时间进行全面测试但空间极为有限的项目,我会使用阿尔派图像。但要注意的是,这可能会导致更长的构建时间和不明显的错误。如果你在将 docker 容器移植到新环境时遇到困难,或者在添加新软件包时出现故障,请尝试使用不同的镜像。 - When I need to install additional packages that target a specific version of Debian, I use a bullseye or bookworm tag. That will ensure that I get the latest of that version of Debian but don’t break my build in the future. You can additionally try the -slim versions of these images to reduce space.
当我需要安装针对特定版本 Debian 的附加软件包时,我会使用 "靶心 "或 "书虫 "标签。这将确保我获得最新版本的 Debian,但又不会在将来破坏我的构建。此外,您还可以尝试使用这些镜像的 -slim 版本来减少空间。 - Lastly, always scroll to the bottom of the DockerHub page for a particular image and read about suggestions for choosing a specific image.
最后,请始终滚动到特定镜像的 DockerHub 页面底部,阅读有关选择特定镜像的建议。
Comparing docker image sizes
比较 docker 映像的大小
If you want to inspect docker images yourself and compare their sizes, try this.
如果你想自己检查 docker 镜像并比较它们的大小,可以试试这个。
docker pull --quiet python:3.11.4
docker pull --quiet python:3.11.4-slim
docker pull --quiet python:3.11.4-alpine
docker pull --quiet python:3.11.4-bookworm
docker pull --quiet python:3.11.4-slim-bookworm
docker images | sort -k7 -h
You will see there are vast differences between de-facto images and -slim and -alpine versions.
您会发现,事实图像与-slim 和-alpine 版本之间存在巨大差异。

Conclusion
结论
When choosing a docker image, it’s important to consider many factors including which architecture you are building for, space constraints, security concerns and time it takes to build images.
在选择 docker 镜像时,必须考虑许多因素,包括你要构建的架构、空间限制、安全问题以及构建镜像所需的时间。
I hope this has helped to shed some light on the differences and guide you in choosing a docker image for your next project.
希望这篇文章能帮助你了解其中的差异,并指导你为下一个项目选择 docker 镜像。
🙏 Thank you for reading to the end! Comment below or email me at [email protected] if you have any questions.
🙏 感谢您读到最后!如果您有任何问题,请在下方评论或发送电子邮件至 [email protected]。
👉 New to Medium? Become a member for only $1 a week to read any article!
👉刚来 Medium?成为会员,每周只需 1 美元即可阅读任何文章!
☕ Enjoy what you read? Buy me a coffee to fuel more content!
☕ 喜欢您阅读的内容吗?请给我买杯咖啡,为更多内容加油!