从理论上讲，容器配置的迭代方法的想法真的很吸引我。在实践中，我很难让它发挥作用，尤其是在 podman/buildah 的无根生态系统中。
我开始觉得 podman/buildah 不是 debian 派生的 linux 发行版的最佳容器开发堆栈。一方面，apt 不支持 dnf 的“--installroot”选项/指令。我尝试将 debootstrap 与 buildah 的“scratch”一起使用，但没有成功……即，我收到“无法安装到目标”错误。
我应该说，我成功地将一个简单的 pod 与运行 NGINX、postgres 和服务的容器组合在一起，这是一个 c++ 库，我使用它来构建一个小型应用程序，用于代理来自 Web 前端的数据库绑定发布请求。问题在于它是一个杂项，主要症结在于基于服务的 C++ 应用程序。在编译和运行时依赖之间，我不确定最好的方法；不用说，我目前的方法行不通。
我会感谢经验丰富的从业者在基于 debian 的发行版上使用无根容器解决方案的任何和所有提示，尤其是。如果您正在推出自己的 C++ 微服务：我真的很想知道您进行配置的策略。提前谢谢了。
我发现来自 y-combinator 用户的这种见解很有用：
我很可能是错的，但 Podman 似乎错过了机会的时间框架。在工具方面，Red Hat 和 Docker 之间一直是一场刀战。Red Hat 想要拥有容器工具链，这样他们就不必处理，这样他们就可以淘汰竞争对手，比如（现在基本上已经不复存在了）Docker Enterprise。这些年来，我不时看一下 podman，但它似乎从未正式化，从未完善过，而且几乎总是在执行方面低于标准。在这个列表中，构建和容器控制是我遇到过的事情。我猜 - 有什么意义？如此依赖的无根论点几乎已经不复存在，Podman 的质量没有（似乎）提高，现在 IBM 拥有 Red Hat（主观的，但考虑到什么是可行的关注/考虑）
您可以安全地利用 Docker 和 buildkit（何时何地需要）。老实说，鉴于这些年来 Red Hat 使用这些工具的执行情况相对较差，我不明白这一点。我确信 Podman/Buildah 有一些利基用例，但总体而言，它似乎只是作为一个议程提出来，而不是在这一点上呈指数级增长的产品。红帽本可以让事情变得更好，但他们只是分散了注意力，并与容器生态系统中更广泛的努力背道而驰。
有关完整上下文，请参阅以下主题：https ://news.ycombinator.com/item?id=26101608