深刻理解Docker ulimit

深刻理解Docker ulimit

【编者的话】Docker大规模应用后，若是你没踩过坑，说出去确定没人信。昨天就遇到一个ulimit的经典问题：业务Container内ulimit值过小，致使启动失败。ulimit问题，老生常谈，可是在不一样的场景与环境，表现出来的灵异，每每须要一些深刻的分析才能找到本因。本次问题就与OS版本，Docker版本及配置方法息息相关，咱们来回顾一下。

问题

1. 背景

微博平台业务通过去年三节Docker化后，已稳定运行半年多了，因为采用的都是较保守的版本，虽然也踩过不少坑，但都在可控内。最近正与RD一块儿推动一个大项目，前提也是平台业务全Docker化，这部分已完成90%了。其基本信息以下：
1）OS版本：CentOS 6.5
2）JDK: 1.7.0_25 Tomcat: 7.0.42
3）Docker：1.3.2
4）Docker Registry：1.0
其中：正在也推动升级OS到CentOS 7，Docker到1.6.2。

2. 现象

本次出现的问题现象：当人工重启服务器后，再启动业务Container，发现启动失败，而且可以重现。

PS: 用运维系统作部署时并未发现此问题。
 

3. 重现

重现的主要条件为：
1）版本：OS（CentOS 6.5），Docker 1.3.2，Docker Daemon随开机启动而启动。
2）主机配置：ulimit设置为200000，配置在/etc/profile。
3）操做：手工reboot机器后，登陆，启动业务容器，启动起来后，一会就失败。

4. 分析

1）服务器重启，此过程正常。
2）业务Container启动后不久失败，经分析为容器内ulimit不对，只得到默认的值：1024。后面会讲这个值为何是1024。
3）重启Docker Daemon进程，再启动Container，发现一切正常。经查看容器内ulimit值为：主机设置的200000。

现象搞清楚后，且能重现，解决问题就很简单了，方法不少。后面细说。

5. 总结

一句话总结，当服务器重启后，Docker Daemon随之系统启动而启动，当启动Container时，因未获取到主机设置的ulimit值而致使启动后一下子就失败了，重启Docker Deamon后解决（PS：这不是解决问题的方法，这只是瞎猫撞到死耗子）。

经典理论之ulimit

关于ulimit问题，我相信只要是作过SA，或者玩过服务器的RD都应该遇到过，各类现象，其理论依据其实很简单，你们能够参考@淘宝褚霸 博客的文章，有4篇，足够细致了。2013年时，我问过他一个问题，他还从源码角度去分析了，这种分享精神棒棒哒。这里就再也不展开说了。

经典理论之Linux系统启动与环境变量加载顺序

1. Linux系统启动

这里就直接说CentOS（Redhat类）的启动过程：你们都知道目前Linux系统启动最经常使用的就是两种：init（SysVinit系）与Systemd系两大阵营，两者的对比能够参考此文。Systemd主要是CentOS 7及以后的版本采用，而以前的发行版均采用SysVinit系，而咱们此次出现问题的是CentOS 6.5，也就是SysVinit系。下面来看下它的启动过程，参考图以下：

具体过程：
1）加载BIOS的硬件信息，执行BIOS内置程序。
2）读取MBR（Master Boot Record）中Boot Loader中的引导信息。
3）加载内核Kernel boot到内存中。
4）内核开始执行/sbin/init，并加载/etc/inittab，执行rc.sysinit进行初始化。
5）启动核心的外挂模块/etc/modules.conf。
6）按照启动级别（服务器默认是3）执行/etc/rc.d/下运行脚本。即：

[guansheng@xx-xx-xx-yf-core rc3.d]# pwd
/etc/rc.d/rc3.d/

这个过程会把chkconfig --list中看到3级下on的服务所有启起来。
7）执行/bin/login程序。

到这里，你就能够看到登陆的tty窗口了。

2. Linux环境变量加载顺序

对于环境变量加载顺序，各发行版本大同小异，这里也只说RedHat系的，其大体顺序以下：

--> /etc/profile     #全局环境变量，每一个用户第一次登陆时设置
-------->~/.bash_profile #用户级环境变量，每一个用户第一次登陆时设置
-------->~/.bash_login
-------->~/.profile 
-->~/.bashrc   #用户级环境变量，每一个用户登陆时设置，打开新Shell时也设置
-->/etc/bashrc
-->~/.bash_logout #用户级环境变量，退出时执行

规则：后面的配置文件继续前面的变量及shell设置，相同的被覆盖。

3. 理论参考之Docker ulimit

Docker在1.6版本及以后，才支持ulimit相关选项，看GitHub上，应该是有人提了PR，后来官方才支持的。 在1.6版本以前，Docker Container继承自Docker Daemon的ulimit设置。 参考文章见Docker blog 之ulimit部分。

问题复盘

通过以上详细介绍及理论引导，其实对于问题复盘就很简单了，咱们简要过一下重点：

1，因为咱们人工重启服务器后，根据上面的启动过程可知，Docker Daemon在系统启动时已经起来了，此时在用户未登陆的状况下，并不会读取咱们设置的/etc/profile下的ulimit配置，因此Docker Daemon会以1024的值进行进程的启动。

2，那么后续建立的Container因为Docker版本为1.3.2，是继续自Docker Daemon的值，而形成在Container只能看到1024的ulimit值，而业务上依赖大量的mc、mcq、Redis、MySQL及HTTP等，天然1024不够用，而启动失败。

3，当用户登陆后，重启Docker Daemon后，进程天然会能读取到该用户的环境变量，从而使ulimit设置为200000。以后再启动Container就再无问题了。

PS：复盘很简单吧，不过不理解上述原理，不少人仍是一头雾水，至少我见到是这样。
 

新问题

探讨CentOS 7下的ulimit

1. 问题描述

当OS为CentOS 6.5，Docker为1.3.2版本状况下的问题理清后，想试试7，因而在7下依然部署了Docker 1.3.2，并进行测试，新问题来了，当主机（Host）上未进行设置时（即为默认1024），启动Container，发现Container内的ulimit是1048576。修改主机的ulimit，再重启Docker Daemon，启动Container，Container内仍是1048576，好奇怪。

2. 分析

通过与同事一块儿看了下Docker源码，Daemon启动那部分，一会儿就明朗了。能够看到，Docker Daemon针对不一样的系统版本，其对ulimit的默认值设置大有差异。

1）CentOS 7 采用Systemd进行系统初始化，自动会调用Systemd下的启动脚本docker.service，其申明默认值以下：

[Service]
         ExecStart=/usr/bin/docker -d -H fd://
         MountFlags=slave
         LimitNOFILE=1048576
         LimitNPROC=1048576
         LimitCORE=infinity

2）CentOS 6的话，Docker Daemon启动，并未设置默认值。参考：sysvinit-redhat。
3）而对于Debian类的系统，尽然也设置了默认值为：1048576。参考。

Docker 1.6版本对ulimit的设置：

在不少时候，对于单个容器来讲，这样的ulimit实在是过高了。在Docker 1.6里，能够设置
1） 全局默认的ulimit：

docker -d --default-ulimit nproc=1024:2048
  docker -d --default-ulimit nofile=20480:40960 nproc=1024:2048

2）在启动容器时，单独对其ulimit进行设置：

docker run -d --ulimit nofile=20480:40960 nproc=1024:2048 容器名

这里有一篇介绍，能够加深你的理解。

对于Docker ulimit的灵活设置，这里还有一个理论须要注意：

1) Docker容器默认移除sys_resource（Linux能力），于是ulimit -n设置只能改小没法改大，改大会报错：ulimit: open files: cannot modify limit: Operation not permitted。
2) CentOS 7下docker run可使用–privileged选项来不移除Linux能力，但Docker默认移除这个Linux能力确定是有安全方面的考量，所以尽可能别用该选项。
3) CentOS 6下要使用–privileged，Docker版本不能>=1.0.1，不然会报错；stat /dev/.udev/db/cpuid:cpu0: no such file or directory。

解决

通过上面的讨论，相应把问题应该说清楚了，也解释清楚了。那么CentOS 6下，除了上述的手动重启Docker Daemon方法解决外，还有其余方法吗？答案是确定的，有不少方法，这里简要说一种吧，思路相似。

即：若使用sysV服务，则在/etc/init.d/functions最开头添加一行：ulimit -u 204800 -HSn 204800。
原理为：Docker服务启动脚本第一行会去执行它。

[guansheng@xx-xx-xx-yf-core ~]# ll /etc/rc.d/rc3.d/ |grep docker
lrwxrwxrwx  1 guansheng root  16 Jul  3 19:25 S95docker -> ../init.d/docker

 

网友建议：

1） @ARGV 指出，/etc/init.d/functions会被全部随系统启动的服务调用，建议直接设置在../init.d/docker启动脚本里，建议有效，感谢指正。不过，这个至关于去修改Docker Daemon的自启动脚本了。
2） @枯木-Linux，与之交流，发现最好的方案，仍是直接修改 /etc/sysconfig/docker 配置文件。赞一个。

总结

白天出的问题，一个多小时把它理清并解决了，感受仍是蛮好的。深夜，头脑清醒，就想写篇长微博分享给你们，问题虽不难，但崇尚分享精神老是很好的。

PS：文章快速写成，思路若是不清晰或由错误点，请帮助指出，万分感谢。