Git Lab 이전

아이디어

나같은 경우는 아래와 같은 상황이었다.
내 자리에서 putty를 이용해 서버 A에 SSH를 사용하여 접속해서 서버 A에 저장 된 git-lab 데이터들을 압축하여 컨테이너에서 뺀 다음,
해당 파일을 서버 A에서 서버 B를 ssh로 접속하여 호스트에 저장된 데이터를 컨테이너로 넣어주는 작업 후,
서버 B에서 압축된 파일을 컨테이너 내부에 넣어서 컨테이너를 실행해주면 됐다.

준비물

1. putty
2. 백업 대상 서비스와 같은 버전의 복원 대상 서버의 gitlab 이미지
   안그러면 아래 사진과 같은 불상사를 직접 맞이할 수 있다.
   

참고

1. 마운트를 완료한 상태에서, 데이터 restore 전, 순정상태의 gitlab을 한번 기동하여 동작을 확인한다.
2. gitlab 쉘을 통해 복원 명령 수행시 확인 입력을 받는 경우(데이터 삭제시)가 있으므로 가급적으로 컨테이너에 직접 접근하여 명령을 수행한다.

1. Git-Lab Back-up

우선 가장 중요한 Back-up 파일 만들기 이다.

컨테이너 내부로 들어가기

sudo docker exec -it <컨테이너명> /bin/bash

컨테이너 내부에 백업 파일 생성하기

gitlab 버전 12.2 이상

gitlab-backup create

gitlab 버전 12.1 이하

gitlab-rake gitlab:backup:create

(옵션) 설정 및 암호키 백업

백업 명령으로 생성되는 백업파일에는 설정정보나 CI/CD 시크릿 변수, 2차인증 정보 등과 관련한 정보들은 자동으로 저장되지 않는다고 한다.
(보안상의 이유로 자동으로 백업을 생성하는 것이 구조적으로 문제가 있어서 그렇다고 한다.)

본인은 pull push도 http 방식으로 진행었고, CI/CD 관련 설정한 것이나 2차인증등은 구현하지 않았었기 때문에 별도로 백업을 하지 않아도 이후 복원시 전혀 문제가 없었지만, 관련하여 백업이 필요한 경우에는 별도 백업 이후 복원작업 진행시 다시 정상 경로에 파일들을 위치시키고 복원을 진행해야 한다고 한다. 파일들의 위치는 다음과 같다.

/etc/gitlab/gitlab-secrets.json
/etc/gitlab/gitlab.rb

• 11.11.8ce 버전을 기준으로 컨테이너 내부에 해당 위치에 백업 파일들이 존재 했으나, 공식 문서에는 /srv/gitlab/config 경로로 표기되어 있으니 참고할것.

백업파일 확인

기본설정으로 세팅되어 있다면, /var/opt/gitlab/backups 경로에 타임스템프값_버전_gitlab_backup.tar 와 같은 형태로 백업파일이 생성된다.

백업 파일을 받아둘 외장하드 마운트하기

mount -t vfat /dev/sdc1 /tmp/usb
umount /tmp/usb

/dev/sdc1 을 /tmp/usb 에

2. 컨테이너에서 백업파일 빼오기

이제 컨테이너에 저장되어있는 tar 백업 파일을 local로 가져와서 scp 명령어로 파일 이동 해보자.

Docker 컨테이너에서 파일 가져오기

도커 컨테이너에 있는 파일을 호스트로 가져오려면

docker cp <컨테이너 이름>:<컨테이너 내부 파일 경로> <복사할 파일 경로> 

만일 도커 컨테이너의 test.txt 파일을 호스트의 경로인 /test 으로 복사를 원한다면, 다음과 같이 사용한다.

docker cp alpine-container:/test.txt /test/

• 참고로 디렉토리도 별다른 옵션없이 복사가 가능하다.

컨테이너 종료 없이 나가기

Ctrl + P + Q

3. SCP(Secure Copy Protocol) 를 사용하여 서버 A 에서 서버 B 로 백업파일 전송하기

명령행 유틸리티를 이용해 사용자는 주로 유닉스(unix)나 리눅스(linux) 두 위치 사이에서 파일이나 디렉터리를 안전하게 복사할 수 있다.

이 프로토콜은 악의를 가진 어떤 이의 민감성 정보 취득을 방지하기 위해 파일 전송의 암호화를 보장한다.

SCP 문법
터미널에서 쓰이는 다른 명령어처럼, SCP도 성공적으로 실행되기 위한 일종의 형식이 있습니다. 이 문법을 이해하면 더 쉽게 명령어를 작성할 수 있게 됩니다.

scp [OPTIONS] [[user@]src_host:]fil1 [[user@]dest_host:]file2

scp - 명령을 초기화하고 SSH 이 준비되도록 한다.

OPTIONS
P(대문자) - 원격 호스트와 연결하기 위해 포트를 특정
p(소문자) - 수정과 열람의 편의성을 위해 타임 스탬프를 보존
r - 디렉터리 전체를 재귀적으로 복사
q - 진행 메시지를 표시하지 않고 조용히 파일을 복사
C - 전송 중 데이터 압축을 위한 옵션

src_host - 파일이 호스트 되는 곳. 소스(source)는 파일의 위치에 따라 클라이언트나 서버 중 하나가 될 수 있다.
dest_host - 파일이 복사되어 가는 곳.

• 이때 중요한 점은 SSH 를 통해 클라이언트와 서버 컴퓨터에 모두 Root 권한 접근이 가능해야 한다.

예시

일반적인 파일 전송~ scp (전송할 파일) (아이디@전송할 서버주소):(저장될 서버의 디렉토리)

scp /home/local/a.txt remote@myserver.com:/home/remote

ssh 포트 번호가 22번(기본)이 아닌경우~ scp -P 포트번호 (전송할 파일) (전송할 서버주소@아이디):(저장될 서버의 디렉토리)

scp -P 9999 /home/local/a.txt remote@myserver.com:/home/remote

디렉토리를 전송~ scp -P 포트번호 -r (전송할 디렉토리) (전송할 서버주소@아이디):(저장될 서버의 디렉토리)

scp -P 9999 -r /home/local remote@myserver.com:/home/remote

4. 서버 B 에서 서버 A 와 같은 버전으로 image pull 및 컨테이너 생성 후 암호까지 확인하여 버전 확인하기

앞서 작성한 포스팅으로 대체

앞서 언급했듯 복원 수행하기 전에 마운트를 완료한 상태에서, 순정상태의 gitlab을 한번 기동하여 동작을 확인해야 한다.
특히 복원을 수행할 때는 gitlab 쉘에서 사용자 입력을 요구하는 경우가 있으니 컨테이너에 쉘 접근을 수행한 후에 명령들을 수행하는 것을 권장한다.

5. 서버 B 에서 컨테이너 내부로 Back-up 파일 이동하기

scp 명령어로 파일을 가져왔다면 아래 명령줄로 백업파일을 다시 컨테이너 내부에 넣어줘야한다.

Docker 컨테이너로 파일 복사하기

호스트에 있는 파일을 도커 컨테이너의 특정 경로로 복사하는 명령어는 다음과 같다.

docker cp <복사할 파일 경로> <컨테이너 이름>:<컨테이너 내부 파일 경로>

만일 호스트에 있는 test.txt 파일을 컨테이너의 /test 경로로 복사한다면, 다음과 같이 사용한다.

docker cp test.txt alpine-container:/test

• 참고로 디렉토리를 복사하는 경우도 위 명령어로 별다른 옵션없이 복사가 가능하다

6. 서버 B 깃랩 도커 내부에서 Back-up 파일 restore 하기

복구도 역시 마찬가지로 컨테이너 내부에서

컨테이너 들어가기

docker exec -it <컨테이너명> /bin/bash

백업파일 위치 확인 및 파일 존재 유무 확인

컨테이너 내부에 백업시 파일이 기본으로 생성되었던 것과 같은 경로( /var/opt/gitlab/backups )에 파일이 잘 있는지 확인한다.

복원 명령 수행

복원 명령 수행시 BACKUP변수에 명시해주는 백업대상 은 복원 대상이 되는 파일명을 기준으로 작성된다.
예를들어 12_2021_03_12_11.11.8_gitlab_backup.tar 이 파일 이름이라면
_gitlab_backup.tar 의 앞부분까지의 문자열인
12_2021_03_12_11.11.8 까지를 입력해주면 된다.

gitlab 버전 12.2 이상

gitlab-backup restore BACKUP=백업대상지정

# 예시
gitlab-backup restore BACKUP=12_2021_03_12_11.11.8

gitlab 버전 12.1 이하

gitlab-rake gitlab:backup:restore BACKUP=백업대상지정 

# 예시
gitlab-rake gitlab:backup:restore BACKUP=12_2021_03_12_11.11.8

(옵션) 설정 및 암호키 배치

/etc/gitlab/gitlab-secrets.json
/etc/gitlab/gitlab.rb

위에서 별도 저장해 두었던 파일들을 본래 경로에 위치시킨다. (다른 경로에서 백업을 수행했다면, 해당 경로에 위치시키면 된다.)

(옵션) 데이터베이스 연결 프로세스 종료

데이터베이스와 연결되는 프로세스들을 정지하고, 잘 정지되었는지 확인한다.
다음 중간에 데이터베이스 초기화가 필요하거나 ~~경우 다음과 같이 사용자의 입력을 요구한다. 적절하게 대답하면 된다.

Before restoring the database, we will remove all existing
tables to avoid future upgrade problems. Be aware that if you have
custom tables in the GitLab database these tables and all data will be
removed.
 
Do you want to continue (yes/no)? yes
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes

작업이 완료된 이후 컨테이너를 재시작 해주면 적용이 완료 된다.

(옵션) 복원 후 설정 리빌드

컨테이너는 복원 완료 이후 기본적으로 reconfigure 과정이 수행되지만, 커스텀 이미지를 사용하거나 기타 다른 이유로 인해 컨테이너 내에서 수동으로 작업해 주어야 하는 경우, 아래와 같은 과정을 통해 설정 리빌드 후 gitlab 서비스 재시작 프로세스를 수행해 주어야 한다.

gitlab-ctl reconfigure
gitlab-ctl restart

• 리빌드 수행시 redis 체크 과정에서 진행이 되지 않을 경우
  컨테이너의 엔트리포인트 오버라이딩을 통해 임의의 프로세스(sleep infinify) 와 같은 형태로 컨테이너를 강제 기동시키고 쉘에서 작업을 수행하는 경우, 기본적으로 기동되고 있어야 하는 gitlab 연관 프로세스들(redis, postgres ..)들이 대기중이지 않기 때문에 서비스들을 1차적으로 기동해주고 리빌드 작업을 수행해야 한다.

/opt/gitlab/embedded/bin/runsvdir-start &

위 명령을 수행하여 runit 서비스들을 띄워주고 리빌드를 수행하면 정상적으로 동작한다. (명령 수행 이후 에러가 발생해도 그냥 진행하면 된다.)

• 컨테이터 자체를 백업하고 복구하기

sudo docker exec -t <컨테이너 이름> gitlab-backup create
sydo docker exec -it gitlab gitlab-backup restore

7. 복구 확인 및 버전 확인

컨테이너가 올라온 곳 뒤에 /help 를 치면 버전을 확인할 수 있다.

reference

scp reference => https://ghostweb.tistory.com/1185
https://www.freecodecamp.org/korean/news/scp-rinugseu-myeongryeong-weongyeogeseo-rokeolro-ssh-paileul-jeonsonghaneun-bangbeob/

ssh reference => https://wiseworld.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4-SSH-%EC%84%A4%EC%A0%95-%EB%B0%8F-%EC%82%AC%EC%9A%A9%EB%B0%A9%EB%B2%95-%EC%9B%90%EA%B2%A9%EC%A0%91%EC%86%8D

docker => https://tear94fall.tistory.com/9

gitlab container => https://ykarma1996.tistory.com/111