CICD

本文以 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 配置说明： ...

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 集群）里，仍然能安全、快速地构建镜像。 ...

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 如何定义流水线？ 一个流水线本质上由两个核心概念构成： ...

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 离线包（无网络环境使用） 官方离线包下载地址 ...

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版本。 ...