所属技术领域：
云原生
| 名词定义|
容器运行时所需要的所有的文件集合称之为容器镜像。
| 发展历程|
2008年，以Google公司开发人员为主导实现的Linux Container(即LXC)功能在被merge到Linux内核中。LXC是一种内核级虚拟化技术，主要基于Namespaces和Cgroups技术，实现共享一个操作系统内核前提下的进程资源隔离，为进程提供独立的虚拟执行环境，这样的一个虚拟的执行环境就是一个容器。本质上说，LXC容器与现在的Docker所提供容器是一样的。Docker也是基于Namespaces和Cgroups技术之上实现的，Docker的创新之处在于其基于Union File System技术定义了一套容器打包规范，真正将容器中的应用及其运行的所有依赖都封装到一种特定格式的文件中去，而这种文件就被称为镜像（即image），原理见下图（引自Docker官网）： 
图1：Docker镜像原理
自从2013年dotCloud公司(现已改名为Docker Inc)发布Docker容器技术以来，到目前为止已经有四年多的时间了。这期间Docker技术飞速发展，并催生出一个生机勃勃的、以轻量级容器技术为基础的庞大的容器平台生态圈。作为Docker三大核心技术之一的镜像技术在Docker的快速发展之路上可谓功不可没：镜像让容器真正插上了翅膀，实现了容器自身的重用和标准化传播，使得开发、交付、运维流水线上的各个角色真正围绕同一交付物，“test what you write, ship what you test”成为现实。
| 技术特点|
容器镜像都是只读的，当容器启动时，一个新的可写层被加载到镜像的顶部。
这一层通常被称作“容器层”，“容器层”之下的都叫“镜像层”
适用场景：
应用打包
制作过RPM、GEM等软件包的同学可能很清楚，每一个软件包依赖于哪个库的哪个版本，
往往需要明确的写在依赖列表里。而依赖又往往分为编译时依赖和运行时依赖。
在传统的基础设施环境下，为了保证所生成的软件包在其它机器上可正常安装且运行，
一般需要在打包之前创建个干净的虚拟机，或者手工创建个chroot环境，
然后在这个干净的环境下安装安全各种依赖包，然后执行打包脚本。
生成软件包以后，需要再创建一个干净的环境安装、运行这个软件包，来验证是否符合预期。
这样虽然也能完成打包工作，但至少有以下缺点：
耗时耗力
依赖关系容易漏掉，比如：在干净的环境中经过多次调试，把缺少的依赖包一个一个的装上了，但最后写spec文件时却忘记添加某个依赖，导致下次打包时需要重新调试或者打包后软件包无法使用等问题。
通过docker可以很好的解决打包问题。具体作法如下：
“干净的打包环境”很容易准备，docker官方提供的ubuntu、centos等系统镜像天生就能作为纯净无污染的打包环境使用
Dockerfile本身能起到文档固化的作用，只要写好Dockerfile，创建好打包镜像，以后就能无限次重复使用这个镜像进行打包
多版本混合部署
随着产品的不断更新换代，一台服务器上部署多个应用或者同一个应用的多个版本在企业内部非常常见。
但一台服务器上部署同一个软件的多个版本，文件路径、端口等资源往往会发生冲突，造成多个版本无法共存的问题。
如果用docker，这个问题将非常简单。由于每个容器都有自己独立的文件系统，所以根本不存在文件路径冲突的问题;
对于端口冲突问题，只需要在启动容器时指定不同的端口映射即可解决问题。
升级回滚
一次升级，往往不仅仅是应用软件本身的升级，通过还会包含依赖项的升级。
但新旧软件的依赖项很可能是不同的，甚至是有冲突的，所以在传统的环境下做回滚一般比较困难。
如果使用docker，我们只需要每次应用软件升级时制作一个新的docker镜像，升级时先停掉旧的容器，
然后把新的容器启动。需要回滚时，把新的容器停掉，旧的启动即可完成回滚，整个过程各在秒级完成，非常方便。
多租户资源隔离
资源隔离对于提供共享hosting服务的公司是个强需求。
如果使用VM，虽然隔离性非常彻底，但部署密度相对较低，会造成成本增加。
docker容器充分利用linux内核的namespaces提供资源隔离功能。
结合cgroup，可以方便的设置某个容器的资源配额。
既能满足资源隔离的需求，又能方便的为不同级别的用户设置不同级别的配额限制。
但在这种应用场景下，由于容器中运行的程序对于hosting服务提供方来说是不可信的，
所以需要特殊的手段来保证用户无法从容器中操作到宿主机的资源（即：越狱，尽管这种问题发生的概率很小，但安全无小事，多一层防护肯定让人更加放心）。
安全及隔离性加固方面，可考虑以下措施：
通过iptables阻断从容器到所有内网IP的通信（当然如果需要也可以针对特定的IP/端口开放权限）2. 通过selinux或者apparmor限制某个容器所能访问的资源3. 对某些sysfs或者procfs目录，采用只读方式挂载4. 通过grsec来加固系统内核5. 通过cgroup对内存、CPU、磁盘读写等资源进行配额控制6. 通过tc对每个容器的带宽进行控制
另外我们在实际测试中发现系统的随机数生成器很容易因熵源耗尽而发生阻塞。
在多租户共享环境下需要在宿主机上启用rng-tools来补充熵源。
这个应用场景下有很多工作是docker本身所不能提供的，并且实施起来需要关注的细节比较多。
为此我们提供了安全加强版docker管理平台，可完美解决以上问题。
需要的朋友可以通过csphere官网了解更多细节。
内部开发环境
在容器技术出现之前，公司往往是通过为每个开发人员提供一台或者多台虚拟机来充当开发测试环境。
开发测试环境一般负载较低，大量的系统资源都被浪费在虚拟机本身的进程上了。
docker容器没有任何CPU和内存上的额外开销，很适合用来提供公司内部的开发测试环境。
而且由于docker镜像可以很方便的在公司内部分享，这对开发环境的规范性也有极大的帮助。
如果要把容器作为开发机使用，需要解决的是远程登录容器和容器内进程管理问题。
虽然docker的初衷是为“微服务”架构设计的，但根据我们的实际使用经验，
在docker内运行多个程序，甚至sshd或者upstart也是可行的。
这方面csphere也有成熟的产品及解决方案，欢迎感兴趣的朋友试用反馈。
