使用 debootstrap 进行迭代容器配置，就像 buildah 的'scratch'

Question

从理论上讲，容器配置的迭代方法的想法真的很吸引我。在实践中，我很难让它发挥作用，尤其是在 podman/buildah 的无根生态系统中。

我开始觉得 podman/buildah 不是 debian 派生的 linux 发行版的最佳容器开发堆栈。一方面，apt 不支持 dnf 的“--installroot”选项/指令。我尝试将 debootstrap 与 buildah 的“scratch”一起使用，但没有成功......即，我收到“无法安装到目标”错误。

我应该说，我成功地将一个简单的 pod 与运行 NGINX、postgres 和服务的容器组合在一起，这是一个 c++ 库，我使用它来构建一个小型应用程序，用于代理来自 Web 前端的数据库绑定发布请求.问题在于它是一个杂项，主要症结在于基于服务的 c++ 应用程序。在编译和运行时依赖之间，我不确定最好的方法；不用说，我目前的方法行不通。

如果有经验的从业者在基于 debian 的发行版上使用无根容器解决方案，我将不胜感激，尤其是。如果您正在推出自己的 C++ 微服务：我真的很想知道您进行配置的策略。非常感谢。

Answer 1

我发现一位 y-combinator 用户的见解很有用：

我很可能是错的，但 Podman 似乎错过了机会的时间框架。在工具方面，Red Hat 和 Docker 之间一直是一场刀战。 Red Hat 想要拥有容器工具链，这样他们就不必处​​理，这样他们就可以淘汰竞争对手，比如（现在基本上已经不复存在的）Docker Enterprise。 这些年来，我不时地看一下 podman，但它似乎从未正式化，从未完善过，而且几乎总是在执行方面低于标准。在这个列表中，构建和容器控制是我遇到过的事情。我猜 - 有什么意义？如此依赖的无根论点几乎已经不复存在，Podman 的质量没有（似乎）提高，现在 IBM 拥有了 Red Hat（主观的，但考虑到 CentOS 最近发生的事情，这是一个可行的担忧/考虑）。

您可以安全地利用 Docker 和 buildkit（何时何地需要）。老实说，鉴于这些年来 Red Hat 使用这些工具的执行相对较差，我不明白这一点。我确信 Podman/Buildah 有一些利基用例，但总的来说，它似乎只是作为一个议程提出来，而不是在这一点上呈指数级增长的产品。红帽本可以让事情变得更好，但他们只是分散了注意力，并与容器生态系统中更广泛的努力背道而驰。

有关完整上下文，请参阅以下主题：https://news.ycombinator.com/item?id=26101608