管理詹金斯管道

通过Jenkins进行部署的常见模型是使项目包含其自己的Jenkins文件。 我们讨论了这种方法的优缺点,并描述了使用Jenkins CLI和模板的替代方法。

我们的持续集成持续交付管理系统长期以来一直专注于詹金斯。 原始模型是每个项目都将为管道定义自己的Jenkins文件。 这导致跨项目的管道相似甚至相同。

该模型有其好处,因为您可以快速查看如何运行,测试和部署项目。 但是,在这种模型中,管理Jenkins的工作和流水线会很快变得很繁琐。 我们遇到以下问题:

*更新管道需要很长时间,因为您必须在多个存储库中更新多个文件。

*由于我们是从UI创建Jenkins作业的,所以没有中央存储库概述了如何构建应用程序集。

随着即将到来的新项目,我们决定回顾我们如何管理CI / CD解决方案。

我们尝试使管理Jenkins作业更容易的第一步是不再从UI创建Jenkins作业并将其配置为代码。 为此,我们决定使用Jenkins CLI。 我们还有其他选择,但是我们希望最大的灵活性是准确选择可能的方式,并限制我们认为是不好的做法。 另一个不错的好处是它不仅限于管理工作。 我们正在考虑的其他选项之一是使用jenkins-jobs-builder。 这对管理工作很有好处,但没有其他好处。

从长远来看,我们希望将Continuous Integration(在Jenkins中)与Continuous Delivery(使用Spinnaker)分开,但是我们仍然想要一种可以在Jenkins和Spinnaker上创建流水线的工具,以确保两个系统可以相互通信。 我们觉得Jenkins CLI是唯一足够灵活以允许以后进行集成的选项。

管道模板

首先,我们为管道和多分支管道的XML模板化。 根据我们的经验,这些是我们使用的仅有的两项工作。 为了帮助组织,我们还添加了一个View模板。 为了模板化它们,我们选择了Jinja2。 由于使用Ansible,这是我们已经熟悉的模板引擎,它使我们能够使用未定义的值。 能够处理未定义的值对我们来说非常重要,因为它允许我们在模板本身中为它们设置默认值。 管道的模板如下:

由于我们拥有的大多数项目都是用Go编写的并且使用Makefile构建,因此我们决定了每个Makefile使用管道所需的步骤。 移动之后,我们以一个用于构建Go项目的Jenkins文件结束。 该文件使用来自GitLab Webhook的信息来了解要构建和测试的项目。 这样我们就可以完成构建Go项目的一项工作。 现在,当我们更新它时,所有项目都将从中受益。

为了能够使用单个作业来构建Go应用程序,我们必须使作业更加灵活。 这意味着我们无法使用声明性管道语法,而不得不依靠groovy获得更复杂的逻辑。 这使我们可以首先添加一个可选的构建步骤。

我们将管道视为其他任何软件项目。 我们可以对其进行版本控制,让人们选择他们想要使用的版本。 这使我们可以在Jenkins中使用不同版本的管道,并且人们可以通过调整Webhooks的URL来选择使用哪个版本。

现在我们已经有了这个功能,我们想让它在Jenkins中创建和更新作业变得更加容易。 我们当前要做的是运行一个命令,如:

j2 -f yaml pipeline.j2 values.yaml | java -jar jenkins-cli.jar创建工作my-awesome-pipeline

但是我们想要的是:jenkins-cli create-project project.json

由于这是一项简单的任务,我们决定为此使用bash脚本作为概念证明。 项目定义的结构最终看起来像:

这里的名称将是在詹金斯创建的视图。 我们有一系列管道,您可以在其中指定用于模板的名称和值。

这使我们可以通过运行Jenkins管道来添加和更新管道。 该脚本将执行的操作是检查管道是否存在并对其进行更新,或者如果管道不存在,则会使用新值创建管道。 最终,这使我们比将所有Jenkins工作作为代码更近了一步,从而使我们能够在灾难情况下进行版本控制和回滚。

下一步

接下来我们要从Jenkins拆分部署部分,然后将其移至Spinnaker。 我们还需要创建一个可以在Jenkins和Spinnaker之间创建管道的工具。

我们正在招募

在此处了解THG令人兴奋的机会:

小屋集团(THG)的职业
有兴趣在THG工作吗? 看看我们目前在各种职位上的职位空缺和机会,以及… www.thg.com