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

我在Docker上使用不同的主机:RHEL7,SELS12和CentOS7,我发现在CentOS7上作为Docker主机运行的容器中有不同的行为,而在SLES12或RHEL7上运行的容器与Docker主机相比 .

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

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

have a permission 来解决路径中的符号:/ proc / 1
命令: ls -la /proc/1
enter image description here

启动容器命令:

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

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

get permission denied 使用相同的命令,您可以在上面的链接中看到 .
命令: ls -la /proc/1
enter image description here

其他信息:

依赖于Docker security documentation,容器默认以受限制的Linux内核功能集开始 .

其中一项功能是:CAP_SYS_PTARCE
默认情况下,任何Linux主机都存在此功能:

Linux机器中的示例:

enter image description here

但是在默认情况下,它在所有容器中都会丢失(除非使用--cap-add = sys_ptrace启动容器)

容器中的示例:
enter image description here
您可以在此处看到容器具有一组不受sys_ptrace功能限制的功能 .

因此,如果我使用RHEL中的--cap-add = sys_ptrace或SLES作为Docker主机启动容器,我会得到与CentOS 7中作为Docker主机相同的行为 .

示例:Docker主机:RHEL7
Docker图片:centos:最新(和以前一样)
Strat command: docker run -it --name=nessi_centos_test5 --cap-add=sys_ptrace centos:latest bash

enter image description here

enter image description here

正如你在这里看到的,为了获得与我在CentOS 7中获得的相同的行为,我需要使用额外的sys_ptrace功能启动我的容器 .

技术信息:

  • 不同的CentOS 7行为:在容器中运行命令:
    ls -la /proc/1
    结果:没有错误

  • 其他主机的常规行为(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

  • The different CentOS 7 behavior reproduced in:

[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 info
容器: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 Sync支持:true
延迟删除已启用:false
延迟删除已启用:false
延迟删除的设备数:0
数据循环文件:/ var / lib / docker / devicemapper / devicemapper / data
警告:强烈建议不要使用环回设备进行 生产环境 .
使用 --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)
记录驱动程序:json-file
Cgroup驱动程序:cgroupfs
插件:
卷:本地
网络:空主机桥
内核版本: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 Root目录:/ var / lib / docker
调试模式(客户端):false
调试模式(服务器):false
登记处:https://index.docker.io/v1/
警告:已禁用bridge-nf-call-iptables
警告:已禁用bridge-nf-call-ip6tables

Docker images:
CentOS的:最新
Ubuntu的:14.04

Also tested on:
Docker守护程序版本:1.10.2

  • The regular behavior of other hosts (RHEL7 and SLES12)

RHEL7 as Docker host:

[root @ localhost~]# uname -a
Linux localhost.localdomain 3.10.0-123.el7.x86_64#1 SMP Mon 5月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
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 Sync支持:true
延迟删除已启用:false
延迟删除已启用:假
延迟删除的设备数:0
数据循环文件:/ var / lib / docker / devicemapper / devicemapper / data
警告:强烈建议不要使用环回设备进行 生产环境 .
使用 --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)
记录驱动程序:json-file
Cgroup驱动程序:cgroupfs
插件:
卷:本地
网络:空主机桥
内核版本:3.10.0-123.el7.x86_64
操作系统:Red Hat Enterprise 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 Root目录:/ var / lib / docker
调试模式(客户端):false
调试模式(服务器):false
登记处:https://index.docker.io/v1/
警告:已禁用bridge-nf-call-iptables
警告:已禁用bridge-nf-call-ip6tables

Docker images:
CentOS的:最新
CentOS的:7
Ubuntu的:14.04
Ubuntu的:最新
RHEL:最新
suse / sles12:latest(在SLES机器上构建映像并复制到RHEL)

Also tested on:
Docker守护程序版本:1.10.3 . 1.9

SLES12 as Docker host:

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
构建版本:Btrfs v3.18.2 20150430
图书馆版本:101
执行驱动程序:native-0.2
记录驱动程序:json-file
插件:
卷:本地
网络:桥接空主机
内核版本:3.12.28-4-default
操作系统: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 images:
CentOS的:最新
CentOS的:7
Ubuntu的:14.04
Ubuntu的:最新
SUSE / sles12:最新

Does anyone understand why CentOS as a Docker host causes different container behavior (ls –la /proc/1 in the container - no error) compared to any other host OS (ls –la /proc/1 in the container - with permission denied errors)?

回答(1)

3 years ago

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

解决问题的步骤(与RHEL相关的Docker主机):
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.重新启动我的机器,现在我可以解决容器内/ proc / 1下的符号链接 .