试图保持在 Red Hat 的良好声誉并规划系统长寿是件棘手的事......
我一直是Linux 容器（LXC）一年多来。我最初的安装是基于从在线教程中收集的信息，比如这个和这个. 这主要围绕lxc-create、lxc-start|stop和lxc-destroy命令以及修改现有的OpenVZ 模板。
效果很好，在生产环境中运行良好。但是，我正在启动一些其他系统，并决定查看 Red Hat 当前关于 EL6 中容器的文档。我很惊讶地看到他们对此的官方立场。
在RHEL 6 是否提供使用 Linux 容器所需的 LXC 工具？，Red Hat 将 LXC 描述为技术预览和建议使用 libvirt 来管理、创建和管理容器。
然而 Oracle提倡一种完全不同的容器化技术在其《坚不可摧的 Linux》中。
libvirt 方法中似乎缺少一些功能，但我最初使用 lxc-* 命令的方法有点像手动过程......我无法完全分辨什么是正确的或在 EL6 上管理容器的“可接受”方法。
- 目前关于 LXC 和 RHEL 类系统的传统观点是什么？
- 怎样你在您的组织中实施它们吗？
- 相对于其他方法，一种方法有什么优势吗？
- 这些可以共存吗？
答案1
目前关于 LXC 和 RHEL 类系统的传统观点是什么？
就我个人而言，我发现当前的设置有些不足。LXC 似乎更处于前沿 - 当然维护得更好。
您如何实施它们？
就提供虚拟化选项而言，我不会这么做。我发现当前的技术设置存在不足。
- 没有用户名命名空间。
- 某些挂载点不了解命名空间（cgroups、selinux）
- /proc 中的值是误导性的系统全局变量，没有考虑到命名空间中的资源分区。
- 中断审计。
不过，我确实发现它确实是一个很棒的应用程序级遏制工具。我们直接使用命名空间和 cgroup 来遏制某些用户运行的 Web 应用程序的网络和 IPC 资源。我们提供自己的界面来控制它。在 RHEL7 中，我正在考虑将此功能移至，因为libvirt-lxc较新的修订版libvirt支持用户 ACL 的概念。
对于完全初始化系统的虚拟化，我正在等待 RHEL7 中提供的功能，但老实说，我觉得我们可能只有在 RHEL7 的后续小版本中才能看到足够好的解决方案，然后可能只是处于技术预览状态。
留意systemd-nspawn一些事情，我被告知在未来 18 个月左右它可能会取代它成为实现完全 Linux 虚拟化的最佳工具，尽管 systemd 作者明确表示它现在不安全！如果libvirt它最终被放弃，并且只提供了一个带有已定义的 systemd 切片的libvirt-lxc包装器，我不会感到惊讶。systemd-nspawn
另外，请注意，过去 6 个月中有很多关于将 cgroups 重新实现为内核程序员接口而不是文件系统接口的讨论（也许使用 netlink 或其他东西，还没有检查），因此 systemd 应该非常热衷于快速完成这项工作。
相对于另一种方法，一种方法有什么优势吗？
我认为 LXC 选项（不是 libvirt-lxc）维护得更好。读过libvirt-lxc源代码后，感觉有点仓促。传统 LXC 当然有经过更好测试的新功能。两者都需要在其中运行的 init 系统具有一定程度的兼容性，但我认为您会发现 LXC 比该选项稍微“交钥匙”一些，libvirt-lxc特别是在让发行版在其中工作方面。
这些可以共存吗？
当然，请记住，无论出于何种目的，两者都在做同样的事情。组织命名空间、cgroup 和挂载点。所有原语都由内核本身处理。这两种lxc实现都只是提供了一种与可用内核选项交互的机制。
答案2
Red Hat 正在制作巨大的推动集装箱化。他们正在开发一款全新的产品，Red Hat Enterprise Linux 原子主机， 周围。
如果想采用不那么激进的方法，可以看看他们的 RHEL7 beta资源管理和 Linux 容器指南；您会注意到它推送了 libvirt-lxc 但没有提及 lxc 工具。