如何在 Ubuntu 16.04 上使用 GitLab CI 设置持续集成管道

介绍

GitLab 社区版是一个自托的 Git 存储提供商,提供额外的功能来帮助项目管理和软件开发. GitLab 提供的最有价值的功能之一是名为 GitLab CI的内置连续集成和交付工具。

在本指南中,我们将展示如何设置 GitLab CI 来监控您的存储库的变化,并运行自动测试来验证新代码。我们将从运行的 GitLab 安装开始,在那里我们将复制一个基本 Node.js 应用程序的示例存储库。

前提条件

在我们开始之前,你需要设置一个初始环境。我们需要一个安全的GitLab服务器配置来存储我们的代码和管理我们的CI/CD流程。此外,我们需要一个地方来运行自动化测试。

通过SSL保护的GitLab服务器

要存储源代码并配置我们的 CI/CD 任务,我们需要安装在 Ubuntu 16.04 服务器上的 GitLab 实例。 GitLab 目前建议使用至少 2 个 CPU 核心和 4 GB 内存的服务器。

您可以使用以下教程完成这些要求:

• 初始服务器设置与Ubuntu 16.04:创建一个sudo用户,并配置一个基本的防火墙
• 如何在Ubuntu 16.04上安装和配置GitLab:在服务器上安装GitLab,并使用让我们加密TLS/SSL证书保护它

我们将展示如何在项目之间共享 CI/CD 运行器(运行自动测试的组件)以及如何将其锁定为单个项目。如果您希望在项目之间共享 CI 运行器,我们强烈建议您限制或禁用公共登录。

使用一个或多个服务器作为 GitLab CI 运行器

GitLab CI Runner 是检查代码并运行自动测试的服务器,以验证新的更改。为了隔离测试环境,我们将在 Docker 容器内运行所有自动测试。

此步骤可以在 GitLab 服务器上或在不同的 Ubuntu 16.04 服务器上完成,以提供额外的隔离并避免资源争议。

• Ubuntu 16.04 初始服务器设置:创建一个sudo用户并配置一个基本的防火墙(如果您在 GitLab 服务器上设置 CI 运行器,您不需要再次完成此操作)
• Ubuntu 16.04 上的 Docker 如何安装和使用:按照 步骤 1 和 2在服务器上安装 Docker

当你准备好开始时,继续这个指南。

从GitHub复制示例存储库

首先,我们将创建一个包含 Node.js 应用程序的 GitLab 中的新项目,我们将直接从 GitHub 导入原始存储库(https://github.com/do-community/hello_hapi/),以便我们不必手动上传。

登录 GitLab 并点击右上角的 ** plus 图标,然后选择 ** 新项目** 以添加新项目:

在新项目页面上,单击 ** 导入项目** 选项卡:

接下来,点击 ** Repo by URL ** 按钮.虽然有 GitHub 导入选项,但它需要一个个人访问令牌,并且用于导入存储库和其他信息。

在Git repository URL字段中,输入以下GitHub repository URL:

1https://github.com/do-community/hello_hapi.git

它应该看起来像这样:

由于这是一个演示,所以最好将存储库标记为 私有. 完成后,单击 ** 创建项目**。

新项目将基于从GitHub进口的存储库创建。

了解.gitlab-ci.yml 文件

GitLab CI 在每个存储库中寻找一个名为 .gitlab-ci.yml’ 的文件,以确定该存储库应该如何测试代码. 我们导入的存储库中已经为该项目配置了 gitlab-ci.yml` 文件.您可以通过阅读 .gitlab-ci.yml 参考文档来了解更多有关该格式的信息。

点击我们刚刚创建的项目GitLab界面中的 .gitlab-ci.yml文件。

 1[label .gitlab-ci.yml]
 2image: node:latest
 3
 4stages:
 5  - build
 6  - test
 7
 8cache:
 9  paths:
10    - node_modules/
11
12install_dependencies:
13  stage: build
14  script:
15    - npm install
16  artifacts:
17    paths:
18      - node_modules/
19
20test_with_lab:
21  stage: test
22  script: npm test

该文件使用 GitLab CI YAML 配置语法来定义应该执行的操作,它们应该执行的顺序,在哪些条件下应该运行,以及完成每个任务所需的资源。

配置文件始于声明一个Docker图像,应该用来运行测试套件. 由于Hapi是一个Node.js框架,我们正在使用最新的Node.js图像:

1image: node:latest

接下来,我们明确定义了将运行的不同连续集成阶段:

1stages:
2  - build
3  - test

您在这里选择的名称是任意的,但排序决定了接下来的步骤的执行顺序。 阶段是您可以应用于个别任务的标签。 GitLab 将并行运行相同阶段的工作,并将等待执行下一步的工作,直到当前阶段的所有工作完成。

定义阶段后,配置包括一个缓存定义:

1cache:
2  paths:
3    - node_modules/

这指定了可以在运行或阶段之间缓存(用于以后使用)的文件或目录,这可以帮助减少运行依赖资源的任务所需的时间,这些资源可能不会在运行之间发生变化。

我们的第一份工作被称为install_dependencies:

1install_dependencies:
2  stage: build
3  script:
4    - npm install
5  artifacts:
6    paths:
7      - node_modules/

工作可以被命名为任何东西,但因为名称将在GitLab UI中使用,描述性名称是有帮助的. 通常,npm install可以与下一个测试阶段相结合,但为了更好地展示阶段之间的相互作用,我们正在提取这个步骤以运行在自己的阶段。

我们用阶段指令明确标记阶段为构建。接下来,我们指定使用脚本指令运行的实际命令。

该文物子部分用于指定文件或目录路径,以便在阶段之间保存和传输。由于npm install命令为项目安装了依赖性,我们的下一步将需要访问下载的文件。 声明node_modules路径确保下一阶段可以访问这些文件。 这些在测试后也可在GitLab UI中查看或下载,所以这对构建文物(如二进制)也很有用。 如果您想保存在阶段中产生的所有东西,请用未跟踪:真实代替整个路径部分。

最后,第二个名为test_with_lab的任务声明了实际运行测试套件的命令:

1test_with_lab:
2  stage: test
3  script: npm test

由于这是一个后期阶段,它可以访问由构建阶段产生的文物,这在我们的情况下是项目依赖部分。在这里,脚本部分展示了单行YAML语法,当只有一个项目时可以使用。

现在你对.gitlab-ci.yml 文件如何定义 CI/CD 任务有一个基本的想法,我们可以定义一个或多个可执行测试计划的跑者。

开启持续一体化之路

由于我们的存储库包含一个 .gitlab-ci.yml 文件,任何新的委托将触发新的 CI 运行. 如果没有跑者可用,CI 运行将设置为等待。在我们定义一个跑者之前,让我们触发一个 CI 运行,看看一个工作在等待状态中看起来是什么样子。一旦一个跑者可用,它将立即接收等待的运行。

在hello_hapi GitLab 项目库视图中,单击分支和项目名称旁边的 ** plus 标记**,然后从菜单中选择 新文件:

在下一页上,输入dummy_file在文件名字段中,然后在主编辑窗口中输入一些文本:

点击 ** 承诺更改 ** 在你完成后,在底部。

现在,回到主项目页面. 将附上一个小小的 ** 暂停的** 图标到最近的 commit. 如果您鼠标超过该图标,它将显示Commit:pending:

这意味着验证代码更改的测试尚未运行。

要获取更多信息,请前往页面顶部并点击 管道.您将被带到管道概述页面,在那里您可以看到CI运行标记为悬挂并标记为粘贴:

<$>[注] 注: 右侧有一个按钮为 CI Lint工具. 这是你可以检查任何你写的 gitlab-ci.yml 文件的语法的地方。

从这里,您可以点击 ** pending** 状态以获取有关跑步的更多细节. 此视图显示了我们跑步的不同阶段,以及与每个阶段相关的个别工作:

最后,点击install_dependencies任务,这将为您提供有关延迟运行的具体细节:

在这里,该消息表明该工作由于缺少跑者而被困住,这是预期的,因为我们尚未配置任何跑者,一旦有跑者可用,可以使用相同的界面来查看输出,这也是您可以在那里下载构建过程中产生的文物。

现在我们知道等待工作是什么样子,我们可以向我们的项目分配一个CI跑者来接收等待的工作。

安装 GitLab CI Runner 服务

现在我们已经准备好设置一个 GitLab CI 运行器。 要做到这一点,我们需要在系统上安装 GitLab CI 运行器包,并启动 GitLab 运行器服务。

如前提所述,您可以在托管您的 GitLab 实例的相同服务器上完成这些步骤,或者在不同的服务器上完成这些步骤,如果您想确保避免资源争议,请记住,无论您选择哪个主机,您都需要安装 Docker 用于我们将使用的配置。

安装 GitLab CI Runner 服务的过程与安装 GitLab 本身的过程相似. 我们将下载一个脚本,将 GitLab 存储库添加到我们的apt源列表中。

首先,将最新版本的 GitLab CI 运行器存储库配置脚本下载到 `/tmp 目录中(这与 GitLab 服务器使用的存储库不同):

1curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh -o /tmp/gl-runner.deb.sh

请自由检查下载的脚本,以确保您对它所采取的行动感到满意.您还可以找到一个主机版本的脚本 在这里:

1less /tmp/gl-runner.deb.sh

一旦您对脚本的安全性感到满意,请运行安装程序:

1sudo bash /tmp/gl-runner.deb.sh

该脚本将为您的服务器设置以使用 GitLab 维护的存储库。这允许您使用您在其他系统包中使用的相同的包管理工具来管理 GitLab 运行包。

1sudo apt-get install gitlab-runner

这将在系统上安装GitLab CI Runner包,并启动GitLab Runner服务。

创建一个GitLab Runner

接下来,我们需要设置一个GitLab CI运行器,以便它可以开始接受工作。

要做到这一点,我们需要一个GitLab运行符号,这样运行者可以通过GitLab服务器进行身份验证。

例如,如果您的「gitlab-ci.yml」文件定义需要凭证的部署任务,则可能需要一个特定的运行者正确身份验证到部署环境中。

另一方面,共享跑者是一个通用跑者,可以被多个项目使用。跑者将根据计算每个项目当前运行的任务数量的算法从项目中获取工作。

我们将在下面展示如何获得这两种跑者类型的跑者代币,选择最适合你的方法。

收集信息以注册项目特定的跑者

如果你想将运行程序绑定到一个特定的项目,请先导航到GitLab界面中的项目页面。

从这里,点击左侧菜单中的 设置项,然后点击子菜单中的 CI/CD项:

在此页面上,您将看到一个 ** Runner 设置** 部分。 点击 ** 扩展** 按钮以查看更多细节。 在详细视图中,左侧将解释如何注册项目特定的 Runner。

如果您想禁用此项目的任何活跃共享跑者,您可以通过右侧的禁用共享跑者按钮来做到这一点。

当你准备好了,跳过前来学习如何使用你从这个页面收集的信息来注册你的跑者。

收集信息注册共享跑者

要找到注册共享跑者所需的信息,您需要使用管理帐户登录。

首先,点击上面的导航栏中的 **wrench 图标来访问管理器区域。在左侧菜单的 Overview 部分,点击 Runners 来访问共享跑者配置页面:

复制向页面顶部显示的注册令牌:

我们将使用这个代币为该项目注册一个GitLab CI Runner。

使用 GitLab 服务器注册 GitLab CI Runner

现在你有一个代币,回到你安装了GitLab CI Runner服务的服务器。

要注册新跑者,请输入以下命令:

1sudo gitlab-runner register

您将被问到一系列问题来配置跑者:

请输入 gitlab-ci 协调 URL(例如 https://gitlab.com/)

输入您的 GitLab 服务器的域名,使用 https:// 来指定 SSL. 您可以选择将 /ci 附加到您的域的末尾,但最近的版本将自动重定向。

请输入此跑者的 gitlab-ci 代币

您在最后一节中复制的代码。

请输入这个跑者的 gitlab-ci 描述

这将出现在跑者服务在命令行和GitLab界面上的跑者列表中。

请输入这个跑者的gitlab-ci标签(comma分开)

GitLab 的工作可以表达这些标签的要求,以确保它们在具有正确依赖性的主机上运行。

你可以在这种情况下空白。

如何锁定 Runner 到当前项目 [true/false]

将运行器分配给特定项目. 它不能被其他项目使用。

点击这里选择假。

请输入执行者

跑步者用来完成任务的方法。

点击这里选择Docker。

请输入默认的 Docker 图像(如 Ruby:2.1)

当.gitlab-ci.yml 文件不包含图像规格时,使用的默认图像运行任务. 最好在这里指定一般图像,并在您的.gitlab-ci.yml 文件中定义更具体的图像,正如我们所做的。

我们将在这里输入alpine:latest作为一个小,安全的默认值。

响应提示后,将创建一个新的运行器,可运行项目的 CI/CD 任务。

您可以通过键入查看 GitLab CI 跑者服务目前可用的跑者:

1sudo gitlab-runner list

1[secondary_label Output]
2Listing configured runners ConfigFile=/etc/gitlab-runner/config.toml
3example-runner Executor=docker Token=e746250e282d197baa83c67eda2c0b URL=https://example.com

现在我们有一个运行器可用,我们可以回到GitLab中的项目。

在 GitLab 中查看 CI/CD 运行

回到您的网页浏览器,返回您的项目在GitLab. 取决于自注册您的跑者以来多久,跑者可能目前正在运行:

或者它可能已经完成了:

无论状态如何,请点击 运行或 通过图标(或 失败如果遇到问题),以查看 CI 运行的当前状态。

您将被带到管道概述页面,在那里您可以看到GitLab CI运行的状态:

在 ** 阶段** 标题下,会有一个圆圈,表示跑步中的每个阶段的状态. 如果你点击舞台,你可以看到与舞台相关的个别工作:

在 build阶段点击 install_dependencies工作,这将带您到工作概述页面:

现在,而不是显示没有跑者可用的消息,就显示了任务的输出,在我们的情况下,这意味着你可以看到安装每个包的npm的结果。

在右侧,你也可以看到一些其他项目,你可以通过更改 ** 阶段**和点击下面的跑步来查看其他工作,你也可以查看或下载任何由跑步制作的文物。

结论

在本指南中,我们已将示范项目添加到 GitLab 实例中,以展示 GitLab CI 的连续集成和部署功能. 我们讨论了如何在 gitlab-ci.yml 文件中定义管道来构建和测试您的应用程序,以及如何将工作分配到阶段来定义它们之间的关系。