Docker Compose部署GitLab全攻略：从入门到生产级实践

1. 为什么选择Docker Compose部署GitLab十年前我第一次搭建GitLab时光环境配置就折腾了两天。如今用Docker Compose方案从零到可用只需要15分钟。这种部署方式之所以成为主流核心在于它完美解决了传统部署的三大痛点依赖地狱传统方式需要手动安装Ruby、PostgreSQL、Redis等十余个组件版本兼容性问题频发。Docker镜像已内置所有依赖的兼容版本组合比如GitLab官方镜像就包含了Ruby 2.7 Bundler 2.1PostgreSQL 12 对应适配器Redis 6.x稳定版Go语言编译环境配置碎片化以前改个SMTP配置要同时修改Nginx、Ruby环境变量和系统服务文件。现在所有配置通过单个docker-compose.yml文件集中管理比如邮件服务配置就集中在environment段environment: GITLAB_OMNIBUS_CONFIG: | gitlab_rails[smtp_enable] true gitlab_rails[smtp_address] smtp.example.com gitlab_rails[smtp_port] 587升级困难传统方式升级需要停服数小时而Docker方案只需docker-compose pull docker-compose up -d整个过程服务中断不超过30秒。2. 生产级部署方案设计2.1 硬件资源配置基准根据GitLab官方性能白皮书我总结出不同团队规模下的资源配置建议活跃用户数CPU核心内存存储空间推荐云机型502核4GB50GBAWS t3.medium50-2004核8GB200GBGCP e2-standard-4200-10008核16GB500GBAzure D4s v3100016核32GB1TB专用物理服务器重要提示存储空间需要额外预留30%用于仓库扩容和备份。我曾有个客户因为只按初始需求配置存储半年后不得不停机迁移数据。2.2 网络拓扑设计生产环境建议采用三层网络隔离架构公网负载均衡器 (HTTPS终结点) ↓ Docker主机 (仅暴露443端口) ↓ GitLab容器组 (内部通信) ├── gitlab-ce (主应用) ├── postgresql (数据库) └── redis (缓存)对应的docker-compose.yml网络配置示例services: gitlab: networks: - frontend - backend postgresql: networks: - backend redis: networks: - backend networks: frontend: driver: bridge ipam: config: - subnet: 172.20.0.0/24 backend: driver: bridge internal: true2.3 持久化存储方案数据持久化需要特别关注三个目录配置数据/etc/gitlab包含所有系统配置和密钥建议使用云厂商的持久化盘如AWS EBS仓库数据/var/opt/gitlab/git-data存储所有git仓库实际内容对IOPS要求高建议使用SSD存储数据库数据/var/lib/postgresql/dataPostgreSQL数据目录需要定期备份典型volume配置volumes: gitlab_config: driver: local driver_opts: type: nfs o: addrnas.example.com,rw device: :/gitlab/config gitlab_data: driver: local driver_opts: type: ext4 device: /dev/sdb13. 完整部署实操手册3.1 基础环境准备先决条件检查清单Docker版本 ≥ 20.10.12Docker Compose版本 ≥ 1.29.2服务器时区设置为UTC防火墙开放22(SSH)、80/443(HTTP/HTTPS)端口内存优化配置必须sudo sysctl -w vm.overcommit_memory1 sudo sysctl -w vm.swappiness0 echo vm.overcommit_memory 1 | sudo tee -a /etc/sysctl.conf echo vm.swappiness 0 | sudo tee -a /etc/sysctl.conf3.2 docker-compose.yml详解这是我优化过的生产级配置模板version: 3.7 services: gitlab: image: gitlab/gitlab-ce:15.11.0-ce.0 container_name: gitlab hostname: gitlab.example.com environment: GITLAB_OMNIBUS_CONFIG: | external_url https://gitlab.example.com gitlab_rails[gitlab_shell_ssh_port] 2222 nginx[listen_port] 80 nginx[listen_https] false nginx[proxy_set_headers] { X-Forwarded-Proto https, X-Forwarded-Ssl on } ports: - 80:80 - 443:443 - 2222:22 volumes: - gitlab_config:/etc/gitlab - gitlab_logs:/var/log/gitlab - gitlab_data:/var/opt/gitlab networks: - gitlab_net restart: always shm_size: 256m healthcheck: test: [CMD, /opt/gitlab/bin/gitlab-healthcheck, --fail] interval: 1m timeout: 10s retries: 3 networks: gitlab_net: driver: bridge volumes: gitlab_config: gitlab_logs: gitlab_data:关键参数解析shm_size: 解决Sidekiq内存不足问题healthcheck: 自动监控服务状态nginx[listen_https] false: 配合外部负载均衡器使用3.3 初始化及优化首次启动后需要执行# 进入容器 docker exec -it gitlab /bin/bash # 重置管理员密码 gitlab-rake gitlab:password:reset[root] # 开启自动垃圾回收 gitlab-rake gitlab:git:prune # 优化PostgreSQL gitlab-psql -c ALTER SYSTEM SET shared_buffers 1GB; gitlab-psql -c ALTER SYSTEM SET effective_cache_size 3GB;性能调优参数追加到GITLAB_OMNIBUS_CONFIGpostgresql[shared_buffers] 1GB sidekiq[max_concurrency] 10 puma[worker_processes] 44. 运维实战技巧4.1 备份与恢复方案全量备份命令docker exec -t gitlab gitlab-backup create STRATEGYcopy自动化备份脚本保存为/usr/local/bin/gitlab-backup.sh#!/bin/bash BACKUP_DIR/mnt/backups/gitlab TIMESTAMP$(date %Y%m%d_%H%M%S) docker exec -t gitlab gitlab-backup create STRATEGYcopy SKIPartifacts cp /var/lib/docker/volumes/gitlab_config/_data/gitlab-secrets.json $BACKUP_DIR/gitlab-secrets_$TIMESTAMP.json find $BACKUP_DIR -type f -mtime 30 -delete通过crontab设置每日凌晨3点备份0 3 * * * /usr/local/bin/gitlab-backup.sh /var/log/gitlab-backup.log 21恢复流程# 停止相关服务 docker exec -it gitlab gitlab-ctl stop puma docker exec -it gitlab gitlab-ctl stop sidekiq # 恢复备份 docker exec -it gitlab gitlab-backup restore BACKUP1234567890_2023_01_01_15.11.0 # 恢复密钥文件 cp gitlab-secrets_20230101.json /var/lib/docker/volumes/gitlab_config/_data/gitlab-secrets.json # 重启服务 docker exec -it gitlab gitlab-ctl restart4.2 监控与日志管理推荐监控指标容器资源CPU使用率、内存占用、磁盘IOPS应用指标HTTP请求延迟P99 500msSidekiq队列积压应 100PostgreSQL连接数使用率 80%日志收集配置示例Fluentd ELKservices: fluentd: image: fluent/fluentd:v1.15-1 volumes: - ./fluent.conf:/fluentd/etc/fluent.conf - gitlab_logs:/var/log/gitlab:ro ports: - 24224:24224 # 在fluent.conf中添加 source type tail path /var/log/gitlab/gitlab-rails/production.log pos_file /var/log/fluentd/gitlab-rails.pos tag gitlab.rails format none /source4.3 版本升级策略安全升级路线图当前版本 → 15.11.0 → 16.0.0 → 16.3.0 → 16.8.0必须按顺序升级不可跨大版本升级。升级检查清单[ ] 确认已备份完整数据和密钥[ ] 检查版本升级路径是否合规[ ] 阅读目标版本的升级说明[ ] 在测试环境验证升级流程零停机升级步骤# 拉取新版本镜像 docker-compose pull # 创建临时副本 docker-compose pause docker commit gitlab gitlab_snapshot # 执行升级 docker-compose up -d # 监控升级状态 docker exec -it gitlab gitlab-ctl status watch -n 1 curl -s http://localhost/-/health | jq5. 企业级安全加固5.1 网络层防护强制HTTPS配置environment: GITLAB_OMNIBUS_CONFIG: | nginx[redirect_http_to_https] true nginx[ssl_certificate] /etc/gitlab/ssl/gitlab.crt nginx[ssl_certificate_key] /etc/gitlab/ssl/gitlab.keyIP访问限制限制内网访问gitlab_rails[rack_attack_git_basic_auth] { enabled true, ip_whitelist [192.168.1.0/24], maxretry 10, findtime 60, bantime 3600 }5.2 账户安全策略密码复杂度要求gitlab_rails[password_compLEXity_requirements] { enabled true, minimum_length 12, require_letter true, require_number true, require_symbol true }双因素认证强制开启gitlab_rails[require_two_factor_authentication] true gitlab_rails[two_factor_grace_period] 48 # 小时5.3 容器安全最佳实践非root用户运行services: gitlab: user: 1000:1000 read_only: true security_opt: - no-new-privileges:true镜像签名验证export DOCKER_CONTENT_TRUST1 docker-compose pull6. 故障排查指南6.1 常见问题速查表故障现象可能原因解决方案502错误Puma worker崩溃docker exec gitlab gitlab-ctl restart puma仓库推送失败gitlab-shell版本不匹配docker exec gitlab gitlab-ctl upgrade后台作业堆积Sidekiq进程僵死docker exec gitlab gitlab-ctl restart sidekiq登录循环Redis会话数据丢失清除浏览器Cookie并重启Redis服务磁盘空间不足日志文件膨胀docker exec gitlab gitlab-ctl rotate-logs6.2 诊断工具集检查服务状态docker exec gitlab gitlab-ctl status实时日志监控docker logs -f gitlab | grep -E WARN|ERROR|FATAL数据库健康检查docker exec gitlab gitlab-rake gitlab:check性能分析工具# 生成性能报告 docker exec gitlab gitlab-rake gitlab:performance:report # 内存分析 docker exec gitlab bundle exec rbtrace -p $(pgrep -f puma) -m ObjectSpace.count_objects6.3 灾难恢复演练建议每季度执行以下演练流程随机停止一个关键容器如PostgreSQL验证监控系统告警是否触发按照备份恢复流程操作验证数据完整性和服务可用性记录RTO恢复时间目标和RPO恢复点目标典型恢复指标RTO ≤ 1小时中型部署RPO ≤ 5分钟依赖备份频率