DevOps和CI/CD已经成为现代软件开发的标配，但在NAS上搭建完整的CI/CD流水线仍然是不少开发者的盲区。群晖DSM搭配Docker容器，完全可以构建一套生产级别的GitLab CI/CD系统，实现从代码提交到自动构建再到部署的全流程自动化。本文将手把手教你如何在群晖NAS上搭建这套系统。
一、群晖Docker中部署GitLab CE容器
在群晖DSM的Container Manager（原Docker套件）中部署GitLab，比想象中更简单。首先在注册表中搜索gitlab/gitlab-ce:latest镜像并下载。为了让GitLab拥有良好的性能，创建容器时至少分配4GB内存和2个CPU核心，端口映射规则为：宿主机22端口映射到容器的22端口（SSH访问代码仓库）、8080端口映射到容器的80端口（HTTP访问）、8443映射到443（HTTPS）。最关键的一步是数据持久化——将容器内的/etc/gitlab、/var/opt/gitlab和/var/log/gitlab三个目录分别映射到NAS的共享文件夹，如/docker/gitlab/config、/docker/gitlab/data和/docker/gitlab/logs。这些目录保存了GitLab的所有配置、仓库数据和日志，一旦容器更新或损坏，数据不会丢失。容器启动后初始化大约需要3-5分钟，通过浏览器访问http://NAS_IP:8080，首次访问时系统会要求设置root管理员密码。然后在GitLab的管理界面中注册一个GitLab Runner——这是一个执行CI/CD任务的代理程序。注册时需要从GitLab的管理区获取注册令牌（registration token），在Runner所在的机器上执行gitlab-runner register命令完成绑定。值得注意的是，如果NAS内存有限（8GB以下），建议单独分配一台轻量级虚拟机或另一台设备来运行GitLab Runner，避免Runner在构建过程中消耗大量资源影响NAS的核心存储服务。
二、编写.gitlab-ci.yml：定义完整的CI/CD流水线
CI/CD流水线的核心是仓库根目录下的.gitlab-ci.yml文件。以一个Node.js Web应用为例，一套完整的流水线通常包含四个阶段：安装依赖、代码质量检查、测试和部署。在依赖安装阶段，配置使用gitlab-runner的node:18-alpine镜像执行npm install，并开启缓存策略将node_modules目录缓存起来，避免每次构建都重新下载依赖包。代码质量检查阶段使用eslint和prettier对代码进行静态分析，如果检测到语法错误或代码风格问题，流水线标记失败并阻止后续阶段的执行。测试阶段运行Jest单元测试和集成测试生成覆盖率报告。部署阶段是整个流水线的核心——当主分支（main或master）的代码通过所有测试后，自动触发部署脚本。在群晖NAS的部署场景中，推荐使用Docker方式部署：部署脚本构建一个新的Docker镜像，推送到NAS上的私有镜像仓库，然后通过SSH连接到NAS执行docker-compose pull && docker-compose up -d来更新服务。为了实现安全的SSH连接，需要在GitLab Runner上配置SSH密钥，并将公钥添加到NAS的authorized_keys文件中。更安全的方式是使用GitLab的CI/CD Variables功能——将NAS的SSH私钥作为一个受保护的变量存储在GitLab中，流水线运行时通过SSH Agent自动加载。
三、持续部署的进阶配置与监控
基础流水线搭建完成后，可以进一步优化持续部署的流程。首先引入环境分支策略——创建staging分支用于预发布环境测试，当staging分支的流水线通过后由管理员手动触发生产环境部署。在GitLab的CI/CD设置中，可以为不同环境配置不同的部署变量：预发布环境使用测试数据库连接，生产环境使用正式域名和SSL证书。第二个进阶配置是自动化版本管理——在部署阶段的脚本中增加自动打Tag的逻辑：当代码合并到主分支时，流水线自动根据package.json中的版本号创建一个Git标签，并推送到仓库。如果使用了Docker镜像部署，自动将镜像标签设置为版本号，实现版本的可追溯。第三个配置是集成群晖DSM的Webhook通知——在CI/CD流水线的最后一个步骤中，通过curl触发群晖DSM的Webhook URL，将构建结果通知到Chat或手机推送。例如，当部署成功时发送通知到团队群聊，部署失败时发送告警到管理员手机。最后别忘了监控CI/CD系统的健康状态——在群晖DSM的Docker管理界面中监控GitLab和Runner容器的CPU和内存占用，为这两个容器设置资源限制和自动重启策略。建议每周检查一次GitLab容器日志，清理超过30天的流水线历史记录和构建产物，防止日志和构件占用过多NAS存储空间。当你的项目量增长后，GitLab可能会成为NAS上资源消耗最大的Docker应用，此时可以考虑将数据和配置文件迁移到更高性能的NVMe SSD上。
评论(0)