Docker如何打造App-Centric交付

今天给大家带来的分享是《Docker如何打造App-Centric交付》，本次分享的内容主要分三个模块。

钟健鑫

第一是 现有交付下存在的问题；

第二是 App-Centric交付模式优化持续交付；

第三是 基于Docker实现基础架构。

如今属于快销时代，软件推出速度越来越跟不上市场的变化，企业为了响应市场的需求，不断构造更多的功能和价值来提供给客户，在这个过程中组织架构服务的依赖、硬件维护存在的问题越发明显，导致整个交付的复杂度越来越高，最终从企业层面会看到投资回报率组件降低，在单位时间内生产出的价值越来越少，这样一种趋势是比较可怕的。

下面我们来看看我们的交付除了什么问题？通常实施过敏锐的公司都会用持续集成流水线，这样一个流水线看起来比较行云流水，开发人员开发代码以后推送到各种环境进行集成，经历测试以后达到生产环境，好像交付就就这么简单，有可能在一天或者一个小时就可以完成。

那我们换一个视角看，我们从基础社区的层面看一个交付过程，我们在启动新项目的时候首先会考虑整体架构，其中包含硬件架构和相关环境依赖。

最初会花大量时间搭建初始化的架构。随着开发的推进这个架构有很大可能被调整，相关依赖也随之改变，这个改变是需要成本的不仅是本地开发环境还有测试环境，需要保证改变后各种运行环境仍保持一致。在开发完成以后是发布上线阶段，企业需要我们通过跟运维人员的沟通做一个跟测试一样的环境，用于保证软件发布的时所表现出来的特性是一样的。最后是长期维护升级阶段，如果是运维团队要保证这个环境的依赖和稳定程度，并与开发和测试环境一致。如果不一致话结果是可能是毁灭性的。一旦线上产品出问题，如果是代码问题很容易找到，因为有迹可循。如果是环境问题，可能会降低很多的效率，大部分的时间都会浪费在上面。

在这个过程中到底有哪些地方浪费我们的时间：第一是准备和维护各种环境浪费大量时间，第二是整个交付的复杂度，随着整个交付往后的演进环境复杂度很难控制计我们可以控制代码，可以通过各种模式和微服务都可以控制。

后面是遗留系统升级和迁移很困难，现在企业发展到一定运维规模以后一定存在遗留系统，如果企业有新的架构模式和决策的时候，对他进行迁移和升级的时候会花费大量的时间做这个事情，投入和产出很难成正比。

最后一个是基础设施的维护和扩展不够安全和高效。在思考解决以上问题的过程当中，技术雷达上有一个被采用的技术实践，“把部署从发布中解耦出来”，给了我一些启示。我们先看下它给出的两个概念：第一是在基础设施代码或者配置变更在产品环境生效成为部署，具有业务影响的功能变化对终端用户可见称为发布。我们把软件发布或者部署到环境，让他能够在线给用户提供服务，我们现在通过这样的实践会着重把这两个概念严格区分出来，因为这样足够灵活。基础设施的变更是很难控制的，如果我们对基础设施的更新和部署可以频繁进行，那足以证明我们的环境是高可用的，就如代码一样，当你看到它是什么样，运用出来一定是什么样。

基于这样一个优秀的实践，我想要优化这样持续交付的过程来解决之前提到问题，以下三点是可以做的。

第一是低耦合的、可以被持续交付的基础设施，在交付过程中如何采用基础设施及代码和其他的实践，来帮助我们能够高效管理基础设施并可以持续改进它，可以同应用一起或单独被部署，这样我们就可以相信基础设施的变更在各个环境是一致的，

第二是授权团队从无到有的构建服务，最重要的是运维能不能引入到我们的团队，如果运维不在我们的团队，证明我们的环境对于整个开发团队来说是不可控的，当我们的软件开发好了以后，交付给另外一个团队，有大量的沟通和清单，让运维团队部署和发布，这样是否得到一个健康的环境和应用是很难控制的。

第三，使整个交付螺旋透明无死角。

如果要做到以上三点个，我想交付的方式应该是这样的，首先我们定义两种团队，第一种是应用交付团队，它是负责直接产生价值的端到端交付团队，第二个团队是公有基础设施交付团队，负责公共基础设施的维护和扩展。这两个团队内部人员的配置是一样的，都是全功能团队包括测试开发运维和产品，应用团队在本地开发时，通过编码的形式不仅把应用价值代码写出来，更重要的是把应用所依赖的环境也通过代码描述出来，形成一个整体，通过整体方式被构建打包，然后整体被部署到测试环境进行一系列测试，最终被整体部署到生产环境。

在整个交付过程中，应用对于公有基础设施来说就是一个黑盒，但是对于应用交付团队来说却是完全透明的，包含了应用以及应用运行所依赖的环境。公有基础设施则是为这个应用提供通用的服务如主机管理，负载均衡，监控等。

接下来我们从全面的视角去看两个团队配合的交付过程是这样的，我称它为交付螺旋，红色是我们应用交付的生命周期闭环，蓝色是公有基础设施的交付闭环，他们在这样一个交付闭环过程中通过低耦合的配合沟通，能够更快速的把我们的应用代码和基础设施完全透明的可视化出来，打破了运维和生产环境黑盒。构造出一个更健康的环境，在这样的环境之上运行的应用，我们有足够的信心相信它是安全可靠的。

这样一个流程的核心，需要重新定义应用，应用即软件+所依赖的运行环境，它不能被分开看，且需要整体被调度和迁移，底层是依赖任何的云平台或者物理机，对他来说不会有强依赖，对于这个应用是开发团队应该全权维护和扩展的。要达到这样效果，当下最好的技术是Docker，Docker是一套基于容器的完整工具集，很多人把他比成一个比较小型的虚拟机，我从来不赞同这个说法，因为Docker和虚拟机的关注和侧重点不一样，虚拟机关注的是机器本身，如何把硬件通过虚拟化抽象形成一个一个的操作系统，对于Docker来说，它关注的是应用本身，以应用为中心的层级打包，并将轻量级的虚拟化容器环境任意分发到各个不同的环境表现出一致的特性。

Docker到底有哪些优势？从持续交付的过程中看，Docker能够从以下优势给我们带来变革，首先是环境标准化和版本控制。

第二是一次构建到处运行，且表现出来的性状是一样的。

第三是基础设施既代码。

第四是插件化硬盘存储，Docker  是无状态的，所以他提供插件式存储，存储交给外部分布式存储系统管理，如果内部可以存储数据、状态，那就和虚拟机一样，很难做到快速分发。

最后是秒级启动，单个容器的启动花费几秒钟已经是很久的时间了。

基于Docker，它不仅提供容器技术的包装，更多是提供了基于容器的交付工作方式，中间模块是容器镜像存储的仓库，它作为一个核心将交付分为三个阶段，构建、分发和运行，当容器镜像被构建好后，可以内分发到任意环境，包括物理机虚拟机和内部测试的环境，然后就可以立即被运行，且表现出绝对的一致性。

我们在考虑用Docker的时候，尽管它这么多的好处能够适应整个交付的特性，但是依然在采用一个新技术的时候心里会打鼓，因为Docker依然是一个还比较年轻的技术，有很多的不确定性，所以我做了一下的调查，从2013年诞生以后，一年多的时间发布了一个生产环境可用的版本，这是站在Docker的视角，官方觉得Docker足够稳定可以再生产环境使用，2015年4月，很多厂商已经在用容器技术构建PaaS公有或私有服务，用在生产环节后围绕

Docker构建很多相关能力。所以技术雷达在这个阶段依然是实验阶段，Docker被加分到平台区域，雷达对其评估的不仅仅是他本身还有周围生态圈的能力，以为如果被应用到生产黄精还需要监控、统一的构建分发、编排、服务的健康检查等等一系列特性和能力，

直到在今年4月份的时候，技术雷达Docker被列入采用的阶段，因为在Docker生态圈发展的两三年以内，周边能用到的技术包括监管容器框架网络存储已经发展的比较成熟了。但是只有Docker还是什么事情做不了，我们需要使用更多的能力来基于Docker打造一个以应用为中心的基础架构。

什么是以应用为基础的基础架构，在我们来看看公有云IaaS这一层，它关注的是计算、存储和网络等硬件资源，而对于App-Centric这个角度来看，它关注的是开发一个应用在开发测试和最终生产环境，在整个迭代阶段不需要关心底层使用什么资源，底层消耗多少，物理空间够不够网络是不是连通，我交付应用时只需要关心用户价值。

这是基于App-Centric的架构层次图，最底层是物理机和虚拟机的技术设施，他可以是云，也可以是企业内部数据中心，也可以是简单的物理机集群，他负责的是计算存储和网络，

第二层是编排和调度，调服主要是调度底层的计算机资源，如内存，cpu等，可以高效的分配和利用计算机集群中的资源。服务编排是一种应用的生命周期和依赖管理方式，通过它可以轻松将一个集群中零散的服务与服务之间建立关系。上一层是公共容器服务，他提供监控部署负载均衡甚至安全，在这一层里是容器化的提供，我们可以通过以代码的形式，统一的形式管理。再上层是应用容器服务，他里面存在的各种云服务和前端的应用还有批量任务，比如Hadoop的任务都可以通过容器形式呈现。

贯穿整个层次的主心骨是持续交付生命周期服务和平台管理服务的结合。在CICD在这个架构中用于贯穿于整个持续交付生命周期，对底层没有感觉的情况下可以很顺畅的把你的服务从流程生命周期的管理从开发阶段输送到生产阶段，而平台管理是在这个过程中用于运维管理，可以增加机器或者其他的运维、配置管理。

下面我们来详细分解一下架构图，从上往下首先需要基于一个持续交付的流水线，这个流水线是负责夸各个环境的整个交付流程，在我们开发人员在构建一个应用的时候，本地会通过代码的形式描述一个容器，这个容器里，他包含了我的软件和环境，他是我最终需要在生产环境运行的一个组件，它是以插件的形式插入到下面的公有基础设施里，形成一种低耦合的依赖。团队不仅能够控制应用相关的依赖，我还不用关心底部如何做负载均衡安全控制和分布式监控，在本地描述好以后告诉公有基础设施，它会自动以插件形式运行这个容器，你不用关心这个容器运行在哪台机器，你只是通过编排描述他应该跟哪个服务器通讯，这样形成一个低耦合连接交付方式。

第二是运维管理通过提供的API来控制底层的基础设施，中间这一层涉及到的调度部署管理技术站安全和日志监控的统一管理，整个数据中心做到全面的透明化。但是对于上层应用开发团队对底层就不用关心了，底层是由公有基础设施团队统一的运维管理整体的基础架构。

之前介绍的App-Centric机构其实是比较复杂的，如果企业要从零构建这样一个架构平台似乎成本会非常高，但是因为他周围生态圈提供的能力已经非常足够，所以我们有足够的理由采用它，一个是DCOS,一个商业产品，第二个是谷歌的Kubernetes，第三个Rancher，后两个本身就是开源框架，而第一个是4月左右宣布开源的，都是适用于生产环境的容器管理架构，App-Centric架构里需要的基本核心能力，他们基本上都具备，唯一一个不具备的，就是全局持续交付服务，虽然说他们都可以通过第三方工具集成的形式帮助企业构造交付流水线，但是并没有持续交付的调度，整个持续交付是零散的，很难控制的。没有一个整体的视角管理整个持续交付的生命周期和过程，企业的各个团队和业务线，被完全的分散开后是很难控制的。目前，这三个框架都没有提供这种能力，有可能他们都在做，有可能他们觉得这不是他们的方向，因为每个行业的性状导，每个行业交付的模式不同致交付的流水线和流程都不尽相同，这样的问题会留给使用这些框架的企业自己解决，这三个框架他只是提供了要打造App-Centric架构基础的能力，来减轻开发量的成本。我们简单分析一下这三个框架的优势和劣势，

第一个是DCOS，它是基于Mesos这个已经相当常熟分布式调度框架和基于Mesos的分布式编排工具Marathon打造的数据中心操作系统，能够高效的协调利用资源，调服，而且它并不仅仅局限于支持Docker，也支持各种分布式平台在其上被调度。在DCOS开源之前，我们也可以选择使用Mesos作为资源调服底层，结合其生态圈构建一套类似的框架，但非常零散，很难用在企业的生态环境里，因为管理的成本太高太复杂。DCOS开源以后把基于Mesos的这套工具集成起来提供了一个整体能力给我们，通过分布式的配置服务管理，基于Mesos框架，把集群看做是一个大型资源池来统一调服和管理资源，不仅可以管理Docker，还可以管理内部抽象的Mesos沙箱。把整个数据中心当成计算机，吧资源经过抽象以后，通过统一的管理方式去调度，这是他最后特点的地方，正因为如此内部还可以安装运行Kubernetes。

Kubernetes是谷歌提出的，谷歌内部每两年有20套容器，他出了Kubernetes的系统，把他平时体验到的实践，通过Kubernetes完成最后展现出来，他的架构和之前的DCOS差别不大，但是对于运维和部署的设计非常精致，他不仅对容器进行抽强，对内部抽象对部署方案也有抽象。内部有一个（Pude）的概念，或者有Docker这样的数据中心，这样形成一个调度和运维方式，当某一些服务中心需要多个做负载均衡的时候可以很容易的调度，当这个服务要对外调度的时候可以通过对这个服务进行一些设置，对外部访问，这样的一套框架也是我们App-Centric这个架构核心的地方，他提供我们的只是易于部署和管理的方式，现在出了1.2版本，可以支持一千个节点三万个容器调度的规模。

最后是Rancher，他的目标是做一个生产环境可用的容器管理平台。他是功能比较全面的平台，甚至提供了非常全面统一的UI管理，这样的管理他把生产环境需要用到的安全监控镜像监控网络包括企业LDAP服务的接入，包括底层云平台的管理，他是一个大而全的东西，目标着力于使Docker可以被用于生产环境。Rancher里面不仅有自己的调度系统，还包装了其他的调度系统，如当前在开发和社区相当活跃的Swarm和Kubernetes, 整因为Rancher背后的支撑相比于DCOS背后的微软和Kubernetes背后的谷歌显得比较无力，所以它集成这个两个人气组件以后可能会使更多开发者和感兴趣的人能够关注他。

DCOS在雷达里被定义为评估阶段，在对它进行定义的时候它还没有开源，可能在下一期雷达上会再往前迈一步，Kubernetes已经在试验阶段，目前很多生产环境已经使用Kubernetes，但是它是否能够持续稳定运行，且提供足够的生产环境所需能力 ，也需要进一步观察，Rancher和Kubernetes一样也处于雷达的试验，很多企业都比较有信心在生产环境采用这样一套开源解决方案，以为它的功能很全面，但是稳定性和规模还有待继续被验证。

通过以上介绍，到底哪一个是最好的，虽然感觉这三个东西提供的功能和能力差不多，但是我也很难有一个准确的答案，因为不同的企业关注的点不一样，都有自己的架构和发展方向的架构，很难说哪一个是最好的，三个系统各有优势，所以还是希望大家在选择方案的时候要多多借助于雷达来帮助你做好评估。

这样的一个交付模式和架构是不是解决了之前的问题。

第一是流程复杂，环境管理工作比较繁琐，我们对流程进行梳理透明化，流程非常清晰，而且他们之间的相辅相成的关系也能够保持整个交付的平滑度。

第二，准备和维护各种环境浪费大量的时间，我们如果采用这个架构，在开发环境定义好以后，后端不需要做任何环境的维护，因为他可以从开发环境调度到测试和生产环境。

第三个是遗留系统升级和迁移，Docker不仅是作为新系统的时候快速应用起来，还可以在迁移的时候足够可以运行，而不用担心迁移会不会成功或者有其他的影响，

最后一个基础设施的维护和扩展不够安全和高效，对于一个调度我可以很快的保障系统可扩展性和横向扩展力。

刚刚介绍的三个框架对于Docker生态圈来说不仅仅是这几个框架，在我们的技术雷达上还有其他的框架，它们可能没有这么全面，但是他都是在雷达上经过评估以后有一定使用价值的，到底哪一些框架使用自己打造自己的数据中心，还需要大家持续关注哪一些才是最适合自己的。