企业官网建设流程全解析

1. GitLab Runner 概述与安装准备

GitLab Runner 是 GitLab CI/CD 的核心组件，负责执行持续集成和持续交付的作业。它作为一个轻量级的代理程序，可以部署在各种操作系统上，与 GitLab 实例协同工作。在 Rocky Linux 10 上安装 GitLab Runner 是一个相对直接的过程，但需要注意一些关键细节以确保稳定运行。

1.1 系统环境检查

在开始安装前，建议先检查系统环境：

# 检查系统版本 cat /etc/redhat-release # 检查CPU架构 uname -m # 确保curl已安装 sudo dnf install -y curl

提示：虽然Rocky Linux 10默认包含curl，但某些最小化安装可能缺少这个工具。如果遇到"command not found"错误，请先安装curl。

1.2 用户与权限规划

GitLab Runner 需要一个专用系统用户来运行作业。我们选择创建名为"gitlab-runner"的用户，这符合Linux系统管理的最佳实践：

# 检查是否已存在gitlab-runner用户 id gitlab-runner || echo "用户不存在，可以继续安装"

创建专用用户有几个重要优势：

• 隔离运行环境，增强安全性
• 便于权限管理
• 方便日志追踪和问题排查

2. 安装GitLab Runner

2.1 下载二进制文件

从官方源下载最新版的GitLab Runner二进制文件：

sudo curl -L --output /usr/local/bin/gitlab-runner \ https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

这里有几个关键点需要注意：

1. 使用-L参数让curl跟随重定向
2. 输出路径选择/usr/local/bin，这是存放本地安装程序的常规位置
3. 下载的是针对amd64架构的Linux版本

注意：如果您的系统是ARM架构，需要将"amd64"替换为"arm64"。

2.2 设置执行权限

下载完成后，需要赋予执行权限：

sudo chmod +x /usr/local/bin/gitlab-runner

权限设置非常重要，它确保：

• root用户可以安装服务
• gitlab-runner用户可以执行程序
• 其他用户无法修改或执行

2.3 创建系统用户

创建一个专用的系统用户来运行GitLab Runner：

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

参数说明：

• --comment：添加用户描述
• --create-home：创建用户主目录
• --shell /bin/bash：指定bash作为默认shell

2.4 安装系统服务

将GitLab Runner安装为系统服务：

sudo /usr/local/bin/gitlab-runner install --user=gitlab-runner \ --working-directory=/home/gitlab-runner

服务安装参数：

• --user：指定运行服务的用户
• --working-directory：设置工作目录

启动服务并设置开机自启：

sudo /usr/local/bin/gitlab-runner start

2.5 创建符号链接（可选但推荐）

为了方便使用，可以创建一个符号链接：

sudo ln -sf /usr/local/bin/gitlab-runner /usr/bin/gitlab-runner

这样就能直接使用gitlab-runner命令，而不需要输入完整路径。

3. GitLab网页端配置

3.1 访问Runner设置页面

1. 登录GitLab网页界面
2. 进入项目设置 → CI/CD → Runners
3. 点击"New project runner"按钮

3.2 填写Runner配置

关键配置项说明：

标签(koji-build)的作用：

• 用于将作业定向到特定Runner
• 后续CI/CD流水线会根据这个标签选择Runner
• 建议使用有意义的、项目相关的名称

勾选"Run untagged jobs"可以防止：

• 忘记给作业打标签时任务被阻塞
• 配置错误导致的作业停滞

3.3 获取注册令牌

点击"Create runner"后，页面会显示一个以glrt-开头的注册令牌。这个令牌有以下几个特点：

• 每个Runner唯一
• 一次性使用（注册后失效）
• 有效期为30分钟

重要：立即复制这个令牌，页面刷新后将无法再次查看。

4. 终端注册Runner

4.1 执行注册命令

在服务器终端运行注册命令：

sudo gitlab-runner register

4.2 输入配置信息

按照提示依次输入以下信息：

1. GitLab实例URL：

   http://172.16.104.218:8080/

   注意：根据实际GitLab地址修改，确保使用HTTP或HTTPS协议

2. 注册令牌：粘贴从网页复制的glrt-xxxx令牌

3. 描述：可以直接回车使用默认值，或输入有意义的名称如yuhua-koji-builder

4. 标签：可以回车跳过（已在网页端设置）

5. 执行器(Executor)：输入shell

   • shell是最简单的执行器
   • 适合大多数基础使用场景
   • 对于更高级的用例可以考虑docker或kubernetes

4.3 验证注册结果

注册完成后，可以通过以下命令检查Runner状态：

sudo gitlab-runner verify

输出应显示Runner已连接并准备就绪。

5. 常见问题与解决方案

5.1 连接问题排查

如果Runner无法连接到GitLab实例，可以尝试：

# 测试网络连通性 ping 172.16.104.218 # 测试端口访问 telnet 172.16.104.218 8080 # 检查防火墙规则 sudo firewall-cmd --list-all

5.2 权限问题处理

常见的权限错误及解决方法：

5.3 服务管理命令

常用服务管理命令备忘：

6. 高级配置与优化

6.1 并发设置

编辑配置文件调整并发数：

sudo vim /etc/gitlab-runner/config.toml

找到concurrent参数，根据服务器性能调整：

concurrent = 4

建议：初始值设置为CPU核心数的1-2倍，根据实际负载调整。

6.2 日志配置

默认日志位置：

/var/log/gitlab-runner/

调整日志级别（在config.toml中）：

log_level = "info" # 可改为debug获取更详细日志

6.3 安全加固建议

1. 定期更新Runner版本：

sudo gitlab-runner stop sudo curl -L --output /usr/local/bin/gitlab-runner \ https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 sudo chmod +x /usr/local/bin/gitlab-runner sudo gitlab-runner start

2. 限制Runner网络访问：

   • 使用防火墙规则限制出站连接
   • 只允许访问必要的GitLab实例和依赖服务

3. 定期检查Runner日志：

sudo journalctl -u gitlab-runner -f

7. 实际使用经验分享

在实际生产环境中运行GitLab Runner几个月后，我总结了一些有价值的经验：

1. 标签策略：不要过度使用标签。开始时我们为每个微服务创建了独立标签，结果导致管理复杂。后来改为按环境(dev/stage/prod)和机器类型(highmem/gpu)分类，效率大幅提升。

2. 资源监控：安装后前两周要密切监控系统资源。我们曾遇到一个失控的构建作业吃光了16GB内存，导致服务器崩溃。现在我们会：

   • 在config.toml中设置output_limit
   • 使用cgroups限制资源使用
   • 对长时间运行的作业设置超时

3. 缓存配置：合理配置缓存可以显著提升构建速度。我们为Maven/NPM等包管理器设置了共享缓存：

[[runners]] [runners.cache] Type = "s3" Shared = true [runners.cache.s3] ServerAddress = "s3.example.com" AccessKey = "access-key" SecretKey = "secret-key" BucketName = "gitlab-runner-cache" BucketLocation = "us-east-1"

4. 灾备方案：永远要有备用Runner。我们配置了至少两台Runner服务器，当主节点维护时，CI/CD流程不会中断。使用相同的标签可以让作业自动故障转移。

5. 清理策略：定期清理工作空间。我们设置了每周执行的cron作业：

0 3 * * 0 find /home/gitlab-runner/builds -mtime +7 -exec rm -rf {} \;

这些经验都是通过实际运维积累的，希望能帮助您避免我们踩过的坑。GitLab Runner是一个非常灵活的工具，正确的配置和管理可以极大提升团队的开发效率。