关于gitlab:记一次gitlab代码仓清空还原复盘

10次阅读

共计 2700 个字符，预计需要花费 7 分钟才能阅读完成。

故事产生在一个夜黑风高的早晨，一通看着不怎么寻常的电话过去，说是业务赶着上线，但他们的 API 包上传不了到公司的 maven 私库，领导叫我撑持下看怎么解决。通过多年不怎么靠谱的直觉，应该是磁盘满了。于是利索地敲下

df -lh

果然磁盘满了，其中 /var/lib/docker/overlay 这个玩意儿基本上把磁盘占满。接着输出

docker system df

查看 docker 所占的磁盘大小。在思考是申请流程单叫运维扩容下磁盘，还是手动清理下磁盘的时候，电话再次过去，说找到问题没，能不能连忙解决。接完电话后，情绪莫名焦躁，于是敲下了如下命令

docker system prune

这个命令能够用于清理磁盘，删除敞开的容器、无用的数据卷和网络，以及 dangling 镜像(即无 tag 的镜像)。接着一通电话又过去，说 gitlab 拜访不了，我过后给的答案是磁盘满了，gitlab 应该是进行了，我稍等重启下 gitlab 容器，就在我打算重启 gitlab 时，敲下命令

docker ps -a

想捞一下 gitlab 容器，而后完犊子了，docker ps -a 看不到任何容器。因为之前 gitlab 的容器是前架构师装置，我压根就不分明他过后是以什么模式装置，于是就把这个问题反馈给领导，通过领导拿到过后启动 gitlab 的 docker-compose.yml. 样例如下

version: '2'

services:
  redis:
    restart: always
    container_name: gitlab_redis
    image: sameersbn/redis:latest
    command:
    - --loglevel warning
    volumes:
    - /usr/local/docker/gitlab/redis:/var/lib/redis:Z
    network_mode: bridge

  postgresql:
    restart: always
    container_name: gitlab_postgresql
    image: sameersbn/postgresql:9.6-2
    volumes:
    - /usr/local/docker/gitlab/postgresql:/var/lib/postgresql:Z
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm
    network_mode: bridge

  gitlab:
    restart: always
    container_name: gitlab
    image: sameersbn/gitlab:10.4.2-1
    links:
    - redis
    - postgresql
    network_mode: bridge
    ports:
    - "10080:80"
    - "10022:22"
    volumes:
    - /usr/local/docker/gitlab/gitlab:/home/git/data:Z
    environment:
    - DEBUG=false

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=Asia/Shanghai
    - GITLAB_TIMEZONE=Beijing

    - GITLAB_HTTPS=false
    - SSL_SELF_SIGNED=false

    - GITLAB_HOST=gitlab.common.com
    - GITLAB_PORT=
    - GITLAB_SSH_PORT=10022
    - GITLAB_RELATIVE_URL_ROOT=

看了一下文件，我看到有做文件目录挂载，而后我就去挂载的文件目录下，看文件有没有在，还好文件都在，于是我就释怀敲下

docker-compose -f gitlab.yml up -d

这命令一敲下，复盘之路富丽的拉开了尾声 …

在我敲下命令，看到容器都显示失常启动，打算持续清理磁盘之时，忽然微信接到好几个开发人员的信息，说他们 gitlab 登陆，都显示用户或者明码有效，于是我也用我的账号，我的账号可是管理员账号，哈哈，一股王八之气，在界面上输出我那耳熟能详的用户名和明码，出其不意的提醒我的用户名或者明码有效，心里莫名有点慌，感觉我干了一件挺了不得的小事。

事件有点超出我的认知，在我看来如果有做了挂载，失常不会呈现数据失落才对，于是就找敌人救急，前面和他交换一下，就是先用备份数据还原，如果有备份的话。而后我在挂载 gitlab 的目录下，看到 backups 目录，看到外面的 tar，忽然有一种挖到宝藏的感觉，但宝藏有了，开宝藏的钥匙在哪里，我要如何把备份的数据恢复回来呢。因为我对 sameersbn 也不理解，于是就去他们的 github 找了下，他们的 github 链接如下

https://github.com/sameersbn/docker-gitlab

通过他们的 github 找到如下介绍

When using docker-compose you may use the following command to execute the restore.

docker-compose run --rm gitlab app:rake gitlab:backup:restore # List available backups
docker-compose run --rm gitlab app:rake gitlab:backup:restore BACKUP=1515629493_2020_12_06_13.10.0 # Choose to restore from 1515629493

照猫画虎，敲下如下命令

docker-compose -f gitlab.yml run --rm gitlab app:rake gitlab:backup:restore

大概过了一首歌的工夫，我再次关上 gitlab 登录界面，怀着忐忑的情绪，输出用户名明码，很惊喜的发现登录胜利了，看一下仓库，都还在

罗里吧嗦说了一堆，其实总结进去就几句话，就是 备份，备份，备份，重要的事件说三遍，其次在做一些可能删数据或者扭转数据的命令，要小心，小心，再小心。最初遇到问题，如果谷歌百度都找不到答案，记得去官方网站或者他们的 github 网站找找答案，比方 sameersbn-gitlab 链接
https://github.com/sameersbn/docker-gitlab

正文完