Docker的典型应用场景

本文列举一些docker的实际应用场景，以期能够起到抛砖引玉的作用， 来帮助大家更加方便的使用docker。

应用打包

制作过RPM、GEM等软件包的同学可能很清楚，每一个软件包依赖于哪个库的哪个版本， 往往需要明确的写在依赖列表里。而依赖又往往分为编译时依赖和运行时依赖。

在传统的基础设施环境下，为了保证所生成的软件包在其它机器上可正常安装且运行， 一般需要在打包之前创建个干净的虚拟机，或者手工创建个chroot环境， 然后在这个干净的环境下安全各种依赖包，然后执行打包脚本。 生成软件包以后，需要再创建一个干净的环境安装、运行这个软件包，来验证是否符合预期。 这样虽然也能完成打包工作，但至少有以下缺点：

1. 耗时耗力
2. 依赖关系容易漏掉，比如：在干净的环境中经过多次调试，把缺少的依赖包一个一个的装上了，  但最后写spec文件时却忘记添加某个依赖，导致下次打包时需要重新调试或者打包后软件包无法使用等问题。

通过docker可以很好的解决打包问题。具体作法如下：

1. “干净的打包环境”很容易准备，docker官方提供的ubuntu、centos等系统镜像天生就能作为纯净无污染的打包环境使用
2. Dockerfile本身能起到文档固化的作用，只要写好Dockerfile，创建好打包镜像，以后就能无限次重复使用这个镜像进行打包

示例：

我们要为某个PHP扩展模块（如：php-redis）制作个RPM包。

首先，需要写个用于创建打包镜像的Dockerfile, 内容如下：

FROM centos:centos6   RUN yum update -y   RUN yum install -y php-devel rpm-build tar gcc make   RUN mkdir -p /rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} && /     echo '%_topdir /rpmbuild' > ~/.rpmmacros ADD https://pecl.php.net/get/redis-2.2.7.tgz /rpmbuild/SOURCES/redis-2.2.7.tgz   ADD https://gist.githubusercontent.com/mountkin/5175c213585d485db31e/raw/02f6dce79e12b692bf39d6337f0cfa72813ce9fb/php-redis.spec /redis.spec   RUN rpmbuild -bb /redis.spec  

然后执行docker build -t php-redis-builder ., 执行成功后，就会生成我们需要的RPM包。

接下来，执行以下命令把生成的软件包从docker镜像中复制出来：

[ -d /rpms ] || mkdir /rpms docker run --rm -v /rpms:/rpms:rw php-redis-builder cp /rpmbuild/RPMS/x86_64/php-redis-2.2.7-1.el6.x86_64.rpm /rpms/  

然后/rpms目录下就会有我们刚刚制作的RPM包。

最后，软件包的验证过各也非常简单，只需要新创建一个docker镜像，把新生成的软件包添加进去并安装即可。

Dockerfile如下（为了ADD RPM文件，需要保存在/rpms目录下）：

FROM centos:centos6   ADD php-redis-2.2.7-1.el6.x86_64.rpm /php-redis-2.2.7-1.el6.x86_64.rpm   RUN yum localinstall -y /php-redis-2.2.7-1.el6.x86_64.rpm   RUN php -d "extension=redis.so" -m |grep redis  

在/rpms目录下执行docker build -t php-redis-validator .，如果执行成功,则表明RPM包可正常工作。

多版本混合部署

随着产品的不断更新换代，一台服务器上部署多个应用或者同一个应用的多个版本在企业内部非常常见。

但一台服务器上部署同一个软件的多个版本，文件路径、端口等资源往往会发生冲突，造成多个版本无法共存的问题。

如果用docker，这个问题将非常简单。由于每个容器都有自己独立的文件系统，所以根本不存在文件路径冲突的问题; 对于端口冲突问题，只需要在启动容器时指定不同的端口映射即可解决问题。

升级回滚

一次升级，往往不仅仅是应用软件本身的升级，通过还会包含依赖项的升级。 但新旧软件的依赖项很可能是不同的，甚至是有冲突的，所以在传统的环境下做回滚一般比较困难。

如果使用docker，我们只需要每次应用软件升级时制作一个新的docker镜像，升级时先停掉旧的容器， 然后把新的容器启动。 需要回滚时，把新的容器停掉，旧的启动即可完成回滚，整个过程各在秒级完成，非常方便。

多租户资源隔离

资源隔离对于提供共享hosting服务的公司是个强需求。 如果使用VM，虽然隔离性非常彻底，但部署密度相对较低，会造成成本增加。

docker容器充分利用linux内核的namespaces提供资源隔离功能。 

结合cgroup，可以方便的设置某个容器的资源配额。 既能满足资源隔离的需求，又能方便的为不同级别的用户设置不同级别的配额限制。

但在这种应用场景下，由于容器中运行的程序对于hosting服务提供方来说是不可信的， 所以需要特殊的手段来保证用户无法从容器中操作到宿主机的资源（即：越狱，尽管这种问题发生的概率很小，但安全无小事，多一层防护肯定让人更加放心）。

安全及隔离性加固方面，可考虑以下措施：

• 通过iptables阻断从容器到所有内网IP的通信（当然如果需要也可以针对特定的IP/端口开放权限）
• 通过selinux或者apparmor限制某个容器所能访问的资源
• 对某些sysfs或者procfs目录，采用只读方式挂载
• 通过grsec来加固系统内核
• 通过cgroup对内存、CPU、磁盘读写等资源进行配额控制
• 通过tc对每个容器的带宽进行控制

另外我们在实际测试中发现系统的随机数生成器很容易因熵源耗尽而发生阻塞。 在多租户共享环境下需要在宿主机上启用rng-tools来补充熵源。

这个应用场景下有很多工作是docker本身所不能提供的，并且实施起来需要关注的细节比较多。 为此我们提供了安全加强版docker管理平台，可完美解决以上问题。 需要的朋友可以通过csphere官网了解更多细节。

内部开发环境

在容器技术出现之前，公司往往是通过为每个开发人员提供一台或者多台虚拟机来充当开发测试环境。

开发测试环境一般负载较低，大量的系统资源都被浪费在虚拟机本身的进程上了。

docker容器没有任何CPU和内存上的额外开销，很适合用来提供公司内部的开发测试环境。 

而且由于docker镜像可以很方便的在公司内部分享，这对开发环境的规范性也有极大的帮助。

如果要把容器作为开发机使用，需要解决的是远程登录容器和容器内进程管理问题。 虽然docker的初衷是为“微服务”架构设计的，但根据我们的实际使用经验， 在docker内运行多个程序，甚至sshd或者upstart也是可行的。

这方面csphere也有成熟的产品及解决方案，欢迎感兴趣的朋友试用反馈。

后记

以上总结了我们在实际开发和生产环境中使用docker的一些场景， 以及在每种情况下遇到的问题和相应的解决方法，希望对有意使用docker的朋友有所启发。 同时我们也欢迎更多的朋友分享关于docker的使用经验。（责编：刘亚琼）

作者： 魏世江, NiceScale联合创始人，长期从事DevOps相关研发工作。 专注于Linux环境Web应用及周边服务的配置管理自动化。擅长使用go语言及PHP语言， 对容器技术有一定的研究，目前正集中精力做基于docker的企业级解决方案。 创业之前在新浪云平台（SAE）任技术经理。欢迎志同道合的朋友以各种方式勾搭骚扰。

原文链接： https://blog.nicescale.com/docker-use-cases/

OpenCloud 2015将于2015年 4月16-18日在北京召开。大会包含“2015 OpenStack技术大会”、“2015 Spark技术峰会”、“2015 Container技术峰会”三大技术峰会及多场深度行业实战培训，主题聚焦技术创新与应用实践，荟萃国内外真正的云计算技术的大牛讲师。这里都是一线接地气的干货，扎实的产品、技术、服务和平台。OpenCloud 2015，懂行的人都在这里！

更多讲师和日程信息请关注OpenCloud 2015介绍和官网。