DevOps系统的变迁

简介:

DevOps系统的变迁

一、DevOps的起源和发展历程

在过去的几十年里,为了按时交付软件产品和服务,大家越来越意识到,对于传统把开发和运营割裂开的做法,不适合现代产品和服务开发的需求。于是,把 开发和运营作为整体来看待的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系统仍然停留在这个阶段,由于DevOps系统没有实现资源环境创建的自动化与基于集群感知的协调自动化,那么这个阶段的DevOps系统的能力会造成以下几个影响和后果:

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

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

2. 基于IaaS的部署时代

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

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

第二代DevOps系统

第二代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系统?

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

原文发布时间:2014-12-23

本文来自云栖合作伙伴“linux中国”

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
3天前
|
Kubernetes Cloud Native Devops
云原生技术落地实现之二KubeSphere DevOps 系统在 Kubernetes 集群上实现springboot项目的自动部署和管理 CI/CD (2/2)
云原生技术落地实现之二KubeSphere DevOps 系统在 Kubernetes 集群上实现springboot项目的自动部署和管理 CI/CD (2/2)
60 1
|
人工智能 运维 Kubernetes
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
研发效能提升不知从何下手、一头雾水?阿里资深技术专家一文为你揭秘研发效能提升的系统方法
3820 1
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
|
存储 Kubernetes Java
DevOps基于k8s发布系统CI/CD的实现
在微服务、DevOps和云平台流行的当下,使用一个高效的持续集成工具也是一个非常重要的事情。虽然市面上目前已经存在了比较成熟的自动化构建工具,比如jekines,还有一些商业公司推出的自动化构建工具,但他们都不能够很好的和云环境相结合。那么[究竟该如何实现一个简单、快速的基于云环境的自动化构建系统呢](https://github.com/tiandizhiguai/dhorse)?
DevOps基于k8s发布系统CI/CD的实现
|
缓存 运维 Kubernetes
『KubeSphere』KubeSphere可插拔组件之DevOps系统
📣读完这篇文章里你能收获到 - 初步认识KubeSphere DevOps可插拔组件 - KubeSphere DevOps组件的安装
272 1
『KubeSphere』KubeSphere可插拔组件之DevOps系统
|
Kubernetes 安全 搜索推荐
Istio生态系统ON ASM(4):在阿里云服务网格ASM中集成阿里云云效Flow实现DevOps
在阿里云服务网格(简称 ASM)企业版实例中,兼容 Istio,支持多个 Kubernetes 集群统一流量管理,为容器和虚拟机应用服务提供一致性的通信控制。基于服务网格最新的“数据面KubeAPI访问"能力,能够通过数据面集群的kubeconfig来管理Istio资源。和阿里云Flow等云效工具集成后,可以享受DevOps、GitOps带来的应用发布的便利性,还能够利用Istio细粒度
226 0
Istio生态系统ON ASM(4):在阿里云服务网格ASM中集成阿里云云效Flow实现DevOps
|
IDE JavaScript 前端开发
terra++ - 一种中心稳定,可扩展的devops可编程语言系统
本文关键字:devops可编程的语言系统。programmable language,可编程容器和可编程语言系统,c++ as terra++
141 0
terra++ - 一种中心稳定,可扩展的devops可编程语言系统
|
运维 监控 Devops
汇丰银行30年恐龙级 IT 系统,DevOps 成功改造
当今需求瞬息万变,传统的瀑布式开发已经严重影响了“传奇”们对需求反应的时效性。加之服务渠道的变迁和新技术的冲击,传奇也慢慢变成了残喘在历史边缘巨大而笨重的恐龙。因此敏捷转型和 DevOps 改造,成了“传奇”能否继续老当益壮,砥砺前行的关键。
2383 0
|
2天前
|
运维 Kubernetes Devops
构建高效稳定的云基础设施:DevOps与容器化技术融合实践
【5月更文挑战第15天】 在当今的云计算时代,企业为了保持竞争力,不断寻求提高软件交付速度和服务质量的方法。本文将探讨如何通过结合DevOps原则和容器化技术来构建一个既高效又稳定的云基础设施。文章首先介绍了DevOps的核心概念及其如何促进开发与运维的协作,然后详细阐述了容器化技术如何优化应用部署和运行环境。最后,通过一个实际案例分析,展示了这种融合策略在提升自动化水平、加快部署速度以及增强系统稳定性方面的具体成效。

热门文章

最新文章