尧图网站建设 免费方案咨询
ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

首页/资讯中心/资讯详情

docker 部署gitlab11.8.0

发布时间：2026/10/24 1:39:53 尧图网站建设
docker 部署gitlab11.8.0

获取镜像

docker pull gitlab/gitlab-ce:11.8.0-ce.0

启动容器

使用如下脚本

#!/bin/bash mkdir -p gitlab/etc mkdir -p gitlab/log mkdir -p gitlab/data docker run \ -d \ -p 8443:443 \ -p 80:80 \ -p 8022:22 \ --restart always \ --name gitlab \ -v $PWD/gitlab/etc:/etc/gitlab \ -v $PWD/gitlab/log:/var/log/gitlab \ -v $PWD/gitlab/data:/var/opt/gitlab \ --privileged=true \ gitlab/gitlab-ce:11.8.0-ce.0

安全停止容器

使用如下脚本

===== 停止docker容器（超时180秒） ===== gitlab GitLab 已安全停机 root@jason-virtual-machine:/opt/git-11.8.0# cat stop.sh #!/bin/bash set -e echo "===== 开始优雅停止GitLab内部服务 =====" # 容器内优雅关闭所有omnibus组件 docker exec gitlab gitlab-ctl stop echo "等待120s让PostgreSQL、Prometheus、Gitaly刷盘收尾..." sleep 120 echo "===== 停止docker容器（超时180秒） =====" docker stop -t 180 gitlab echo "GitLab 已安全停机"

修改配置

vim gitlab/etc/gitlab.rb # 配置http协议所使用的访问地址,不加端口号默认为80 external_url 'http://10.0.1.181' #配置ssh协议所使用的访问地址 gitlab_rails['gitlab_ssh_host'] = '10.0.1.181' #配置ssh协议所使用的访问端口，此端口是run时22端口映射的8022端口 gitlab_rails['gitlab_shell_ssh_port'] = 8022 :wq #保存配置文件并退出 # 重启gitlab容器 docker restart gitlab

修改root登录密码

# 进入容器内部 docker exec -it gitlab /bin/bash # 进入控制台 gitlab-rails console -e production # 查询id为1的用户，id为1的用户是超级管理员 user = User.where(id:1).first # 修改密码为12345678 user.password='12345678' # 保存 user.save! # 退出 exit;

也可以 用 下面 命令直接查找 root 初始化密码 然后在页面手动修改

docker exec -it gitlab grep "Password:’ /etc/gitlab/initial_root_password"

登录web直接输入： 10.0.1.181即可，因为默认端口80被映射出来了。用户名 root ，密码 12345678，首次登陆提示修改密码，按照提示修改即可。

如果使用默认端口如果启动不了可以按照如下方式尝试

如果无法创建项目：进入到容器后执行 chmod 777 /tmp -R

如果无法ssh方式克隆：进入到容器后执行 mkdir /var/run/sshd

参考配置：

external_url 'http://git.abc.com'
gitlab_rails['gitlab_ssh_host'] = 'git.abc.com'
gitlab_rails['gitlab_shell_ssh_port'] = 22 # 此端口是run时22端口映射的222端口

常用操作

  1. 如果远程仓库地址发生改变需要修改本地仓库对应远程仓库的url时可以使用如下命令：git remote set-url origin <新的仓库URL>
  2. 备份：默认目录为/var/opt/gitlab/backups，自定义备份目录需要赋予目录git权限。
    1. 自定义目录的配置文件修改 /etc/gitlab/gitlab.rb
      1. gitlab_rails['manage_backup_path'] = true
      2. gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
    2. 手动备份
      1. 使用命令：gitlab-rake gitlab:backup:create
  3. 恢复备份：
    1. 首先把需要恢复的备份放到默认备份目录下
    2. 其次停止相关服务
      1. gitlab-ctl stop unicorn
      2. gitlab-ctl stop sideki
    3. 最后恢复：gitlab-rake gitlab:backup:restore
  4. 修改配置重新加载命令：gitlab-ctl reconfigure
  5. 扩展：定时操作（比如备份）
    1. 使用命令：crontab
      1. crontab -e 0 3 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1
      2. 说明
        1. 上述时间格式为：分时日月周 m： 表示分钟，可以是从0到59之间的任何整数。 h：表示小时，可以是从0到23之间的任何整数。 dom：表示日期，可以是从1到31之间的任何整数。 mon：表示月份，可以是从1到12之间的任何整数。 dow：表示星期几，可以是从0到7之间的任何整数，这里的0或7代表星期日。 user : 表示执行的用户。 command：要执行的命令，可以是系统命令，也可以是自己编写的脚本文件。

相关问题解决方案

1.找回root密码

gitlab-rails console user = User.where(id: 1).first user.password = '密码' user.password_confirmation = '密码' user.save!

理论上需要重启服务，实际不用重启也生效。

2.客户端克隆失败

2.1 已经添加公钥到gitlab并且失败

执行如下2个命令就可以解决：

eval "$(ssh-agent -s)" ssh-add

说明：

ssh-agent是一种控制用来保存公钥身份验证所使用的私钥的程序,ssh-agent是个长时间持续运行的守护进程（daemon），设计它的唯一目的就是对解密的专用密钥进行高速缓存，ssh-agent启动时高速缓存当然是空的，里面不会有解密的专用密钥,在我们真能使用ssh-agent之前，首先还需要使用ssh-add命令把我们的专用密钥添加到ssh-agent的高速缓存中（ssh-add (私钥地址)），如果不加默认地址是~/.ssh/id_rsa

3.太耗费内存资源（技巧）

# 关闭prometheus，不再产生TSDB prometheus['enable'] = false alertmanager['enable'] = false grafana['enable'] = false # 还可以额外关掉不需要组件进一步省内存 promtail['enable'] = false 先一句话总结：**TSDB 只存监控指标，关掉它不会影响代码提交、仓库、CI、用户登录、Issue、Wiki 这些核心业务；代价是丢掉 GitLab 自带全套监控告警能力**，下面分点讲清楚，结合你 11.8.0 老版本说明： ## 直接失去的能力 1. **GitLab 自带监控面板（Metrics 仪表盘）全部失效** GitLab 界面里【管理中心 → 监控】页面，原本可以看： - GitLab 整体 QPS、HTTP 响应耗时 - PostgreSQL 数据库慢查询、连接数、数据库负载 - Redis 命令延迟、命中率 - Gitaly（git 服务）的 push/clone 请求耗时、并发数 - Sidekiq 后台任务队列堆积、任务执行时长 关掉 prometheus 之后，这些图表空白、无数据，看不到负载。 2. **内置告警功能（Alertmanager）失效** 原本可以配置告警：CPU 过高、数据库连接打满、Sidekiq 任务堆积、Gitaly 超时、磁盘快满自动发通知（邮件 /webhook）。 关闭后，**GitLab 自身不会主动报警**，负载异常、数据库慢、仓库服务卡住你只能自己看日志发现。 3. **GitLab 自带自动性能诊断没了** 当 Gitaly、PostgreSQL 卡顿的时候，GitLab 原生会采集指标辅助定位问题（比如你之前遇到的 `DeadlineExceeded` 超时）。 > > 以后再出现 Gitaly 超时、页面卡顿、push 慢，**没有指标曲线辅助排查，只能硬啃日志，定位问题难度上升**。 ## 隐性影响（11.8.0 版本重点） 1. **GitLab 健康检查还会尝试采集指标（只是采集失败）** 版本 11.8 比较老，部分内部组件依然会尝试拉取 metrics 接口，只是不会再持久化存入 TSDB；一般不会阻断业务，但日志里偶尔会出现 metrics 拉取失败的 warning，不影响使用。 2. **CI 流水线的 job 性能指标看不到** 流水线 job 的执行耗时、Runner 负载、并发数量的监控图表消失，没法直观看到 Runner 是不是过载。 ## 🟢 带来的收益（对比弊端，帮你权衡） ✅ **内存节省明显**：Prometheus+Alertmanager 常驻一般占 300~700MB 内存，你只有 1G/2G 小机器时，这是救命的资源； ✅ **彻底根除 TSDB 损坏报错**，不会再因为断电、强制停机出现 `unexpected end of JSON input` 导致 GitLab 起不来； ✅ 减少磁盘 IO 压力：Prometheus 持续写入时序数据，频繁写盘，弱机械盘环境下 IO 压力下降，Gitaly、PostgreSQL 会更稳。 ## 🧾 两种方案对比，给你选 ### 方案 A：关闭 Prometheus（适合你当前低内存机器，推荐） 适用场景：**内网自用、小团队、不做性能监控，能接受出问题看日志排查** - 优点：省内存、不再 TSDB 损坏，GitLab 稳定性大幅提升 - 缺点：没有自带监控面板、告警、性能曲线 ### 方案 B：保留 Prometheus（适合 4G 以上内存、需要监控） - 优点：全套监控告警，方便提前发现负载异常 - 缺点：吃内存、吃 IO，非正常关机极易 TSDB 损坏，必须严格使用优雅停机脚本
网站建设 视觉设计 SEO优化
返回列表