Jenkins X将自动化管道引入Kubernetes


【编者的话】Jenkins X是一套高度集成化的CI/CD平台,以Jenkins和Kubernetes为实现基础,旨在解决微服务体系架构下云原生应用的持续交付问题,最终简化整个云原生应用的开发、运行和部署流程。Jenkins X带来一系列新特性,具体包括:全面自动化,基于GitOps的一键环境部署,自动生成预览环境以及信息同步反馈。 Jenkins X和Kubernetes的结合则将运维自动化推向新的高度。

Jenkins持续集成服务器一直是DevOps浪潮中的重要组成部分。作为持续集成与持续部署环境中自动化任务的中央协调服务器,全球的开发和运营团队已经积极接纳Jenkins,并为之构建了多种扩展及构建包。 然而,从设计初衷角度来看,Jenkins并没有考虑到面向容器环境的迁移需求。
1.jpg

Cloudbees公司高级架构师James Strachen身为Jenkins X项目负责人,他一直在思考这种迁移对Jenkins用户的意义及影响。

他表示,将CI/CD管道迁移到配备容器及容器编排工具(如Kubernetes)的基于容器云托管环境时,用户需要在构建、测试和部署过程中建立更高的自动化水平。Strachen说:“ 为了实现这一点,Jenkins X必须具备远超常规Jenkins的易学习性及易用性。”

“我们要做的,是打破少数人对相关知识的‘垄断’。这部分人往往对Jenkins非常了解,但是团队里的每个人都有权也有意愿参与其中。我们需要开发人员能够随时根据需求启动新的项目——这也正是微服务时代的最大差异优势所在。我们希望Jenkins自助服务能够像云一样全面覆盖。“

“Jenkins X的目标是将Jenkins转化为一种自助服务设备,允许任何开发人员启动新项目,而与之相关的全部管道及匹配元素都能够顺利到位。 当然,这并不是说团队成员完全不需要了解Jenkins,但更重要的是我们希望让CI/CD拥有与云服务类似的低准入门槛,“他解释称。

Strachen在3月中旬发表的一篇博文中详细介绍了Jenkins X的技术细节,当时该项目才刚刚面向公众正式公布。在文章中,他解释称Jenkins X可用于设置Jenkins管道,自动生成Jenkinsfile和Dockerfile以定义应用程序的管道与打包步骤。

由于DockerKubernetes的运行活动同Jenkins设计环境存在一些差别,因此Strachen表示Jenkins X还需要将安全保障机制引入到复杂的容器镜像构建过程中。Strachen指出,用户可以利用自己的Dockerfiles或pop在管道中使用其最熟悉的容器构建工具。Strachen同时提到,Skaffold是一种用于构建和标记Docker镜像的工具——尽管听起来很简单,但其意义却非常重大。

“[Skaffold]负责管理Docker和安全模型的复杂性事务。 如果您使用Google Cloud,则可能需要使用谷歌提供的容器构建器。 您可能需要在自己的Kubernetes集群中使用SaaS CI或本地Docker套接字。 这种方法会带来安全隐患,因为这意味着使用者将掌握设备的root权限。因此,绝对不可让他人访问生产集群中的Docker套接字。举例来说,在默认情况下,Jenkins S会假设用户处于开发集群当中,并有权访问Docker套接字。但很明显,这样的假设并不靠谱,“Strachen强调称。

Strachen认为这是未来Docker镜像构建层面的一大主要问题。“我们需要利用Skaffold以及其它同类工具将用户与高权限隔离开来。我希望这一目标能够尽快实现。”他曾听到未经证实的消息称,Skaffold可能会在未来几个月内获得上述能力。

“在开发群集上,我们允许用户使用Docker来构建镜像。 大家往往坚定地相信团队中的开发者不会利用这些硬件挖掘比特币。 而在生产群集上,我们不需要构建镜像,而只是使用已经构建完成的现成镜像。 这是一个简单的方法,易于实现,而且能够有效消除风险。我认为从长远角度来看,为了确保在不使用Docker守护进程、root或其它特殊权限的前提下构建Docker镜像,最好是能够将Docker构建流程彻底移出Kubernetes集群之外,”Strachen表示。

稳定性和兼容性

未来,Strachen表示Jenkins X团队在稳定性和兼容性方面还拥有多项开发目标。 “最重要的是检查一切组成元素。 在同一时间内支持多种云环境可谓极具挑战性。 因此,我们的第一项重点在于构建起坚如磐石的集群系统。 此外,我们还需要支持更多的Git供应程序以及问题跟踪器。 我们正在添加Jira支持能力,此外社区中也有部分贡献者正在进一步扩展Git供应程序的支持范围,例如GitLabBitBucket,“Strachen表示。

“着眼于更长期的目标,我们将着力改进反馈与整合等机制。 我们拥有一份宏观路线图,主要关注增加构建包的数量,此外还需要实现更广泛的语言支持能力,“Strachen说。

核心开发团队当前的另一项研究目标是与Anchore CI/CD安全扫描软件进行集成。 Anchore负责根据漏洞数据库分析代码与Docker镜像。

在实现上述复杂目标的过程当中,有一段代码已经为Jenkins X团队节省了大量时间,这就是UpdateBot。 这款小工具运行在其他项目更新库的依赖关系库中,能够自动提交请求以使用新的依赖项。

“有时候,我们需要使用上游库,”Strachen说,“而其他团队正在使用下游类库。通常情况下,如果不存在信息交换,这些库很少需要进行更新。但在实际更新过程中,我们需要采取持续部署的处理方法。UpdateBot要做的在执行过程中严格遵循持续部署原则。这些库不会被部署为Docker镜像,而是作为版本更改、经过更新的XML文件或基础Docker镜像文件存在。”

Strachen表示,这种在更新过程中持续面向下游消费者推送请求的作法,能够有效防止错误因未被及时发现而在更新周期之后集中爆发。

“我个人最欣赏的一点在于,如果上游开发者犯了错误,他们会立刻发现问题。这是因为在持续发布的版本中,所有相关请求都会遭遇故障。如此一来,将不致出现某一团队的失误导致另一团队的工作成果付之东流,并有效避免由此引发的团队间摩擦与挫败感。必须承认,犯下错误的团队往往对此毫不知情,因此在传统变更流程当中,当人们意识到存在严重问题时,其间往往已经进行过无数次变更——也就是说根本无法判断问题到底源自哪里。而持续部署原则将彻底攻克这一难题,”Strachen总结称。

原文链接:Jenkins X Brings Automated Pipelines to Kubernetes(翻译:ylzhang)

0 个评论

要回复文章请先登录注册