文档章节

从 Jenkins 到 Jenkins X

Jenkins中文社区
 Jenkins中文社区
发布于 05/17 21:53
字数 3927
阅读 47
收藏 0

本文首发于:Jenkins 中文社区

这是一个关于 dailymotion 从 Jenkins 到 Jenkins X 的旅程,我们遇到的问题,以及我们是如何解决它们的故事。

我们的上下文

dailymotion ,我们坚信 devops 最佳实践,并且在 Kubernetes 投入了大量投资。 我们的部分产品已经部署在 Kubernetes 上,但并不是全部。 因此,当迁移我们的广告技术平台的时候,我们想要完全采用“ Kubernetes 式”——或者云原生,以追随技术趋势! 这意味着要重新定义整个 CI/CD 流水线,从静态/永久环境迁移,转向动态按需分配环境。 我们的目标是授权给我们的开发人员缩短我们的上线时间以及降低我们的运营成本

对于新的 CI/CD 平台我们的初始需求是:

  • 尽可能避免从零开始:我们的开发人员已经习惯使用 Jenkins 和声明式流水线,并且它们可以很好地满足我们当前的需求。
  • 以公有云基础设施为目标——Google 云平台和 Kubernetes 集群
  • gitops 方法论兼容——因为我们喜欢版本控制、同行评审和自动化

在 CI/CD 生态系统中有相当多的参与者,但是只有一个符合我们的需求,Jenkins X ,它基于 Jenkins 和 Kubernetes ,原生支持预览环境和 gitops

Kubernetes 之上的 Jenkins

Jenkins X 的设置相当简单,并且在他们的官方网站上已经有很好的文档(译注:译者曾对 Jenkins X 文档中文本地化做了一些贡献,同时也期待更多的人参与以完善中文文档)。 由于我们已经使用了 Google Kubernetes Engine (GKE),所以 jx 命令行工具自己创建了所有东西,包括 Kubernetes 集群。 这里有一个小小的哇哦效果,在几分钟内获得一个完整的工作系统是非常令人印象深刻的。

Jenkins X 提供了很多快速入门和模板来增加哇哦效果, 然而,在 dailymotion ,我们已经有了带有 Jenkins 流水线的仓库,我们想要重用它们。 我们决定以"艰难的方式"做事情,并重构我们的声明式流水线,使它们与 Jenkins X 兼容。

实际上,这一部分并不针对 Jenkins X ,而是基于 Kubernetes 插件在 Kubernetes 上运行 Jenkins 。 如果您习惯使用“经典的” Jenkins ,即在裸金属或虚拟机上运行静态代理,那么这里的主要更改是,每次构建都将在自己的短暂的 pod 上执行。 流水线的每个步骤都可以指定应该在 pod 的哪个容器上执行。 在插件的源代码中有一些流水线的例子。 在这里,我们的"挑战"是定义容器的粒度,以及它们将包含哪些工具:需要足够的容器,以便我们可以在不同流水线之间重用它们的镜像,但也不能太多,以控制维护量——我们不想花时间重新构建容器镜像。

以前,我们通常在 Docker 容器中运行大多数流水线步骤,当我们需要自定义步骤时,我们在运行中的流水线中构建它,就在运行它之前。 虽然它比较慢,但是易于维护,因为所有内容都是在源代码中定义的。 例如,升级 Go 运行时的版本可以在一个 pull-request 中完成。 因此,要预先构建容器镜像听起来像是给现有设置增加了更多的复杂性。 它还有几个优点:仓库之间的重复更少,构建速度更快,并且不会因为某些第三方托管平台宕机而出现更多构建错误。

在 Kubernetes 上构建镜像

这些天将给我们带来一个有趣的话题:在 Kubernetes 集群中构建容器镜像。

Jenkins X 附带了一组"构建打包",使用 "Docker in Docker" 从容器内部构建镜像。 但是随着新的容器运行时的到来,Kubernetes 推出了它的容器运行时接口( CRI ),我们想要探索其他的选择。 Kaniko 是最成熟的解决方案,符合我们的需求/技术栈。 我们很兴奋……

……直到我们遇到两个问题:

  • 第一个问题对我们来说是一个阻塞问题:多阶段构建不起作用。 多亏了谷歌,我们很快发现我们不是唯一受到影响的人,而且目前还没有解决办法。 然而,Kaniko 是用 Go 开发的,而我们是 Go 开发人员,所以……为什么不看看源代码呢? 事实证明,一旦我们理解了问题的根本原因,修复就很容易了。 Kaniko 维护者是很愿意帮忙的,并且快速地合并了修复,所以一天之后一个被修复的 Kaniko 镜像就已经可用了。
  • 第二个问题是,我们不能使用同一个 Kaniko 容器构建两个不同的镜像。 这是因为 Jenkins 并没有按照预期的方式使用 Kaniko ——因为我们需要先启动容器,然后再运行构建。 这一次,我们找到了一个针对谷歌的解决方案:声明我们所需要的尽可能多的 Kaniko 容器来构建镜像,但是我们不喜欢它。 所以回到源代码,再一次,一旦我们理解了根本原因,修复就很容易了

我们测试了一些解决方案来为 CI 流水线构建定制的"工具"镜像, 最后,我们选择使用一个单个仓库,每个分支对应一个 Dockerfile 和镜像。 因为我们将源代码托管在 Github 上,并且使用 Jenkins Github 插件来构建我们的仓库, 所以它可以构建我们所有的分支,并为 webhook 事件上的新分支创建新的任务,这使得管理起来很容易。 每个分支都有自己的 Jenkinsfile 声明式流水线,使用 Kaniko 构建镜像,并将其推入我们的容器注册中心。 这对于快速添加新镜像或编辑现有的镜像非常有用,因为我们知道 Jenkins 会处理好所有的事情。

声明所需资源的重要性

我们在之前的 Jenkins 平台中遇到的一个主要问题来自静态的代理/执行器,在高峰时间有时构建队列很长。 Kubernetes 之上的 Jenkins 使这个问题很容易解决,主要是在 Kubernetes 集群上运行时,它能支持集群自动伸缩。 集群将根据当前负载简单地添加或删除节点。 但这是基于所请求的资源,而不是基于所观察到的使用的资源。 这意味着,作为开发人员,我们的工作是在构建 pod 模板中定义所需的资源( CPU 和内存)。 然后 Kubernetes 调度程序将使用此信息找到一个匹配的节点来运行 pod ——或者它可能决定创建一个新的节点。 这真是太好了,因为我们不再有长构建队列。 但相反,我们需要谨慎地定义我们所需资源的恰当数量,并在更新流水线时更新它们。 由于资源是在容器级别定义的,而不是在 pod 级别定义的,所以处理起来有点复杂。 但是我们不关心限制,只关心请求。 pod 的请求只是所有容器请求的相加。 因此,我们只是将整个 pod 的资源请求写在第一个容器上——或者 jnlp 容器上——它是默认的容器。 下面是我们使用的一个 Jenkinsfile 的例子, 也是我们如何声明请求的资源的例子:

pipeline {
    agent {
        kubernetes {
            label 'xxx-builder'
            yaml """
kind: Pod
metadata:
  name: xxx-builder
spec:
  containers:
  - name: jnlp

Jenkins X 上的预览环境

现在我们已经拥有了所有的工具,并且能够为我们的应用程序构建一个镜像, 我们准备下一步:将它部署到"预览环境"!

Jenkins X 通过重用现有的工具——主要是 Helm ,使得部署预览环境变得很容易, 只要你遵循一些约定,例如用于镜像标签的值的名称。 最好是从"包"中提供的 Helm charts 复制/粘贴。 如果你不熟悉 Helm ,它基本上是一个 Kubernetes 应用程序包管理器。 每个应用程序都打包为一个 "chart" ,然后可以通过使用 helm 命令行工具作为一个 "release" 被部署。 预览环境是通过使用 jx 命令行工具进行部署的,该工具负责部署 Helm chart ,并以评论的形式,将所公开服务的 URL 添加到 Github pull-request 中。 这一切都非常好,而且对于我们第一个使用纯 http 的 POC 来说很有效。 但现在是2018年(译注:作者是在2018年写的这篇文章),没有人再使用 http 了。 让我们加密吧! 多亏了 cert-manager,当在 kubernetes 中创建 ingress 资源时,我们可以自动为我们的新域名获得一个 SSL 证书。 我们试图在我们的设置中启用 tls-acme 标志——与 cert-manager 进行绑定,但是它不起作用。 这给了我们一个机会来看看 Jenkins X 的源代码——它也是用 Go 开发的。 稍作修复之后都好了, 现在我们可以使用 let's encrypt 提供的自动化证书来享受安全的预览环境。

我们在预览环境中遇到的另一个问题与上述环境的清理有关。 每个打开一个 pull-request ,就创建一个预览环境,因此在 pull-request 被合并或关闭时应该删除预览环境。 这由 Jenkins X 设置的 Kubernetes 任务来处理,它删除了预览环境所使用的名称空间。 问题是这个任务不会删除 Helm release ——所以,比如如果您运行 helm list,您仍然会看到一个很大的旧的预览环境列表。 对于这个问题,我们决定改变使用 Helm 部署预览环境的方式。 Jenkins X 团队已经写过关于 Helm 和 Tiller ( Helm 的服务器端组件)的这些问题, 因此,我们决定使用 helmTemplate 特性标志,只使用 Helm 作为模板渲染引擎,并使用 kubectl 处理生成的资源。 这样,我们就不会用临时预览环境"污染" Helm releases 列表。

Gitops 应用到 Jenkins X

在初始化 POC 的某个阶段,我们对我们的设置和流水线感到满意,并希望将我们的 POC 平台转变为准生产的平台。 第一步是安装 SAML 插件以设置 OKTA 集成——以允许内部用户登录。 它运行得很好,几天后,我注意到我们的 OKTA 集成已经不再存在了。 我正忙着做其他事情,所以我只是问我的同事他是否做了一些改变,然后继续做其他事情。 但几天后再次发生时,我开始调查。 我注意到的第一件事是 Jenkins Pod 最近重新启动过。 但是我们有一个持久化的存储,我们的任务仍然在那里,所以是时候仔细看看了! 事实证明,用于安装 Jenkins 的 Helm chart 有一个启动脚本, 它从 Kubernetes configmap 重置了 Jenkins 配置。 当然,我们不能像在虚拟机上管理 Jenkins 那样管理在 Kubernetes 中运行的 Jenkins !

因此,我们没有手动编辑 configmap ,而是后退一步,查看全局。 这个 configmap 本身由 jenkins-x-platform 管理, 因此升级平台将重置我们的自定义更改。 我们需要将我们的"定制"存储在安全的地方并跟踪我们的更改。 我们可以用 Jenkins X 的方式,用一个 umbrella chart 来安装/配置一切, 但是这种方法有一些缺点:它不支持 "secret" —— 我们将一些敏感的值存储在我们的 Git 仓库中—— 它"隐藏"了所有的 sub-charts 。 所以,如果我们列出所有已安装的 Helm releases ,我们将只看到一个。 但是还有其他基于 Helm 的工具,它们更对 Gitops 更友好。 Helmfile 就是其中之一,它通过 helm secrets 插件sops为 secrets 提供了原生支持。 我现在不会详细介绍我们的设置,但别担心,这将是我下一篇博客文章的主题!

迁移

我们故事的另一个有趣的部分是从 Jenkins 到 Jenkins X 的实际迁移。 以及我们如何使用两个构建系统处理仓库。 首先,我们设置新的 Jenkins 来只构建 "jenkinsx" 分支, 并且更新了旧的 Jenkins 的配置来构建除 "jenkinsx" 分支之外的所有分支。 我们计划在 "jenkinsx" 分支中准备新的流水线,并将其合并以进行迁移。 对于我们的初始化 POC ,它工作得很好,但是当我们开始使用预览环境时, 我们必须创建新的 PR ,而这些 PR 不是基于新的 Jenkins 构建的,因为分支限制。 因此,我们选择在这两个 Jenkins 实例上构建一切, 但对于旧的 Jenkins 使用 Jenkinsfile 文件名,对于新的 Jenkins 使用 Jenkinsxfile 文件名。 迁移之后,我们将更新此配置并重命名文件,但这是值得的, 因为它使我们能够在两个系统之间进行平滑的转换,并且每个项目都可以自己迁移,而不会影响其他项目。

我们的目的地

所以,Jenkins X 为大家准备好了吗?老实说,我不这么认为。 并非所有功能和所支持的平台—— Git 托管平台或 Kubernetes 托管平台——都足够稳定。 但是,如果您准备投入足够的时间来深入研究,并选择适合您的使用场景的稳定特性和平台, 那么您将能够使用 CI/CD 等所需的一切来改进您的流水线。 这将缩短您的上线时间,降低您的成本,如果您对测试也很认真,那么请对您的软件质量充满信心。

一开始,我们说这是我们从 Jenkins 到 Jenkins X 的旅程。但我们的旅程并未结束,我们还在旅行中。 部分原因是我们的目标仍在移动:Jenkins X 仍处于大的发展阶段,而且它本身正在朝着 Serverless 的方向前进, 目前正在使用 Knative 构建 的路上。 它的目的地是云原生 Jenkins 。 它还没有准备好,但是您已经可以预览它的外观了。

我们的旅程还将继续,因为我们不希望它结束。 我们现在的目的地并不是我们的最终目的地,而是我们不断进化的一个步骤。 这就是我们喜欢 Jenkins X 的原因:因为它遵循相同的模式。 那么,你在等待什么来开始你自己的旅程呢?

译注:译者曾对 Jenkins X 文档中文本地化做了一些贡献,同时也期待更多的人在 Jenkins X 旅程中, 能够参与到 Jenkins 中文社区以完善 Jenkins X 的中文文档。

译者:王冬辉

© 著作权归作者所有

Jenkins中文社区

Jenkins中文社区

粉丝 36
博文 48
码字总数 79155
作品 1
杭州
私信 提问
关于 Jenkins master 共享 JENKINS_HOME 目录的实验

本文首发于:Jenkins 中文社区 作者:翟志军 审校:王冬辉,linuxsuren Jenkins master 的高可用是个老大难的问题。和很多人一样,笔者也想过两个 Jenkins master 共享同一个 JENKINS_HOME 的...

Jenkins中文社区
04/23
36
0
15分钟在阿里云Kubernetes服务上快速建立Jenkins X Platform并运用GitOps管理应用发布

本文主要介绍如何在阿里云容器服务Kubernetes上快速安装部署Jenkins X Platform并结合demo实践演示GitOps的操作流程。 注意: 本文中使用的jx工具、cloud-environments等做过改造用以适配阿里...

zhaowei121
01/29
71
0
Jenkins 文档特别兴趣小组

本文首发于:Jenkins 中文社区 我们很高兴地宣布 Jenkins 文档特别兴趣小组的成立。 文档特别兴趣小组鼓励贡献者和外部社区创建和 review Jenkins 文档。 更多详情和计划,请参见:文档特别兴...

Jenkins中文社区
05/27
17
0
使用Jenkins构建Docker镜像

Jenkins是一个开源项目,提供了一种易于使用的持续集成系统,使开发者从繁杂的集成中解脱出来,专注于更为重要的业务逻辑实现上。同时Jenkins能实施监控集成中存在的错误,提供详细的日志文件...

秦时明月路
2018/07/18
0
0
持续集成JenkinsAPI常见用法

【背景】:部门在搞持续集成,使用jenkins作为核心调度,要再其基础上进行二次封装,所以需要研究下jenkins的api。笔者主要负责搭建平台,在研究用法也花费了些时间,本文主要做个简要的记录...

彼得
2014/02/08
32.2K
7

没有更多内容

加载失败,请刷新页面

加载更多

Executor线程池原理与源码解读

线程池为线程生命周期的开销和资源不足问题提供了解决方 案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。 线程实现方式 Thread、Runnable、Callable //实现Runnable接口的...

小强的进阶之路
23分钟前
4
0
maven 环境隔离

解决问题 即 在 resource 文件夹下面 ,新增对应的资源配置文件夹,对应 开发,测试,生产的不同的配置内容 <resources> <resource> <directory>src/main/resources.${deplo......

之渊
今天
8
0
详解箭头函数和普通函数的区别以及箭头函数的注意事项、不适用场景

箭头函数是ES6的API,相信很多人都知道,因为其语法上相对于普通函数更简洁,深受大家的喜爱。就是这种我们日常开发中一直在使用的API,大部分同学却对它的了解程度还是不够深... 普通函数和...

OBKoro1
今天
5
0
轻量级 HTTP(s) 代理 TinyProxy

CentOS 下安装 TinyProxy yum install -y tinyproxy 启动、停止、重启 # 启动service tinyproxy start# 停止service tinyproxy stop# 重启service tinyproxy restart 相关配置 默认...

Anoyi
今天
2
0
Linux创建yum仓库

第一步、搞定自己的光盘 #创建文件夹 mkdir -p /media/cdrom #挂载光盘 mount /dev/cdrom /media/cdrom #编辑配置文件使其永久生效 vim /etc/fstab 第二步,编辑yun源 vim /ect yum.repos.d...

究极小怪兽zzz
今天
6
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部