Preface

The story happened on a dark night with high winds. An unusual phone call came and said that the business was rushing to go online, but their API package could not be uploaded to the company’s maven private library. The leader asked me to support it and see how to solve it. . After years of unreliable intuition, the disk should be full. So he knocked down neatly

df -lh

Sure enough, the disk is full, and /var/lib/docker/overlay basically fills the disk. Then enter

docker system df

Check the disk size occupied by docker. When I was thinking about whether the application process was called O&M expansion to download the disk, or to manually clean the disk, the phone came back again and said that the problem was not found, can I quickly solve it. After answering the phone, I felt inexplicably irritable, so I typed the following command

docker system prune

This command can be used to clean up disks, delete closed containers, useless data volumes and networks, and dangling mirrors (that is, mirrors without tags). Then a phone call came back and said that gitlab could not be accessed. The answer I gave was that the disk was full and gitlab should have stopped. I waited to restart the gitlab container. Just when I was about to restart gitlab, I typed the command

docker ps -a

I want to get a gitlab container, and then I'm done, docker ps -a can't see any containers. Because the previous gitlab container was installed by the former architect, I didn’t know what form he installed at the time, so I reported this issue to the leader, and got the docker-compose.yml that started gitlab at the time through the leader. Examples are as follows

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=

After looking at the file, I saw that there was a file directory mounting, and then I went to the mounted file directory to see if the file was there. Fortunately, the files were there, so I felt relieved to type it.

docker-compose -f gitlab.yml up -d

Once this order was struck, the road of resumption kicked off in a magnificent way...

text

When I typed the command, I saw that the container started normally and I was about to continue cleaning the disk. Suddenly, WeChat received a message from several developers saying that they had logged in to gitlab, and they all showed that the user or password was invalid, so I also used mine. Account, my account is an administrator account, haha, I feel like I’m so arrogant. I typed in my familiar user name and password on the interface, and unexpectedly prompted my user name or password to be invalid. I felt a little flustered in my heart. Done a terrific event.

Things are a bit beyond my cognition. In my opinion, if there is a mount, there will be no data loss normally, so I ask a friend for emergency help, and talk to him later, is to use the backup data to restore first, if there is a backup if. Then I was in the directory where gitlab was mounted, and I saw the backups directory and the tar inside. Suddenly I felt like digging into the treasure, but the treasure is there. Where is the key to open the treasure? How do I restore the backup data? Come back. Because I don’t know about sameersbn, so I went to their github to find it. Their github link is as follows

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

Find the following introduction through their 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

Take a picture of a cat and draw a tiger, and type the following command

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

After about a song, I opened the gitlab login interface again, and with a sense of anxiety, I entered the username and password. I was pleasantly surprised to find that the login was successful. I looked at the warehouse and it was still there.

Summarize

, but in fact, I sum it up in just a few sentences, that is, 16180db05ae41b backup, backup, backup , the important thing is said three times, and secondly, I am doing some commands that may delete data or change data. Be careful, be careful , Be careful. Finally, if you encounter a problem, if Google and Baidu can’t find the answer, remember to find the answer on the official website or their github website, such as the sameersbn-gitlab link
https://github.com/sameersbn/docker-gitlab


linyb极客之路
355 声望193 粉丝