实战：在 Linux 系统用 Docker-Compose 优雅部署 GitLab 及防坑指南

开篇引言：

团队开发怎么能少得了代码托管？虽然市面上有现成的云服务，但把源码握在自己手里总是更踏实。最爽的部署方式莫过于用 Docker 一键拉起，不用弄脏宿主机的环境。

不过，GitLab 是个名副其实的"资源吞噬者"，直接裸跑很容易把服务器直接卡死。今天和大家分享一套我在生产环境中实际使用的部署方案，通过 docker-compose 结合 .env 环境变量，实现配置解耦、资源限制，并且完美兼容宿主机原本的网络和反向代理环境。

1. 核心配置文件整理

为了方便维护，强烈建议把环境参数和部署编排分开。

项目目录：/home/dk_project/dk_app/gitlab
第一步：创建环境变量文件 .env

在这个文件里定义好我们需要的版本、路径、端口和限制参数：

env 复制代码

VERSION=latest
CONTAINER_NAME=CONTAINER_NAME
HOST_IP=127.0.0.1
WEB_HTTP_PORT=10080
WEB_HTTPS_PORT=10443
WEB_SSH_PORT=10022
DOMAIN_HOST=域名（或IP+端口）
CPUS=6
MEMORY_LIMIT=15360MB
APP_PATH=/home/dk_project/dk_app/gitla

第二步：编写 docker-compose.yml

利用上面的变量，把应用跑起来。注意看这里面的网络和端口映射细节：

yaml 复制代码

services:
  gitlab_3Lss:
    image: gitlab/gitlab-ce:${VERSION}
    deploy:
      resources:
        limits:
          cpus: ${CPUS}
          memory: ${MEMORY_LIMIT}
    restart: always
    hostname: ${DOMAIN_HOST}
    shm_size: '256m'
    ports:
      - ${HOST_IP}:${WEB_HTTP_PORT}:80
      - ${HOST_IP}:${WEB_HTTPS_PORT}:443
      - ${HOST_IP}:${WEB_SSH_PORT}:22
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://${DOMAIN_HOST}'
        # ⚠️ 强烈建议在此处补充这一行，解决 SSH 端口显示问题：
        gitlab_rails['gitlab_shell_ssh_port'] = ${WEB_SSH_PORT}
    volumes:
      - ${APP_PATH}/config:/etc/gitlab
      - ${APP_PATH}/logs:/var/log/gitlab
      - ${APP_PATH}/data:/var/opt/gitlab
    labels:
      createdBy: "bt_apps"
    networks:
      - baota_net

networks:
  baota_net:
    external: true

2. 部署过程中的"踩坑"与细节解读

为什么配置文件要这么写？这背后其实藏着几个极其关键的防坑技巧：

避坑 1：内存直接吃满，服务器卡死

$cite_start$ GitLab 启动后会有几十个后台进程。如果不做限制，它能榨干宿主机的最后一滴内存。在我们的配置中，直接通过 deploy.resources.limits 强制给它分配了 15360MB 的内存 $cite: 1$ $cite_start$ 和 6 核 CPU $cite: 1$ 。
划重点： 同时加上 shm_size: '256m'，防止共享内存不足导致 GitLab 的 Prometheus 等组件报错挂掉。
避坑 2：端口冲突与外网安全

$cite_start$ 你看我的端口映射是 ${HOST_IP}:${WEB_HTTP_PORT}:80，而在环境里 ${HOST_IP} 被设置成了 127.0.0.1 $cite: 1$ $cite_start$ 。这是为了安全！意味着 GitLab 的 10080 端口 $cite: 1$ $cite_start$ 只对服务器内部开放，外网根本无法直接通过 IP+端口访问。我们需要在宿主机上通过 Nginx（或者宝塔面板）做一个反向代理，把 git.gozuche.com $cite: 1$ 代理到本机的 10080 端口上，既安全又能加 SSL 证书。
避坑 3：克隆代码时 SSH 端口不对

$cite_start$ 宿主机的 22 端口通常用来远程登录，所以我们把 GitLab 的 SSH 暴露到了 10022 端口 $cite: 1$ 。但是，如果不告诉 GitLab 这个变化，你在网页上点击"Clone"时，出来的链接还是默认的 22 端口。
解决办法： 一定要在 GITLAB_OMNIBUS_CONFIG 里加上 gitlab_rails['gitlab_shell_ssh_port'] = 10022，这样复制出来的 clone 命令才是对的。
避坑 4：网络隔离冲突

如果你在使用类似宝塔面板的环境，里面往往有自己的一套 Docker 网络（比如 baota_net）。在 compose 的底部通过 external: true 声明引入外部网络，可以让 GitLab 和面板上的其他服务（比如 Nginx 容器）处于同一个网段，方便反代。

总结：

用 Docker 部署应用，能用变量就用变量，能绑本地 IP 就别直接暴露给外网。配置弄好后，在目录下执行 docker-compose up -d，接下来就是泡杯茶，静等 3-5 分钟让它初始化完毕吧！