有Dockerfile经验团队：Buildpacks与Dockerfile优劣评估是否公允？

我对Buildpacks做了一些了解，它似乎是个不错的工具。在我看来，它主要提供两方面的能力：

• 无需了解容器构建知识，即可将代码仓库自动转换为可运行容器（Heroku风格）
• 让开发者更便捷地构建高质量OCI容器

因此，对于不太了解OCI镜像构建的个人或团队而言，同时受益于上述两点的Buildpacks颇具吸引力。

但我们团队并非如此，我们不需要第一点能力。我们具备编写Dockerfile的经验，且编写过程耗时不长。因此引入并学习这一新工具的成本收益比并不理想。

采用Buildpacks的收益 #

• （忽略学习曲线的前提下）提升镜像创建与维护的效率
• 接近最优的分层策略，代码变更仅需重建少量镜像层；采用多阶段构建，运行时容器不含多余的构建工具等组件
• 至少能在一定程度上缩小镜像体积
• 可重现构建（暂未明确该特性的收益点）
• 以非root用户运行，可能还包含其他安全最佳实践
• 软件物料清单（暂未明确该特性的收益点，我们的镜像已在镜像仓库中完成漏洞扫描）
• 无需重建应用即可对镜像进行rebase操作（暂未明确该特性的收益点，我们发布前总会重建应用并运行CI测试）
• 诸如Paketo的Buildpacks拥有社区支持，我认为社区会监控并修复底层操作系统发行版等的漏洞

采用Buildpacks的成本 #

• 增加复杂度：需学习另一款非 trivial 的工具
• 存在学习曲线
• 类似“黑盒”魔法：符合预期时体验良好，不符合时排查困难；实际投入使用前难以预判其局限性
• 可能更难对容器进行临时修改
• 新增一个可能故障的环节：若Buildpacks生成的运行时容器不符合最佳实践、质量不佳或效率低下怎么办？虽然其质量大概率优于我们手写的Dockerfile，但并非绝对

请问针对Dockerfile为可行替代方案的场景，上述优劣评估是否公允？我是否遗漏了某些要点？

内容的提问来源于stack exchange，提问作者Janne Mattila