1) Linux 环境准备与总体架构设计
在正式搭建 GitLab CI/CD 之前，需要明确目标与架构，以便后续的环境搭建、流水线编排与交付策略保持一致。目标是实现从代码提交到自动构建、测试、打包与部署的全流程自动化，并确保在 Linux 环境下具备稳定性与可扩展性。
本阶段的核心要点包括：操作系统版本、硬件资源、网络连通性、存储容量与备份策略，以及流水线涉及的安全、审计和监控需求。
# 查看当前 Linux 发行版与版本信息，帮助确定后续安装方式
lsb_release -a
uname -r
1.1 操作系统与硬件需求
推荐在 Debian/Ubuntu、CentOS/RHEL 等主流发行版上部署，并确保系统具备4核 CPU与至少 8GB 内存，生产级别建议配置更高的内存以支撑并发任务。
存储方面应优先使用 SSD，并规划合理的 I/O 吞吐与 IOPS，对数据库、镜像与构建制品的写入有直接影响；此外，考虑到备份与自愈能力，建议配置 RAID/ZFS 以及定期的全量与增量备份策略。
1.2 架构组件与部署模式
核心组件通常包含 GitLab 实例、GitLab Runner、镜像仓库（Registry）、数据库与缓存服务，以及可选的 外部对象存储。网络分段与端口规划是确保流水线稳定性的基础。
部署模式常见为 单机 Omnibus、多节点 HA、以及云原生组合（Kubernetes/容器化部署）。在设计阶段要明确分工：构建节点、测试节点与部署节点的职责边界，以及要达到的 持续交付域的目标。
2) 在 Linux 上安装 GitLab 与依赖
2.1 部署方式选型：Omnibus、Docker、或源码
Omnibus 安装提供了极简化的集成方案，依赖性自动打包、便于快速上线，适合初学者和中小规模环境；Docker 部署更利于容器化治理、水平扩展和快速回滚，适合微服务化架构；源码安装则在灵活性和定制化方面有优势，但 维护成本较高。
本教程以 Omnibus 安装为主，同时提供 Docker 的关键命令以作参考，帮助读者快速搭建并后续演进。下列命令仅作为示例，请根据实际网络环境和发行版调整。
# Omnibus 安装（Ubuntu/Debian 示例）
sudo apt-get update
sudo apt-get install -y curl ca-certificates openssh-server postfix
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install -y gitlab-ce
sudo gitlab-ctl reconfigure
2.2 安装前的系统准备与依赖
为确保服务稳定，需完成时间同步、时区设置、防火墙策略与 swap 配置等准备工作；时钟准确性对证书校验与任务调度有直接影响。
生产环境通常需要禁用过大或过小的 swap，并确保 持久化日志与数据目录的挂载点稳定，便于后续迁移与备份。
# 设置时区
sudo timedatectl set-timezone Asia/Shanghai
# 同步时间（以 chrony 为例）
sudo apt-get install -y chrony
sudo systemctl enable chrony
sudo systemctl start chrony
# 关闭 swap（生产环境根据内存情况调整）
sudo swapoff -a
sudo sed -i '/\sswap\s/d' /etc/fstab
3) GitLab Runner 的部署与管理
3.1 安装 GitLab Runner
GitLab Runner 提供多种执行器，常用的有 shell、Docker、Kubernetes。在 Linux 上，Docker 执行器与 Shell 执行器的组合最为常见。
安装步骤简洁，完成后即可将 Runner 注册到相应的 GitLab 实例或特定项目中，开始绑定作业执行环境。
# 以 Debian/Ubuntu 为例安装 GitLab Runner
curl -L https://packages.gitlab.com/install/repositories/gitlab/gitlab-runner/script.deb.sh | sudo bash
sudo apt-get install -y gitlab-runner
3.2 注册 Runner 与标签、并发数配置
注册 Runner 需要获得 注册令牌，并为 Runner 指定 描述、标签、执行器与并发数，以实现作业的精准分发与资源控制。
注册完成后，Runner 将出现在对应 GitLab 实例的 Runner 列表中，读写权限及并发策略将直接影响流水线的执行效率与稳定性。
sudo gitlab-runner register
# 交互示例
# GitLab 实例 URL: https://gitlab.example.com/
# Registration token:
# Description: my-runner
# Tags: linux, docker
# Executor: docker
# Docker image: docker:20.10.16-dind
4) .gitlab-ci.yml 的编写与最佳实践
4.1 基础模板：阶段、脚本、缓存与 Artifacts
在仓库根目录创建 .gitlab-ci.yml，通过 stages、jobs、cache、artifacts 等字段实现流水线的结构化定义。
关键概念包括：stages、jobs、artifacts、cache、only/except，以及对并发、超时和环境变量的合理配置。
stages:- build- test- deploybuild_job:stage: buildscript:- echo "Building..."- # 构建步骤tags:- linuxcache:key: ${CI_COMMIT_REF_SLUG}paths:- node_modules/- package-lock.jsontest_job:stage: testscript:- npm ci- npm testartifacts:paths:- coverage/only:- merge_requests
4.2 部署阶段的流水线示例：容器镜像构建与推送
在部署阶段，可以通过 Docker in Docker 或 Buildx 实现镜像构建与多平台推送，并将制品发布到注册表或镜像仓库，确保生产环境的可追溯性。
确保在 Runner 的执行器中具备对目标镜像仓库的写权限，并设置合理的秘密变量以保护凭据。
# 在 .gitlab-ci.yml 中使用 docker-in-docker 的示例
build_image:stage: buildimage: docker:24.0.2services:- docker:dindscript:- docker build -t registry.example.com/project/app:$CI_COMMIT_SHORT_SHA .- docker push registry.example.com/project/app:$CI_COMMIT_SHORT_SHA
5) 持续交付与安全/性能最佳实践
5.1 使用缓存、并行作业与流水线分级
通过作业缓存、依赖缓存与并行执行，可以显著提升流水线速度，降低总体时长；并通过 分支策略 实现不同阶段的安全性与回滚能力。
在设计 pipelines 时，应该明确哪些作业可以并发执行，哪些需要串行依赖，以确保关键路径的稳定性与可回溯性。
# 通过 yaml 逻辑实现并行策略的简化示例
.parallel: 4
stages:- build- test- release
5.2 回滚策略与持续交付中的分支管理
需要为生产交付设计清晰的回滚方案、版本标签与分支保护策略，确保在出现异常时可以快速切换到已验证的稳定版本。
在流水线中可设置 自动回滚条件，比如当部署阶段的健康检查失败时触发回滚流程，以保障生产环境的可用性。
6) 生产环境的部署与监控
6.1 生产网络与安全配置
生产环境需要完善的网络防护与证书配置，建议使用 反向代理（如 Nginx/Traefik）进行 TLS 终端保护，并对 GitLab、Runner、镜像仓库端口进行最小权限访问控制。
推荐设立 HTTPS-only、强制自动更新的证书策略，以及基于角色的访问控制（RBAC）以限制敏感操作。
# 典型的 Nginx TLS 代理示例（简化）
server {listen 80;server_name gitlab.example.com;return 301 https://$host$request_uri;
}
server {listen 443 ssl;server_name gitlab.example.com;ssl_certificate /etc/ssl/certs/gitlab.crt;ssl_certificate_key /etc/ssl/private/gitlab.key;location / {proxy_pass http://127.0.0.1:8080;}
}
6.2 日志与监控
通过集中式日志、指标与告警实现可观测性，推荐结合 Prometheus/Grafana 等工具对 GitLab、Runner 与容器运行时进行监控，并对关键指标设定阈值警报。
在流水线级别，可以使用 GitLab 内置审计日志、以及外部应用日志以实现全链路追踪与合规性审查。
global:scrape_interval: 15s
scrape_configs:- job_name: 'gitlab'static_configs:- targets: ['gitlab.example.com:9090']
