데이터 레지던시 대응 GitLab 클라우드 마이그레이션

동기

데이터가 국내에 있어야 한다는 요건이 있었습니다. 형상관리 시스템의 데이터가 국내에 놓이려면 자체 설치형을 국내 리전에 세워야 하고, 그래서 옮기는 일이 됐습니다.

내가 담당한 트랙

인프라 구성과 전환이 제 쪽이었습니다. 항목별 내역은 오른쪽 「주요 업무」에 있습니다.

저장소를 그대로 옮기기

GitLab 이 제공하는 백업 유틸리티로 원본을 뜨고 새 인스턴스에 복원했습니다. 두 인스턴스의 GitLab 버전을 같게 맞춘 뒤에 했습니다. 복원이 같은 버전을 전제하기 때문입니다.

이 길은 원본 인스턴스를 직접 관리할 수 있을 때만 열립니다. 그럴 수 없으면 그룹과 프로젝트를 하나씩 옮기는 방식으로 가야 하는데, 그쪽에는 따라오지 않는 것들이 있습니다. GitLab 문서가 빠지는 항목을 따로 적어 두고 있습니다 — CI 잡 로그와 아티팩트, CI 변수, 컨테이너 레지스트리 이미지, 패키지 레지스트리, 웹훅, 배포 키와 토큰, 머지 리퀘스트 승인 규칙 같은 것들입니다. 인스턴스를 통째로 복원하는 쪽은 이 목록을 볼 일이 없습니다.

전환하는 순간

백업을 뜬 뒤에 옛 인스턴스로 들어간 커밋은 새 쪽에 없습니다. 그래서 어느 시점부터는 옛 곳에 쓰지 말아야 하는데, 여기서는 그 경계가 위험하지 않았습니다.

Git 은 이력을 개발자 각자의 로컬에도 그대로 들고 있고, 저장소를 손대지 않고 그대로 옮겼습니다. 그러니 사람들이 할 일은 리모트 주소를 새 곳으로 바꾸는 것뿐이었고, 잘못 올라간 커밋이 있어도 로컬에서 다시 밀면 됩니다. 별도 장치 없이 안내로 처리했습니다.

배운 점

• 인포그랩에 들어와 처음 맡은 고객사 프로젝트였습니다. 규모나 난도와 별개로 그래서 기억에 남습니다.