从 Jenkins 到 Jenkins X

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

我们的上下文

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

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

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

Kubernetes 之上的 Jenkins

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

在 Kubernetes 上构建镜像

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

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

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

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

声明所需资源的重要性

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

Jenkins X 上的预览环境

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

Gitops 应用到 Jenkins X

迁移

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

我们的目的地

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

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