什么样的Docker图像尺寸被认为是“太大”?

5f0d552i  于 2022-11-28  发布在  Docker
关注(0)|答案(2)|浏览(144)

在我以前的公司,我们采用了微服务架构,并使用Docker来实现它。我们Docker映像的平均大小为~ 300 MB- ~ 600 MB。然而,我的新公司主要使用Docker进行开发工作流,平均映像大小为~1.5GB - ~3GB。一些较大的映像(10 GB以上)正在积极重构,以减小映像大小。
从我所读到的一切,我觉得这些图像太大,我们会遇到问题,但其余的团队认为,Docker引擎和Docker Swarm应该处理这些图像大小没有问题。
我的问题:Docker图像是否有一个可接受的理想范围,尝试使用GB图像的工作流程时会面临哪些陷阱(如果有)?

bf1o4zei

bf1o4zei1#

在我看来,理想尺寸只适合你的确切情况。对我和我现在的公司来说,我们没有大于1GB的图像。
如果您使用10 GB大小的映像并且没有任何问题(这甚至是可能的吗?!),那么它对于您的情况是可以的。
作为问题案例的示例,您可以考虑以下问题:“在通过Internet将映像部署到远程服务器/开发机器时,我需要等待1-2个小时,这样可以吗?”十有八九,这是不可以的。另一方面,如果您没有遇到这样的问题,那么您就完全没有问题。
另一个问题是小映像启动几秒钟,而大映像启动几分钟。如果你使用“热部署”方案,它也会破坏它。
它也可以用来检查为什么你的图片这么大。你可以读how layers work
请考虑以下两个Dockerfile:
第一:

RUN download something huge that weighs 5GB
RUN remove that something huge from above

第二:

RUN download something huge that weighs 5GB &&\
    remove that something huge from above

从第二个Dockerfile构建的映像比从第一个构建的映像轻5GB,而它们的内部是相同的。
另一个技巧是从一开始就使用一个小的、基本的图像。只要比较一下这些差异:

IMAGE NAME     SIZE
busybox        1 MB
alpine         3 MB
debian         125 MB
ubuntu         188 MB

虽然debian和ubuntu的内部几乎是一样的,debian从一开始就可以为你节省50 MB的内存,并且在将来需要更少的依赖性。

8dtrkrch

8dtrkrch2#

Docker本身可以处理它们没有问题,我不能说任何关于群。“多大是太大”,但只有你的团队可以回答。如果图像是5GB的,它的90%是重要的应用程序,我不会说它是臃肿。如果图像只有300M,但只有10%的应用程序需要,我会说它是臃肿。
FWIW,取决于你的“新公司”有多“新”,你最好不要捣乱。

相关问题