在线公开课 | 云原生下的DevOps与持续交付

课程概要
2009年，一场演讲在O’Reilly Velocity大会上一炮而红，演讲中有一句话深得人心：“因为开发和运维须要在Flickr（一个图片存储和视频托管网站）上合做，这致使开发者天天至少得进行十次部署。”演讲结束后，“DevOps之父”Patrick Debois受该演讲启发，在比利时发起一场名为DevOps之日的运动，号召开发和运维们，应该破除对立、走向合做。

DevOps是一个合成词，由开发（Developments）和运维（Operations）两个单词组成，其主要目的是拆断不一样部门之间隔离的墙。 简而言之，DevOps可让公司的流程更快、更有效，而且更可靠。那么，持续交付和DevOps到底有什么关系？为何要放到一块儿说？

4月1日，京东云与AI云产品研发部架构师井亮亮，讲授了《六周玩转云原生》第三讲：云原生下的DevOps与持续交付，让咱们来回顾一下精华内容吧！

关于云原生的解释有不少种，这张PPT里列了常见的两种说法，大致意思是云原生是持续交付+DevOps+微服务+容器化。

六周玩转云原生

云原生下的DevOps与持续交付

— 京东智联云 井亮亮—

概念与简介

关于云原生的解释有不少种，这张PPT里列了常见的两种说法，大致意思是云原生是持续交付+DevOps+微服务+容器化。

也就是说，云原生是一个概念集合，既包含微服务、容器，也包含更多的管理方法，好比持续交付、DevOps和重组等。

那么如何定义云原生？下面这张图是CNCF官网对于云原生的定义，也是相对来讲比较靠谱的定义。而想了解云原生，就得先了解K8S，由于它是云原生的基石。

- K8S

K8S是CNCF的第一个项目，云原生整个生态都是依靠K8S构建出来的。云原生的表明技术包括容器、微服务、服务网格、不可变基础设施和声明式API等。

- DevOps

每当你们提起DevOps，总把它比做盲人摸象，不少公司的叫法也不同。有的企业会把内部上线平台说成这是本身构建的DevOps。

但咱们先看维基百科的定义：即透过自动化“软件交付”和“构建变动”的流程，来使得构建、测试、发布软件可以更加快捷、频繁和可靠。

-持续集成、持续交付和持续部署

持续交付可让软件交付变得更快更频繁，即随时均可以发布，它的目标是让软件的构建、测试与发布变得更快、更频繁。要确保效率，就只能交付得更快，但交付更快的前提是确保质量。提及持续交付，不少人还听过持续集成、持续部署。以下图所示，这三者之间存在着必定差异。

在传统软件开发中，开发者在项目结束后都须要作集成，这一过程少则几星期、多则几个月。软件开发在中早期时，须要频繁地进行集成，频繁集成的好处就是，避免到最后环节才发现问题。

不少人可能会说，咱们团队早就集成了，那么大家多久构建一次？是否是每次发布时才走构建流程？若是是这样就要考虑一下持续集成。由于持续集成是持续交付的第一步。

而持续交付就是把前面全部东西集成在一块去交付给客户。固然不一样公司对于这个阶段的叫法也有所不一样，有些叫“测试-生产”，有些叫“测试-准生产”或者“上线”等等。

持续部署的意思是，全部环节都是自动化的，开发者提交完代码以后，能够自动化部署到生产环境里。持续部署跟持续交付惟一的区别就是，开发者可否把产品自动化地发布到生产环境里。

近年来，技术名词更新很是快。关于此，在基础设施方面体现得最为明显，几年前发布一个应用去部署时通常有以下几种选择：最好最根本的办法就是建机房，但全部的硬件、网络、水电等问题都得考虑进去；其次是搞服务器、装操做系统，最后再部署或者虚拟化一下。

再后来，咱们会作相似VMware的虚拟机，即在上面虚拟化一下部署方式，直接写一些脚本执行一下就能跑起来。再日后，你们都开始搞相似OpenStack一类的私有云技术。

不管方法如何变化，也不管你用什么基础设施，最后都会演变成混合云或者多云的方式，你的交付不只要支持这些模式、更要支持容器包。当前这个过程也变得愈来愈自动化，且愈来愈能知足业务诉求。好比，咱们会用弹性伸缩技术，来知足业务需求和成本诉求。

持续交付-流水线？

持续交付须要一系列的过程，在这一系列的环境中，不管是测试、预发、生产，越日后就越接近客户的环境。尽管每一个阶段关注的问题都不同，但你会发现，每个过程和环境都须要作发布作验证。

而经过流水线的方式，就能很好地把这一系列过程自动化起来，开发者构建的效率和发布的质量也会借此提升。

- 软件交付的挑战和问题

上图是2016年一个DevOps的调查报告截图。你们都知道，软件交付的过程自己，意味着线上变动，变动就意味着有风险。交付最大的挑战是上线过程当中遇到失败，失败的话确定会引起线上故障。

2016年的调查报告显示，81%的团队能将失败比例控制在15%之内，可是能把失败比例控制在5%的团队只有35%。这意味着发布100次就有50次故障。因此，变动对于软件交付的质量至关重要。

既然质量这么重要，那该如何选择交付工具？下面这张图，供你们参考。

- 流水线

世界上的第一条流水线，由福特汽车提出并上线。在当时，流水线极大地提升了汽车生产效率。而开发者在提交完代码后，把软件交付到客户手里，一样也会经历一系列的过程。那么这个过程怎么去建模和运行？

这时就得结合流水线的目标来推动，流水线的目标是快速集成、快速交付，能够说流水线其实就是个管道，它并无一个标准的流程，咱们彻底能够根据业务去定制。

好比说，当你要构建一个流水线，你可能须要代码扫描、代码测试、测试部署再预发等等一系列过程。可是你怎么确保本身作的流水线能够很好地运行？

这个问题并不难，作到如下三点就能够：

第一，必定要作自动化构建。不少开发者以为已经作了自动化了、已经持续集成了。可是若是你在构建上不够自动化、也不够及时，那就谈不上测试或者集成。

第二，必定要作自动化测试。构建完以后产生的产物确定要测试，不管是功能测试、性能测试、仍是压力测试。这个测试过程是为了达到预期质量，但也要根据状况去作自动化，由于只有自动化才能提升效率。

第三，持续集成。流水线只有重复、快速、频繁地运行，才能发现问题、解决问题。

在整个软件行业，起码作到以上三点，才能达到持续交付的目标。世界上的第一条流水线，由福特汽车提出并上线。在当时，流水线极大地提升了汽车生产效率。而开发者在提交完代码后，把软件交付到客户手里，一样也会经历一系列的过程。那么这个过程怎么去建模和运行？

- 最基本的部署流水线

上图虽然是最基本的流水线，可是你们能够看到，它涵盖整个环节，包括源代码环节、提交环节构建、测试和代码分析等等，到了后面就是验收、UAT测试生产环境、制品发布到生产环境。

- 一些流水线实践

上图是一些流水线的实践，具体能够分为三方面：

- 二进制包只构建一次

二进制包只构建一次的意思是，开发者在每次写完代码后再构建一次，从而生成一个二进制包，而后再去进行后面的流程。这样不只能够避免浪费时间、还能提高效率。

但即使是这样，仍然出现两次构建的结果不一样的状况，这是由于虽然你的代码和ID没变，可是你的包可能会产生变化。

- 要采用同一部署方式在不一样环境里

在发布部署时，全部部署的方式和环境，例如测试、预发和生产都采用同一种方式部署，而不是部署到测试环境时用Jenkins作持续集成，生产环境要发布时却经过另一套工具去部署。部署工具不同就有可能致使最终交付的产物不同。

在线上生产环境时，无论用物理机、云主机仍是虚拟化物理机，都要确保它的高可用性能。这时就须要堆一堆资源，来保障线上用户的可用性。

- 流水线管道要灵活

流水线存在的意义，是为了提高效率和确保质量，可是开发者的业务可能有Java的、可能有Go的。所以你的流水线，要知足各类各样的诉求。

好比说，有些团队一套测试环境就够了，另一个项目可能以为该项目要提供给别的团队作联调，这时就要确保测试环境的稳定性，好比构建两套测试环境，A环境能够团队本身拿来作工程验证，B环境则能够提供给第三方去联调。

最后须要作的，是验证整个流水线的落地，不能说你把整个流水线构建起来了，而后就按照这种方式去走。真正落地时，要考虑到每次代码提交完成后 ，是否完成了自动化触发测试的流程。

京东智联云在持续交付的实践

每一个企业作持续交付的经验，都是一步一步趟出来的。

京东最先的固定上线日是周二和周四，为了确保稳定性，研发人员不能去操做线上环境，那么就得运维上线去操做。这时产品经理们就会在运维后面排队，可是排队的效率比较低，而且那时尚未上线工具，自动化能力也特别差，线上故障的修复也没法获得保障。直到后来，才开始想办法填平。

- 两条交付的流程

在京东早期的两条交付流程中，第一条交付流程从开发、编译构建、代码分析、抽包到整个上线都有涵盖到。

在工具上，私服用的是商业版Artifactory、构建用的是Jenkins、代码扫描用的是SonarQube、对象存储用的是内部一个私有云，发布用的是rsync。

在第二条交付流程中，最大的变化是咱们把rsync替换成ANSIBLE了，这的确极大提高了效率，而且解决了排队问题。

因此在发布过程当中，咱们原来是抽包模式，后来所有改为全量包的方式。另一块是提测，原来咱们只作功能测试，后来安全测试也作，原来只是对接静态代码扫描，后来也作安全漏洞的筛查。这两条流水线有一个共性问题，即每条流水线都会有一条测试包、一条生产包。

目前京东智联云的实践，基本分为三套环境，一套测试、一套预发、一套生产，测试、预发、生产与网络之间又是相互隔离的。

如上图所示，京东智联云的流水线会从源代码、构建、代码检查、测试依次进行，预发环节和生产环节基本都有涵盖到，假如核心功能自动化这块失败了，开发者得确保部署到测试环境后可以作到自动化验证测试环境的功能，最起码确保测试环境的核心功能没有问题。

从设计角度来讲，整个流水线自己就是一个管道，管道里面每个原子的功能都是独立的，像安全代码检测确定是安全团队更专业，京东智联云在这一块就是安全团队去作的，他们提供安全机制，确保原子能力建设，咱们经过流水线把它接过来。

- 持续交付最核心的就是规范

能够说，持续交付就是一个编排，你们都知道Jenkins特别流行，那为何京东智联云的持续交付不能直接用Jenkins呢？由于持续交付最核心的一块就是规范。部署平台比如在大草原上放羊，必定得有牧羊犬管理羊群。

- 京东智联云如何作规范

京东智联云全部线上的操做都以同一套上线平台控制系统去作，这样的好处首先是减小风险，另外是统一控制系统可以作到秒级回滚。

其次，部署平台要用统一的账号去作发布，出问题后好操做。而统一规范的实例部署路径、日志路径，都是按照必定目录去作，目录若是出问题，很快可以经过日志平台或者京东智联云内部平台“门神”去快速找到问题。

此外，京东智联云内部有整套DevOps平台，该DevOps平台涵盖各个方向，目标就是解决软件全生命周期的问题，包括开发、测试、运维，让开发者经过工具更好地工做。整个工具层面包含项目协做部分、开发工具和测试部分。

在配置管理方面，京东智联云的配置管理不只涵盖应用层面的一些服务管理，好比人员角色的权限等。当把这些东西做为基础数据的核心，那后面的业务逻辑，包括监控、发布、日志等全部的服务基础数据都已经有了。

京东智联云是按照App的维度，向上是整个组织结构，向下会把整个模块和机器的信息管理起来，这时就不须要考虑发布机器的状况，只须要考虑发布哪一个App，以什么流量切换的方式去发布它。持续交付真正的核心是靠流水线把整个环节去打通，京东智联云的监控是一个比较全链路的监控，不只仅包括技术层面的监控、底层基础设施、容器、物理机，还支持混合云。

如今的企业通常不可能只用一种云或者只用本身构建的私有云，公有云也可能不会只用一家的，可能有A家的、有B家的，这种模式的话，无论是交付仍是监控，都要作到支持基础设施混合云的模式。这样的话，就得在上层作到统一调度，全部监控部署的Agent也要作统一管控。此外，以下图所示，在这方面京东智联云也会对外输出本身的经验。

- 如何落地方案

在企业里面实施DevOps，很大一部分状况是企业已经用了一些东西，而后想用Jenkins提升一些能力。这时就要考虑为何要作改变，而且说服你的老板或同事去作内部DevOps工具链条的改变。

这里有两种改变的方式，一种是国家信通院跟DevOps社区出具了一个DevOps标准，这个标准是上百个专家力量一块儿写的，你们能够参考一下。

云原生下持续交付

京东智联云上的工具链条比较多，目前咱们正在作公测的过程当中，将来会把内部项目管理的实践，以原生的方式开放给你们。

Ops部分则包含日志服务、监控、云拨测、云事件、运维的堡垒机能力，这一块也是咱们内部自研的一款叫作“门神”的产品，这款产品已经支撑京东内部好几年了，0故障。当下，京东智联云以云原生的方式，进行的开发，预计会在下一步开源出去。

另外，京东智联云也支持Terraform和Packer能力，能够帮助开发者快速构建基础设施。整个京东智联云是以原生的方式，把工具以各类原生作法提供各类API，其目的就是但愿帮助你们在原生云下构建属于本身的能力。

TIPS：在这样一顿操做以后，不少参加课程的小伙伴都纷纷表示咱们这个系列的课程「帮助小白走近云原生的大门」，并对下次课程充满期待！

这里提醒你们一下，《六周玩转云原生》的第四期课程走近监控与日志，云原生基石探秘即将和你相见！

小伙伴们千万不要错过！扫码关注社区，追踪更多课程信息吧

云原生的时代已来，而你，也将成为这个新时代的构建者之一！

欢迎点击“更多”观看视频回顾。