Files

jack 8c43761962 feat: 按 doc_id 重组 ansible/files 与验证框架

- ansible/files 改为与文档 XX-YY 对齐的目录结构，更新相关 playbook 路径
- 新增 scripts/verify.sh 与 ansible/playbooks/verify/*.yml，移除单体 verify-matrix.yml
- 补充 docs/00-02 矩阵状态、00-05 验证框架与流程、00-04 环境与 ylc65 工作机说明
- 增加 k3s 存储准备、Longhorn、local-path 等 playbook 与辅助脚本

Made-with: Cursor

2026-03-26 07:01:14 +08:00

4.6 KiB

Raw Blame History

05-03-k3s 安装 GitLab（含 Runner）

通过 Helm 在 K3s 部署 GitLab，并接入 Runner 执行 CI 任务。

前置条件

01、02、04-01 已完成
集群资源足够（GitLab 对 CPU/内存要求较高）
已有可用域名（例如 git.example.com）

为什么这里用 Helm 而不是纯 YAML？

GitLab 属于重量级应用：组件多（Web/Sidekiq/Registry/DB/Redis 等），关联的 YAML 数量非常大。
官方维护的 Helm Chart 已经帮你整理好了依赖关系、默认参数和升级路径，本质上还是“渲染出一堆 YAML 再 kubectl apply”。
在本仓库里：简单/教学型服务（nginx、Node.js demo、Homer、OneNav 等）我们通过示例 YAML 手写；而像 GitLab 这种复杂应用，则更推荐直接沿用官方 Chart，只维护一份 values-gitlab.yaml。

安装 Helm

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

安装 GitLab

helm repo add gitlab https://charts.gitlab.io/
helm repo update
kubectl create namespace gitlab

准备 values-gitlab.yaml（按你的域名与资源调整），然后安装：

helm upgrade --install gitlab gitlab/gitlab \
  -n gitlab \
  -f values-gitlab.yaml

安装/绑定 Runner

在 GitLab 管理后台获取 Runner 注册信息
按节点类型（x86 / arm64 / armv7）分别部署 Runner，并为每类 Runner 设置不同的 tag
确认 Job 能被对应架构的 Runner 拉起执行

安装 gitlab-runner 二进制（各架构通用）

GitLab 官方提供多架构的 Runner 二进制，常见 Linux 节点可以用如下方式安装（以 root 或具备 sudo 权限的用户为例）：

# x86_64
sudo curl -L https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 -o /usr/local/bin/gitlab-runner
sudo chmod +x /usr/local/bin/gitlab-runner

# arm64
sudo curl -L https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm64 -o /usr/local/bin/gitlab-runner
sudo chmod +x /usr/local/bin/gitlab-runner

# armv7 (arm32)
sudo curl -L https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm -o /usr/local/bin/gitlab-runner
sudo chmod +x /usr/local/bin/gitlab-runner

安装完成后，可按官方文档将 Runner 注册为 systemd 服务；下面的注册命令默认 gitlab-runner 已在对应架构节点上就绪。

x86 Runner（两种典型方式）

方案一：在 K3s 集群内，使用 Helm 部署 Kubernetes executor

适合大部分“直接对接 K3s”的 CI 场景，Runner 以 Pod 形式运行在集群中：

helm repo add gitlab https://charts.gitlab.io/
helm repo update

kubectl create namespace gitlab-runner

helm upgrade --install gitlab-runner-x86 gitlab/gitlab-runner \
  -n gitlab-runner \
  --set gitlabUrl=https://git.example.com/ \
  --set runnerRegistrationToken=<YOUR_RUNNER_TOKEN> \
  --set runners.tags=x86

后续在 .gitlab-ci.yml 中通过 tags: [x86] 指定由该 Runner 执行。

方案二：在独立 x86 节点上，使用 shell/docker executor

如果你有独立的 x86 机器（不在 K3s 集群中），也可以在该节点上直接安装 Runner，并打上 x86 tag：

sudo gitlab-runner register \
  --url https://git.example.com/ \
  --registration-token <YOUR_RUNNER_TOKEN> \
  --executor shell \
  --description "x86-standalone-runner" \
  --tag-list "x86" \
  --non-interactive

arm64 / armv7 Runner（物理机上，shell/docker executor）

对于 arm64 与 armv7 这类非 x86 节点，更常见的做法是在对应物理机上直接安装 GitLab Runner，并打上架构标签。例如：

# 在 arm64 主机上
sudo gitlab-runner register \
  --url https://git.example.com/ \
  --registration-token <YOUR_RUNNER_TOKEN> \
  --executor shell \
  --description "arm64-runner" \
  --tag-list "arm64" \
  --non-interactive

# 在 armv7 主机上
sudo gitlab-runner register \
  --url https://git.example.com/ \
  --registration-token <YOUR_RUNNER_TOKEN> \
  --executor shell \
  --description "armv7-runner" \
  --tag-list "armv7" \
  --non-interactive

在 .gitlab-ci.yml 中即可按需指定不同架构运行 Job，示例见 ansible/files/05-03-gitlab-runner/gitlab-ci-runner-tags.example.yml。

验证

kubectl -n gitlab get pods
kubectl -n gitlab get svc

在 GitLab 页面检查：

项目能正常访问
Pipeline 可成功执行

下一步

05-04-k3s-配置gitlab-cicd.md
03-04-k3s-cloudflare-tunnel-配置接入.md

4.6 KiB Raw Blame History Unescape Escape