转自:FIT2CLOUD http://blog.fit2cloud.com/2014/12/14/devops-system-evolution.html
作者: Jason
在过去的几十年里,为了按时交付软件产品和服务,大家越来越意识到,对于传统把开发和运营割裂开的做法,不适合现代产品和服务开发的需求。于是,把 开发和运营作为整体来看待的DevOps工程思想逐步深入人心,随之也逐步有了对DevOps系统的需求,希望能有个平台或工具来统一支持开发和运营的交 付工作及之后的环境管理工作,即需要一系列的持续集成,持续交付,自动化部署,自动化测试监控,自动化伸缩,自动化恢复系统,以提升开发测试运营过程中的 部署效率,简化开发测试运维过程的管理,降低交付风险,降低沟通成本及运营成本。
从广义来讲,不管是云管理平台工具(比如RightScale),还是各种PaaS平台(CloudFoundry,Heroku etc.),还是自动化部署工具比如Chef、Puppet和Ansible等,其本质上都是DevOps系统的一部分,都是为了解决在开发过程的交付环 节问题和交付后的运营管理问题,即
这些年,随着云计算和容器技术的进步,以及产品业务对IT能力的需求推动,DevOps系统发展越来越快,其角色和概念也越来越清晰和独立。回顾其 发展的路径和变迁的过程,我们认为基本可以分为三代:基于物理机或独立虚拟机的部署时代,基于IaaS可编程资源的部署时代和基于容器的部署时代。随着这 三代的改进,DevOps系统的整体能力越来越强。下面我们首先看一下各代DevOps系统的特点和能力,之后再对DevOps系统进行更进一步的分类, 以帮助我们选择合适的DevOps系统。
这是第一代DevOps系统,特点是静态配置 + 人工协调 + 仅应用部分自动部署。
在搭建整个应用系统的过程中,首先需要在DevOps系统外创建运行应用所需的资源环境(如主机,网络,存储等),DevOps系统对这部分没有控 制,只负责在资源环境搭建好后自动化部署应用,资源环境的搭建与之后的应用部署过程是割裂开来的,需要人为的手工协调控制,即等资源环境搭建好后,由人控 制时机,等待资源环境准备好后再手工修改配置(如各种主机IP地址,登陆密码Key信息),然后手工运行自动化脚本工具,如 Shell,Python,Ruby脚本,进行应用的安装部署升级,而且之后当增加或减少节点后,也由人来手工运行自动化脚本来配置系统,不能实现包括资 源环境创建或节点变更到应用部署的整个过程的一键部署,即集群感知 + 自动协调控制 + 动态配置 + 全栈自动化。
目前,可以说大多数的DevOps系统仍然停留在这个阶段,由于DevOps系统没有实现资源环境创建的自动化与基于集群感知的协调自动化,那么这个阶段的DevOps系统的能力会造成以下几个影响和后果:
这里需要提的一点就是,尽管很多组织已经在使用IaaS(如阿里云)创建虚拟机搭建应用系统所需资源环境,但是并没有实现集群感知,系统整套环境创 建的自动化,仍然停留在半自动化的阶段(例如,先启动一组包年包月虚拟机后,然后手工配置部署脚本所需IP地址,登陆密码,登陆密钥等信息,然后手工运行 自动化脚本部署),所以这种方式仍然属于第一代的DevOps系统。同时,这也是国内大多数组织DevOps的现状,其自动化和效率的改进空间巨大。
这是第二代DevOps系统,特点是集群感知 + 自动协调控制 + 动态配置 + 全栈自动化。
借助于云计算IaaS资源的可编程特性,这一代的DevOps系统实现了集群感知,自动协调控制,动态配置,全栈自动化,即实现了从创建环境到部署 安装应用组件整个过程的一键创建和部署,并且在创建后的阶段,能够实现集群感知(Cluster-Aware),即自动根据环境的变更,自动部署和配置系 统。举个例子,某网站业务量增长需要扩容时,当人为添加Web计算节点后,能够自动在新添加Web虚拟机启动后安装Web组件,并将各个虚拟机Web服务 注册配置到负载均衡服务中,当收缩时,自动移除,这个过程不需要人为的协调控制,DevOps系统能够根据集群的变化自动地配置集群。
目前,做到这个层面DevOps系统还是比较少的,由于这个阶段的DevOps系统自动化管理覆盖了环境的创建变更,应用组件部署自动化,以及环境 创建,集群感知和应用组件部署的各个过程自动化协调控制,那么这个阶段的DevOps系统相比第一代会给开发和运维工作带来以下非常巨大的改进:
这是第三代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系统呢? 这里我们建议一种基于目标系统分类的选择方法。我们根据要管理的目标应用或系统类型来分类,对于目标系统,我们可以将其首先分为三大类,即IaaS服务系 统,PaaS服务系统,应用系统,应用系统又可以分为简单的Web应用系统,复杂的分布式系统,那么有了这个分类,我们选择DevOps系统和工具就会相 对容易和明确一些。
由于IaaS系统的创建,本身就是基于物理机创建的,所以对于这类的系统,其适用的DevOps系统或工具就是Shell,Chef, Puppet及IaaS服务提供商自身开发的自动化运维管理系统,只能选用第一代的基于物理机的DevOps系统。
如果一个PaaS不是部署在IaaS之上,从本质上说这不是一个PaaS,因为其不具备弹性和自动伸缩。真正的PaaS系统是部署在IaaS上,为 开发测试运维人员来提供服务,那么其适用的DevOps工具就可以选用 RightScale,Scalr,Cloudformation,Opsworks和FIT2CLOUD这类第二代基于IaaS可编程资源的 DevOps系统,当然也可以选择第三代基于容器的DevOps系统,只是第三代的目前还在发展中,还不如第二代成熟。
对于简单的Web应用系统,突出的特点就是应用的结构简单,比如只包含一个Web组件及数据库,缓存,或一些常见的中间件服务等,没有包含非常多的 分布式组件,那么对于这类的系统可以选择容器类的传统PaaS,即CloudFoundry,Heroku,OpenShift等。
对于复杂的分布式应用系统,无法使用容器类PaaS来管理,只能通过自定义的DevOps工具或系统,或者使用云管理 RightScale,Scalr,Cloudformation,Opsworks,FIT2CLOUD这类工具的某种或某种组合,即第二代基于 IaaS可编程资源的DevOps系统,也可以选择第三代基于容器的DevOps系统。因为这类工具给用户提供了对IaaS主机更大的控制权,且提供了各 个部署过程中的回调接口,实现了集群感知及各个部署过程的自动协调控制,即全栈自动化。
以上是我们对DevOps系统变迁的一些思考,大家通过微博和我们进行讨论,我们的微博是:@fit2cloud。