🔎 你可能正面临的痛点

• 手工部署步骤繁琐，一次失误就可能导致线上故障。
• 不同环境的部署方式不统一，缺少可追溯的日志。
• 上线后想回滚，却找不到对应的建立产物或版本标签。
• 团队成员频繁在同一套脚本上“踩坑”，导致效率低下、交付不稳定。

📖 知识点简介

CI/CD可以把代码提交 → 建立 → 测试 → 部署的全过程自动化，让运维从“人肉敲命令”转向“代码运维”。说到关键价值，

• 标准化流程每一次部署都有完整日志。可追溯、可审计，
• 快速回滚建立产物保留标签，一键切换到上一版本。说起来，
• 提高交付频率提交即触发流水线。降低人为延迟，

GitLab CI 与 GitLab 深度集成。只需编写 .gitlab-ci.yml 即可定义整个流水线，Runner 可部署在任意机器上，兼容 Docker、Shell 等执行器。

🔧 主要概念 & 配置整理

. GitLab CI 基础概念

. .gitlab-ci.yml 基本结构示例

stages:
- build
- test
- deploy
# 全局变量
variables:
DOCKER_IMAGE: registry.company.com/myapp
DEPLOY_DIR: /opt/myapp
# -------------------- Build --------------------
build-job:
至于stage，build
再看script，- docker build -t $DOCKER_IMAGE:$CI_COMMIT_SHORT_SHA .
- docker push $DOCKER_IMAGE:$CI_COMMIT_SHORT_SHA
从only来看，- main
# -------------------- Test --------------------
test-job:
再看stage，test
说到script，- docker run --rm $DOCKER_IMAGE:$CI_COMMIT_SHORT_SHA npm test
再看only，- main
# -------------------- Deploy Staging --------------------
deploy-staging:
从stage来看，deploy
说到script，- ansible-playbook -i inventory/staging deploy.yml
environment:
再看name，staging
再看only。- main
# -------------------- Deploy Production --------------------
deploy-production:
说到stage，deploy
script的观点是，- echo "Deploying to production..."
- ansible-playbook -i inventory/production deploy.yml
environment:
至于name，production
再看when，manual # 必须人工确认，防止误触发生产环境
说到only，- main

. 注册 GitLab Runner

# 安装 Runner
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
sudo yum install -y gitlab-runner
# 注册 Runner
sudo gitlab-runner register
#> 输入 GitLab 实例 URL → https://gitlab.company.com
#> 输入 Registration Token → 项目 Settings → CI/CD → Runners 中获取
#> 输入描述 → prod-deploy-runner
#> 输入标签→ prod,docker
#> Choose executor → shell # 简单场景；生产推荐 docker executor
# 验证是否注册成功
sudo gitlab-runner list

. 常用内置变量速查表

# 提交相关信息
$CI_COMMIT_SHORT_SHA # 短哈希，例如 a1b2c3d
$CI_COMMIT_REF_NAME # 分支名。例如 main、feature/xyz
# 流水线/Job 标识符
$CI_PIPELINE_ID # 唯一流水线 ID
$CI_JOB_ID # 当前 Job ID
# 环境信息
$CI_ENVIRONMENT_NAME # 如 staging / production
# Docker 镜像仓库凭证
$CI_REGISTRY_USER # 登录使用者名
$CI_REGISTRY_PASSWORD # 登录密码

🧪 实操示例：Docker 应用“一键建立‑部署”全链路演练

. 场景描述 & 痛点映射

前后端分离项目，每次将代码推送至 Main 分支 后需要：

• 分别为前端 & 后端建立 Docker 镜像并推送至私有仓库。话说回来，
• 在测试服务器上拉取最新镜像并通过 Docker‑Compose 启动。 不过，
• 保留历史镜像标签。以便出现问题时快速回滚，

# .gitlab-ci.yml – Docker 应用自动化流水线
stages这方面，- build # 前后端镜像建立
- test # 单元/集成测试
- deploy-staging # 推送至测试环境
variables:
REGISTRY: registry.company.com # 私有仓库地址
PROJECT: myapp # 项目名称统一前缀
TAG这方面，$CI_COMMIT_SHORT_SHA # 使用短哈希做唯一 tag
说到cache，paths:
- node_modules/ # 前端依赖缓存，加速后续 job
##############################
## Build ##
##############################
build-frontend:
stage的观点是，build
至于script，- cd frontend
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $REGISTRY
- docker build -t $REGISTRY/$PROJECT/frontend:$TAG .
- docker push $REGISTRY/$PROJECT/frontend:$TAG
artifacts:
再看paths，- frontend/dist # 将产出文件传递给后续 job
build-backend:
至于stage，build
至于script，- cd backend
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $REGISTRY
- docker build -t $REGISTRY/$PROJECT/backend:$TAG .
- docker push $REGISTRY/$PROJECT/backend:$TAG
##############################
## Test ##
##############################
test-backend:
stage这方面，test
needs的观点是，# 明确依赖，仅等待 backend 建立完成即可开始测试
script的观点是，- docker run --rm $REGISTRY/$PROJECT/backend:$TAG pytest # 示例：运行 pytest
##############################
## Deploy ##
##############################
deploy-staging:
说到stage，deploy-staging
至于needs，script:
- ssh deploy@staging-server "
docker pull $REGISTRY/$PROJECT/frontend:$TAG && \
docker pull $REGISTRY/$PROJECT/backend:$TAG && \
docker-compose -f /opt/$PROJECT/docker-compose.yml up -d"
environment:
再看name，staging
再看url，https://staging.company.com
only这方面，- main # 限制仅在主分支触发
##############################
## Optional Production ##
##############################
deploy-production:
stage这方面。deploy
至于if，$CI_COMMIT_TAG # 使用 tag 推送到生产，可避免误触发
script的观点是，- echo "Tagging stable image..."
- docker tag $REGISTRY/$PROJECT/backend:$TAG $REGISTRY/$PROJECT/backend:stable
- docker push $REGISTRY/$PROJECT/backend:stable
- ssh deploy@prod-server "
docker pull $REGISTRY/$PROJECT/frontend:$TAG && \
docker pull $REGISTRY/$PROJECT/backend:$TAG && \
# // 若需要回滚，只需 pull stable 标签即可""
environment:
name: production
when的观点是， manual # 这个文件集优，需要写前列正"

. 部署目标服务器准备工作
# 在目标机器上执行以下步骤：
# 创建专用于部署的使用者，并加入 docker 群组
sudo useradd -m deploy
sudo usermod -aG docker deploy
# 安装 Docker 与 Docker‑Compose
curl -fsSL https://get.docker.com | bash
sudo pip install docker-compose
# 为 GitLab Runner 所在机器生成 SSH 密钥对
ssh-keygen –t ed25519 –C "gitlab-ci-deploy"
# 将公钥复制到目标服务器，实现免密登录
ssh-copy-id deploy@staging-server
# 在 GitLab 项目 Settings → CI/CD → Variables 中添加以下变量：
# SSH_PRIVATE_KEY
# CI_REGISTRY_USER
# CI_REGISTRY_PASSWORD

. 本地调试 & CI Lint 验证方式 


# 本地调试：“gitlab-ci-local validate --file .gitlab-ci.yml --debug”

# 在线校验：“/项目 ➜ CI/CD ➜ Editor ➜ CI Lint”.

If lint passes,commit and push to trigger pipeline.


⚠️ 常见坑点 & 注意事项 🚧 

. Runner 安全风险 


SHELL 执行器：S​​hell Runner 在宿主机直接执行脚本，权限极高。生产环境建议使用Docker 执行器或 Kubernetes Executor​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​‌‌‌‌‌‌‌‌‌‌‍‍‍‍‍‌‍‍‍ ‌ ‌  ‌‌‌   ‏‏‏‏‏‏‏‏‏‏‫‎‎‎‎‎ ‎\u200B\u200B\u200B \u200B \u200B \u200B\*\*Docker Executor\*\* 来实现作业隔离。

敏感信息泄露： 切勿把 CI_REGIST ER_PASSWORD 、SSH_PRIVATE_KEY 等硬编码进 .gitlab-ci.yml。务必通过 “Settings → CI/CD → Variables” 并勾选 *Masked* 与 *Protected* 标记。

Runner 权限最小化： 为每类任务创建独立 Runner，并使用标签限定 Job 调度范围。话说回来，例如 “prod‑runner” 专用于生产环境部署。
<\/ul>

. 部署密钥管理错误案例 &正确做法

＃ ❌ 错误写法——直接在脚本里写明文密码
script :
- sshpass ‑p '' ssh user@server ./deploy.sh
＃ ✅ 正确写法——使用 GitLab Variables 注入 SSH 私钥
before_script :
- eval $
- echo "$SSH_PRIVATE_KEY" | tr ‑d '\r' | ssh‑add -
- mkdir ‑p ~/.ssh
- chmod 700 ~/.ssh
script :
- ssh deploy@staging-server 'cd /opt/myapp && ./restart.sh'


. 流水线性能调整技巧 



Cache 缓存依赖 ： 如 npm 、pip 、maven，避免每次 job 都重新下载。

needs 明确依赖 ： 用 needs 控制作业顺序。只等真正需要的前置作业结束，从而缩短整体耗时。

only / except 精细控制 ： 防止每次 push 都跑完整流水线，例如只对特定目录或标签触发。
<\/ ul>


. 回滚策略落地方案 

每一次 CD 成功后把当前镜像同时打上 “stable” 标签；出现故障时只需把 “stable” 拉下来重新部署，就可以秒级回滚。

deploy-production :
script :
- docker tag ${ REGI STRY }/${ PROJECT }:${ TAG } ${ REGI STRY }/${ PROJECT }:stable
- docker push ${ REGI STRY }/${ PROJECT }:stable
- echo "Deploying stable version…"
- ansible‑playbook …<\/ code>

. 环境隔离与审批机制 



Staging vs Production ： 所有变量、Secrets 必须分别定义，防止跨环境污染。

Production 手动确认 ： 使用 when：manual + protected variables + approvers，实现多人审核后方可上线。
<\/ ul>