使用 GitLab CI/CD 为 Linux 创建 RPM 包（一）

大家好！我是大聪明-PLUS！

各位同事，大家好。前段时间，我们团队接到一个任务，开发一个用于与外围设备协同工作的服务，该服务将作为服务在 Linux 操作系统工作站上运行。

到目前为止，我们部门的所有桌面应用程序都是专门为 Windows 开发的。当前的任务对团队来说既是一个挑战，也是一个学习新知识的机会。我的团队对这个项目的准备标准是编写程序本身并将其发布为 RPM 包以供分发。

技术栈：

• 返回 NET Core 8

• 操作系统 Alt Linux 工作站 K 10.4。

• GitLab

• Docker

问题分解

如果你把问题分解成各个部分，并分别处理，那么解决问题就会容易得多。我列出了以下步骤：

• 使用.NET Core 8开发一个简单的控制台程序。

• 手动构建 RPM 包。

• 设置 CI/CD。

• 为 GitLab 创建一个工作管道并获取 RPM 包作为输出。

开发一个简单的程序

如果您尝试立即打包一个包含许多项目和依赖项的现成程序，您可能会遇到意想不到的问题，从而分散您对目标的注意力。

在我看来，打包一个简单的程序要容易得多。仔细检查所有步骤，并解决所有与打包相关的问题。当需要打包目标程序时，您可以轻松扩展现有的流程，并且任何错误都只与二进制文件编译问题有关。

说干就干。一个简单的控制台程序就开发出来了——一个计数器，每秒显示一个 +1 的数字。

Console.WriteLine("Start counting");
await Counter();Task Counter()
{int i = 0;while (true){Console.WriteLine(i);i++;Thread.Sleep(1000);}
}

工作成果

因此，如果我们在构建软件包、在全新操作系统上安装并从命令行运行后得到相同的结果，则一切正常。如果这一切都是通过管道自动完成的，那就太棒了。

构建 RPM 包

从现在开始，我将描述具体步骤，假设你已经熟悉 spec 文件及其工作原理的术语和基本原理。

要构建 RPM 包，您需要按顺序执行以下步骤：

• 安装 rpm-build 实用程序

• 组装目录的配置。

• 生成 spec 文件

• 准备文件并将其移动到所需的目录。

• 运行命令 rpmbuild -ba <spec 文件名>

安装 rpm-build 实用程序

sudo apt-get update && apt-get install -y rpm-build

组装目录的配置

这在现阶段很方便，但在流程中并不方便。

rpmdev-setuptree

请注意：绝大多数文章，甚至任何神经网络，都会告诉你 /home/user/.rpmbuild 目录已创建。Alt Linux 的配​​置似乎有所不同，它创建了 /home/user/RPM 目录。这并不重要，而且我还没有测试如果通过 .rpmbuild 文件夹执行所有操作，它是否能在管道中正常工作。我决定保持现状。

此外，您的主目录根目录下会创建一个 .rpmmacros 文件，您需要手动编辑该文件以删除所有不必要的文本。您可以在上面的链接中相关信息。

结论：在管道中，我们将手动创建一个目录结构并放置一个预先生成的.rpmmacros文件，该文件将位于项目的根目录。

生成 spec 文件

构建包最重要的一步是创建正确的规范文件。

spec 文件本身在本质上与管道描述文件非常相似。它是一个清单和一组指令，脚本必须执行这些指令才能生成编译后的程序，以及在安装过程中在哪里以及如何编写它。

请注意：我因为一个相当愚蠢的错误浪费了一些时间。SPEC 文件最初是在 Windows 中生成的，换行符用 \r\n 标记。我构建的 Linux 系统不接受这个标记，并报出了“无效返回码”的错误。我尝试使用 exit 0 等命令返回正确的返回码，结果浪费了不少时间。我删除了文件中的 \r 后，一切正常。

一个有趣的观察是，如果你在 Git 中提交文件，这些问题就不会发生。它似乎会立即更改它们并发出警告。

Spec 文件示例

在生成 spec 文件时，我假设程序应该位于 /opt/{name} 目录中，并且应该有一个指向 /usr/bin/{name} 中可执行文件的链接，以便可以在不指定路径的情况下运行它。

Name:           utestrpm
Version:        0.0.0 
Release:        1%{?dist}License:        MIT
Group:			Other
URL:            https://your-domain.com
Source0:        source_file.tar.gz BuildArch:      x86_64 
BuildRequires:  dotnet-8.0 %prep
%setup -q%buildexport DOTNET_NUGET_SIGNATURE_VERIFICATION=false dotnet publish -c Release -r linux-x64 --self-contained true -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true%install
rm -rf %{buildroot}
mkdir -p %{buildroot}/opt/%{name}
mkdir -p %{buildroot}%{_bindir}install -m 755 %{name}/bin/Release/net8.0/linux-x64/publish/%{name} %{buildroot}/opt/%{name}/%{name}ln -sf /opt/%{name}/%{name} %{buildroot}%{_bindir}/%{name}%post%preun%files/opt/%{name}/%{name}%{_bindir}/%{name}# /opt/%{name}/config/appsettings.json%changelog

这份清单简洁明了，每一行的功能都一目了然。我想强调几点。

%{buildroot}是文件中最重要的宏。构建软件包时，会创建一个虚拟根系统，该宏指向它。安装软件包时，它将指向根系统的链接。通常情况下，该宏的值为“/”。

尽可能多地使用宏也很重要。例如，Alt Linux 中的 %{_bindir} 是“/usr/bin”。在其他存储库中，它可能只是“/bin”或其他名称。因此，宏越多越好。但是，我找不到指向 /opt 的宏。

在 Linux 上构建 .NET Core 解决方案时，我在更新 NuGet 包时遇到了证书验证问题。网上有很多解决这个问题的技巧。禁用验证对我有帮助。我认为这是可以接受的，也很方便。请记住，我们的目标是从管道运行所有内容，因此复杂的解决方案可能不合适。

export DOTNET_NUGET_SIGNATURE_VERIFICATION=false 

我还想指出构建 .NET 应用程序的一些细微差别。我决定将整个解决方案打包成一个可执行文件。这大大简化了 spec 文件的创建。但这可能会导致以后出现问题，在这种情况下，我们将不得不采用传统的方式构建，复制所有内容，而不是直接复制一个文件。

dotnet publish -c Release -r linux-x64 --self-contained true -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true

关于 spec 文件，我最后想指出的是，如果你仔细观察，会发现第 48 行（也就是写入配置文件的部分）被注释掉了。这是为了在开发过程中，当我把程序变得更复杂，以便调试它在 Linux 下运行的所有细微差别时，留出一些余地。

准备文件

重要！请注意：我认为最重要的细节是从头开始阅读文章！如果你还没读过，也请从头开始。否则，你可能会看不清楚。

因此，我们有一个必需的 Version 字段和一个 Source 字段。在示例中，Source 通常这样描述：

Source: %name-%version.tar

这可以很容易地改变，然后在管道中完成，为静态名称，这在管道阶段之间形成工件时更加方便。

但是！这里有个陷阱！源文件可以任意命名，但它的结构严格依赖于 %name 和 %version 宏。

rpmbuild 脚本解压存档并运行命令

cd ~/RPM/BUILD/%name-%version

当然，从 spec 文件中替换所需的值。如果找不到此目录，脚本将因错误而终止。

下面是我们的程序需要的 tar.gz 存档的示例，其名称为 utestrpm，版本为 1.0.2，例如：

因此，仅仅将程序打包到存档中是不够的。您需要创建一个名为 %name-%version 的目录。将源文件放入其中，然后将该目录打包到存档中。

我几乎可以肯定这种行为是可以定制的。但何必呢？把这个功能纳入到流程中要容易得多。

召集团队

这是最简单的部分。我们调用命令并等待它成功完成。

rpmbuild -ba utestrpm.spec

请注意：需要注意的是，默认情况下，此命令无法从特权用户（root 或 sudo）调用。我在网上找到了一篇文章，解释了为什么这是正确的。我没有读过这篇文章，所以就照搬了。

结论：您必须在管道中创建一个非特权用户并在其下执行命令。

设置 CI/CD

原则上，如果 GitLab 和运行器已经设置好了，可以跳过这一步。但是，为了让一切按我想要的方式运行，我需要 80 次提交。而且，在我完成所有实验并准备好将所有工作应用到目标项目之前，还需要大约 80 次提交。我不想让我的主仓库被这些垃圾弄得乱七八糟。

我决定在我的办公电脑上使用 Docker 设置 GitLab 和一个 Runner。

安装 GitLab

docker run --detach \--hostname 172.17.0.2 \--publish 443:443 --publish 80:80 --publish 22:22 \--name gitlab \--restart always \gitlab/gitlab-ce:latest

注意主机名。您可能需要使用其他值。我将在下面解释具体值以及原因。

安装 GitLab 后（启动需要几分钟）

登录名为 root。可以通过运行以下命令找到密码

 docker exec -it gitlab cat /etc/gitlab/initial_root_password

请注意：快速执行命令很重要，因为文件会在短时间后被删除。

让我们安装 GitLab。创建一个组和一个项目。它看起来应该像这样。

在 GitLab 中创建 Runner

需要注意的是，这可能会造成混淆。在 GitLab 中，您需要创建一个名为 Runner 的实体。该实体将拥有所有权（Runner 可以是本地的、组的等等）。它还包含一些设置——何时运行、在哪些项目上运行等等。

在本文中，我创建了一个单组运行器。要创建它，请转到组部分。在我的示例中，它被称为 lnx，然后选择“Build/Runners”。

你会看到跑步者。我有一个，这就够了。还有一个按钮可以创建新的runner。

让我们创建一个可以在所有提交上运行的新运行器。

注意，点击“创建跑步者”后，它会将我重定向到哪个地址。

这个 IP 的出现是因为我分配了那个主机名。只需在浏览器中将其替换为 localhost，我们就能找到所需的内容。这只是暂时的不便，理想情况下我们只需要忍受一次，但它会为我们节省很多后续的精力。我很快会解释原因。

请注意：请务必复制标有感叹号的文本。您将无法再次访问它。它是最终配置所必需的。

如果我们回到runner名单页面，我们会看到一位注册跑步者的状态为“从未联系过”

创建并注册 gitlab-runner 容器

正如我之前所写，运行器既是 GitLab 中的一个实体，也是安装在特定工作站上的特殊程序。该程序将执行管道命令。要确定 GitLab 将调用哪个工作站，您需要将 GitLab 运行器与该工作站关联起来。

虚拟机通常是创建运行器的理想选择。您可以创建多个虚拟机，并为其分配所需的资源等等。要运行管道，只需一个安装了运行器程序的 Docker 镜像即可。要安装它，请运行以下命令。

docker run -d --name gitlab-runner --restart always \-v /srv/gitlab-runner/config:/etc/gitlab-runner \-v /var/run/docker.sock:/var/run/docker.sock \gitlab/gitlab-runner:latest

因此，我们有两个 docker 镜像

最后一步是注册参赛者。你需要给参赛队伍打电话。

docker exec -it gitlab-runner /bin/bash

我们将连接到 Docker 容器控制台。将复制的文本粘贴到控制台中。每次操作的令牌都会有所不同。

gitlab-runner register  --url http://172.17.0.2  --token glrt-570XNtiakleL5Dn_tzWUrmc6MwpvOjEKdDoyCnU6MQ8.01.171afrob3

接下来，系统会要求我们指定地址——我们保留默认地址。为运行器命名。指定运行器的启动方式——输入 docker。并指定默认镜像。我使用了 alt:p10。

GItlab 中的运行器应该会变成绿色，并显示“在线”状态。好啦，我们快完成了。现在只剩下编写管道了。

为什么 172.17.0.2 这个地址受到如此多的关注？

在继续之前，我们有必要解释一下主机名 172.17.0.2 的由来。我将介绍一种快速简便（尽管略显不妥）的方法来配置运行器，使其正常工作，而无需任何不必要的工作。这仅适用于测试假设和作为临时措施。仅此而已。

问题是，Docker 容器通过它们自己的网络相互通信，而这个网络由 Docker 管理。你可以在 Docker 中添加自己的网络，分配一系列 IP 地址，并将每个镜像与该网络内的特定 IP 地址关联。这没问题。但我们正在构建一个 MVP 解决方案，它只服务于一个目的。在我看来，花时间完美配置 Docker 是没有必要的。

解决方案是查看默认网络，找出分配给 GitLab 容器的 IP 地址。让我们运行以下命令：

docker network ls

就我而言，我得到了以下结果

请注意名为“bridge”的网络。除非您删除它，否则它始终存在。您创建的任何容器都将链接到此网络。

要查看哪个 IP 地址与容器关联，可以运行命令

docker network inspect bridge

这是这个 IP 地址。

请注意：由于我们没有为 gitlab 容器分配此 IP 地址，重启计算机后，gitlab-runner 容器很可能会先启动，然后它会占用此 IP 地址。这个问题可以轻松解决，只需停止所有容器，然后先启动 gitlab，再启动 gitlab-runner 即可。

文字太多了，仍然不明白为什么这如此重要。

这一点很重要，因为 gitlab-runner 容器内部也包含 Docker。我们的流水线将在内部 Docker 中运行，下载 alt:p10 镜像，并在每一步上传源文件，等等。

这只是 Docker in Docker 方法的一个经典示例。

通过指定主机名，我们配置了 GitLab，以便运行器能够通过 IP 地址而不是域名访问它。这样就可以正常工作了。例如http://172.17.0.2/groups/lnx/utestrpm。

如果我们的 GitLab 配置正确，并分配了一个可在您的网络上访问的有效域名，那么就不会有问题。我们可以使用正确的主机名成功访问它。

在我们的例子中，在本地机器上，我们会遇到一些麻烦。我们必须在 hosts 文件中指定主机名，重启，还要确保为容器分配正确的 IP 地址，或者在 Docker 中创建自定义网络等等。在我看来，将 IP 地址指定为主机名更简单，而且一切正常。

创建管道

你已经了解了什么是管道以及它的用途。如果你不知道，任何神经网络都会很乐意告诉你。我们将提供一个 GitLab 管道示例，它将构建一个 RPM 包，并涵盖其中的关键点。

准备档案（prepare_tar）

此阶段旨在生成成功执行 rpmbuild 脚本所需的工件。

第一步是确定应用程序版本。在实际开发中，版本增量非常重要。版本值放在项目中包含的 env.json 文件中。

{"service": "1.0.2"
}

安装了 jq 实用程序并用于查找版本。该版本被放置在 $VERSION 变量中。为了方便起见，还确定了未来存档的根文件夹名称。

- VERSION=$(jq -r '.service' utestrpm/env.json)- echo "VERSION=$VERSION" > version.env- FOLDER="utestrpm-$VERSION"

下一步是生成归档文件。tar 命令非常复杂且用途广泛，因此我将在评论中解释其工作原理。

- tar -czf source_file.tar.gz --transform "s,^,$FOLDER/," utestrpm.sln utestrpm/

下一步是生成与当前版本匹配的 spec 文件。最简单的方法是直接替换基础模板文件中的版本，并相应地重命名。

- sed "s/^Version:.*/Version:$VERSION/" utestrpm_template.spec > utestrpm.spec

我们需要发送到下一步的只是正确的存档和正确的 spec 文件，以及版本信息。.rpmmacros 文件已存在于项目中，永远不会被更改。我们会在构建过程中将其复制到正确的位置。

发布 RPM（build_rpm）

最后的润色。首先，让我们安装所需的依赖项。这些包括 rpm-build 包本身、dotnet-sdk 环境和 su 实用程序，我们需要它来防止脚本崩溃（您无法以 root 身份运行它）。

下一步是创建一个用户、他们的主文件夹以及其中的正确目录结构。

- useradd -m -s /bin/bash $RPM_USER- mkdir -p $RPM_DIR/{SOURCES,SPECS,RPMS,SRPMS}

需要复制这些文件并更改所有者。目前是 root 用户，但应该是我们的服务用户。

TODO：路径是硬编码的 - 需要修复:)

- cp source_file.tar.gz $RPM_DIR/SOURCES/- cp utestrpm.spec $RPM_DIR/SPECS/- cp .rpmmacros /home/$RPM_USER- chown -R pipe_builder:pipe_builder /home/pipe_builder/

好吧，最好的部分是 - 我们运行脚本

- su - $RPM_USER -c "cd $RPM_DIR/SPECS && rpmbuild -ba utestrpm.spec"- cp $RPM_DIR/RPMS/x86_64/*.rpm ./- ls -al *.rpm

请注意：直接运行 su 会失败，因为我们在当前线程中仍然是 root 权限。您可以运行 whoami 命令来验证这一点。

-c 选项可以解决问题，立即在我们需要的用户下执行命令。

结果

我不知道你的情况，但我一切正常。RPM 包已创建，版本号也正是我需要的。包可以下载了。在实际项目中，我会添加测试、检查/复检、发布并部署到沙盒，以及将包保存到 Nexus，但那是另一回事。

研究阶段尚未完成。然而，研究结果对本文来说已经足够了。在将这些研究成果转化为实际项目之前，我们需要完成以下步骤：

• 将程序设为服务，配置自动启动（systemctl enable），编辑 spec 文件以便在包安装期间进行配置。

• 正确输入日志，以便可以通过 journalctl 读取

• 添加配置文件，例如 appsettings.json。确保它们已安装并应用。

我可能会写另一篇文章，但肯定会更短。

感谢您的关注。希望本文能对大家有所帮助。