环境准备与镜像选择
在开始部署之前，我们需要确保宿主机已经正确安装并配置了容器运行环境。由于GitLab本身是一个集成了众多组件的庞大系统，包含Nginx、PostgreSQL、Redis、Sidekiq等，因此对硬件资源有一定的门槛要求。建议宿主机至少具备4GB的可用内存，如果团队规模较大或需要开启完整的CI/CD流水线，内存最好提升至8GB甚至更高。CPU核心数建议在2核以上，否则在处理代码提交或构建任务时可能会出现明显的卡顿现象。
官方提供了两个主要版本的镜像：社区版（CE）和企业版（EE）。对于绝大多数个人开发者或中小型团队而言，社区版已经提供了足够丰富的代码托管、代码审查以及基础的持续集成功能，完全能够满足日常研发需求。企业版虽然功能更全面，但需要付费授权，且对硬件资源消耗更大。因此，我们通常选择拉取gitlab/gitlab-ce镜像。通过使用带有特定版本标签的镜像，例如gitlab-ce:16.6.0-ce.0，可以确保每次部署的环境一致性，避免由于上游镜像更新带来的兼容性问题。
拉取镜像的过程十分简单，只需在终端执行拉取指令即可。由于GitLab镜像体积较大，包含了所有依赖组件，下载可能需要一些时间，具体取决于网络带宽。建议在拉取前配置好国内的镜像加速器，以大幅提升下载速度。拉取完成后，可以通过查看本地镜像列表来确认镜像是否已经成功下载到本地仓库中，为后续的容器启动做好准备。
核心配置与容器启动方案
容器化部署的核心原则是数据与容器本身分离。GitLab在运行过程中会产生大量的配置文件、运行日志以及用户代码仓库数据，如果将这些数据存储在容器内部的临时层，一旦容器被删除或重建，所有数据都会丢失。因此，必须通过数据卷将宿主机的目录映射到容器内部。通常我们需要映射三个核心路径：/etc/gitlab用于存储配置文件，/var/log/gitlab用于存储各类运行日志，/var/opt/gitlab用于存储实际的应用数据。
除了数据卷，端口映射也是部署成功的关键。GitLab主要依赖两个对外提供服务的端口：HTTP端口用于网页访问和API调用，SSH端口用于基于Git协议的代码推送与拉取。在宿主机上，80端口和22端口可能已经被其他服务占用，例如宿主机自身的Nginx或SSH服务。为了避免端口冲突，我们需要将容器的80端口映射到宿主机的空闲端口（如8080），将容器的22端口映射到另一个空闲端口（如2222）。同时，还需要在GitLab的配置文件中指定外部访问的URL和SSH端口，否则在网页上看到的克隆地址会显示错误的端口号。
下面是一个完整的容器启动命令示例。在这个命令中，我们不仅设置了数据卷和端口映射，还通过环境变量GITLAB_OMNIBUS_CONFIG预先注入了外部访问URL和SSH端口配置。这种方式的好处是，容器在首次启动时就会自动应用这些配置，无需后续手动进入容器修改文件并重启服务。
docker run --detach \ --hostname gitlab.ippipp.com \ --publish 8443:443 --publish 8080:80 --publish 2222:22 \ --name gitlab \ --restart always \ --volume /srv/gitlab/config:/etc/gitlab \ --volume /srv/gitlab/logs:/var/log/gitlab \ --volume /srv/gitlab/data:/var/opt/gitlab \ --env GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.ippipp.com:8080'; gitlab_rails['gitlab_shell_ssh_port'] = 2222" \ gitlab/gitlab-ce:16.6.0-ce.0
执行上述命令后，容器会在后台运行。此时GitLab内部的各种组件正在初始化，包括数据库迁移、密钥生成等操作，这个过程可能需要几分钟时间。在此期间访问网页可能会报502错误，这是正常的等待现象。可以通过查看容器日志来跟踪启动进度，当日志中出现类似gitlab Reconfigured!的字样时，说明初始化已经完成，此时刷新浏览器即可看到GitLab的登录页面。
初始化设置与性能调优
首次访问页面时，系统会要求你设置管理员账户的密码。但在较新的GitLab版本中，默认不再提供直接设置密码的页面，而是自动生成了一个随机的初始密码。这个密码存放在容器内的/etc/gitlab/initial_root_password文件中。你需要进入容器内部查看这个文件，使用root作为用户名，加上文件中的随机字符串进行首次登录。登录成功后，强烈建议立即在用户设置中修改密码，并妥善保管，因为该初始密码文件会在24小时后自动执行删除操作以保证安全。
虽然GitLab默认配置能够满足基本运行，但在资源有限的服务器上，其内存占用往往居高不下。为了优化性能，我们需要对核心组件进行调优。首先可以关闭不常用的功能模块，例如Prometheus监控和Grafana可视化面板，这能节省可观的内存和CPU开销。其次，GitLab默认使用Puma作为Web服务器，其worker进程数默认是根据CPU核心数计算的。对于2GB或4GB内存的小型机器，建议手动将worker数量减少为2，并将每个worker的线程数设置为3，这样可以有效防止内存被耗尽导致服务假死。
修改配置参数时，不能直接修改容器内的临时文件，而应该修改挂载到宿主机的gitlab.rb配置文件。找到宿主机上的/srv/gitlab/config/gitlab.rb文件，在末尾添加相应的配置项。修改完成后，需要执行重新配置命令使更改生效。这个过程会触发GitLab内部组件的重启，期间会有短暂的不可用状态。通过合理的参数调整，原本占用4GB内存的GitLab实例，可以被压缩到2GB以内平稳运行，极大地提高了服务器资源的利用率。
# 关闭内置监控组件 prometheus_monitoring['enable'] = false grafana['enable'] = false # 调整Puma Web服务器参数 puma['worker_processes'] = 2 puma['threads_per_worker'] = 3 # 重新配置并应用更改 docker exec -it gitlab gitlab-ctl reconfigure
最后，定期备份是保障代码资产安全的最后一道防线。由于我们将数据目录映射到了宿主机，最简单的备份方式就是直接打包压缩/srv/gitlab目录。但更推荐使用GitLab自带的备份命令，它会生成一个包含完整数据库和仓库数据的tar包。结合定时任务，可以轻松实现每日自动备份，确保在发生意外时能够快速恢复整个代码托管环境。