【2018可信云大会】京东石雪峰：JenkinsX基于Kubernetes的新一代CI/CD平台

核心特性第二点是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。

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!