DevOps系统的变迁

一、DevOps的起源和发展历程

在过去的几十年里，为了按时交付软件产品和服务，大家越来越意识到，对于传统把开发和运营割裂开的做法，不适合现代产品和服务开发的需求。于是，把 开发和运营作为整体来看待的DevOps工程思想逐步深入人心，随之也逐步有了对DevOps系统的需求，希望能有个平台或工具来统一支持开发和运营的交 付工作及之后的环境管理工作，即需要一系列的持续集成，持续交付，自动化部署，自动化测试监控，自动化伸缩，自动化恢复系统，以提升开发测试运营过程中的 部署效率，简化开发测试运维过程的管理，降低交付风险，降低沟通成本及运营成本。

从广义来讲，不管是云管理平台工具(比如RightScale)，还是各种PaaS平台(CloudFoundry，Heroku etc.)，还是自动化部署工具比如Chef、Puppet和Ansible等，其本质上都是DevOps系统的一部分，都是为了解决在开发过程的交付环 节问题和交付后的运营管理问题，即

• 在开发和测试过程中，帮助开发测试人员搭建和管理环境，以便在变更后部署变更以测试;
• 在运营和支持过程中，帮助运营支持人员升级系统，扩展重建恢复系统，在升级后能够持续地掌握系统整体和各个栈的状态，从各个层面监控系统，伸缩系统，恢复系统。

这些年，随着云计算和容器技术的进步，以及产品业务对IT能力的需求推动，DevOps系统发展越来越快，其角色和概念也越来越清晰和独立。回顾其 发展的路径和变迁的过程，我们认为基本可以分为三代：基于物理机或独立虚拟机的部署时代，基于IaaS可编程资源的部署时代和基于容器的部署时代。随着这 三代的改进，DevOps系统的整体能力越来越强。下面我们首先看一下各代DevOps系统的特点和能力，之后再对DevOps系统进行更进一步的分类， 以帮助我们选择合适的DevOps系统。

二、DevOps的变迁及其关键使能技术

1. 基于物理机/独立虚机的部署时代

这是第一代DevOps系统，特点是静态配置 + 人工协调 + 仅应用部分自动部署。

在搭建整个应用系统的过程中，首先需要在DevOps系统外创建运行应用所需的资源环境(如主机，网络，存储等)，DevOps系统对这部分没有控 制，只负责在资源环境搭建好后自动化部署应用，资源环境的搭建与之后的应用部署过程是割裂开来的，需要人为的手工协调控制，即等资源环境搭建好后，由人控 制时机，等待资源环境准备好后再手工修改配置（如各种主机IP地址，登陆密码Key信息），然后手工运行自动化脚本工具，如 Shell，Python，Ruby脚本，进行应用的安装部署升级，而且之后当增加或减少节点后，也由人来手工运行自动化脚本来配置系统，不能实现包括资 源环境创建或节点变更到应用部署的整个过程的一键部署，即集群感知 + 自动协调控制 + 动态配置 + 全栈自动化。

目前，可以说大多数的DevOps系统仍然停留在这个阶段，由于DevOps系统没有实现资源环境创建的自动化与基于集群感知的协调自动化，那么这个阶段的DevOps系统的能力会造成以下几个影响和后果:

• 创建系统资源环境效率低、耗时、风险高，特别是创建复杂的系统组件多结构复杂时;
• 创建系统资源环境过程需要专门的网络工程师、系统工程师，不能够实现开发测试运维人员自助服务，系统越复杂，沟通成本越大，开发运维过程管理也越复杂;
• 创建整个系统需要网络工程师，系统工程师，开发人员的共同参与和合作，系统组件越多结构越复杂，沟通成本越大，开发运维过程管理也越复杂，费时费力，协调麻烦，风险高且易出错;
• 当系统资源环境变更时，如在增加减少主机后，由人来手工协调控制，人为手工静态配置部署升级所需IP，登陆密码或Key等信息，造成变更过程风险高且效率低，特别是系统庞大和复杂时;
• 交付过程风险高，开发测试产品各个环境不统一，经常出现在一个环境里运行正常，另外一个环境不正常的现象

这里需要提的一点就是，尽管很多组织已经在使用IaaS（如阿里云）创建虚拟机搭建应用系统所需资源环境，但是并没有实现集群感知，系统整套环境创 建的自动化，仍然停留在半自动化的阶段（例如，先启动一组包年包月虚拟机后，然后手工配置部署脚本所需IP地址，登陆密码，登陆密钥等信息，然后手工运行 自动化脚本部署），所以这种方式仍然属于第一代的DevOps系统。同时，这也是国内大多数组织DevOps的现状，其自动化和效率的改进空间巨大。

2. 基于IaaS的部署时代

这是第二代DevOps系统，特点是集群感知 + 自动协调控制 + 动态配置 + 全栈自动化。

借助于云计算IaaS资源的可编程特性，这一代的DevOps系统实现了集群感知，自动协调控制，动态配置，全栈自动化，即实现了从创建环境到部署 安装应用组件整个过程的一键创建和部署，并且在创建后的阶段，能够实现集群感知(Cluster-Aware)，即自动根据环境的变更，自动部署和配置系 统。举个例子，某网站业务量增长需要扩容时，当人为添加Web计算节点后，能够自动在新添加Web虚拟机启动后安装Web组件，并将各个虚拟机Web服务 注册配置到负载均衡服务中，当收缩时，自动移除，这个过程不需要人为的协调控制，DevOps系统能够根据集群的变化自动地配置集群。

目前，做到这个层面DevOps系统还是比较少的，由于这个阶段的DevOps系统自动化管理覆盖了环境的创建变更，应用组件部署自动化，以及环境 创建，集群感知和应用组件部署的各个过程自动化协调控制，那么这个阶段的DevOps系统相比第一代会给开发和运维工作带来以下非常巨大的改进:

• 开发测试运维人员能够自助创建环境和部署系统，系统越复杂，沟通成本减少越多，开发运维过程管理复杂性风险减少越多，比如只能由有专门知识的工程师做，如果工程师在需要的时候不可用，就很麻烦;
• 创建环境和部署效率高，自动化，快速，所需时间少，风险低;
• 当系统资源环境变更时，如伸缩时，在增加减少主机后，能够实现集群感知，动态配置集群，提高变更过程效率且降低风险，特别是系统组件多庞大和复杂时;
• 能够按需快速创建环境满足各种测试，演示，上线扩容需要
• 能够按需创建启动关闭开发测试环境，节约成本
• 能够提高开发测试和交付的效率

3. 基于容器的部署时代

这是第三代DevOps系统，特点是在第二代基础上，又增加了应用跨云可迁移性。(基于容器技术)。

借助于云计算IaaS资源的可编程特性以及Linux容器技术，不仅实现了集群感知，自动化协调，动态配置和全栈自动化，而且实现了应用跨云可迁移 性和弹性伸缩，消除了开发，测试，生产环境的不一致，使应用不会被锁定在某个IaaS上，让所有的基础设施服务IaaS及物理机都变成通用的资源池，还可 以提高资源利用率，这给IT的开发建设和运营带来了更多更大的想象空间，这也是Docker，Kubernetes现在很火的原因。

举个例子: 如果我们想把一套服务从AWS迁移到Azure上，那么，我们将不得不从头开始创建一组虚拟机镜像及虚拟机，并配置安装系统或应用的组件，如果系统复杂庞 大的话，这个过程仍然会耗费很多的时间和人工，并且依赖于某些具备这个知识的工程师，但是如果有容器技术及相关容器工具的支持，那么这个过程会变成一个非 常快速简单的过程，变成在目标云如Azure上自动启动需要的标准虚拟机，然后下载容器镜像，配置启动容器，配置相关DNS等，真正实现方便的跨云迁移， 和弹性动态的伸缩服务。

再举个例子，目前Google开源的容器管理系统Kubernetes可以说得到了工业界的广泛认同和支持，当我们已经做好应用系统的Docker images后，那么只要在各个不同的IaaS上有支持Docker的环境，如Kubernetes集群，那么我们就能在不同的IaaS上快速方便的迁移 应用系统，或者扩容，下图展示了基于FIT2CLOUD的跨云部署和管理解决方案，我们希望未来用户可以使用FIT2CLOUD在多个不同的IaaS上创 建Kubernetes集群，通过Kubernetes管理和部署应用系统。之后，我们会有新文章来分享FIT2CLOUD是如何创建和运维 Kunerbetes集群的。

上面这一节中我们介绍了不同时代的DevOps系统的特点和能力，那么是不是我们直接选择能力最强的第三代DevOps系统就可以了吗? 是不是选一种DevOps系统就通杀了呢? 答案是否定的，每种DevOps系统都不是银弹，都需要我们根据要管理的系统的需求来选择合适的DevOps系统或工具，在接下来的一节，我们来回答这个 问题。

三、如何选择适合自己的DevOps系统？

目前DevOps系统可以说五花八门非常多，功能上差别大，适用场景也不同，那么我们究竟该如何选择合适的DevOps系统呢? 这里我们建议一种基于目标系统分类的选择方法。我们根据要管理的目标应用或系统类型来分类，对于目标系统，我们可以将其首先分为三大类，即IaaS服务系 统，PaaS服务系统，应用系统，应用系统又可以分为简单的Web应用系统，复杂的分布式系统，那么有了这个分类，我们选择DevOps系统和工具就会相 对容易和明确一些。

1. IaaS服务系统

由于IaaS系统的创建，本身就是基于物理机创建的，所以对于这类的系统，其适用的DevOps系统或工具就是Shell，Chef， Puppet及IaaS服务提供商自身开发的自动化运维管理系统，只能选用第一代的基于物理机的DevOps系统。

2. PaaS服务系统

如果一个PaaS不是部署在IaaS之上，从本质上说这不是一个PaaS，因为其不具备弹性和自动伸缩。真正的PaaS系统是部署在IaaS上，为 开发测试运维人员来提供服务，那么其适用的DevOps工具就可以选用 RightScale，Scalr，Cloudformation，Opsworks和FIT2CLOUD这类第二代基于IaaS可编程资源的 DevOps系统，当然也可以选择第三代基于容器的DevOps系统，只是第三代的目前还在发展中，还不如第二代成熟。

3. 简单的Web应用系统

对于简单的Web应用系统，突出的特点就是应用的结构简单，比如只包含一个Web组件及数据库，缓存，或一些常见的中间件服务等，没有包含非常多的 分布式组件，那么对于这类的系统可以选择容器类的传统PaaS，即CloudFoundry，Heroku，OpenShift等。

4. 复杂的分布式应用系统

对于复杂的分布式应用系统，无法使用容器类PaaS来管理，只能通过自定义的DevOps工具或系统，或者使用云管理 RightScale，Scalr，Cloudformation，Opsworks，FIT2CLOUD这类工具的某种或某种组合，即第二代基于 IaaS可编程资源的DevOps系统，也可以选择第三代基于容器的DevOps系统。因为这类工具给用户提供了对IaaS主机更大的控制权，且提供了各 个部署过程中的回调接口，实现了集群感知及各个部署过程的自动协调控制，即全栈自动化。

以上是我们对DevOps系统变迁的一些思考，大家通过微博和我们进行讨论，我们的微博是：@fit2cloud。

来自：http://blog.fit2cloud.com/2014/12/14/devops-system-evolution.html