DevOps on 维克的博客

从零开始：生产级 GitLab CI 流水线搭建

Fri, 30 Oct 2026 15:59:39 +0800

本文以 Go 语言为案例，从「只做编译和测试」的最小流水线起步，逐步加上构建镜像、镜像漏洞扫描、推送 Harbor，最终形成五阶段完整生产级 GitLab CI 流水线。

下面是本文的实践路线：

最小流水线，只做 build 和 test 阶段，让流水线先简单跑通。
增加 build-image 阶段，用 Kaniko 按 Dockerfile 构建镜像。
增加 scan-image 阶段，用 Trivy 扫描镜像，有高危漏洞直接退出。
增加 push 阶段，扫描通过后把镜像推送并打上标签。
汇总：给出完整五阶段配置与生产最佳实践。

为什么从头开始一点点增加步骤?

直接给出五十行的完整配置的话，出了问题根本不知道是编译、测试、构建、扫描还是推送哪一个阶段的问题。先跑通最小闭环，每次增加一个阶段，有问题能立即验证，排查范围小，人也更有把握。

日常编写构建生产级别的流水线也建议这样一步步验证。

1. 最小流水线验证

先只配置两个 job：

build 阶段：负责编译校验，确认代码能否正常打包、是否存在语法错误。
test 阶段：运行单元测试。

这两个 job 是整个 CI 的基础，也是触发最频繁、最需要优先跑稳的部分。

1.1 为什么先只做这两步

反馈最快：编译和单元测试在同一个代码环境中运行，几秒内就能拿到结果，不依赖镜像仓库或外部服务。
成本最低：不构建镜像、不推送，也不做扫描，任何分支的提交都可以安全触发，不会产生多余产物。
优先保障代码质量：如果编译或测试失败，就不应继续执行后续的构建、扫描和推送步骤。

1.3 写配置文件

在项目根目录新建 .gitlab-ci.yml，写入下面内容：

stages:
 - build
 - test

variables:
 GO_VERSION: "1.26"

 # 国内须覆盖 GOPROXY，否则 go mod download 走 proxy.golang.org 会超时
 GOPROXY: "https://goproxy.cn,direct"
 GOSUMDB: "sum.golang.google.cn"

 # 镜像仓库地址
 HARBOR_REGISTRY: example.harbor.com
 IMAGE_NAME: ${HARBOR_REGISTRY}/devops/web-demo

 # 缓存目录
 GOMODCACHE: $CI_PROJECT_DIR/.cache/go-mod
 GOCACHE: $CI_PROJECT_DIR/.cache/go-build


# ============================================================================
# Stage 1: 服务构建
# ============================================================================
build:
 stage: build
 image: ${HARBOR_REGISTRY}/devops/golang:1.26-trixie
 variables:
 GOFLAGS: "-mod=mod"
 cache:
 key:
 files:
 - go.sum
 paths:
 - .cache/go-mod/
 - .cache/go-build/
 untracked: true
 before_script:
 - mkdir -p ${GOMODCACHE} ${GOCACHE}
 script:
 - go mod download
 - go build -o /dev/null ./...  # 只验证能否编译，不产出二进制
 - go vet ./...

# ============================================================================
# Stage 2: 单元测试
# ============================================================================
test:
 stage: test
 image: ${HARBOR_REGISTRY}/devops/golang:1.26-trixie
 cache:
 key:
 files:
 - go.sum
 paths:
 - .cache/go-mod/
 - .cache/go-build/
 untracked: true
 before_script:
 - mkdir -p ${GOMODCACHE} ${GOCACHE}
 script:
 - go mod download
 - go test -v -race -coverprofile=coverage.out ./...
 artifacts:
 when: always
 expire_in: 1 week
 reports:
 coverage_report:
 coverage_format: cobertura
 path: coverage.out
 paths:
 - coverage.out

配置说明：

Kaniko 从入门到实践

Sat, 24 Oct 2026 11:28:31 +0800

1. Kaniko 是什么

Kaniko 是一个由 Google 开源的，在容器或 Kubernetes 集群内部，直接根据 Dockerfile 构建容器镜像的工具。

它最核心的特点只有一个：不依赖 Docker daemon（守护进程），所有构建动作都在用户态（userspace）完成。这意味着你不需要在集群里跑一个 Docker 服务，也不需要挂载 /var/run/docker.sock，就可以构建出标准镜像。

2. Kaniko 解决了什么问题

在 Kaniko 出现之前，CI 里构建镜像的主流做法是 Docker-in-Docker（DinD）。即在 CI Job 里再起一个 Docker 守护进程，用它去 build。这套方案在 Kubernetes 集群里有两个致命痛点：

需要 privileged 特权模式：dind 服务容器要操控内核特性，必须给 Pod 开 privileged: true。这是很严重的安全隐患——容器可能逃逸到宿主机，很多安全策略严格的集群直接禁止。
性能差：每个 Job 都额外拉起一个完整 Docker daemon，启动慢、占用高，多任务并发时更是灾难。

Kaniko 就是为了解决这个问题而生的：不用特权、不用 daemon，在标准 K8s 集群里就能安全构建镜像。

问题	DinD（旧方案）	Kaniko
需要 privileged 特权	✅ 必须	❌ 不需要
依赖 Docker daemon	✅ 必须	❌ 完全不需要
挂载 docker.sock	✅ 需要	❌ 不需要
安全性	有容器逃逸风险	纯用户态，安全
性能开销	每个 Job 起 daemon，慢	轻量，快

Kaniko 的核心价值用一句话来说就是：在不安全、不方便跑 Docker daemon 的环境（尤其是 K8s 集群）里，仍然能安全、快速地构建镜像。

GitLab CICD 入门指南

Thu, 22 Oct 2026 10:02:12 +0800

1. 简介

1.1 GitLab CI/CD 是什么？

GitLab CI/CD 可以理解为：GitLab 内置的持续集成 / 持续交付引擎。代码提交、合并请求、打标签或定时触发后，GitLab 会根据项目里的 .gitlab-ci.yml 生成流水线，再交给 GitLab Runner 去执行构建、测试、扫描、打包、部署等任务。

它的整体架构可以分成三层：

层级	组件	作用
控制层	GitLab Server	解析 `.gitlab-ci.yml`，生成 Pipeline，分发 Job，展示结果
执行层	GitLab Runner	从 GitLab 拉取任务，执行脚本，回传日志和产物
环境层	Executor	决定 Job 跑在哪里，比如 Docker、Kubernetes、Shell、SSH 等

一个典型的 Gitlab CICD 执行链路如下所示：

开发者 push 代码或创建 MR，触发流水线
 ↓
GitLab 读取仓库里的 .gitlab-ci.yml，生成 Pipeline 流水线作业
 ↓
Runner 轮询到待执行的任务，领取 Job
 ↓
Job 的 Tag 会和 Executor 的 Tag 进行匹配，匹配成功后，Executor 去执行 Job
 ↓
执行完成后，日志、制品、状态回传到 GitLab，在页面上可以查看结果

1.2 如何定义流水线？

一个流水线本质上由两个核心概念构成：

Gitlab 备份恢复和版本升级

Mon, 12 Oct 2026 19:32:50 +0800

1. gitlab 数据备份

1.1 数据备份

GitLab 提供一条命令 gitlab-backup create，运行命令后会产出一个压缩 tar 归档，包含数据库、Git 仓库与 LFS、CI/CD artifacts、Wiki、附件上传、Pages、注册表等。但它不包含配置文件、密钥、Redis 队列和对象存储，这些要另行处理。

官方提示至少必须单独备份 /etc/gitlab/gitlab-secrets.json（内含数据库加密密钥，丢失后无法解密两步验证和 CI 安全变量）与 /etc/gitlab/gitlab.rb。建议连同 /etc/gitlab/trusted-certs一起备份，避免整机恢复时出现中间人警告。

1.2 执行备份

Omnibus 包安装的环境下，可以直接调用官方封装命令：

gitlab-backup create

归档默认生成在 /var/opt/gitlab/backups/，文件名一般是这个样子： 1730000000_2026_10_12_17.5_gitlab_backup.tar。

可以在 /etc/gitlab/gitlab.rb 中调整文件保存路径和时间:

# 备份保留7天
gitlab_rails['backup_keep_time'] = 604800

# 备份目录配置
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

修改后执行 gitlab-ctl reconfigure。

需要排除某类数据时用 SKIP，例如跳过 CI 输出日志：

gitlab-backup create SKIP=builds,artifacts

1.3 生产备份策略

策略	做法	为什么
定时执行	用 cron 每天/每周触发 `gitlab-backup create`	备份频率决定最多可丢失多少数据（RPO）
异地/对象存储	把 tar 归档拷贝到另一台机器或对象存储（支持 S3 等 remote 配置）	单机磁盘故障时本地归档同样会丢
配置密钥单独备	定期打包 `/etc/gitlab` 到加密存储	密钥丢失=数据库无法解密，归档也无意义
定期恢复演练	在测试机用备份实际恢复一次	没验证能恢复的备份等于没有备份

提示：

Gitlab 入门和生产部署实践

Mon, 12 Oct 2026 14:51:37 +0800

1. 什么是 GitLab

GitLab 是一款开源的 Git 代码托管平台，支持私有化部署，被众多企业用于搭建内部代码仓库。与 GitHub 主打开源协作不同，GitLab 更聚焦于代码托管和研发流程自动化，原生提供 CI/CD、代码评审、权限管控、镜像仓库、日志审计等能力。

GitLab 主要分为两个版本：

CE 社区版：免费开源，基本能满足 95% 中小企业的生产需求（本文案例）；
EE 企业版：付费使用，提供高可用架构、高级安全扫描、集群权限管控以及官方技术支持，比较适合大厂落地。

总之，对企业来说，GitLab 的核心价值主要体现在四个方面：代码内网私有化存储、研发流程标准化、流水线自动化、操作可审计追溯。

2. 三种部署方式（选型）

Omnibus 包部署（生产首选）：官方推荐的标准生产部署方案，以一键安装包形式提供，支持主流 Linux 发行版。内置 PostgreSQL、Redis、Gitaly、Web、Sidekiq 等核心组件，部署路径清晰、运维成本较低、稳定性较高，是生产环境中最稳妥的选择。
K8s 混合部署（不推荐新人尝试）：面向大规模高并发场景时，官方推荐采用混合架构，将 Web、Sidekiq 等无状态组件部署在 Kubernetes 中，便于弹性扩缩；Gitaly、数据库、缓存等有状态服务则保留在虚拟机或独立节点上部署，以保证存储和数据的稳定性。不建议新手直接使用 Kubernetes 全组件部署 GitLab。有状态组件在容器环境中的存储管理、备份恢复和升级复杂度较高，生产风险较大。
Docker 单容器部署（仅测试用）：Docker 单容器部署启动快、上手简单，但在数据持久化、备份恢复、版本升级和高可用方面能力有限，仅适合本地测试、功能验证或演示环境，不建议用于生产。

3. 安装 GitLab

官方安装文档

3.1 前置硬件&系统要求

仅支持 linux，最低配置：4核8G（10人以内小团队），生产推荐 8 核 16G 及以上；
关闭 SELinux 或 AppArmor，否则可能影响服务正常运行；
存储优先用 SSD；不建议用 NFS、EFS、Azure Files 这类网络文件系统放仓库数据；
开放端口：80(http)、443(https)、22(ssh)。

3.2 添加 apt 源安装

# 更新系统依赖
sudo apt update && sudo apt upgrade -y

# 安装必备依赖
sudo apt install -y curl openssh-server ca-certificates tzdata

# 添加 GitLab 官方 APT 源
sudo curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash

# 安装 GitLab 社区版（默认启动初始化）
sudo apt install gitlab-ce -y

3.3 离线包（无网络环境使用）

官方离线包下载地址

ArgoCD 入门和生产实践指南

Sat, 10 Oct 2026 09:33:28 +0800

1. 什么是 ArgoCD

ArgoCD 是 CNCF 毕业级项目，面向 Kubernetes 的声明式 GitOps 持续交付工具。

GitOps 核心思想：Git 仓库作为应用配置的唯一可信源。ArgoCD 持续监听 Git 仓库内定义的应用目标状态，对比集群内资源的实际运行状态，自动完成应用部署、版本更新与故障回滚。

ArgoCD 原生支持多种配置编排方式：Helm Chart、Kustomize、Jsonnet、Ksonnet，以及原生 YAML/JSON Kubernetes 资源清单。

2. 架构原理

ArgoCD 以 Kubernetes 控制器形态运行，持续对应用做状态巡检：

拉取 Git 仓库中声明的期望状态（Target State）
采集集群内资源实际运行状态（Live State）
对比两者差异，不一致时标记为 OutOfSync（不同步）
可视化展示资源差异，支持手动同步 / 自动同步，将集群状态收敛到 Git 定义的目标状态

Git 仓库中修改清单后，ArgoCD 会感知变更并同步至目标集群，实现“改 Git 即发布”。

具体工作流程参见下面的图片：

核心组件:

组件	核心作用
`argocd-server`	ArgoCD API 服务，提供 REST API、Web UI，处理认证鉴权
`argocd-repo-server`	Git 仓库管理服务，缓存仓库代码、渲染 Helm/Kustomize 生成K8s清单
`argocd-application-controller`	应用控制器，持续做状态比对，执行同步、健康检查
`argocd-applicationset-controller`	ApplicationSet控制器，批量、模板化管理多环境/多集群 Application
`argocd-redis`	缓存组件，存储仓库缓存、应用状态信息
`argocd-dex-server`	可选，Dex 身份代理，对接OIDC、LDAP等外部身份源
`argocd-notifications-controller`	可选，通知控制器，同步状态变更推送至邮件、Slack、Webhook等

3. 部署

部署前建议查阅官方版本兼容矩阵，选择与K8s集群匹配的ArgoCD版本。

Harbor 私有镜像仓库安装部署和最佳实践

Sat, 03 Oct 2026 11:32:44 +0800

1. 简介

Harbor 是 CNCF 托管、VMware 开源的企业级容器镜像仓库，基于 Docker Registry 二次开发。除基础镜像存储能力外，还提供 Web UI、细粒度RBAC权限、镜像漏洞扫描、垃圾回收、镜像复制同步、审计日志等企业级能力，是 Kubernetes 集群离线部署、容器镜像统一管理的核心组件。

适用场景：企业内网私有镜像托管、Kubespray 离线集群镜像分发、CI/CD流水线镜像仓库。

官方参考文档：

Harbor 官方安装指南：https://goharbor.io/docs/2.8.0/install-config/
Harbor HTTPS 证书配置文档：https://goharbor.io/docs/main/install-config/configure-https/
Harbor 版本生命周期与版本策略：https://goharbor.io/docs/main/install-config/versioning/
Harbor 备份恢复官方文档：https://goharbor.io/docs/main/administration/backup-restore/
Harbor 生产环境最佳实践：https://www.cncf.io/blog/2026/02/24/making-harbor-production-ready-essential-considerations-for-deployment/
Harbor 官方 Trivy 文档：https://goharbor.io/docs/2.14.0/scan/
Trivy 官方文档：https://aquasecurity.github.io/trivy/

2. 前置环境准备

2.1 Harbor版本选型指南

当前最新版已经到 v2.15.x，很多人会直接选用最新版，但不建议生产直接上最新大版本。

Harbor版本命名规则：主版本.次版本.补丁号，例如 2.10.2、2.15.0

奇数小版本（2.11、2.13、2.15）：新特性版本，引入新功能、重构模块；bug相对多，适合测试体验，不推荐生产直接使用。
偶数小版本（2.10、2.12、2.14）：长期维护稳定分支，重点修复漏洞，新增功能保守，生产首选。

举例：

v2.15.x：新特性版，适合尝鲜、学习测试；
v2.14.x：当前最新稳定偶数版；
v2.10.x：久经大规模生产验证，bug少，社区问题资料极多，如果不需要新版本的一些新特性的话，推荐使用。

企业生产环境：优先选择偶数LTS稳定分支，发布至少3个月以上，积累足够补丁。不要选用刚发布的 .0 首版（例如 2.15.0），这类版本会存在较多未发现的bug。

2.2 基础依赖

Harbor 基于 Docker Compose V2 编排运行，提前准备依赖环境：

Docker Engine：20.10+
Docker Compose V2
系统架构：amd64 / arm64 均可支持（OrbStack、VMware虚拟机均可正常运行）
硬件资源：测试环境≥2核4G；生产环境≥4核8G，推荐SSD存储提升镜像读写性能

3. Harbor 离线安装流程

离线包稳定性高于在线安装，内网、离线集群优先选用。本文部署以v2.14.4版本为例。