我在我的testing环境中运行了Docker中的chromedriver + chrome。
一切工作正常，直到最新的CoreOS升级。
这些是似乎工作的版本：
VERSION=1185.5.0 VERSION_ID=1185.5.0 BUILD_ID=2016-12-07-0937 这是一个更新的版本，导致铬coredump：
VERSION=1235.4.0 VERSION_ID=1235.4.0 BUILD_ID=2017-01-04-0450
看着变化，似乎docker从1.11.x升级到1.12.x，这打破了容器内的setns()调用。 Chrome使用setns()来创build名称空间。
这是示例输出：
jsosic-coreos-test-20161207 ~ # docker --version Docker version 1.11.2, build bac3bae
从这个盒子的一个容器里面：
[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome [57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:
这是新版本如何打破它的：
jsosic-coreos-test-2017-01-04 ~ # docker --version Docker version 1.12.3, build 34a2ead [root@13ab34c36c82 /]# /opt/google/chrome/chrome Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted Aborted (core dumped)
我发现的是，如果我用--cap-add=SYS_ADMIN或--privileged启动容器 – Chrome按预期工作。
这两个交换机有什么区别？ 哪些function是由 – --privileged启用的？
而且，我可以允许setns()在容器内而不危及安全性吗？
AFAICS，文档build议授予容器所需的function，而不是使用--privileged开关。 在特权模式下运行似乎授予 容器的所有function （确切地说，那些在第一个URL中列出，只要文档是最新的）。
总之，我会说--cap-add=SYS_ADMIN赋予容器更小的function子集，与--privileged开关相比。 事件Docker文档中的示例（第一个URL）似乎更喜欢只在需要时添加SYS_ADMIN或NET_ADMINfunction。