我试图在redhat中设置容器。容器还应该运行与host相同的redhat版本。在探索这些时,我遇到了virsh和docker。 Virsh支持基于主机的容器,并与主机共享用户空间。在这里,我对用户空间感到困惑。无论是文件系统空间还是其他东西。任何人都可以澄清这个吗?此外,在哪些场景/情况下,可以使用virsh(基于主机的容器),以便我可以得出结论是否更好地使用virsh或docker。在我的情况下,我需要在redhat主机中设置一个redhat容器,并在每个容器中运行相同进程的多个实例。容器应该在不使用网络接口的情况下相互交换数据。
答案 0 :(得分:1)
这应该有助于澄清:http://rhelblog.redhat.com/2015/07/29/architecting-containers-part-1-user-space-vs-kernel-space/
听起来你真的想用Docker和-v bind挂载来共享数据。这是未来的一篇文章: - )
答案 1 :(得分:0)
当前内核尚不支持用户命名空间。 这是当前容器化解决方案的已知限制。不幸的是,usernamespace是在最新的内核版本中实现的(从内核3.8开始)http://kernelnewbies.org/Linux_3.8虽然在许多主流发行版中尚未启用。
这是容器当前最强的限制之一,如果你是容器中的root(ID 1),那么你就是操作容器的机器的root。
这是影响任何基于LXC的产品的问题,尽管有很强的解决方法。这实际上是一件必需的事情!
替代方案是选择严格的Selinux监管或与弱势用户帐户合作,并为每个容器分配不同的用户。
来自Libvirt文档https://libvirt.org/drvlxc.html:
用户和组隔离 如果guest虚拟机配置未列出任何ID映射,则容器内使用的用户和组ID将与容器外使用的用户和组ID匹配。此外,与容器中的进程关联的功能将推断出它们对主机中的进程具有的相同权限。这对安全性有明显的影响,因为容器内的root用户将能够访问容器可见的root拥有的任何文件,并执行或多或少的任何特权内核操作。在没有sVirt的额外保护的情况下,这意味着容器内的root用户实际上与主机中的root用户一样强大。 root用户没有安全隔离。
引入了ID映射工具,以允许更严格地控制容器内用户的权限。它允许应用程序定义规则,例如“容器中的用户ID 0映射到主机中的用户ID 1000”。此外,与功能相关的权限也有所降低,因此它们不能用于从容器环境中逃脱。用户命名空间的完整描述超出了本文档的范围,但LWN对该主题有很好的描述。从libvirt的角度来看,要记住的关键是在容器XML配置中为用户和组定义ID映射会导致libvirt激活用户命名空间功能。