与任何其他主机操作系统相比，CentOS作为Docker主机会导致不同的容器行为

我在不同的主机上使用Docker：RHEL7，SELS12和CentOS7，并且发现在CentOS7上作为Docker Host运行的容器中的不同行为，与在SLES12或RHEL7上作为Docker主机运行的容器相比。

不同的行为与Docker容器中的常见问题有关： https ： //github.com/docker/docker/issues/7147
https://github.com/docker/docker/issues/6800

在CentOS7作为Docker主机的容器中：

我有权限parsingpath中的符号：/ proc / 1
命令： ls -la /proc/1

启动容器的命令：

 docker run -it --name=nessi_centos_test centos:latest bash 

但是，在SLES12或RHEL7作为Docker主机的容器中：

我在上面的链接中看到了使用相同的命令拒绝了权限 。
命令： ls -la /proc/1

附加信息：

依靠Docker安全性文档 ，默认情况下容器是以受限制的Linux内核function开始的。

其中一个function是：CAP_SYS_PTARCE
这个function默认存在于任何Linux主机中：

在Linux机器上的例子：

但是在所有的容器中默认都是缺less的（除非你使用–cap-add = sys_ptrace启动容器）

容器中的示例： 您可以在此看到容器具有一组受限制的function，不包括sys_ptracefunction。

因此，如果我在RHEL或SLES中使用–cap-add = sys_ptrace作为Docker主机启动容器，则获得与作为Docker主机在CentOS 7中相同的行为。

示例：Docker主机：RHEL7
Docker镜像：centos：最新（与之前一样）
Strat command: docker run -it --name=nessi_centos_test5 --cap-add=sys_ptrace centos:latest bash

正如你在这里所看到的，为了获得和我在CentOS 7中一样的行为，我需要启动我的容器，并具有额外的sys_ptracefunction。

技术信息：

1. 不同的CentOS 7行为：在容器中运行命令：
   ls -la /proc/1
   结果：没有错误
2. 其他主机（RHEL7和SLES12）的常规行为在容器中运行命令：
   ls -la /proc/1
   结果：

ls: cannot read symbolic link /proc/1/cwd: Permission denied ls: cannot read symbolic link /proc/1/root: Permission denied ls: cannot read symbolic link /proc/1/exe: Permission denied

1. 不同的CentOS 7行为转载于：
   

[root @ localhost桌面] ＃uname -a
Linux localhost.localdomain 3.10.0-327.22.2.el7.x86_64＃1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

[root @ localhost桌面]＃ docker信息
容器：1
运行：0
暂停：0
停止：1
图片：1
服务器版本：1.11.2
存储驱动程序：devicemapper
游泳池名称：docker-253：0-136686025-pool
Pool Blocksize：65.54 kB
基本设备大小：10.74 GB
备份文件系统：xfs
数据文件：/ dev / loop0
元数据文件：/ dev / loop1
使用的数据空间：324.3 MB
数据空间总计：107.4 GB
数据空间可用：35.43 GB
元数据使用空间：847.9 kB
元数据空间总计：2.147 GB
元数据空间可用：2.147 GB
支持Udev同步：true
推迟删除已启用：false
延迟删除启用：false
推迟删除的设备数量：0
数据循环文件：/ var / lib / docker / devicemapper / devicemapper / data
警告：强烈build议在生产中使用回送设备。
请使用--storage-opt dm.thinpooldev或使用--storage-opt <br>dm.no_warn_on_loop_devices=true来取消此警告。
元数据循环文件：/ var / lib / docker / devicemapper / devicemapper / metadata
资料库版本：1.02.107-RHEL7（2016-06-09）
logging驱动程序：json文件
Cgroup驱动程序：cgroupfs
插件：
卷：本地
networking：空主机桥
内核版本：3.10.0-327.22.2.el7.x86_64
操作系统：CentOS Linux 7（核心）
OSType：linux
架构：x86_64
CPU：1
总内存：993.3 MiB
名称：localhost.localdomain
ID：BPVJ：YDPR：4VUO：WNBN：DVZH：7MEH：TPMP：Y3MP：GMN7：UT36：LQ74：GJ4N
Docker根目录：/ var / lib / docker
debugging模式（客户端）：false
debugging模式（服务器）：false
registry： https ： //index.docker.io/v1/
警告：bridge-nf-call-iptables被禁用
警告：bridge-nf-call-ip6tables被禁用

Docker镜像：
CentOS的：最新
Ubuntu的：14.04

还testing了：
Docker守护进程版本：1.10.2

2. 其他主机（RHEL7和SLES12）的正常行为

   RHEL7作为Docker主机：

   [root @ localhost〜] ＃uname -a
   Linux localhost.localdomain 3.10.0-123.el7.x86_64＃1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU / Linux

   [root @ localhost〜] ＃docker info
   集装箱：14
   运行：6
   暂停：0
   停止：8
   图片：22
   服务器版本：1.11.2
   存储驱动程序：devicemapper
   游泳池名称：docker-253：0-67168288池
   Pool Blocksize：65.54 kB
   基本设备大小：10.74 GB
   备份文件系统：xfs
   数据文件：/ dev / loop0
   元数据文件：/ dev / loop1
   使用的数据空间：9.66 GB
   数据空间总计：107.4 GB
   数据空间可用：16.27 GB
   使用的元数据空间：7.68 MB
   元数据空间总计：2.147 GB
   元数据空间可用：2.14 GB
   支持Udev同步：true
   推迟删除已启用：false
   延迟删除启用：false
   推迟删除的设备数量：0
   数据循环文件：/ var / lib / docker / devicemapper / devicemapper / data
   警告：强烈build议在生产中使用回送设备。
   请使用--storage-opt dm.thinpooldev或使用--storage-opt dm.no_warn_on_loop_devices=true来禁止此警告。
   元数据循环文件：/ var / lib / docker / devicemapper / devicemapper / metadata
   资料库版本：1.02.107-RHEL7（2015-12-01）
   logging驱动程序：json文件
   Cgroup驱动程序：cgroupfs
   插件：
   卷：本地
   networking：空主机桥
   内核版本：3.10.0-123.el7.x86_64
   操作系统：红帽企业Linux
   OSType：linux
   架构：x86_64
   CPU：2
   总内存：1.798 GiB
   名称：localhost.localdomain
   ID：VL2V：RUOZ：U55X：OCEQ：MAS6：MXYV：CKUY：WJQY：3KH3：LWPW：LUYH：E3MM
   Docker根目录：/ var / lib / docker
   debugging模式（客户端）：false
   debugging模式（服务器）：false
   registry： https ： //index.docker.io/v1/
   警告：bridge-nf-call-iptables被禁用
   警告：bridge-nf-call-ip6tables被禁用

   Docker镜像：
   CentOS的：最新
   CentOS的：7
   Ubuntu的：14.04
   Ubuntu的：最新
   RHEL：最新
   suse / sles12：latest（在SLES机器上构build映像并将其复制到RHEL）

   还testing了：
   Docker守护进程版本：1.10.3。 1.9

   SLES12作为Docker主机：

linux-ojix：〜＃ uname -a
Linux linux-ojix 3.12.28-4-default＃1 SMP Thu Sep 25 17:02:34 UTC 2014（9879bd4）x86_64 x86_64 x86_64 GNU / Linux

linux-ojix：〜＃docker info
容器：6
运行：3
暂停：0
停止：3
图片：10
服务器版本：1.10.3

存储驱动程序：btrfs
构build版本：Btrfs v3.18.2 + 20150430
库版本：101
执行驱动程序：native-0.2
logging驱动程序：json文件
插件：
卷：本地
networking：网桥null主机
内核版本：3.12.28-4-默认
操作系统：SUSE Linux Enterprise Server 12
OSType：linux
架构：x86_64
CPU：2
总内存：1.853 GiB
名称：linux-ojix
ID：NU4F：MOFR：RTUA：F2OM：4G67：NMGV：76S6：BONN：ASD5：XGHF：KVJQ：N242
警告：不支持交换限制

Docker镜像：
CentOS的：最新
CentOS的：7
Ubuntu的：14.04
Ubuntu的：最新
SUSE / sles12：最新

有没有人明白为什么CentOS作为一个Docker主机导致不同的容器行为（容器中的ls -la / proc / 1 – 没有错误）与任何其他主机操作系统相比（容器中的ls -la / proc / 1） ）？

Answer 1

问题解决了，非常感谢:)

解决问题的步骤（与作为Docker主机的RHEL相关）：
1.我从rhel-7-server-extras-rpms安装了Docker版本：docker-1.10.3-44
2.将我的内核从3.10.0-229.el7.x86_64升级到kernel-3.10.0-327.18.2.el7.x86_64。
3.重新启动我的机器，现在我可以parsing容器内/ proc / 1下的符号链接。