>>返回主页
京东工程效率专家 石雪峰 JenkinsX:基于Kubernetes的新一代CI/CD平台

2018-08-15 16:00

石雪峰.jpg

  石雪峰:今天很荣幸,给大家分享一下关于Jenkins X开源项目的一些最新进展,可能有的同学之前也听过我讲过这个项目,作为社区来说,对Jenkins X项目也倾注了很大的精力,不断有一些新的想法或者是工具整合进来,发布半年来始终保持着一个旺盛的生命力,所以借此机会还是给大家介绍一下代表着下一代云原生应用流水线的解决方案。

  首先自我介绍一下,我是石雪峰,是Jenkins的认证工程师,也在社区参与一些活动和项目,期望更好的推进Jenkins在国内的发展,今天给大家带来的就是社区的重点项目之一Jenkins X。

  可信云大会举办这些年来,云计算迅猛发展,大家从昨天的栗主任的云计算发展报告中也能看到,整个云计算行业的发展趋势依然向好,其中孕育了巨大的变革。对于我们来说,已经谈了很多理念、方法,但最终还是想通过一些具体的工具或者说技术方法帮助大家实现真正落地。面对目前这样一个云原生应用时代,DevOps、持续交付、容器和微服务是典型的代表。这一波技术变革迅猛无比又异常深刻,更重要的是不仅仅局限于单一领域,而是涉及基础设施,软件架构,部署发布方式,研发过程,组织文化等,彼此独立又互相推动,裹挟着行业向前发展。同时新技术层出不穷。前两天lstio正式发布了1.0版本,同时容器监控领域的代表项目Prometheus也正式从CNCF毕业。技术人员需要不断学习,同业务发展速度赛跑,这就是我们在云原生应用时代所面临的真正的挑战。

  云原生应用架构基本上符合这种模式,包括微服务,API,消息队列,缓存和分布式数据库,面对这种全新的应用架构,我们的选择非常多,包括各种各样的开源商业工具,公有云、私有云和混合云,伴随冗余建设的基础设施,高度人员能力依赖的解决方案,大量的评估和研究成本在里面,以及组织内部的高度差异化,而这并非核心价值所在,所以平台就有了存在的意义。

  在这时候Kubernetes应运而生,可以说对容器云平台而言, 它是一个改变世界的工具。的确随着Kubernetes项目的不断成熟,它为我们解决了很多云原生应用时代的难题,比如服务发现、滚动升级、弹性集群、资源管理、调度编排等等。同时Kubernetes也构建了自己的完整的生态系统从而实现了云原生应用时代的弯道超车。在这个生态系统中包括了云基础设置服务、日志监控、管理,安全等等,但唯独缺少的就是持续交付能力平台,所以我们想解决的问题是什么呢,答案就在Jenkins X。

  Jenkins X是什么?简单用一句话描述,我们认为Jenkins X是Kubernetes原生的CI/CD解决方案,用于云原生应用的快速开发和部署。我们想解决的问题是为Kubernetes生态系统建立原生的CI/CD平台,复用Jenkins自身能力,简化整个云原生应用的开发,部署,运行过程。所以Jenkins X是基于Kubernetes,这是它的核心价值,另外它更面向云原生应用更适合复杂的应用架构下的系统开发。

  回到设计理念层面,我相信凡是接触过DevOps,大家有听说过DevOps年度状态报告。这个报告基于一种科学的研究方法,结合大量的调查数据统计分析得出,有相当的代表性。今年推出的《加速》这本书同样是当今热点,从五大领域,二十四项能力指标帮助大家更好的落地DevOps。对Jenkins X来说,它的设计理念也借用了其中的大量能力指标,其中主要覆盖在持续交付和应用架构领域里面。所以Jenkins X更多的是想思考我们在云原生应用时代,研发工程师和CI/CD的交互方式。

  那么这种交互方式是怎样的?我们看一下是不是Jenkins加Kubernetes就等于Jenkins X。答案显然是否定的,并不是说在Jenkins上安装了Kubernetes插件,动态生成资源节点就是Jenkins X。Jenkins X要做的远远不止于此,但是从另外一个角度来看,Jenkins X依然用原生Jenkins作为流水线持续交付引擎,其特性被良好封装但没有完全隐藏。一方面利用了Jenkins庞大的插件扩展能力,另外一方面也允许熟悉Jenkins的人继续它所熟悉的交互方式。这和很多公司的作为似乎有些背道而驰,其实很多公司都在使用Jenkins,但表面上却完全看不出来,因为已经对Jenkins做了完全的封装,用户只能通过前段界面和Jenkins进行交互,由此屏蔽了Jenkins本身的复杂度。这样做本来无可厚非,但是从社区的角度而言,更倾向于选择另外一条路,也就是提供一个良好封装的接口命令行工具,通过工具来完成系统交互。

  所以对于Jenkins X的项目来说,如果你希望用传统的方式访问Jenkins,这是完全开放的 。但是通过封装的命令行工具,将背后多套系统打通,实现系统间的自动化代用,从而给用户带来真正的价值。作为Jenkins的一个子项目,Jenkins X也希望通过尝试帮助Jenkins自身向云原生应用转变。社区现在成立了很多SIG,就是有点类似于Kubernetes社区的兴趣小组。每一个SIG有自己的主题,大家有兴趣也可以加入。其中第一个公开的SIG就是云原生应用小组,要实现这个工作并不简单,很多年前就已经有人提出过这个想法,但对于Jenkins基于文件存储的方式来说,想要去改变要分多个阶段来逐步实现。

  第一阶段要实现外部存储的支持,第二块是日志系统,第三块是配置,也就是基于YAML文件的配置方式,社区已经有很多成功的项目,大家感兴趣可以自行查阅。

  回到刚才我们讲的DevOps要打破研发交付过程中的交互墙,但是交互墙不只是在组织层面的部门强,很多时候也是技术墙。比如研发人员完成代码编写要部署上线,那么不仅仅是代码,还要编写Dockerfile、Jenkinsfile、Chartfile,同时还要管理代码仓库、Webhook和构建环境工具等。越过所有的障碍才能把一行代码部署到线上的Kubernetes环境上去。这就要求一个研发工程师要拥有非常全面的知识和能力,可是研发工程师的诉求非常简单,那就是我作为一个工程师可以非常简单创建一个应用,不需要关心这中间的事情。而Jenkins X

  可以解决这中间的隔阂,这也是Jenkins X给出的云原生应用时代研发工程师和CI/CD的理想关系。

  Jenkins X可以帮你自动生成所需要的流水线文件,相关的容器配置,构建环境等,大大简化了代码部署上线的难度。对于Jenkins X来说,核心关注的是三个方面。第一方面是端到端,第二方面是把一些优秀实践,比如刚才《加速》一本书中的能力项内嵌到系统平台里面来。第三方面是覆盖完整的环境。这里面可以看到,包括代码仓库、流水线,应用包管理,构建都是通过Jenkins X完成的,你只需要创建一个应用就够了。当然为了实现自动化,依然要有一些专业的人员来做好预定义工作,对研发人员而言所做的工作就非常简单了。

  核心特性第二点是GitOps。我们总提到研发和运维的冲突和对立,很多时候这很正常,除了组织层面的问题以外,运维都在写脚本,而研发在写JAVA代码。运维用自己的工单系统,开发用Jira需求缺陷管理系统。运维人员喜欢命令行式的黑白屏,开发喜欢彩色的IDE。天生这两个工种的差异就是巨大的。那么要解决这个问题,首先就是要把所有的环境代码化,纳入到版本控制库里面来,让大家共用一套版本控制系统。这样做的好处有几点,第一环境纳入版本控制,对所有人可见,实现全流程的变更可追溯 。

  第二是把研发习惯的敏捷实践应用到运维侧,通过代码合并的方式实现应用部署。第三是打通开发的持续集成和运维持续部署的流水线。因为在实际公司里面,大多需要不同系统提供部署功能,在Jenkins X通过一条流水线支持多环境,中间通过GitOps实现。

  说了很多,看下实际效果,当我们要部署应用的时候,系统提交一个PR,其中包含了应用的变更,版本,环境,这些通过运维人员审核、点击合入,后台自动完成应用部署。这和研发正常的开发流程来说并没有很大差异。

  核心特性第三点是环境。在生产软件开发过程中,很多时候受限于测试环境,需要排队、等待批次、完成部署后才能实现测试环境的验证。而在Jenkins X里面,基于云的能力可以帮助你动态初始化不同类型的环境。基于不同环境,一条流水线可以呈现出不同的走向,这可以通过阶段判断来实现。核心还是希望把整个环境,从本地开发、测试、预发布到生产环境都是通过Jenkins X背后的Kubernetes去管理。

  也就每次研发提交一次改动,代码管理系统里面可以自动生成测试环境访问地址,测试人员收到信息之后,通过点击链接可以快速查看改动的效果,这些帮助Jenkins X实现了快速的验证改动,避免缺陷流向下游。

  整体的流程图就不细说了。简单来说Jenkins X帮助我们建立代码仓库,构建环境,自动生成流水线,这时候只要提交代码,即可生成测试验证环境,通过后promote到预发布环境或者是生产环境,体现出端到端的流水线的概念。

  接下来还是简单介绍一下Jenkins X里面的组件信息。其中两个核心Jenkins和Kubernetes没什么好说的。Jenkins作为核心,和我们日常使用的版本没有任何的区别,只是把Jenkins部署到Kubernetes上而已。

  几个比较核心的工具跟大家简单介绍一下。第一个是命令行工具jx,jx 就是我刚刚提到对整个Jenkins X的一个封装,很多同Jenkins,Kubernetes和流水线等的交互,都可以通过jx 统一脚本来实现。这个工具是基于GO语言写的,现在越来越多的开源项目都是采用GO语言实现,大家感兴趣的话可以了解一下。

  工具提供了很多的命令,就像我刚刚提到的Jenkins X并不想把Jenkins隐藏掉,而是通过友好的方式交互,通过一两条jx命令就可以调用各个系统接口,提供给用户一种比较好的交互方式。jx是跟Jenkins X交互的一个唯一入口。详细的文档大家可以去参考项目地址。

  第二块就是Helm。对简单的应用部署当然很简单,通过脚本就可以实现,但是对复杂系统来说,很难通过一个文件实现编排。最早我们是把所有的Kubernetes相关的资源文件打包成一个大而全的文件,每次都要去复制粘贴。为了解决越来越复杂的微服务项目的部署,社区提出了Helm的工具,Helm相对于 Kubernetes而言,就类似Ubuntu上的APT,和CENTOS上的yum命令。Helm把整个的Kubernetes的资源进行打包。好处第一是复用性,第二是标准化,第三是版本控制。Chartmuseum就一个仓库,用于管理Chart文件。对于Chart文件自身起始很好理解,使用的就是模板加变量的方式。通过把模板和变量分离之后,每次部署,更新应用版本的时候,都只需要在变量中进行调整,直接执行命令就可以把新的应用在Kubernetes上执行起来。

  对于制品管理工具来说,Jenkins官方提供了Nexus和Docker registry,这些工具可以自行替换,但是作为演示项目默认使用了Nexus和Docker registry。

  接下来是核心组件Draft。刚才我们说过Jenkins X可以自动初始化代码编译文件、环境、流水线和容器配置等,那么他是怎样实现的呢?核心就是Draft工具。它是Kubernetes运行自动化的一个套件的工具。具备强大的是语言识别能力,同时Draft里面有一个pack的概念,这个pack包含了预定义的Jenkinsfile,dockerfile,构建环境工具信息等。执行过程第一步是识别出语言类型,然后根据预定义内容来完成初始化。Draft本身来说不仅是为Jenkins X提供的,它也可以独立使用和执行,所以即便不用Jenkins X,Draft对你来说也是有用的。

  上面都是Jenkins X的一些核心组件,我们发现随时都有很多的新需求会涌现出来,并提供了扩展功能给大家做一个分享。实际上说道Jenkins X并不希望以后所有公司都能使用这样一套工具,至少目前差距还比较远,所以更多的想把设计思路跟大家分享。那么在你们自己开发流水线工具的时候可以一定程度借鉴Jenkins X的思路。

  刚才提到的环境管理,更多的是预览环境和生产环境,而很多公司里面研发环境是一个空白,研发人员使用自己的笔记本开发,发现问题的时候,总说不清是谁的问题。Jenkins X提供了研发环境,保证了本地环境和线上环境的一致性。第二个是修改代码自动完成环境部署。第三个是通过IDE实时打通,目前对主流的IDE都提供插件,你可以在IDE中看到流水线的日志和状态,包括生成项目的地址等,也就是研发人员来说最终只要在IDE中工作就可以了。这些都是DevPod想解决的问题。对IDE来说,插件打通不难理解,但如何实现修改代码自动完成部署,这里面用到一个新的工具,是谷歌开源出来的。它的功能非常神奇,只要本地修改代码,会自动检测到代码变动,并完成构建、推送、部署,真正实现了研发只要改代码,所有的工作都自动完成。当在本地环境验证OK后,就可以提交代码并随着流水线自动生成环境。这些都是使用的Skaffold工具。它可以对接很多的基础设施类型,不管是公有云、私有云还是本地的环境都可以支持,大家感兴趣的可以看一下。

  最后再描述一下DevPod的工作过程。研发去下载代码,在本地工作空间进行开发,所有代码变更通过刚才的工具部署到DevPod,研发在DevPod上验证通过之后可以部署到集群上去,支持不同的语言。

  另外提到安全,实际上对于Jenkins X来说也有考虑到这个点,并引入了Anchore工具。这个工具第一能实现流水线整合,每次生成一个镜像,就会自动分析并生成一个BOM,也就是物料清单,相当于对Docker镜像做一个体检,并输出结果。第二是扫描基于标准的漏洞库,会告诉你包含什么高危险的漏洞,有哪些缺陷,你还能自定义一些安全规则,放到流水线里来。比如检测是否开放了违规端口,这些东西做成白名单或者是黑名单的方式,在流水线执行过程中进行扫描并作为质量门控制发布。

  ZAP是最新提供的一个功能,针对的是OWASP开放网页应用的安全项目。在Jenkins X里面Anchore更多关注静态的安全检测,因为扫面对象是一个应用镜像,通过扫描镜像和漏洞比对生成结果。对于ZAP来说是动态检测,通过端点查找潜在的问题。它的背后也有一个非常大的漏洞库,并且工具也提供了Jenkins插件。所以动态检测和静态检测,这两个工具都可以实现。

  说了这么多,从今年年初参与到这个项目来到现在我越发觉得这个项目是一个开源工具链的理想国。随着版本的不断更新,越来越多的工具被整合进来,作为平台而言很好的承载了这些外部能力,并且可以灵活配置。通过Jenkins X项目一方面可以了解到原来社区有这么多的好用的工具,可以同开源流水线做整合。另外一方面也提供了一个试验田,来证明一个好的流水线平台到底应该是什么样子,核心是可选性。Jenkins X设计的时候非常好的考虑到了可扩展性,通过插件的方式进行集成。

  给大家简单介绍一下Jenkins X的安装过程。这个事情看起来简单,按照官方文档的说法只需要执行一条命令就搞定了,但是基本上一条命令是搞不定,里面有一些坑,这里面想把这个过程个大家做个介绍,在执行jx install的时候先安装了Helm,Jenkins X是基于Helm管理的,所有的组件打包成Helm包,同时支持 Helm2和Helm3,它们之间的差别就在是否有服务端程序。

  第二是必须有jx的命令。没有这个的话执行不了jx install命令。

  第三是创建默认命名空间,必须有一个可用的默认空间,一般是jx。

  接下来是配置Ingress Controller,否则没法对外提供服务,配置这个的目的是可以访问到Jenkins X的各种系统。

  第五是创建默认管理员密码。其实对于Jenkins X来说,是通过文件加密的方式来管理密码的,这一块熟悉Kubernetes的同学来说,不难理解。但是由于secret资源还是不太灵活,所以后续计划引入Let’s encrypt工具。对平台能力的极致追求, 也是引入新的动力所在。

  接下来密码创建好之后就开始配置Jenkins,包括整个环境的配置。安装,配置,还有代码托管平台整合等等,都可以在这一步完成。最后就可以开始正式使用Jenkins X了。核心还是Helm,大家可以通过Helm Chart就可以知道做了什么事情了。

  最后想说两点,Jenkins X从今年3月份正式公布,到现在也有将近半年的时间,在这个过程中,很多国内的开发者也对这个项目做了很大的贡献。所以我们希望大家可以更多的参与到社区贡献里面来。我们可以看到Jenkins X的官方中文站现在已经上线了,这一块也是来自社区同学的贡献。但是大家知道,Jenkins X目前的迭代速度是非常频繁的,很有新的内容不断的加入进来,就像我刚才提到的这么多的工具和文档。所以我们成立了一个新的SIG,也就是本地化小组,这个小组不仅是关注Jenkins X,而是做 Jenkins社区的本地化的工作。目前来说,可供大家加入的小组有三个,一个是本地化小组,还有就是云原生和平台小组,也希望新的同学加入进来,感兴趣的同学下来可以找我。

  想强调一点的是,关于社区贡献,写代码只是其中之一,提交文档,需求,用户反馈等都是很好的贡献方式。我的分享到这里,时间刚刚好,感谢大家坚持到最后,感兴趣大家可以下来找我交流。

  董伟:感谢雪峰精彩的分享,Jenkins X的特性,安装、步骤真的非常细致,最后有一些社区的活动希望大家积极参与进来,有一些时候我们技术人就是需要有一个自己的情怀的地方,同时也能提升自己的影响力,今天非常感谢来宾朋友参加今天的会议,两天会议非常辛苦,感谢主办方,感谢所有的讲师,我们下次再见,谢谢大家。

0