1. GitLab基础环境搭建1.1 安装方式选择与对比GitLab的安装主要有三种主流方式官方Omnibus包、Docker容器化和源码编译安装。对于大多数生产环境我推荐使用Omnibus包方式它提供了完整的依赖管理和一键式配置。Docker方式适合快速测试环境部署而源码安装则适合需要深度定制的场景。以Ubuntu系统为例Omnibus包安装步骤如下# 添加GitLab仓库 sudo apt-get update sudo apt-get install -y curl openssh-server ca-certificates postfix curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash # 执行安装替换your-domain.com为你的域名 sudo EXTERNAL_URLhttp://your-domain.com apt-get install gitlab-ce重要提示安装前确保服务器至少4GB内存否则可能因内存不足导致服务异常。我曾遇到过2GB内存机器安装后Sidekiq频繁崩溃的情况最终通过增加swap空间临时解决。1.2 初始访问与安全加固安装完成后首次访问会强制重置root密码。建议立即进行以下安全操作修改默认管理员密码12位以上包含特殊字符进入「Admin Area Settings Sign-in restrictions」启用双因素认证配置「Admin Area Monitoring IP Whitelist」限制管理后台访问IP# 查看初始密码安装后首次配置前有效 sudo cat /etc/gitlab/initial_root_password2. 核心功能配置详解2.1 用户与权限体系设计GitLab采用三级权限模型项目可见性Private/Internal/Public、项目成员角色Guest/Reporter/Developer/Maintainer/Owner和分支保护规则。合理的权限设计应遵循最小权限原则graph TD A[项目可见性] -- B[Private] A -- C[Internal] A -- D[Public] E[成员角色] -- F[Guest: 仅查看] E -- G[Reporter: 问题跟踪] E -- H[Developer: 代码提交] E -- I[Maintainer: 合并权限] E -- J[Owner: 全权管理]实际案例为外包团队配置权限时我通常会创建专属Group「Outsourcing」设置项目为「Internal」可见性分配Developer角色限制直接push到protected分支通过「Protected Branches」设置master分支需MR2个批准2.2 SSH密钥与CI/CD集成2.2.1 用户SSH密钥配置开发者在「Profile Settings SSH Keys」添加公钥后即可实现免密代码拉取推送。推荐使用ED25519算法生成更安全的密钥对ssh-keygen -t ed25519 -C your_emailexample.com2.2.2 Runner注册与管理共享Runner适合小型团队中大型项目建议配置专属Runner# 注册项目专用Runner sudo gitlab-runner register \ --non-interactive \ --url https://gitlab.example.com/ \ --registration-token PROJECT_REGISTRATION_TOKEN \ --executor docker \ --docker-image alpine:latest \ --description docker-runner \ --tag-list docker,aws \ --run-untaggedfalse \ --lockedtrue踩坑记录曾因未设置--locked导致Runner被其他项目误用引发构建资源争抢。建议生产环境始终启用locked模式。3. 高级配置优化3.1 存储库存储策略默认存储路径为/var/opt/gitlab/git-data生产环境应考虑使用独立分区避免磁盘写满配置对象存储如AWS S3存放大型附件# /etc/gitlab/gitlab.rb 配置示例 git_data_dirs({ default { path /mnt/gitlab-data }, alternative { path /mnt/gitlab-alt } }) # 对象存储配置 gitlab_rails[object_store][enabled] true gitlab_rails[object_store][connection] { provider AWS, region eu-west-1, aws_access_key_id AKIAXXXXXXXXXXXXXXXX, aws_secret_access_key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX }3.2 备份与恢复方案全量备份包含数据库、仓库和附件但需注意备份时不自动包含配置文件恢复要求GitLab版本完全一致# 手动备份默认保存到/var/opt/gitlab/backups sudo gitlab-backup create # 恢复操作先停止相关服务 sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop sidekiq sudo gitlab-backup restore BACKUPtimestamp_of_backup我曾遇到过备份文件权限问题导致恢复失败解决方法sudo chown git:git /var/opt/gitlab/backups/* sudo chmod 600 /var/opt/gitlab/backups/*4. 日常运维与排错4.1 服务状态监控内置Prometheus监控需在配置中启用prometheus[enable] true node_exporter[enable] true redis_exporter[enable] true关键监控指标阈值内存使用率 70% 需告警Unicorn workers队列 5 需扩容Sidekiq作业积压 100 需检查4.2 常见问题处理手册4.2.1 502错误排查流程检查服务状态sudo gitlab-ctl status查看日志sudo journalctl -u gitlab-unicorn -n 100常见原因内存不足增加swap或升级配置端口冲突修改unicorn[port]4.2.2 仓库无法推送检查仓库权限sudo chown -R git:git /var/opt/gitlab/git-data验证hooks完整性sudo gitlab-rake gitlab:check查看磁盘inodesdf -i5. 效能提升实践5.1 大型仓库优化当仓库体积超过1GB时应考虑启用Git LFS管理二进制文件定期执行仓库压缩git gc --aggressive --prunenow配置pack文件缓存gitlab_rails[gitlab_shell_git_timeout] 10800 gitlab_rails[git_max_pack_size] 512.megabytes5.2 自动化管理技巧使用GitLab API批量管理项目需personal_access_tokenimport requests headers {PRIVATE-TOKEN: your_access_token} api_url https://gitlab.example.com/api/v4 # 批量归档过期项目 projects requests.get(f{api_url}/projects?archivedfalse, headersheaders).json() for p in projects: if p[last_activity_at] 2023-01-01: requests.put(f{api_url}/projects/{p[id]}/archive, headersheaders)这套配置方案在某200人研发团队的生产环境中稳定运行3年日均处理200次代码提交和50次CI/CD流水线执行。关键是要根据团队规模动态调整Unicorn workers数量建议每100活跃用户配置1个worker和Sidekiq并发数CPU核心数的1.5倍为宜。
1. GitLab基础环境搭建1.1 安装方式选择与对比GitLab的安装主要有三种主流方式官方Omnibus包、Docker容器化和源码编译安装。对于大多数生产环境我推荐使用Omnibus包方式它提供了完整的依赖管理和一键式配置。Docker方式适合快速测试环境部署而源码安装则适合需要深度定制的场景。以Ubuntu系统为例Omnibus包安装步骤如下# 添加GitLab仓库 sudo apt-get update sudo apt-get install -y curl openssh-server ca-certificates postfix curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash # 执行安装替换your-domain.com为你的域名 sudo EXTERNAL_URLhttp://your-domain.com apt-get install gitlab-ce重要提示安装前确保服务器至少4GB内存否则可能因内存不足导致服务异常。我曾遇到过2GB内存机器安装后Sidekiq频繁崩溃的情况最终通过增加swap空间临时解决。1.2 初始访问与安全加固安装完成后首次访问会强制重置root密码。建议立即进行以下安全操作修改默认管理员密码12位以上包含特殊字符进入「Admin Area Settings Sign-in restrictions」启用双因素认证配置「Admin Area Monitoring IP Whitelist」限制管理后台访问IP# 查看初始密码安装后首次配置前有效 sudo cat /etc/gitlab/initial_root_password2. 核心功能配置详解2.1 用户与权限体系设计GitLab采用三级权限模型项目可见性Private/Internal/Public、项目成员角色Guest/Reporter/Developer/Maintainer/Owner和分支保护规则。合理的权限设计应遵循最小权限原则graph TD A[项目可见性] -- B[Private] A -- C[Internal] A -- D[Public] E[成员角色] -- F[Guest: 仅查看] E -- G[Reporter: 问题跟踪] E -- H[Developer: 代码提交] E -- I[Maintainer: 合并权限] E -- J[Owner: 全权管理]实际案例为外包团队配置权限时我通常会创建专属Group「Outsourcing」设置项目为「Internal」可见性分配Developer角色限制直接push到protected分支通过「Protected Branches」设置master分支需MR2个批准2.2 SSH密钥与CI/CD集成2.2.1 用户SSH密钥配置开发者在「Profile Settings SSH Keys」添加公钥后即可实现免密代码拉取推送。推荐使用ED25519算法生成更安全的密钥对ssh-keygen -t ed25519 -C your_emailexample.com2.2.2 Runner注册与管理共享Runner适合小型团队中大型项目建议配置专属Runner# 注册项目专用Runner sudo gitlab-runner register \ --non-interactive \ --url https://gitlab.example.com/ \ --registration-token PROJECT_REGISTRATION_TOKEN \ --executor docker \ --docker-image alpine:latest \ --description docker-runner \ --tag-list docker,aws \ --run-untaggedfalse \ --lockedtrue踩坑记录曾因未设置--locked导致Runner被其他项目误用引发构建资源争抢。建议生产环境始终启用locked模式。3. 高级配置优化3.1 存储库存储策略默认存储路径为/var/opt/gitlab/git-data生产环境应考虑使用独立分区避免磁盘写满配置对象存储如AWS S3存放大型附件# /etc/gitlab/gitlab.rb 配置示例 git_data_dirs({ default { path /mnt/gitlab-data }, alternative { path /mnt/gitlab-alt } }) # 对象存储配置 gitlab_rails[object_store][enabled] true gitlab_rails[object_store][connection] { provider AWS, region eu-west-1, aws_access_key_id AKIAXXXXXXXXXXXXXXXX, aws_secret_access_key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX }3.2 备份与恢复方案全量备份包含数据库、仓库和附件但需注意备份时不自动包含配置文件恢复要求GitLab版本完全一致# 手动备份默认保存到/var/opt/gitlab/backups sudo gitlab-backup create # 恢复操作先停止相关服务 sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop sidekiq sudo gitlab-backup restore BACKUPtimestamp_of_backup我曾遇到过备份文件权限问题导致恢复失败解决方法sudo chown git:git /var/opt/gitlab/backups/* sudo chmod 600 /var/opt/gitlab/backups/*4. 日常运维与排错4.1 服务状态监控内置Prometheus监控需在配置中启用prometheus[enable] true node_exporter[enable] true redis_exporter[enable] true关键监控指标阈值内存使用率 70% 需告警Unicorn workers队列 5 需扩容Sidekiq作业积压 100 需检查4.2 常见问题处理手册4.2.1 502错误排查流程检查服务状态sudo gitlab-ctl status查看日志sudo journalctl -u gitlab-unicorn -n 100常见原因内存不足增加swap或升级配置端口冲突修改unicorn[port]4.2.2 仓库无法推送检查仓库权限sudo chown -R git:git /var/opt/gitlab/git-data验证hooks完整性sudo gitlab-rake gitlab:check查看磁盘inodesdf -i5. 效能提升实践5.1 大型仓库优化当仓库体积超过1GB时应考虑启用Git LFS管理二进制文件定期执行仓库压缩git gc --aggressive --prunenow配置pack文件缓存gitlab_rails[gitlab_shell_git_timeout] 10800 gitlab_rails[git_max_pack_size] 512.megabytes5.2 自动化管理技巧使用GitLab API批量管理项目需personal_access_tokenimport requests headers {PRIVATE-TOKEN: your_access_token} api_url https://gitlab.example.com/api/v4 # 批量归档过期项目 projects requests.get(f{api_url}/projects?archivedfalse, headersheaders).json() for p in projects: if p[last_activity_at] 2023-01-01: requests.put(f{api_url}/projects/{p[id]}/archive, headersheaders)这套配置方案在某200人研发团队的生产环境中稳定运行3年日均处理200次代码提交和50次CI/CD流水线执行。关键是要根据团队规模动态调整Unicorn workers数量建议每100活跃用户配置1个worker和Sidekiq并发数CPU核心数的1.5倍为宜。
