拓冰网站定制 
先聊点实在的。最近不少朋友在折腾前端项目部署要么手动打包上传服务器要么用各种面板点到手酸一更新就要重复劳动还得记着备份。我之前在本地和云服务器上捣鼓过好几套方案最后稳定用下来的组合是 Docker 1Panel GitLab 社区版代码推到 GitLab服务器上自动拉取、构建、发布到 Nginx全程不用登录服务器敲命令。这套流程对个人开发者、小型团队、外包项目都非常实用尤其适合“前端项目需要频繁迭代、又不想为了部署单独养运维”的场景。这篇教程我尽量把每一步都讲透包括为什么这么配、参数怎么理解、踩了哪些坑争取让你照着做就能复现。如果你手头有一台哪怕配置很一般的 Linux 服务器2核4G就够跑这套基础环境或者想在 Windows 11 上用 Docker Desktop 先练手都可以跟着走一遍。1. 先说清楚这套自动部署的整体思路1.1 为什么选 Docker 1Panel GitLab 这个组合市面上做自动部署的路线很多比如直接用 Jenkins、用 Gitea Drone、或者全家桶 Gitea Woodpecker再简单一点甚至可以写个 git hook 直接拉代码。但 GitLab 社区版在“代码管理 CI/CD 一体”这个维度上依然是目前最均衡的选择尤其是团队协作、Merge Request、权限管理这些能力对前端项目来说体验很完整。Docker解决的是“环境一致性”问题。GitLab 依赖的 PostgreSQL、Redis以及部署前端的 Nginx、构建用的 Node 环境全部容器化不用在宿主机上装一堆东西换服务器也能快速恢复。1Panel解决的是“服务器管理体验”问题。这个国产开源面板在容器管理、文件管理、防火墙、域名解析、反向代理这些日常操作上做得足够顺手比纯命令行对新手友好得多。1Panel 还能直接管理 Docker 容器、查看日志、设置端口映射省去了手动敲 docker ps、docker logs 的麻烦。GitLab解决的是“代码托管 自动化执行”问题。社区版虽然砍掉了一些 CI 分钟数和高级功能但本地 Docker 部署下GitLab Runner 完全可以自己跑起来.gitlab-ci.yml 一写push 即触发。一句话总结这套架构GitLab 管代码和触发条件Runner 管构建执行Nginx 管静态资源发布1Panel 负责让这些容器都跑得明明白白。1.2 一次 push 触发的前端自动部署链路在细讲配置之前先用最简单的话描述目标状态本地前端项目通过git push origin master推送到 GitLab。GitLab 检测到代码变更触发注册好的 Runner。Runner 在容器里执行构建脚本安装依赖、打包。构建产物自动发布到服务器上的 Nginx 静态目录。浏览器直接访问域名或 IP看到的就是最新版本。这个链路里最关键的两个环节触发条件怎么配构建产物怎么落到 Nginx 目录。前者靠 GitLab CI/CD 的 pipeline 机制后者靠 Runner 执行 shell 脚本或 docker 命令。后面我会把每一步都展开。2. 环境准备从零到 Docker 跑起来2.1 服务器选型和系统要求先别急着装东西服务器得满足两个基本条件能联网至少能访问外网拉取镜像内存别太小。GitLab 社区版是出了名的吃内存官方建议是 4GB RAM 起步。实际使用中2GB 内存跑 GitLab 会非常紧张经常出现 502建议至少 4GB。我自己测过2核4G的云服务器跑 GitLab Runner Nginx 1Panel内存剩余大概在 800MB 到 1.2GB 之间波动勉强够用但不宽裕。如果你只是自己玩可以先用 Docker Desktop 在 Windows 11 上模拟后面我会提到。系统方面Ubuntu 22.04/24.04、Debian 11/12、CentOS 7/8 都可以。GitLab 官方对 Ubuntu 24.04 支持得最好但 1Panel 本身对主流发行版兼容都很好所以不用太纠结。如果是 CentOS注意 gitlab-ce 的 Docker 镜像对 glibc 版本的要求老版本 CentOS 7 有可能会出现奇怪的问题建议直接用 Docker 镜像绕开这个坑。2.2 Windows 11 上装 Docker Desktop 的坑如果你没有现成的 Linux 服务器想先在 Windows 11 上把整套流程跑通那 Docker Desktop 是必经之路。但 Docker Desktop 在 Windows 上有个著名的老毛病Virtualization support not detectedDocker Desktop failed to start because virtualization support is disabled。这个报错核心原因是 Windows 的虚拟化功能没开启或者与 Hyper-V 冲突。解决办法按顺序试进入 BIOS/UEFI开启Intel VT-x 或 AMD SVM不同主板叫法不一样这个是硬件层面的虚拟化。Windows 功能里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”然后重启。如果开了 Hyper-V 还是不行可能是和 VMware/VirtualBox 冲突把第三方虚拟机软件关掉再试。还有一个小坑Docker Desktop 在 Windows 下默认通过 WSL2 运行如果 WSL2 内核版本过老也会启动失败。可以执行wsl --update更新内核。启动成功后记得在 Docker Desktop 的 Settings 里把资源调高一些否则后面跑 GitLab 容器很容易内存不足直接被杀。2.3 1Panel 安装与 Docker 环境确认1Panel 的安装脚本官方文档写得很清楚核心就一句命令。装完面板后它会默认监听一个随机端口通过浏览器访问https://服务器IP:端口进入管理界面。首次登录需要设置用户名和密码。这里有个细节1Panel 安装的时候会检查系统里是否已经有 Docker。如果没有它会自动帮你装如果已有它会直接接管。所以顺序可以是“先装 Docker再装 1Panel”也可以是“直接装 1Panel 让它帮你装 Docker”两种都行。推荐后者省事。1Panel 装完以后建议先去“面板设置”里把备份、快照功能看一眼后续操作出了问题能快速回滚。这个习惯很重要尤其是你后面要频繁改 Nginx 配置、调容器参数的时候一份快照能省掉很多重装的痛苦。3. GitLab 社区版在 Docker 里的落地部署3.1 用 docker run 还是 docker-composeGitLab 社区版直接用docker run也能跑但参数特别多后期想改配置还得重新起容器容易丢参数。我强烈建议用docker-compose来编排尤其是 1Panel 里也能识别 docker-compose 项目管理起来更直观。我用的 compose 配置删减掉注释的核心版本version: 3 services: gitlab: image: gitlab/gitlab-ce:latest container_name: gitlab restart: always hostname: gitlab.example.com environment: GITLAB_OMNIBUS_CONFIG: | external_url http://gitlab.example.com gitlab_rails[gitlab_shell_ssh_port] 2222 unicorn[worker_processes] 2 nginx[enable] true postgresql[shared_buffers] 256MB ports: - 80:80 - 2222:22 - 443:443 volumes: - /opt/gitlab/config:/etc/gitlab - /opt/gitlab/logs:/var/log/gitlab - /opt/gitlab/data:/var/opt/gitlab shm_size: 256m3.2 关键参数逐个说清楚很多教程直接甩一段配置不讲为什么出了问题完全不知道怎么改。这里把几个最重要的参数讲透external_url这个必须和你访问 GitLab 的地址一致。如果是 IP 访问就写http://服务器IP如果有域名就写http://gitlab.你的域名.com。这个 URL 会被写入 GitLab 配置影响后续克隆仓库时显示的地址。如果这里写错网页上复制的克隆地址就会带着错误 URL。ssh_port 映射宿主机把 2222 端口映射到容器内的 22 端口是为了避免和宿主机自身的 SSH 冲突。如果你服务器上没别的 SSH 服务也可以直接把宿主机的 22 映射给 GitLab这样克隆地址就不用带端口号。但多数人和服务器连接用的就是 22 端口所以映射到 2222 是更稳妥的做法。注意需要在GITLAB_OMNIBUS_CONFIG里把 SSH 端口也改成 2222让 GitLab 在克隆地址里自动带上这个端口。shm_size容器默认的 /dev/shm 只有 64MBGitLab 在编译资源、跑测试的时候很容易撑爆表现就是莫名 502。设置成 256M 基本够用。volumes 映射GitLab 的配置、日志、数据分三个目录挂载到宿主机上这样升级容器、迁移数据都不丢。启动命令docker compose up -d第一次拉镜像比较慢gitlab/gitlab-ce 镜像本身就接近 1.5GB等就是了。容器起来后GitLab 内部还要初始化配置、启动 PostgreSQL 和 Redis这个过程快的 2 分钟慢的可能要 5-8 分钟。别急着访问可以通过日志判断docker logs -f gitlab看到类似gitlab Reconfigured!或者nginx started之类的输出再开浏览器访问。3.3 首次登录与 root 密码GitLab 首次访问会让你设置 root 用户的密码。如果页面没跳出来或者你错过了初始密码设置可以用下面的命令直接重置docker exec -it gitlab gitlab-rake gitlab:password:reset按提示操作选择 root 用户输入新密码。之后用 root 登录建议立刻进 Admin Area 创建独立的项目管理员账号别直接用 root 做日常操作。root 权限太大万一密钥泄露整个项目代码都会被拿走。登录进去第一件事去 Admin Area - Settings - Visibility and access control把Sign-up enabled关闭。否则你的 GitLab 要是暴露在公网上任何人都能注册账号往里推代码。3.4 GitLab 内存优化小内存服务器的自救如果你的服务器是 2G 内存GitLab 默认配置很容易 OOM。可以针对性地调低几个关键组件的内存占用GITLAB_OMNIBUS_CONFIG: | unicorn[worker_processes] 2 sidekiq[max_concurrency] 5 postgresql[shared_buffers] 128MB prometheus_monitoring[enable] falsePrometheus 监控在社区版里也会常驻内存关掉能省出不少。这样设置之后GitLab 的内存占用大概能控制在 1.5GB 左右再配合 2GB swap基本能稳定跑。4. 前端项目导入与代码管理4.1 创建空项目把前端代码推上去GitLab 的“新建项目”流程很直观登录后点 New Project选 Create blank project填项目名比如frontend-xxx可见性选 Private私有还是 Internal内部可见取决于你的需求。前端项目一般有大量 node_modules、dist 等不需要纳入版本库的内容在创建项目后先在本地初始化好.gitignore把node_modules、dist、.env这些目录和文件都加进去再推代码。否则node_modules一旦被 push 上去仓库体积瞬间爆炸后患无穷。推送命令git init git remote add origin http://你的GitLab地址/root/frontend-xxx.git git add . git commit -m first commit git push -u origin master如果你是本地 IDE比如 IDEA里已经有一套项目想直接推到 GitLab先git add remote指向 GitLab 地址再 push 就行不需要重新建一遍项目结构。4.2 SSH 密钥配置clone 和 push 不走密码用 HTTPS 克隆每次都要输密码很烦而且 GitLab 上某些 CI 操作不认输入的密码票据。推荐配置 SSH 密钥一劳永逸。在本地终端生成密钥ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车即可生成的公钥在~/.ssh/id_rsa.pub。然后到 GitLab 的 User Settings - SSH Keys 里把公钥内容整个粘贴进去。克隆地址就改用 SSH 格式git clone git你的GitLab地址:root/frontend-xxx.git如果你是前面映射的 2222 端口地址会自动带上-p 2222格式实际执行是git clone ssh://git你的GitLab地址:2222/root/frontend-xxx.git4.3 前端项目建议的 Git 管理分支策略一个人开发可能无所谓但既然上了 GitLab建议从一开始就建立基本的分支习惯master/main生产分支只允许通过 Merge Request 合入。dev开发分支日常提交都往这里推。功能分支feat/xxx每个功能一个分支。在 GitLab 的 Project Settings - Repository - Protected Branches 里把 master 设置成“仅允许 Maintainer 角色 push其他人必须走 Merge Request”。这对团队协作来说是一个非常好的保护机制避免有人直接把半成品推到主分支上。5. 自动部署的核心GitLab CI/CD 配置实战5.1 Runner 部署让 GitLab 有个“能干活的人”GitLab 本身只是“发布任务”真正执行构建的是 GitLab Runner。Runner 可以装在 GitLab 同一台服务器上也可以单独一台机器这里为了简化直接放在同一台服务器上。安装 Runner 时有个选择用 Docker 方式还是直接二进制安装。我更推荐 Docker 方式这样跑 CI 的时候每个 job 都在独立容器里干净无污染。执行注册命令docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register注册过程中需要填 GitLab 地址和注册 TokenToken 在 GitLab 的 Admin Area - CI/CD - Runners 里可以看到。注册时有个关键参数executor 选择 docker然后填默认镜像比如node:18-alpine。这样前端构建 job 就可以直接使用 Node 环境。如果 Runner 跑起来后GitLab 页面里 Runners 列表还是显示“online”说明注册成功。这是最容易被忽略的一步——很多人注册完发现 Runner never contacted site多半是 GitLab 地址填错了或者端口不通。5.2 .gitlab-ci.yml 完整配置说明前端项目根目录下新建.gitlab-ci.yml这个文件就是 GitLab 的流水线说明书。我贴一份经过实际使用的 Vue 项目配置稍作简化stages: - build - deploy cache: key: ${CI_COMMIT_REF_NAME} paths: - node_modules/ before_script: - node -v - npm -v build: stage: build image: node:18-alpine script: - npm install --registryhttps://registry.npmmirror.com - npm run build artifacts: paths: - dist/ expire_in: 1 hour only: - master deploy: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client script: - scp -r dist/* root你的服务器IP:/opt/nginx/www/yourproject/ only: - master对这段配置做几点说明stages 顺序先 build 再 deploy两个 stage 不能调换否则构建产物还没生成就去部署必然失败。cache 配置npm 安装依赖耗时很长配置了 cache 之后同一分支的后续 pipeline 可以复用node_modules速度会快很多。但要小心如果依赖版本变动频繁cache 偶尔会带来“幽灵依赖”这时候需要手动清除 cache。before_script每个 job 执行前都会跑的初始化命令可以用来统一检查 Node 版本。artifactsbuild job 里把dist/目录打包成临时产物传递给 deploy job。这里设置expire_in: 1 hour是因为默认保留时间是 30 天没必要占用那么多 GitLab 存储空间。deploy 里的 scp这里用的是最直接的方案——构建完直接传到 Nginx 目录。更优雅的方案后面我会讲。5.3 部署的三种常见实现方式方式一scp/rsync 直接传文件适合小项目上面的示例就是这种方式。优点是简单不依赖额外组件缺点是权限比较大需要把服务器 SSH 密钥放到 CI 环境变量里。部署目标目录必须提前创建好mkdir -p /opt/nginx/www/yourproject chown -R 你的用户:你的用户 /opt/nginx/www/yourproject方式二GitLab Runner 直接调用宿主机脚本适合和服务器紧密集成在 Runner 的机器上写一个部署脚本/opt/scripts/deploy.sh内容就是把构建产物拷贝到 Nginx 目录、重新加载配置。CI 里通过ssh userhost bash /opt/scripts/deploy.sh触发。好处是脚本在服务器上改部署逻辑不需要提交代码。方式三docker-compose 重建前端容器如果前端项目是跑在容器里的可以构建镜像后通过 docker-compose 更新容器。这种方式适合前端需要服务端渲染SSR或者后端 API 一起部署的场景。但纯前端静态站直接 Nginx 托管静态文件就够了没必要多套一层容器。5.4 环境变量与安全说明.gitlab-ci.yml是明文提交到仓库里的所以任何敏感信息都绝对不能直接写在配置里。SSH 私钥、服务器密码、密钥等都要放到 GitLab 项目的 Settings - CI/CD - Variables 里传值用$变量名引用。例如script: - echo $DEPLOY_SSH_PRIVATE_KEY /tmp/deploy_key - chmod 600 /tmp/deploy_key - scp -i /tmp/deploy_key -r dist/* 服务器用户服务器IP:/opt/nginx/www/yourproject/变量在 GitLab 后台配置时可以选择Protected只有受保护分支能用和Masked日志里自动打码这两个选项强烈建议都勾上。5.5 触发方式自动触发和手动触发起推送 master 分支会自动触发 pipeline这是默认行为。你还可以在 GitLab 页面的 CI/CD - Pipelines 里手动点击 Run pipeline 重新触发一次方便修复失败任务。这个“手动重跑”操作在日常开发中很常用比如这次构建失败只是网络抖动、依赖没装全不需要 commit 一个空操作去重新触发直接在页面上点一下 Run pipeline 就行。6. Nginx 配置与静态资源发布6.1 Nginx 静态站配置模板前端构建产物是纯静态文件部署到 Nginx 的/opt/nginx/www/yourproject目录后需要在 1Panel 里新建站点或者直接修改 Nginx 配置。1Panel 的文件管理直接编辑/opt/nginx/conf/nginx.conf也可以在网站菜单里创建网站并指定静态目录。我贴一份标准静态站配置server { listen 80; server_name yourdomain.com; root /opt/nginx/www/yourproject; index index.html; location / { try_files $uri $uri/ /index.html; } }try_files那行是单页应用SPA的核心——前端路由是 history 模式时刷新某个子页面 NGINX 找不到对应路径就会返回 index.html 让前端自己去路由解析。6.2 端口与域名访问如果暂时没有域名直接用服务器 IP 访问也是可以的只要把server_name改成 IP 即可。但生产环境建议上域名原因很简单HTTPS。GitLab 本身也建议用域名 HTTPS否则登录密码等都是明文传输。1Panel 的“网站”功能里可以一键申请 Lets Encrypt 证书并配置 HTTPS省去不少手动操作的时间。6.3 定时清理构建产物前端项目迭代快dist/目录下会有大量带 hash 的文件。发布新版本后过期文件的清理如果不做目录大小会慢慢膨胀。可以在 CI 里加一步发布完成后删除旧版本的缓存目录比如只保留最新两份构建after_script: - ls -t /opt/nginx/www/yourproject/releases | tail -n 3 | xargs rm -rf这段脚本的意思是列出按时间排序的构建目录从第三个开始全部删掉。配合 Nginx 软链指向最新的 release 目录可以实现零停机发布。7. 常见问题与排查技巧7.1 Docker Desktop 启动失败排查清单前面提到的 Virtualization support not detected 是最典型的问题。除此之外还有几个高发情况failed to connect to the docker api at npipe这个报错出现在 Windows 上通常是 Docker Desktop 的引擎没起来或者 WSL2 后端崩了。试试右下角托盘图标右键 Restart或者在 PowerShell 里执行wsl --shutdown然后重新启动 Docker Desktop。Linux 服务器上 Docker 启动失败先systemctl status docker看错误日志一个常见原因是 cgroup 版本不对需要加GRUB_CMDLINE_LINUXsystemd.unified_cgroup_hierarchy0CentOS 7 这类老系统会遇到。Ubuntu 22.04 以上用 cgroup v2 问题不大但如果装了老版本的 Docker也可能会出问题直接升级 Docker 就行。7.2 GitLab 容器起不来或频繁 502这个问题的排查思路要按层来下面这个表格是排查顺序现象可能原因排查命令 / 操作容器反复重启内存不足被杀docker stats gitlab看内存占用调小组件配置或加 swap502 Bad GatewayGitLab 内部组件还没完全启动docker logs -f gitlab等它初始化完成有时需要 5-10 分钟502 且日志报puma failed to start80 端口被宿主机别的服务占用ss -tlnpGitLab 页面能打开但仓库 500 错误PostgreSQL 数据损坏或磁盘满df -h检查磁盘docker logs gitlab容器起不来提示mkdir permission denied挂载目录权限不对chown -R 998:998 /opt/gitlab无法从网页 clone 仓库external_url 配错了检查external_url是否包含端口、域名是否和实际一致GitLab 容器内部有个调试命令非常好用docker exec -it gitlab gitlab-rake gitlab:check它会自动检查所有组件状态报错信息基本都能直接定位问题。7.3 Docker 网络不通的问题1Panel 创建的网桥和 docker run 默认的网桥是两个不同的网段跨容器通信时容易出现互相访问不到的情况。比如前端容器要调接口容器的 IP如果它们不在同一个网络里会直接 connect refused。解决方法是把相关容器都加入同一个自定义网络docker network create mynetwork docker network connect mynetwork gitlab docker network connect mynetwork frontend或者在 1Panel 的容器编辑页面直接调整网络配置。1Panel 本身对这块封装得简单但网络层级的概念还是建议了解一下排错的时候能少绕很多弯。7.4 SSH 连接失败无法 clone 或 push最常见的原因是 GitLab 的 SSH 端口映射了 2222但克隆地址还用了默认 22。在 GitLab 项目页面上点 Clone下拉框选 SSH看地址里有没有带上 2222 端口。没有的话手动改成git clone ssh://git你的IP:2222/root/frontend-xxx.git还有一个坑本地 SSH 客户端默认尝试多个密钥文件但 GitLab 上只添加了一个公钥。如果之前用过其他服务器的密钥SSH agent 可能会优先给 GitLab 发错密钥服务器直接拒绝。排查方法ssh -T -p 2222 git你的IP -v输出里能看到用的是哪个 key 文件找到问题后指定密钥连接或者编辑~/.ssh/config单独为 GitLab 配一条规则。7.5 GitLab 高危漏洞修复GitLab 官方经常发布安全更新社区版如果没有及时更新容易暴露已知漏洞。这个没什么黑魔法核心策略就是保持镜像版本最新。具体操作拉取最新镜像重建容器。但重建前务必备份/opt/gitlab/config、/opt/gitlab/logs、/opt/gitlab/data这三个目录或者用 1Panel 的快照功能做好备份。升级命令docker compose pull gitlab docker compose up -d --force-recreate gitlab升级后也会有一个重新配置的过程耐心等日志输出。另外定期关注 GitLab 官方 release notes高危漏洞公告出来后尽早升级不要拖。7.6 CI 任务执行失败login failed 与 Runner 失联CI 报login failed. check api token or gitlab version多半是你用了自定义 Runner 的注册 Token 不对或者 GitLab 版本和 Runner 版本不兼容。Runner 的版本不要用 latest 一拉了之最好和 GitLab 版本匹配一个大版本线。检查方法docker exec -it gitlab-runner gitlab-runner -v docker exec -it gitlab gitlab-rake gitlab:env:info如果 Runner 显示 not connected重启一下 Runner 容器确认注册信息没被清掉还是不行就重新注册一次。7.7 前端依赖安装太慢或者失败CI 里构建前端npm install 速度极大影响整体耗时。国内服务器直连 npm 官方源非常慢在.gitlab-ci.yml里加参数npm install --registryhttps://registry.npmmirror.com如果你用 pnpm配置pnpm config set registry https://registry.npmmirror.com另一个技巧是缓存~/.npm目录GitLab 的cache可以配合paths指定这样后续任务能复用下载过的依赖包显著提速。8. 进阶扩展方向这套流程跑顺之后还可以在现有基础上升级加 Webhook 对接其他系统GitLab 项目设置里可以配置 Webhook比如推代码后自动通知企微/钉钉或触发远程构建。1Panel 的“应用”里也有不少集成可以自己研究一下。多环境多分支push dev 分支时构建到测试服务器push master 时发布到生产服务器。在.gitlab-ci.yml里用$CI_COMMIT_BRANCH变量判断两套部署动作轻松区分。Docker 化前端部署写一个 Nginx 静态文件的 Dockerfile把构建产物打进镜像推到 GitLab Container Registry再在服务器上拉镜像跑容器。这样前端应用也能享受镜像版本管理的优势。集成自动化测试前端 lint、单元测试可以放在 build 之前测试不过直接 fail pipeline。这对多人团队尤其重要能挡住很多低级错误。最后分享几个实操心得整套流程我实测跑了大半年最深的体验是自动部署的核心不是“自动”两个字而是“可重复”和“可回滚”。只要每次发布都是从同一个流程走出来的问题就很好排查出了问题把上一个镜像或上一份 dist 恢复回去就行这比手动操作稳定太多了。几个小细节再说一下GitLab 的docker-compose.yml里的restart: always建议一定要加服务器重启后容器能自动恢复不用你惦记着手动拉起。构建前端项目时内存小的服务器上npm run build偶尔会 OOM可以在构建 job 里限制 Node 的内存NODE_OPTIONS--max-old-space-size1024。1Panel 自带的备份功能强烈建议用起来尤其是 GitLab 的 config 目录的备份里面包含仓库访问密钥、数据库密码等关键信息。恢复的时候把备份文件放回/opt/gitlab/config再启动容器GitLab 基本能原地满血复活。CI 变量的作用域记得确认好是只在某个项目生效、还是要多个项目共用。如果多个项目用同一套部署逻辑可以把变量配在 Admin Area 的 CI/CD Variables 里这样一次配置全局复用不用每个项目都复制一遍。我写这篇教程的时候尽量把“为什么这么做”也讲清楚了因为配置这东西死记硬背只能解决眼前的问题理解了原理遇到新情况才知道怎么应变。希望你这套流程搭起来之后以后每次 push 完代码喝口水的功夫新版本就已经上线了。 Docker+1Panel+GitLab 搭建前端自动化部署流程
先聊点实在的。最近不少朋友在折腾前端项目部署要么手动打包上传服务器要么用各种面板点到手酸一更新就要重复劳动还得记着备份。我之前在本地和云服务器上捣鼓过好几套方案最后稳定用下来的组合是 Docker 1Panel GitLab 社区版代码推到 GitLab服务器上自动拉取、构建、发布到 Nginx全程不用登录服务器敲命令。这套流程对个人开发者、小型团队、外包项目都非常实用尤其适合“前端项目需要频繁迭代、又不想为了部署单独养运维”的场景。这篇教程我尽量把每一步都讲透包括为什么这么配、参数怎么理解、踩了哪些坑争取让你照着做就能复现。如果你手头有一台哪怕配置很一般的 Linux 服务器2核4G就够跑这套基础环境或者想在 Windows 11 上用 Docker Desktop 先练手都可以跟着走一遍。1. 先说清楚这套自动部署的整体思路1.1 为什么选 Docker 1Panel GitLab 这个组合市面上做自动部署的路线很多比如直接用 Jenkins、用 Gitea Drone、或者全家桶 Gitea Woodpecker再简单一点甚至可以写个 git hook 直接拉代码。但 GitLab 社区版在“代码管理 CI/CD 一体”这个维度上依然是目前最均衡的选择尤其是团队协作、Merge Request、权限管理这些能力对前端项目来说体验很完整。Docker解决的是“环境一致性”问题。GitLab 依赖的 PostgreSQL、Redis以及部署前端的 Nginx、构建用的 Node 环境全部容器化不用在宿主机上装一堆东西换服务器也能快速恢复。1Panel解决的是“服务器管理体验”问题。这个国产开源面板在容器管理、文件管理、防火墙、域名解析、反向代理这些日常操作上做得足够顺手比纯命令行对新手友好得多。1Panel 还能直接管理 Docker 容器、查看日志、设置端口映射省去了手动敲 docker ps、docker logs 的麻烦。GitLab解决的是“代码托管 自动化执行”问题。社区版虽然砍掉了一些 CI 分钟数和高级功能但本地 Docker 部署下GitLab Runner 完全可以自己跑起来.gitlab-ci.yml 一写push 即触发。一句话总结这套架构GitLab 管代码和触发条件Runner 管构建执行Nginx 管静态资源发布1Panel 负责让这些容器都跑得明明白白。1.2 一次 push 触发的前端自动部署链路在细讲配置之前先用最简单的话描述目标状态本地前端项目通过git push origin master推送到 GitLab。GitLab 检测到代码变更触发注册好的 Runner。Runner 在容器里执行构建脚本安装依赖、打包。构建产物自动发布到服务器上的 Nginx 静态目录。浏览器直接访问域名或 IP看到的就是最新版本。这个链路里最关键的两个环节触发条件怎么配构建产物怎么落到 Nginx 目录。前者靠 GitLab CI/CD 的 pipeline 机制后者靠 Runner 执行 shell 脚本或 docker 命令。后面我会把每一步都展开。2. 环境准备从零到 Docker 跑起来2.1 服务器选型和系统要求先别急着装东西服务器得满足两个基本条件能联网至少能访问外网拉取镜像内存别太小。GitLab 社区版是出了名的吃内存官方建议是 4GB RAM 起步。实际使用中2GB 内存跑 GitLab 会非常紧张经常出现 502建议至少 4GB。我自己测过2核4G的云服务器跑 GitLab Runner Nginx 1Panel内存剩余大概在 800MB 到 1.2GB 之间波动勉强够用但不宽裕。如果你只是自己玩可以先用 Docker Desktop 在 Windows 11 上模拟后面我会提到。系统方面Ubuntu 22.04/24.04、Debian 11/12、CentOS 7/8 都可以。GitLab 官方对 Ubuntu 24.04 支持得最好但 1Panel 本身对主流发行版兼容都很好所以不用太纠结。如果是 CentOS注意 gitlab-ce 的 Docker 镜像对 glibc 版本的要求老版本 CentOS 7 有可能会出现奇怪的问题建议直接用 Docker 镜像绕开这个坑。2.2 Windows 11 上装 Docker Desktop 的坑如果你没有现成的 Linux 服务器想先在 Windows 11 上把整套流程跑通那 Docker Desktop 是必经之路。但 Docker Desktop 在 Windows 上有个著名的老毛病Virtualization support not detectedDocker Desktop failed to start because virtualization support is disabled。这个报错核心原因是 Windows 的虚拟化功能没开启或者与 Hyper-V 冲突。解决办法按顺序试进入 BIOS/UEFI开启Intel VT-x 或 AMD SVM不同主板叫法不一样这个是硬件层面的虚拟化。Windows 功能里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”然后重启。如果开了 Hyper-V 还是不行可能是和 VMware/VirtualBox 冲突把第三方虚拟机软件关掉再试。还有一个小坑Docker Desktop 在 Windows 下默认通过 WSL2 运行如果 WSL2 内核版本过老也会启动失败。可以执行wsl --update更新内核。启动成功后记得在 Docker Desktop 的 Settings 里把资源调高一些否则后面跑 GitLab 容器很容易内存不足直接被杀。2.3 1Panel 安装与 Docker 环境确认1Panel 的安装脚本官方文档写得很清楚核心就一句命令。装完面板后它会默认监听一个随机端口通过浏览器访问https://服务器IP:端口进入管理界面。首次登录需要设置用户名和密码。这里有个细节1Panel 安装的时候会检查系统里是否已经有 Docker。如果没有它会自动帮你装如果已有它会直接接管。所以顺序可以是“先装 Docker再装 1Panel”也可以是“直接装 1Panel 让它帮你装 Docker”两种都行。推荐后者省事。1Panel 装完以后建议先去“面板设置”里把备份、快照功能看一眼后续操作出了问题能快速回滚。这个习惯很重要尤其是你后面要频繁改 Nginx 配置、调容器参数的时候一份快照能省掉很多重装的痛苦。3. GitLab 社区版在 Docker 里的落地部署3.1 用 docker run 还是 docker-composeGitLab 社区版直接用docker run也能跑但参数特别多后期想改配置还得重新起容器容易丢参数。我强烈建议用docker-compose来编排尤其是 1Panel 里也能识别 docker-compose 项目管理起来更直观。我用的 compose 配置删减掉注释的核心版本version: 3 services: gitlab: image: gitlab/gitlab-ce:latest container_name: gitlab restart: always hostname: gitlab.example.com environment: GITLAB_OMNIBUS_CONFIG: | external_url http://gitlab.example.com gitlab_rails[gitlab_shell_ssh_port] 2222 unicorn[worker_processes] 2 nginx[enable] true postgresql[shared_buffers] 256MB ports: - 80:80 - 2222:22 - 443:443 volumes: - /opt/gitlab/config:/etc/gitlab - /opt/gitlab/logs:/var/log/gitlab - /opt/gitlab/data:/var/opt/gitlab shm_size: 256m3.2 关键参数逐个说清楚很多教程直接甩一段配置不讲为什么出了问题完全不知道怎么改。这里把几个最重要的参数讲透external_url这个必须和你访问 GitLab 的地址一致。如果是 IP 访问就写http://服务器IP如果有域名就写http://gitlab.你的域名.com。这个 URL 会被写入 GitLab 配置影响后续克隆仓库时显示的地址。如果这里写错网页上复制的克隆地址就会带着错误 URL。ssh_port 映射宿主机把 2222 端口映射到容器内的 22 端口是为了避免和宿主机自身的 SSH 冲突。如果你服务器上没别的 SSH 服务也可以直接把宿主机的 22 映射给 GitLab这样克隆地址就不用带端口号。但多数人和服务器连接用的就是 22 端口所以映射到 2222 是更稳妥的做法。注意需要在GITLAB_OMNIBUS_CONFIG里把 SSH 端口也改成 2222让 GitLab 在克隆地址里自动带上这个端口。shm_size容器默认的 /dev/shm 只有 64MBGitLab 在编译资源、跑测试的时候很容易撑爆表现就是莫名 502。设置成 256M 基本够用。volumes 映射GitLab 的配置、日志、数据分三个目录挂载到宿主机上这样升级容器、迁移数据都不丢。启动命令docker compose up -d第一次拉镜像比较慢gitlab/gitlab-ce 镜像本身就接近 1.5GB等就是了。容器起来后GitLab 内部还要初始化配置、启动 PostgreSQL 和 Redis这个过程快的 2 分钟慢的可能要 5-8 分钟。别急着访问可以通过日志判断docker logs -f gitlab看到类似gitlab Reconfigured!或者nginx started之类的输出再开浏览器访问。3.3 首次登录与 root 密码GitLab 首次访问会让你设置 root 用户的密码。如果页面没跳出来或者你错过了初始密码设置可以用下面的命令直接重置docker exec -it gitlab gitlab-rake gitlab:password:reset按提示操作选择 root 用户输入新密码。之后用 root 登录建议立刻进 Admin Area 创建独立的项目管理员账号别直接用 root 做日常操作。root 权限太大万一密钥泄露整个项目代码都会被拿走。登录进去第一件事去 Admin Area - Settings - Visibility and access control把Sign-up enabled关闭。否则你的 GitLab 要是暴露在公网上任何人都能注册账号往里推代码。3.4 GitLab 内存优化小内存服务器的自救如果你的服务器是 2G 内存GitLab 默认配置很容易 OOM。可以针对性地调低几个关键组件的内存占用GITLAB_OMNIBUS_CONFIG: | unicorn[worker_processes] 2 sidekiq[max_concurrency] 5 postgresql[shared_buffers] 128MB prometheus_monitoring[enable] falsePrometheus 监控在社区版里也会常驻内存关掉能省出不少。这样设置之后GitLab 的内存占用大概能控制在 1.5GB 左右再配合 2GB swap基本能稳定跑。4. 前端项目导入与代码管理4.1 创建空项目把前端代码推上去GitLab 的“新建项目”流程很直观登录后点 New Project选 Create blank project填项目名比如frontend-xxx可见性选 Private私有还是 Internal内部可见取决于你的需求。前端项目一般有大量 node_modules、dist 等不需要纳入版本库的内容在创建项目后先在本地初始化好.gitignore把node_modules、dist、.env这些目录和文件都加进去再推代码。否则node_modules一旦被 push 上去仓库体积瞬间爆炸后患无穷。推送命令git init git remote add origin http://你的GitLab地址/root/frontend-xxx.git git add . git commit -m first commit git push -u origin master如果你是本地 IDE比如 IDEA里已经有一套项目想直接推到 GitLab先git add remote指向 GitLab 地址再 push 就行不需要重新建一遍项目结构。4.2 SSH 密钥配置clone 和 push 不走密码用 HTTPS 克隆每次都要输密码很烦而且 GitLab 上某些 CI 操作不认输入的密码票据。推荐配置 SSH 密钥一劳永逸。在本地终端生成密钥ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车即可生成的公钥在~/.ssh/id_rsa.pub。然后到 GitLab 的 User Settings - SSH Keys 里把公钥内容整个粘贴进去。克隆地址就改用 SSH 格式git clone git你的GitLab地址:root/frontend-xxx.git如果你是前面映射的 2222 端口地址会自动带上-p 2222格式实际执行是git clone ssh://git你的GitLab地址:2222/root/frontend-xxx.git4.3 前端项目建议的 Git 管理分支策略一个人开发可能无所谓但既然上了 GitLab建议从一开始就建立基本的分支习惯master/main生产分支只允许通过 Merge Request 合入。dev开发分支日常提交都往这里推。功能分支feat/xxx每个功能一个分支。在 GitLab 的 Project Settings - Repository - Protected Branches 里把 master 设置成“仅允许 Maintainer 角色 push其他人必须走 Merge Request”。这对团队协作来说是一个非常好的保护机制避免有人直接把半成品推到主分支上。5. 自动部署的核心GitLab CI/CD 配置实战5.1 Runner 部署让 GitLab 有个“能干活的人”GitLab 本身只是“发布任务”真正执行构建的是 GitLab Runner。Runner 可以装在 GitLab 同一台服务器上也可以单独一台机器这里为了简化直接放在同一台服务器上。安装 Runner 时有个选择用 Docker 方式还是直接二进制安装。我更推荐 Docker 方式这样跑 CI 的时候每个 job 都在独立容器里干净无污染。执行注册命令docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register注册过程中需要填 GitLab 地址和注册 TokenToken 在 GitLab 的 Admin Area - CI/CD - Runners 里可以看到。注册时有个关键参数executor 选择 docker然后填默认镜像比如node:18-alpine。这样前端构建 job 就可以直接使用 Node 环境。如果 Runner 跑起来后GitLab 页面里 Runners 列表还是显示“online”说明注册成功。这是最容易被忽略的一步——很多人注册完发现 Runner never contacted site多半是 GitLab 地址填错了或者端口不通。5.2 .gitlab-ci.yml 完整配置说明前端项目根目录下新建.gitlab-ci.yml这个文件就是 GitLab 的流水线说明书。我贴一份经过实际使用的 Vue 项目配置稍作简化stages: - build - deploy cache: key: ${CI_COMMIT_REF_NAME} paths: - node_modules/ before_script: - node -v - npm -v build: stage: build image: node:18-alpine script: - npm install --registryhttps://registry.npmmirror.com - npm run build artifacts: paths: - dist/ expire_in: 1 hour only: - master deploy: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client script: - scp -r dist/* root你的服务器IP:/opt/nginx/www/yourproject/ only: - master对这段配置做几点说明stages 顺序先 build 再 deploy两个 stage 不能调换否则构建产物还没生成就去部署必然失败。cache 配置npm 安装依赖耗时很长配置了 cache 之后同一分支的后续 pipeline 可以复用node_modules速度会快很多。但要小心如果依赖版本变动频繁cache 偶尔会带来“幽灵依赖”这时候需要手动清除 cache。before_script每个 job 执行前都会跑的初始化命令可以用来统一检查 Node 版本。artifactsbuild job 里把dist/目录打包成临时产物传递给 deploy job。这里设置expire_in: 1 hour是因为默认保留时间是 30 天没必要占用那么多 GitLab 存储空间。deploy 里的 scp这里用的是最直接的方案——构建完直接传到 Nginx 目录。更优雅的方案后面我会讲。5.3 部署的三种常见实现方式方式一scp/rsync 直接传文件适合小项目上面的示例就是这种方式。优点是简单不依赖额外组件缺点是权限比较大需要把服务器 SSH 密钥放到 CI 环境变量里。部署目标目录必须提前创建好mkdir -p /opt/nginx/www/yourproject chown -R 你的用户:你的用户 /opt/nginx/www/yourproject方式二GitLab Runner 直接调用宿主机脚本适合和服务器紧密集成在 Runner 的机器上写一个部署脚本/opt/scripts/deploy.sh内容就是把构建产物拷贝到 Nginx 目录、重新加载配置。CI 里通过ssh userhost bash /opt/scripts/deploy.sh触发。好处是脚本在服务器上改部署逻辑不需要提交代码。方式三docker-compose 重建前端容器如果前端项目是跑在容器里的可以构建镜像后通过 docker-compose 更新容器。这种方式适合前端需要服务端渲染SSR或者后端 API 一起部署的场景。但纯前端静态站直接 Nginx 托管静态文件就够了没必要多套一层容器。5.4 环境变量与安全说明.gitlab-ci.yml是明文提交到仓库里的所以任何敏感信息都绝对不能直接写在配置里。SSH 私钥、服务器密码、密钥等都要放到 GitLab 项目的 Settings - CI/CD - Variables 里传值用$变量名引用。例如script: - echo $DEPLOY_SSH_PRIVATE_KEY /tmp/deploy_key - chmod 600 /tmp/deploy_key - scp -i /tmp/deploy_key -r dist/* 服务器用户服务器IP:/opt/nginx/www/yourproject/变量在 GitLab 后台配置时可以选择Protected只有受保护分支能用和Masked日志里自动打码这两个选项强烈建议都勾上。5.5 触发方式自动触发和手动触发起推送 master 分支会自动触发 pipeline这是默认行为。你还可以在 GitLab 页面的 CI/CD - Pipelines 里手动点击 Run pipeline 重新触发一次方便修复失败任务。这个“手动重跑”操作在日常开发中很常用比如这次构建失败只是网络抖动、依赖没装全不需要 commit 一个空操作去重新触发直接在页面上点一下 Run pipeline 就行。6. Nginx 配置与静态资源发布6.1 Nginx 静态站配置模板前端构建产物是纯静态文件部署到 Nginx 的/opt/nginx/www/yourproject目录后需要在 1Panel 里新建站点或者直接修改 Nginx 配置。1Panel 的文件管理直接编辑/opt/nginx/conf/nginx.conf也可以在网站菜单里创建网站并指定静态目录。我贴一份标准静态站配置server { listen 80; server_name yourdomain.com; root /opt/nginx/www/yourproject; index index.html; location / { try_files $uri $uri/ /index.html; } }try_files那行是单页应用SPA的核心——前端路由是 history 模式时刷新某个子页面 NGINX 找不到对应路径就会返回 index.html 让前端自己去路由解析。6.2 端口与域名访问如果暂时没有域名直接用服务器 IP 访问也是可以的只要把server_name改成 IP 即可。但生产环境建议上域名原因很简单HTTPS。GitLab 本身也建议用域名 HTTPS否则登录密码等都是明文传输。1Panel 的“网站”功能里可以一键申请 Lets Encrypt 证书并配置 HTTPS省去不少手动操作的时间。6.3 定时清理构建产物前端项目迭代快dist/目录下会有大量带 hash 的文件。发布新版本后过期文件的清理如果不做目录大小会慢慢膨胀。可以在 CI 里加一步发布完成后删除旧版本的缓存目录比如只保留最新两份构建after_script: - ls -t /opt/nginx/www/yourproject/releases | tail -n 3 | xargs rm -rf这段脚本的意思是列出按时间排序的构建目录从第三个开始全部删掉。配合 Nginx 软链指向最新的 release 目录可以实现零停机发布。7. 常见问题与排查技巧7.1 Docker Desktop 启动失败排查清单前面提到的 Virtualization support not detected 是最典型的问题。除此之外还有几个高发情况failed to connect to the docker api at npipe这个报错出现在 Windows 上通常是 Docker Desktop 的引擎没起来或者 WSL2 后端崩了。试试右下角托盘图标右键 Restart或者在 PowerShell 里执行wsl --shutdown然后重新启动 Docker Desktop。Linux 服务器上 Docker 启动失败先systemctl status docker看错误日志一个常见原因是 cgroup 版本不对需要加GRUB_CMDLINE_LINUXsystemd.unified_cgroup_hierarchy0CentOS 7 这类老系统会遇到。Ubuntu 22.04 以上用 cgroup v2 问题不大但如果装了老版本的 Docker也可能会出问题直接升级 Docker 就行。7.2 GitLab 容器起不来或频繁 502这个问题的排查思路要按层来下面这个表格是排查顺序现象可能原因排查命令 / 操作容器反复重启内存不足被杀docker stats gitlab看内存占用调小组件配置或加 swap502 Bad GatewayGitLab 内部组件还没完全启动docker logs -f gitlab等它初始化完成有时需要 5-10 分钟502 且日志报puma failed to start80 端口被宿主机别的服务占用ss -tlnpGitLab 页面能打开但仓库 500 错误PostgreSQL 数据损坏或磁盘满df -h检查磁盘docker logs gitlab容器起不来提示mkdir permission denied挂载目录权限不对chown -R 998:998 /opt/gitlab无法从网页 clone 仓库external_url 配错了检查external_url是否包含端口、域名是否和实际一致GitLab 容器内部有个调试命令非常好用docker exec -it gitlab gitlab-rake gitlab:check它会自动检查所有组件状态报错信息基本都能直接定位问题。7.3 Docker 网络不通的问题1Panel 创建的网桥和 docker run 默认的网桥是两个不同的网段跨容器通信时容易出现互相访问不到的情况。比如前端容器要调接口容器的 IP如果它们不在同一个网络里会直接 connect refused。解决方法是把相关容器都加入同一个自定义网络docker network create mynetwork docker network connect mynetwork gitlab docker network connect mynetwork frontend或者在 1Panel 的容器编辑页面直接调整网络配置。1Panel 本身对这块封装得简单但网络层级的概念还是建议了解一下排错的时候能少绕很多弯。7.4 SSH 连接失败无法 clone 或 push最常见的原因是 GitLab 的 SSH 端口映射了 2222但克隆地址还用了默认 22。在 GitLab 项目页面上点 Clone下拉框选 SSH看地址里有没有带上 2222 端口。没有的话手动改成git clone ssh://git你的IP:2222/root/frontend-xxx.git还有一个坑本地 SSH 客户端默认尝试多个密钥文件但 GitLab 上只添加了一个公钥。如果之前用过其他服务器的密钥SSH agent 可能会优先给 GitLab 发错密钥服务器直接拒绝。排查方法ssh -T -p 2222 git你的IP -v输出里能看到用的是哪个 key 文件找到问题后指定密钥连接或者编辑~/.ssh/config单独为 GitLab 配一条规则。7.5 GitLab 高危漏洞修复GitLab 官方经常发布安全更新社区版如果没有及时更新容易暴露已知漏洞。这个没什么黑魔法核心策略就是保持镜像版本最新。具体操作拉取最新镜像重建容器。但重建前务必备份/opt/gitlab/config、/opt/gitlab/logs、/opt/gitlab/data这三个目录或者用 1Panel 的快照功能做好备份。升级命令docker compose pull gitlab docker compose up -d --force-recreate gitlab升级后也会有一个重新配置的过程耐心等日志输出。另外定期关注 GitLab 官方 release notes高危漏洞公告出来后尽早升级不要拖。7.6 CI 任务执行失败login failed 与 Runner 失联CI 报login failed. check api token or gitlab version多半是你用了自定义 Runner 的注册 Token 不对或者 GitLab 版本和 Runner 版本不兼容。Runner 的版本不要用 latest 一拉了之最好和 GitLab 版本匹配一个大版本线。检查方法docker exec -it gitlab-runner gitlab-runner -v docker exec -it gitlab gitlab-rake gitlab:env:info如果 Runner 显示 not connected重启一下 Runner 容器确认注册信息没被清掉还是不行就重新注册一次。7.7 前端依赖安装太慢或者失败CI 里构建前端npm install 速度极大影响整体耗时。国内服务器直连 npm 官方源非常慢在.gitlab-ci.yml里加参数npm install --registryhttps://registry.npmmirror.com如果你用 pnpm配置pnpm config set registry https://registry.npmmirror.com另一个技巧是缓存~/.npm目录GitLab 的cache可以配合paths指定这样后续任务能复用下载过的依赖包显著提速。8. 进阶扩展方向这套流程跑顺之后还可以在现有基础上升级加 Webhook 对接其他系统GitLab 项目设置里可以配置 Webhook比如推代码后自动通知企微/钉钉或触发远程构建。1Panel 的“应用”里也有不少集成可以自己研究一下。多环境多分支push dev 分支时构建到测试服务器push master 时发布到生产服务器。在.gitlab-ci.yml里用$CI_COMMIT_BRANCH变量判断两套部署动作轻松区分。Docker 化前端部署写一个 Nginx 静态文件的 Dockerfile把构建产物打进镜像推到 GitLab Container Registry再在服务器上拉镜像跑容器。这样前端应用也能享受镜像版本管理的优势。集成自动化测试前端 lint、单元测试可以放在 build 之前测试不过直接 fail pipeline。这对多人团队尤其重要能挡住很多低级错误。最后分享几个实操心得整套流程我实测跑了大半年最深的体验是自动部署的核心不是“自动”两个字而是“可重复”和“可回滚”。只要每次发布都是从同一个流程走出来的问题就很好排查出了问题把上一个镜像或上一份 dist 恢复回去就行这比手动操作稳定太多了。几个小细节再说一下GitLab 的docker-compose.yml里的restart: always建议一定要加服务器重启后容器能自动恢复不用你惦记着手动拉起。构建前端项目时内存小的服务器上npm run build偶尔会 OOM可以在构建 job 里限制 Node 的内存NODE_OPTIONS--max-old-space-size1024。1Panel 自带的备份功能强烈建议用起来尤其是 GitLab 的 config 目录的备份里面包含仓库访问密钥、数据库密码等关键信息。恢复的时候把备份文件放回/opt/gitlab/config再启动容器GitLab 基本能原地满血复活。CI 变量的作用域记得确认好是只在某个项目生效、还是要多个项目共用。如果多个项目用同一套部署逻辑可以把变量配在 Admin Area 的 CI/CD Variables 里这样一次配置全局复用不用每个项目都复制一遍。我写这篇教程的时候尽量把“为什么这么做”也讲清楚了因为配置这东西死记硬背只能解决眼前的问题理解了原理遇到新情况才知道怎么应变。希望你这套流程搭起来之后以后每次 push 完代码喝口水的功夫新版本就已经上线了。