1月 102018
 

把下面脚本当做容器的init进程:

 

知识点:

  1. while循环中修改外部的环境变量,则 不能使用管道的方式给while提供数据,这样的话,while 就是在新的子shell中执行的,不会影响到当前shell,所以:
    1. 使用了标准输入的重定向
    2. 使用了 <($cmd) 的方式
  2. 为了让字符串中连续的空格被保留,参数传递时多要通过双引号引上,即使是 $(cmd) 产生的字符串也要整个用双引号引上,当然,此时的双引号比较特殊,因为此时的双引号可以套双引号而不需要转义,示例: (注意下面几种双引号中嵌套单引号的的区别)

 

注意:

  1. 这个init进程是bash做的,如果docker attach的话,不管是ctrl-d退出还是ctrl-c退出,都会导致init进程终止,容器退出
  2. 脚本中的while循环最初想到的是通过sleep实现暂停的,但是考虑到sleep会产生一个额外的进程,不好看,于是选择了read
 Posted by at 上午 10:57

docker on openstack

 docker, openstack  docker on openstack已关闭评论
12月 142017
 

场景,用docker做开发用的虚拟机,每个docker都有一个可以公开访问的IP地址。

由于docker和宿主机共享内核,一不小心可能会把整个宿主机搞挂,而且,docker热迁移也是个难题,所以,尽管openstack马上可以支持docker,我也不想让docker直接部署在计算节点;我的思路是,将docker部署在openstack管理的kvm虚拟机上,这样还能通过热迁移kvm的方式将容器迁移到别的计算节点。

 

注意事项:

  1. 关闭openstack的端口安全
  2. 热迁移后容器的IP地址在交换机上的mac地址与端口的映射不能及时更新
    1. 如果容器频繁地和外部通信的话,mac地址与端口的映射会被及时刷新
    2. 如果没能及时刷新的话,可以在与容器IP同网段的机器上,先clear一下arp缓存,在ping 一下容器IP,就可以了;
    3. 如何自动处理呢?在kvm虚拟机上(就是容器的宿主机上),docker exec到容器内部,然后ping一下网关就行。
 Posted by at 下午 2:01

变化的mac地址

 docker, openstack  变化的mac地址已关闭评论
11月 212017
 

 

一个bridge诞生时,会有一个mac地址;当向bridge上addif  veth2时,bridge的mac地址就跟随了veth2的mac地址,难道br0就不能固定一个mac地址吗?

可以的:

默认情况下,bridge总是跟随port中mac地址最小的那个port的mac地址,如果不想让mac地址总是变化,则可以设置bridge的首选mac地址,方法就是显式地给bridge设置mac地址:

参考:

http://blog.csdn.net/fanwenbo/article/details/2131193

 Posted by at 下午 2:58

创建新的名字空间

 docker  创建新的名字空间已关闭评论
10月 202017
 

功能: 创建新的名字空间,并使得进程处于sleep状态,可以随时nsenter进来

测试 mnt 时发现,似乎并没有实现mount的隔离; 测试方法:

./new-namespace -m &

然后使用nsenter,分别在名字空间内外查看 /proc/self/mountinfo 的内容,发现如何操作,内外都是一致的。

注意: 需要和pid名字空间一起使用

 

参考: https://www.toptal.com/linux/separation-anxiety-isolating-your-system-with-linux-namespaces

 Posted by at 下午 12:08

docker 之 exec失败的问题

 docker  docker 之 exec失败的问题已关闭评论
10月 122017
 

现象:

乍一看, /proc/self/exe 文件找不见?

一般来讲,文件找不见并不奇怪,怪就怪在是 /proc/self/exe 找不见就不太应该了;

因为docker exec 最终是由libcontainerd进程来出来的,strace跟进发现,是chdir到 /root/data1/docker/devicemapper/mnt/4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc/rootfs 时,找不到目标目录导致的,于是我就迅速地看了一下,该目录确实不存在,但是对于正常的能够exec的容器来讲,相应的rootfs目录也是不存在的

思考中。。。

docker玩的就是名字空间和cgroup,所以不能不想到这些;libcontainerd也有自己的(mnt)名字空间,我们进入libcontainerd进程的文件系统就可以查看到上面目录的存在了,而且,正常的容器存在相应的目录,异常的容器不存在相应的目录;

通过mount命令可以发现mount的规律,从容器的config.json (/var/run/docker/libcontainerd/c6176f37c4b67b03d4187edef6d1131cd44ab80bd0f0c20b24a7a20056967652/config.json) 中查看到对应的mount的位置,通过nsenter进入libcontainerd的mnt名字空间手动mount上去就好了,如下:

那么该mount点是如何丢掉的呢?重启dockerd能否自动修复该问题呢?稍后再研究

 Posted by at 下午 6:34

cgroup 审计策略

 docker, Linux & Unix  cgroup 审计策略已关闭评论
9月 072017
 

内存子系统

场景:

当你把一个已经占用了1GB内存的进程转移到一个新的cgroup后,新的cgroup看到的该进程使用的内存大小会是多少呢?

memory.max_usage_in_bytes  和 memory.usage_in_bytes 都不会将这1GB计算在内的,只有该进程继续申请内存才会计算新申请的内存。

同样,如果把一个占用内存很多的进程从cgroup中移出来,memory.max_usage_in_bytes  和 memory.usage_in_bytes 应该也不会被更新

Process Number Controller

  1.  pids.current 可以大于 pids.max
    1. 当cgroup中进程数量达到最大时,cgroup并不“阻止”从其它cgroup中移动一个进程到该cgroup中;只是说不允许在该cgroup中fork、clone新的进程或线程
  2. pids.current包含所有子孙cgroup中的进程(和线程)
  3. 当cgroup对进程数量不限制时,pids.max 不是0(零)也不是-1,而是字符串max😓
 Posted by at 下午 6:33

docker 之磁盘限额

 docker, Linux & Unix  docker 之磁盘限额已关闭评论
9月 062017
 

docker-ce-17.07.0 版本开始支持overlay2的磁盘配额,该版本 8月29号release了,现在可以使用edge版本:

https://download.docker.com/linux/centos/7/x86_64/edge/Packages/docker-ce-17.07.0.ce-1.el7.centos.x86_64.rpm

 

overlay2的配额限制是有条件的:

  1. 基于xfs文件系统(如果不开启配额的话,ext4上也能支持,如果内核版本够高的话,btrfs也能支持)
  2. xfs文件系统挂载时使用pquota选项(pquota和gquota 不能同时出现)
  3. xfs 格式化时需要ftype=1,用于enable d_type

 

xfs的pquota是个啥东西: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/xfsquota.html

 

XFS quotas are enabled at mount time, with specific mount options. Each mount option can also be specified as noenforce; this will allow usage reporting without enforcing any limits. Valid quota mount options are:
  • uquota/uqnoenforce – User quotas
  • gquota/gqnoenforce – Group quotas
  • pquota/pqnoenforce – Project quota

注意:

pquota和gquota 不能同时出现

  • uquota: 强制限制,绝对不能超限
  • uqnoenforce:可以超限,但是会贴罚单

 

如果是kickstart 安装的系统,用如下命令:


mkfs.xfs 还有很多选项,专门研究存储的话,还是要了解的

参考: http://foxhound.blog.51cto.com/1167932/1841487

docker-ce-17.07.0 关于xfs上的overlay2存储驱动的磁盘限额,使用效果如下:

注意:

  1. –storage-opt时, 使用的是size,而不是overlay2.size;关键是多处文档描述的都是overlay2.size=1g,而实际上却不识别overlay2.size,识别的却是size
  2. 做磁盘限额的时候,基础镜像的大小显然没有计算在内; 不做磁盘限额的时候,显示的是整个overlay文件系统的使用情况
  3. 据说daemon.json 中也是可以定义存储选项的,但是测试发现不管使用overlay2.size还是size都不报错,也都不生效(但是源码上确实都是overlay2.size呢)
  4. docker info中不显示默认的存储配额
  5. 关于存储选项: overlay2.override_kernel_check, 文档 要求必须设置为true,实际情况是:
    1. 如果设置为true,docker会帮忙检查内核版本够不够高,不够高就直接报错了
    2. 如果设置为false,docker依然会帮忙检查内核版本够不够高,不够包就记录一个警告日志

阿里云提供的centos7镜像的文件系统类型似乎都是ext4的

并非所有的D状态的进程都是kill不掉的:

docker 的磁盘限额是可以通过xfs_quota 查看到的(kernel内核版本要求4.6以上才能查看到,小于4.6的内核版本上不是不支持限额,只是通过xfs_quota 看不到而已)

 

 Posted by at 下午 2:16

docker之username space

 docker, Linux & Unix  docker之username space已关闭评论
9月 062017
 

usernamespace在docker中的用法:

  1. docker 中可以通过dockerd的 –userns-remap=$username 选项来指定用户映射,从文档上来看,该选项只能使用一次,也就是说,只能指定一个用户
  2. docker 参考的用户映射关系文件为 /etc/subuid  和 /etc/subgid ,文件格式大约为:

    其中:
    bozo: 是–userns-remap 指定的用户名
    100000:65536   以为着该用户可以映射到的容器外部的uid的范围为 100000 ~ (100000 + 65536)
  3. 目前来看,不同容器中相同用户映射到容器外面的uid是相同的
  4. docker文档 要求需要映射的用户必须在容器外面是真实存在的,至少在 /etc/passwd 中是需要存在的; 从uid映射来看,/etc/passwd 中定义的uid基本是被无视的
  5. 通过–userns-remap伪造的容器内部的root用户,虽然在容器外部就是个普通用户,但是在容器内部确实是有很大的特权的
  6. docker create的 –user选项和usernamespace没有关系,只是说用哪个用户启动容器内部的进程而已
  7. 参考: https://github.com/docker/labs/tree/master/security/userns

从上面分析来看,userns-remap使用起来是比较麻烦的、且功能太有限; 我们期望不需要太多配置的情况下,不同容器中所有进程、子进程的用户都能自动映射到外部单独的uid,可能实现这个确实比较麻烦(参考下面原理部分)

 

username space原理:

  1. User Namespace是Linux 3.8新增的一种namespace
  2. clone系统调用CLONE_NEWUSER
  3. /proc/$pid/uid_map  (对于支持user namespace的内核,都存在该文件,不明确设置就为空)
  4. 当我们通过CLONE_NEWUSER去clone一个进程(或线程)的话,进程的后续行为都会参考 /proc/$pid/uid_map 来决定用户的身份,那么该uid_map 文件必然要在clone之后才能写入了;为了避免我们clone出来的那个进程很快执行到用户代码而实现提权,则往往在clone后执行的是可控的代码,在准备工作完成后在execv()去执行用户的进程(注意: execv并不改变进程号,或者说不产生新的进程,而是在当前进程空间来执行用户的代码),用户代码中很可能会继续clone,那么后续的clone如果没有CLONE_NEWUSER的话,能否参考到上面的/proc/$pid/uid_map 呢?或者说,只参考该pid namespace中init进程下面的uid_map ? (稍后继续研究)
  5. http://man7.org/linux/man-pages/man7/user_namespaces.7.html

看个例子:

 

实际问题:

在没有使用–userns-map的情况下,很多容器都使用相同的镜像(所以,相同用户名的uid基本都一样),每个容器都可以通过容器中的sshd进行登录,sshd登录后都会有相应的limits限制,以单个用户最大进程数量为例,一般来讲,root都是没有限制的,其他用户都是有限制的,对于mysql用户,通常会产生很多线程,从容器的角度来看,该用户名下的进程数量确实不多,甚至整个容器都没有几个进程,这时候,启动mysql时却是失败的;原因在于:

  1. 启动进程这事儿归根结底还是内核干的
  2. ulimit资源限制最终是从进程属性上生效的,而不是直接从配置文件上生效的
  3. 容器外部和容器内部看到的uid是相同的
  4. 其他容器已经在没有ulimit限制(或者配额足够)的情况下启动了很多mysql进程(或线程)了
  5. 最后,在ulimit限制比较小的情况下启动mysql进程(或线程)自然就会失败的
  6. 所以,从用户级别的资源限制方面来讲,容器之间的相互影响是比较难以控制的
  7. docker本来不是让作为虚拟机使用的,所以,类似问题是不会被docker官方在意(和觉察)的,docker中的–userns-map 仅仅考虑了通常情况下单个容器中只有单个(被docker-containerd启动)的进程的场景
  8. 解决办法: 给用户足够的资源
  9. 我们可以限制单个容器的进程数量:
    1. https://segmentfault.com/a/1190000007468509   https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
    2. 通过docker create 的 –pids-limit 选项进行配置
  10. dockerd 启动选项 –default-ulimit 可以设置默认的ulimit
  11. 目前,我们生产环境使用的docker容器都是通过docker exec 启动进程的,docker exec 进去后,ulimit如下:

     

问题:

  1. 如何从容器级别限制进程数量?

参考资料:

 Posted by at 上午 10:52

关于容器oom

 docker  关于容器oom已关闭评论
9月 052017
 

缘起:

偶尔有同学反应容器很慢,查看容器状态发现内存没用完了;问题是,oom命名是开启的,为什么不杀进程呢?

其实,我忽略了一个问题,为了不必要的内存浪费,我给每个容器都配备了相当多的swap,oom是发生在连swap都被用完的情况下的;上面的情况是:内存用完了,但是swap还足够,开始大量使用swap,于是乎,反应就很慢;不仅如此,swap引发的设备IO,是不受单个容器的IO配额限制的,在没有控制的情况下疯狂使用swap会导致其他容器也会变慢

结论:

容器之间的资源隔离是相对的,总是会有某些情况下,容器之间会相互影响的;有些场景下,这些问题都无所谓,有些情况下就是致命的

 Posted by at 上午 10:40