一年多来,我一直是Linux Containers (LXC)的支持者.我的初始安装基于从在线教程中收集的信息,如this one和this one.这主要围绕lxc-create,lxc-start | stop和lxc-destroy命令并修改现有的OpenVZ templates.
这很好用,并且很乐意在生产中运行.但是,我提出了一些额外的系统,并决定检查Red Hat当前有关EL6容器的文档.我很惊讶地看到他们对此的正式立场.
在Does RHEL 6 provide LXC tools needed to use Linux Containers?,Red Hat将LXC描述为技术预览版和suggests using libvirt to manage create and manage containers.
然而,Oracle advocates a totally different containerization technique在其坚不可摧的Linux中.
在libvirt方法中似乎缺少一些功能,但我最初使用lxc- *命令的方法是一个手动过程…我无法确定什么是正确的或者在EL6上管理容器的“接受”方法.
>今天关于LXC和RHEL类系统的传统智慧是什么？
>您是如何在组织中实施的？
>一种方法与其他方法相比有什么优势吗？
>这些可以共存吗？
What’s the conventional wisdom regarding LXC and RHEL-like systems today?
就个人而言,我发现目前的设置有点缺乏. LXC似乎更加走在前列 – 当然更加坚持.
How are you implementing them?
在将其作为虚拟化选项提供方面,我不是.我发现当前的技术设置缺乏.
>没有用户名空间.
>某些挂载点不支持名称空间(cgroups,selinux)
> / proc中的值是误导性的系统全局变量,它们不考虑命名空间中的资源分区.
>打破审计.
我确实发现它非常适合应用程序级别的包含.我们直接使用命名空间和cgroup来包含某些用户运行的Web应用程序的网络和IPC资源.我们提供自己的界面来控制它.在RHEL7中,我正在考虑将此功能移至libvirt-lxc,因为libvirt的新版本支持用户ACL的概念.
对于完全初始化系统的虚拟化而言,我正在等待RHEL7提供的内容,但是老实说,我觉得一旦我们在RHEL7的后期次要版本发布时,我们可能只会看到一个足够好的解决方案.仅限于技术预览状态.
密切关注systemd-nspawn在接下来的18个月左右的时间告诉我它可能取而代之的是完全充满Linux的虚拟化的最佳工具,不管是系统作者明确表示它现在还不安全！如果libvirt最终丢弃了libvirt-lxc并且只提供了systemd-nspawn并且定义了systemd slice的包装器,我不会感到惊讶.
另外,要警惕过去6个月里关于将cgroup重新实现为内核程序员接口而不是文件系统接口(可能使用netlink或者其他东西,没有检查过)的问题,所以系统应该非常热在很快就能做到这一点的尾巴上.
Are there any advantages to one approach versus the other?
我认为LXC选项(不是libvirt-lxc)可以得到更好的维护.阅读了libvirt-lxc源代码后,感觉很仓促.传统的LXC肯定有更新的功能,经过更好的测试.两者都需要在其中运行的init系统具有一定程度的兼容性,但是我怀疑你会发现LXC比libvirt-lxc选项略微“交钥匙”,特别是在让发行版工作的时候.
Can these coexist?
当然,请记住,无论出于什么意图和目的,两者都在做同样的事情.组织命名空间,cgroup和挂载点.所有原语都由内核本身处理.两种lxc实现都提供了一种与可用内核选项接口的机制.
