5.1容器典型应用场景

Docker技术的出现和迅猛发展，已成为云计算产业的新的热点。容器使用范围也由互联网厂商快速向传统企业扩展，大量传统企业开始测试和尝试部署容器云。相比于企业对容器技术的逐步接受与认同，在如何使用容器上却并不统一，存在多种思路和诉求。容器技术开发者和社区倡导云原生应用场景，这一理念被业界普遍认可，但在实际使用中发生分化。部分企业基于容器技术，尝试新应用开发和对传统应用的改造；而有的企业在实际使用中，面临应用改造困难和人员技能变更的问题，认为不可一蹴而就，希望先以轻量级虚拟机的方式使用容器。容器的下述技术特点，决定了容器所能发挥真正价值的应用场景。" 轻量化：容器相比于虚拟机提供了更小的镜像，更快的部署速度。容器轻量化特性非常适合需要批量快速上线的应用或快速规模弹缩应用，如互联网web应用。" 性能高、资源省：相比虚拟化，接近物理机的性能，系统开销大幅降低，资源利用率高。容器的高性能特性非常适合对计算资源要求较高的应用，如大数据和高性能计算应用。" 跨平台：容器技术实现了OS解耦，应用一次打包，可到处运行。容器的跨平台能力非常适合作为DevOps的下层封装平台，实现应用的CI/CD流水线；容器应用可跨异构环境在不同云平台、公有云和私有云上部署，也非常适合作为混合云的平台。" 细粒度：容器本身的“轻”和“小”的特性非常匹配细粒度服务对资源的诉求，与微服务化技术的发展相辅相成，可作为分布式微服务应用的最佳载体。企业关注下一代内部IT架构变革，希望将服务作为IT核心，提升业务敏捷性，大幅降低TCO。容器成为企业应用转型很好的承载平台，针对企业的业务痛点，使用上述一种或多种特点，优化业务场景。下面内容详细描述了容器支持的典型应用场景。

5.1.1  互联网web类应用

这是容器技术最广泛使用的场景。Web类应用通常是三层架构(见图5-1)。系统面临大量用户突发业务访问时，对于无状态的Web前端，非常适合使用容器部署。快速规模弹性伸缩Web服务节点实例数，结合ELB的分发调度，适配业务的负载变化。无状态的App服务节点，或通过无状态化改造，也可以打包为容器，提供快速弹缩能力。

5.1.2  CI/CD开发测试

云Docker开源后，在开发人员和运维人员之间迅速流行起来，成为第一款获得共同认可的DevOps工具，继而成为容器的事实标准。Docker为实现DevOps的四个技术基础技术提供了完善的解决方案，分别是：分布式的开发环境、标准化的运行环境、丰富的应用镜像仓库以及持续的自动化部署(见图5-2)。

" 分布式的开发环境：Docker的分层文件系统机制，使不同的开发人员完全独立地进行开发，并最终进行文件挂载的方式搭建应用开发程序，使开发人员之间的影响最小，实现开发敏捷。" 标准化的运行环境：Docker Image可以在各种支持Docker的开发、测试和生产环境中运行，而屏蔽不同环境间软硬件的差异。" 丰富的应用仓库：在Docker Hub和私有镜像仓库中存储着多种类型的Docker Image，利用仓库来存储Docker镜像，快速搭建应用所需的标准化环境。" 持续的自动化部署：各种Docker的编排工具，如Mesos、Kubernates工具能够支持应用生命周期管理，支持服务发现、负载均衡和灰度升级等，满足运维的应用不停机升级。

5.1.3  微服务管理平台微服务是一种软件架构模式，此模式下应用被分解为一系列相互独立、边界明确、自主完成单一的任务的服务，服务之间解耦，可独立替换、升级和伸缩，服务间通过语言无关的轻量级接口，如网络通信(RPC、HTTP等)、消息队列等进行协同。微服务架构将应用解耦分拆为小粒度服务模块，容器的轻量化可为微服务提供更细粒度的资源供给，有效地利用资源。服务启动快和弹缩快，也能更好地应对单服务和系统突发式的业务访问，如图5-3所示。

5.1.4  容器主机容器不同于虚拟化的实现方式，占用更少的系统资源，有效地提升了数据中心的资源利用率，同时利用容器快速弹性等特性，使业务系统可以灵活扩展，架构演进至微服务架构。对于轻量级虚拟机，虚拟机管理程序对硬件设备进行抽象处理，而容器只对操作系统进行抽象处理，容器有自己的文件系统、CPU和内存，意味着容器能像虚拟机一样独立运行，却占用更少的资源，极大地提高了资源利用率。

5.2  Docker容器关键技术

5.2.1  Docker Daemon技术人员一般会将Docker的技术堆栈分成好几层，用来进一步阐明Docker技术本身。相对于整个技术堆栈而言，Docker容器OS层的关键技术显得尤为重要。要了解Docker，首先看看Docker总架构图，如图5-4所示。由图可知，用户可以从Docker Client建立与Docker Daemon的通信连接，发送容器的管理请求，这些请求最终被Docker Server接受，而请求处理则交给Engine处理。而在与系统调用方面，Docker则是通过更底层的工具LibContainer与内核交互。Libcontainer是真正的容器引擎，是容器管理的解决方案，涉及大量的Linux内核方面的特性，如namespace、cgroups、apparmor等。LibContainer很好地抽象了这些特性，提供接口给Docker daemon。用户执行启动容器的命令后，一个DockerContainer实例就运行起来了，这个实例拥有隔离的运行环境、网络空间以及配置好的受限资源。Docker Daemon是一个常驻在后台的系统进程，实际上就是驱动整个Docker功能的核心引擎。简单地说，Docker Daemon实现的功能就是接收客户端发来的请求，并实现请求所要求的功能，同时针对请求返回相应的结果。在功能的实现上，因为涉及容器、镜像、存储等多方面的内容，实现复杂，涉及多个模块的交互。

5.2.2  Docker容器Container(容器)是整个Docker技术堆栈的核心内容，相对传统虚拟化，这项基础技术在性能上给Docker带来了极大优势。Docker Daemon通过LibContainer对容器运行实例实现了生命周期的管理，配置信息的设置、查询、监控以及通信等丰富的功能。概念上来说，容器诠释了Docker提倡的集装箱的概念：存放任何货物，通过货轮运输到各个不同的码头。而运输、装载、卸载集装箱的码头都不用关心集装箱中的货物是什么，这种标准的应用封装形式真正意义上打破了原有云计算世界中虚拟机镜像格式的束缚，极大地方便开发人员的工作。Docker容器作为一个集装箱，可以安装指定的软件和库，以及任意环境配置。当开发和运维人员在部署和管理应用的时候，可以直接把应用容器运行起来，不用关心容器里是什么。容器技术不是一个新的技术，但是通过Docker的神奇封装，与集装箱概念联系起来，开创了云计算领域的新的时代，并迅速推广到全世界。

5.2.3  Docker镜像运行中的容器实例，提供了一个完整的、隔离状态的运行环境，与之相对应的Docker Image技术，则是整个运行环境的静态体现。相比较传统虚拟机繁杂、多样的镜像格式而言，Docker的镜像要轻量化很多，并且简单很多。从技术层面俯视，这就是一个可以定制的RootFS。Docker公司在镜像上的另外一个创新就是分层复用。其在一些实际场景中非常有用，大部分的镜像需要相同的OS发行版环境，而许多文件的内容都是一致的，因此复用这些基础文件将会减少很多制作镜像时候的工作。Docker Image做到了这点，采用UnionFS的特性，通过一个基础版本的分层机制，不断开发新的版本堆叠在上面即可，减少磁盘和内存的开销。开发人员通常会使用Dockerfile来创建DockerImage，这是一个定制镜像内容的配置文件，同时也能在内容上体现层级关系的建立关系。可以使用docker commit这样的命令行方式来手动修改镜像内容并提交生成新的镜像。

5.2.4  Docker Registry有了Docker Image之后，就需要考虑镜像仓库了，Docker Registry就是这样的功能设定。在Docker的世界中，开发人员可以很容易地从这里下载镜像，Registry通常被部署在互联网服务器或者云端。在Docker Image的传输过程，Registry就是中转站。例如，在公司里，我们可以把一个软件的运行环境制作成为镜像，上传到Registry中，然后就可以很方便地在可以接入到网络的地方从Registry上把镜像下载下来并运行，当然这些操作都是和Docker结合在一起的，使用者甚至不会感知到Registry的存在，简单的命令行就可以显示所有的操作了。Docker公司提供的官方镜像Registry叫做Docker Hub，提供了大部分的常用软件和OS发行版的官方镜像，同时也存有无数的个人用户提供的镜像文件。Registry本身也是一个开源项目，任何开发人员可以在下载该项目后，自己部署一个Registry，许多企业都会选择独立部署DockerRegistry并且做二次开发，或者购买更强大的企业版Docker Hub。

5.3  容器操作系统

Docker发布以来，对传统的操作系统厂商产生了巨大的冲击，出现了很多容器操作系统，包括CoreOS、Ubuntu Snappy、RancherOS、Red Hat的Atomic等。这些操作系统支持容器技术，作为主要卖点，构成了新的轻量级容器操作系统的生态圈。传统Linux的操作系统，其发行版本出于通用性考虑，会附带大量的软件包，而很多运行中的应用并不需要这些外围包。例如在容器中运行Java程序，容器中安装了JRE，而容器外的环境不会产生任何依赖，除系统支持Docker运行时的环境之外，无用的外围包可以省略掉。这可以减少一些磁盘空间开销。同样地，运行在后台的服务，如果没有封装到Docker 容器中，也可以认为是不需要的，多余的。减少这样的服务，也可以减少内存的开销，因此全面面向容器的操作系统就这样诞生了，“Container OS”就是最好的诠释，与其他OS相比，这些操作系统更小巧，占用资源更少，相应的运行速度更快。图5-5是容器操作系统与其他OS在软件栈中的对比。顺应市场需求，容器操作系统应运而生，我们接下来盘点一些业界常见的“Container OS”。

5.3.1  CoreOS

CoreOS是第一个容器操作系统，它是为大规模数据中心和云计算而生，立足于云端生态系统的分布式部署、大规模伸缩扩展的需求，具备在生产环境中运用的能力。相比于其他瘦客户操作系统主要是针对特殊需求进行技术定制，CoreOS通过容器技术支持大众通用的选择。CoreOS官方支持很多部署方案，甚至一些有特殊需求的方案也得到支持。CoreOS是基于Chrome OS再定制的轻量级Linux发行版，将操作系统和应用程序分离，所有用户服务和应用都在容器内运行。鉴于CoreOS源于Chrome OS，因此它的系统升级方法和ChromeOS也很类似，比如，有新的组件发布就会自动更新。而且它支持双系统分区，这样可以通过滚动更新的方式在任何时候直接将系统升级成最新的版本。另外，CoreOS还支持秘钥签名，能有效保证更新的有效性和整个系统的完整性。CoreOS还同时支持Docker和Rkt，也预装了Etcd、Fleet、Flannel和Cloud-init等容器集群管理配置工具。

5.3.2  RancherOS

RancherOS只由内核和Docker构成。相比于VMware的Photon大约300MB的体积来说，RancherOS是最小的容器操作系统之一，它只有22MB左右。为了开发Docker化的容器操作系统，它采用了一种与众不同的方式来引导系统，也就是：去掉了内嵌在Linux发行版中的服务管理系统Systemd，改用Docker来引导系统，这个Docker叫“系统Docker”，负责系统服务的初始化，并将所有的系统服务作为Docker容器进行管理，包括Systemd。另外系统Docker会创建一个特殊的容器服务Docker，称为“用户Docker”，主要负责应用容器的管理。在RancherOS开发的早期阶段，“系统Docker”创建的Systemd容器经常会和“用户Docker”直接冲突。因为“用户Docker”创建的应用容器是在Systemd外创建的，Systemd总是会去杀掉它们。RancherOS花了很长时间才找到一种解决方案，且目前不确定是否还有其他方法可以解决这个问题。RancherOS具有如下特点。" 与Docker的开发速度相匹配，提供最新版本的Docker。" 不再需要复杂的初始化系统，使用一个简单的配置文件，管理人员就能很容易地把系统服务配置成Docker容器。" 容易扩展 ， 用户很容易通过配置使RancherOS启动一个自定义的控制台容器，提供Ubuntu、CentOS或者Fedora发行版的体验。" 资源占用小、启动速度快、容易移植、安全性更好，升级、回滚简单。" 可以使用像Rancher这样的集群管理平台，容易维护。

5.3.3  Snappy Ubuntu CoreUbuntu是Docker容器技术最流行的Linux发行版，Canonical引以为傲。从Docker的周边生态来看，在Ubuntu上运行Docker容器的数量远远超过其他操作系统。Canonical为移动设备创建“短小精悍”的操作系统付出了很多努力，也从其中吸取了很多经验教训，而Snappy Ubuntu Core就是运用这些经APPAPP APP APP APP容器 容器硬件 硬件 硬件Hypervisor (Host OS) 容器OSGuest OS Guest OS操作系统传统OS 虚拟化OS 容器OS图5-5 几种操作系统在各自应用场景中的位置对比开发出来的，其体积只有200MB左右。为了支持用户系统可靠和应用更新的需求，SnappyUbuntu Core对系统和应用采取“基于业务和镜像delta”的更新，只传输镜像delta以保证小数据量下载，并且可以回滚。Snappy Ubuntu Core从安全性考虑，引入AppArmpr来隔离应用的运行环境，并且它将会与Canonical自己基于LXC开发的轻量化Hypervisor(LXD)整合，使得VM化的容器成为可能。此外，Snappy Ubuntu Core还支持Canonical自己的编排部署工具Juju Charms，提供对容器整个生命周期的管理。可以说，Snappy Ubuntu Core是目前业界唯一支持ARM的容器操作系统。

5.3.4  VMware PhotonDocker使用容器这种轻量级虚拟化技术部署应用，随着Docker的越来越流行，对VMware将会造成潜在威胁。这是因为容器可以不需要虚拟机而直接运行在裸机上，虽然目前由于安全性还有不足，公有云上的容器仍然跑在虚拟机里。虽然VMware在2014年8月宣布了与Docker的合作伙伴关系，且宣称会帮助Docker构建一个真正可扩展的系统，后续也在其产品中对与Docker相关的网络和存储等做了优化和增强。但是，应用在操作系统之上的容器中运行，是VMware无论如何也无法面对的痛点，因为VMware没有操作系统，或者就VMware目前的技术软件栈来说，需要在Hypervisor之上的系统中提供管理，也就是在操作系统中实施管理。当然，VMware也不可能不允许CoreOS、Red Hat或者其他操作系统在Hypervisor上运行，而独自在Hypervisor中提供对容器的支持。这就需要一个特别的操作系统来帮助把容器加到VMware产品里，并且需要扩展Hypervisor到操作系统里。于是，在2015年4月VMware推出了容器操作系统Photon，它紧密地与vSphere生态集成，并做了相应的优化，定位于VMware产品线。它具备以下特性。" 支持多种主流容器——Docker、Rkt和Garden。" 通过虚拟机技术或者集成Lightwave的授权与鉴权机制来提高容器运行的安全隔离性。" 支持全新的、开源的兼容Yum的包管理器。

5.3.5  Red Hat Atomic HostRHEL 7 Atomic Host在2015年3月发布，相比RHEL 7完全发行版的6500个外围包，它只有不到200个，总大小约为400MB。它比传统操作系统更轻量，但体积并没有其他同类产品小。其主要考量的是，尽管RancherOS能做最小化的构建，但是可能会带来更多的复杂度，因为除了应用容器之外，还需要运行额外的系统容器，所以核心系统服务需要在主机里。Red Hat针对系统行为的数据收集、系统日志和身份验证等也开发了容器化版本，但是坚持认为这些组件必须放在主机上。Atomic Host是从经过Red Hat工程团队严格验证的企业级操作系统派生而来的精简系统。RedHat对Atomic Host也在做ISV(Independent SoftwareVendors)的工作，认证容器是基于知名的、测试过的、安全的基础镜像构建的。Atomic Host采用Selinux提供强大的多租户环境下的安全防护。此外，Atomic Host支持Docker，也预装了Kubernetes等集群管理配置工具。

5.3.6  Microsoft Nano ServerNano Server是微软的容器操作系统，约400MB大小，还处于早期阶段。它定位在两个场景上，一是聚焦Hypervisor集群和存储集群等云基础设施，二是着重于原生云应用的支持。对于第二种场景，Nano Server适配新类型的应用，这些应用在全新的基于Azure的开发环境中开发，并部署在Azure上面，而不是在传统的基于客户端的Visual Studio中。这些新的应用为Windows开发者通往容器领域提供了入门通道。云计算架构技术与实践(第2版) 114开发者为Nano Server开发的程序，可完全与已有的Windows服务器安装版本兼容，因为NanoServer实际上是Windows服务器版的子集。给Nano Server写的应用可以运行在物理机上、虚拟机上或者容器里。有两类容器可在Windows服务器和Nao Server上工作，一类是为Linux开发的Docker容器，另一类是微软为自己的Hypervisor平台Hyper-V开发的容器。这些容器提供了额外的隔离，能真正用于像多租户服务或者多租户PaaS等场景。Nano Server支持多种编程语言和运行时，如C#、Java、Node.js和Python，也支持Windows服务器容器和Hyper-V容器，预装了Chef等集群管理配置工具。微软从Nano Server入手，拥抱容器，给开发者提出了挑战。开发者可能需要一个比较长的转变期来接受并习惯微服务理念。

微信公众号【Java技术江湖】一位阿里 Java 工程师的技术小站。（关注公众号后回复”Java“即可领取 Java基础、进阶、项目和架构师等免费学习资料，更有数据库、分布式、微服务等热门技术学习视频，内容丰富，兼顾原理和实践，另外也将赠送作者原创的Java学习指南、Java程序员面试指南等干货资源）