[开源项目]分享一个 Docker 容器瘦身的项目

[AIdiot]

自己开发的一个给 Docker 容器瘦身的工具，在这里分享一下： https://github.com/negativa-ai/BLAFS

[memcache]

能给镜像瘦身吗？还是给运行中容器瘦身

[AIdiot]

@memcache 给镜像(image)瘦身。

[uid106]

是否可以考虑在 dockerfile 中集成，GitHub action 中直接打包发布瘦身版的镜像

[AIdiot]

@uid106 这个项目是根据运行时分析做瘦身的，应该不容易在 dockerfile 中集成，不过可以写个自动化脚本集成到 Github action 中，这里给了一些自动化瘦身的示例： https://github.com/negativa-ai/BLAFS/tree/main/examples

[cnnblike]

这个原理是啥？看起来只是用这个 fs 分析了以下文件的依赖？
同样的原理是不是也能对 linux 的镜像起作用？

[AIdiot]

@cnnblike 是的，对 Linux 镜像也能起作用

[Alias4ck]

和这个有什么区别 https://github.com/slimtoolkit/slim

[AIdiot]

@Alias4ck 和 slim 的目标是一样的，但是方法不一样。slim 我测试过，一是自动化不太方便，二是对一些复杂的镜像（比如 tensorflow/pytorch ），slim 会导致瘦身后的镜像无法运行。

[AIdiot]

@Alias4ck 我测过 DockerHub Top 20 的容器，slim 只能成功瘦身 8 个，成功率低于一半。

[duzhuo]

牛的 看起来好专业，还有论文

[songray]

看了一下论文原理，笼统来说，镜像有大量未使用的文件，比如基于 alpine-linux 的一堆容器，可能每个容器运行时你都只需要 usr 目录，别的比如 /bin /etc 压根不会动，那理论上我们可以把 /etc 之类的目录提取出来。

这个项目引入了一个 去膨胀层 的概念，通过分析容器运行时实际使用的文件，将他们提取出来成为去膨胀层，别的都剔除掉。

不过这种动态分析的方法可靠性我表示怀疑... 存在太多的 corner case 。有可能这个容器能跑起来别的就跑不起来了，或者基于这个容器导出的镜像打包出来的新镜像就跑不起来了。

[jhdxr]

我对最终效果（从 host 的角度看）存疑

第一点是在分析运行时实际使用的文件这个方面。很有可能存在分析时某个功能并没有触发，导致对应依赖文件被剔除的风险
第二点是团队的技术栈相似的情况下，base image 很有可能是一样的。那么当我有很多应用的时候，其实 base image 的层本身是复用的。而通过这个途径剔除后的 image ，每个单独看的确都变小了，但从 host 的角度可能反而需要存更多的层。

[xjzshttps]

@jhdxr 赞同，底层系统就那几种，看似体积很大，但是实际是全局很多容器共享，没什么大问题。

[AIdiot]

@xjzshttps 所以这个瘦身主要是针对上层应用容器的，比如用户上传的一些 serverless 容器。

[AIdiot]

@jhdxr 所以这个项目有 layer-sharing 模式，就是只瘦身应用独有的那几层，然后 base image 保持不变，可以参考一下 readme 中的论文有提到这一点。

[caola]

瘦身对我来说可能不太需要，
但我很想找一个能同时支持管理 Docker 和 LXC 的管理系统或者面板，奈何都没有发现有谁在做…

[smallparking]

我之前一直使用的是 docker-squash 不知道你这个和 squash 有什么区别

[lonccc]

star 一个