1

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

 2 years ago
source link: https://segmentfault.com/a/1190000040899661
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

故事发生在一个夜黑风高的晚上,一通看着不怎么寻常的电话过来,说是业务赶着上线,但他们的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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK