DevOps 系统的变迁

Question

一、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 主机更大的控制权，且提供了各 个部署过程中的回调接口，实现了集群感知及各个部署过程的自动协调控制，即全栈自动化。