[팀 개발 문화 발전시키기] Git 및 Gitlab 서버 운영

Git을 관리해야겠다고 마음먹은 이유

Git은 강력한 분산 버전 형상 관리 시스템으로 사실상 de-facto라고 할 수 있다. 보통 git만 사용하지는 않고 클라우드 서비스와 함께 사용하여 협업을 진행한다. 우리 팀에서도 Gitlab 서비스를 사용하여 서로의 local git을 동기화시킨다.

그러나 팀 내 공식 Gitlab 서버를 자유롭게 이용하기에는 불편한 점도 있다. 팀원들에게 공유하기 전에 개인적으로 플레이그라운드 역할로 사용할 레포지토리도 필요하고, 잠시 집에 가기 전 임시로 커밋을 올려두고 집에서 내려받아 작업을 이어나가기도 한다. 이런 브랜치의 활동 기록까지 팀원들 사이에서 모두 공유된다면 약간은 피곤할 것이다. 이것은 곧 개인별로 자유롭게 사용 가능한 git 클라우드 서버가 있었다면 좋겠다는 생각으로 이어졌다.

개선한 내용

우선 가장 쉽게 시도해볼 수 있었던 것은 git에서 기본적으로 제공하는 Git Web 기능을 사용하는 것이었고, 몇 가지 아쉬운 점 때문에 Gitlab 환경을 구성하는 것으로 넘어갔다.

Git Web 사용해보기

<Pro Git 2/E>를 앞에라도 읽어본 것이 이렇게 도움이 될 줄 몰랐다. 초반부에 git 레포지토리를 시각적으로 보여주는 방법이 있었던 것이 떠올라서 책을 다시 펴고 적용해보았다. 다음 링크의 내용과 동일하기 때문에 자세한 과정은 패스한다.

그런데 아주 기초적인 기능만 제공하다보니 좀 더 개선된 툴을 이용해야 할 필요를 느꼈다. 첫째로 Git Web URL을 직접 git remote URL로 사용할 수 없었다. ssh 방식으로만 요청과 응답을 주고받다 보니 pull이나 push 과정에서 매번 git 계정에 대해 2FA 인증 과정을 거쳐야 해서 불편했다. (현재 개발서버는 Google OTP를 이용한 2FA 인증을 거치도록 강제하고 있다.) 그리고 시각화도 매우 기초적인 수준이어서 커밋 히스토리나 diff 내용 등을 보는 데 부족한 점이 많았다. 이것이 실제 상용 수준의 기능을 제공하는 Gitlab 사용으로 넘어가는 계기가 되었다.

Gitlab 사용해보기

Gitlab은 우리 팀에서 사용하고 있는 git 레포지토리이기도 하면서, 공식적으로 도커 이미지를 오픈 소스로 제공하고 있기 때문에 가장 친숙하게 고를 수 있는 옵션이었다. 도커 이미지는 크게 gitlab-ee, gitlab-ce가 존재한다. 그 중 gitlab-ee를 선택하여 설치하였다. 과금을 할 계획이 당장은 없었지만 설치해도 문제가 될 것이 없기 때문에 선택하지 않을 이유도 없었다.

enterprise edition in public docker-hub?

돈을 내고 사용해야 하는 엔터프라이즈를 위한 서비스가 도커 이미지로 오픈되어 있는 것이 이상하다고 생각할 수도 있다. ee를 설치하면 돈을 내기 전까지는 ce 기능만 사용할 수 있다. 그 대신 실제 payment를 통해 ee로 넘어갈 때 마이그레이션을 쉽게 할 수 있다. 즉, 써보고 괜찮으면 과금을 해서 ee로 넘어오라는 뜻이다.

Gitlab 도커 컨테이너로 실행하기

$ sudo docker run -d -p $GITLAB_HTTP_PORT:80 -p $GITLAB_SSH_PORT:22 --name gitlab --restart always --shm-size 256m --volume $GITLAB_HOME/config:/etc/gitlab --volume $GITLAB_HOME/logs:/var/log/gitlab --volume $GITLAB_HOME/data:/var/opt/gitlab gitlab/gitlab-ee:latest

1. volume mount 기능을 이용해서 도커 컨테이너가 꺼지는 상황에도 데이터를 잃어버리지 않도록 한다.
2. HTTP_PORT, SSH_PORT를 호스트 머신에 포트포워딩으로 공개하여 외부에서도 접속 가능하도록 한다.
3. 지금 다시 보면 아쉬운 부분인데, gitlab/gitlab-ee:latest 이미지를 사용하여 실행하였다. latest 버전을 지정하면 나중에 볼 때 어떤 버전인지 확인하기 쉽지 않기 때문에 버전을 명확하게 지정하는 것이 좋겠다. 지금 다시 확인해보면 gitlab/gitlab-ee:15.5.3-ee.0 버전이다.

Gitlab 기본 설정하기

처음에 컨테이너 안에서 이것저것 설정하느라 starting 상태에서 healthy 상태가 되는데 약 5분 정도 걸렸다. healthy 상태가 되면 root 계정으로 로그인할 수 있다.

root 계정의 비밀번호를 확인하기 위해서는 다음 명령어로 내부에 있는 파일을 읽어서 할 수 있다.

$ sudo docker exec -it gitlab cat /etc/gitlab/initial_root_password

당연히 로그인을 하고 비밀번호 변경이 필요하고, 24시간이 지나면 initial_root_password 파일은 삭제된다고 하기 때문에 바로 세팅을 시작해야 한다.

root 계정으로 로그인한 뒤에는 팀원들을 사용자로 추가해주는 작업을 했다. ADMIN 패널에서 New user 버튼을 눌러 계정을 생성할 수 있다. 이 때, 비밀번호는 설정할 수 없지만 무시하고 생성을 완료한 뒤 Edit user를 하면 비밀번호를 지정할 수 있어서 초기 비밀번호를 같이 팀원들에게 전달할 수 있었다.

Gitlab으로 기존 레포지토리 이전하기

Git Web으로 서빙하는 레포지토리가 열몇 개 있었다. 프로토타입을 만들며 좌초되었던 프로젝트의 잔해 코드도 있고 간단한 스크립트 파일을 보관하는 레포지토리도 있었다. 이를 Gitlab으로 옮기는 과정이었다.

Group 만들기

당연히 group 없이 모든 레포지토리를 최상단 namespace에 올리는 것도 가능하다. 몇 개의 레포지토리는 이름이 client, server 이렇기 때문에 이름 수정은 필요하겠지만 말이다. 그러나 보기 좋게 관리하려면 group을 나누는 것이 무조건 좋다. 일상적으로 마주하는 컴퓨터의 파일시스템 디렉토리 구조도 그러하고, 슬랙에서 스레드를 나누는 것도 그러하다. 사람은 관련된 주제로 묶어서 정보를 관리할 때 보기에도, 기억하기에도 좋다.

다행히도 이전해야 할 모든 레포지토리를 파일시스템 디렉토리를 이용하여 주제별로 나눠 관리하고 있었다. 해야 할 일은 단순히 디렉토리 이름에 따라 group을 생성하기만 하면 끝이었다. 우측 상단에서 + 모양의 버튼을 누르고 New group 버튼을 눌러 그룹을 생성할 수 있다. Access control까지 고려해야 할 프로젝트도 딱히 없었기 때문에 Group을 만들고 나서 Group Information > Members 탭에 들어와 모든 사원이 접근 가능하도록 추가하였다.

Git 레포지토리 이전하기

마지막으로 만들어진 Group 안에 새로운 Project를 만들고 git 레포지토리를 옮겨 이전을 마무리하였다. 우선 Group 페이지 안에서 Create new project > Create blank project 를 통해 빈 Project를 하나 생성한다. 그리고 로컬에서 다음과 같이 실행한다. 빈 Project를 만들었을 때 README에 나오는 내용과 동일하다.

$ cd existing_repo
$ git remote add origin $GITLAB_REPO_URL
$ git branch -M main
$ git push -uf origin main

위를 풀어서 설명하면, git remote 저장소로 새로 만든 Project의 URL을 등록한 후, 현재 브랜치의 이름을 main 으로 바꿔 remote 저장소의 main 브랜치로 푸시하는 것이다. 이 때, remote 저장소의 main 브랜치에는 README 파일이 생성되면서 initial commit이 하나 들어가있는데, 이 commit을 동일한 히스토리로 공유하지 않으므로 -f 옵션을 통해 강제로 푸시해야 한다. -u 옵션은 로컬의 main 브랜치와 remote의 main 브랜치가 서로를 트래킹하도록 설정한다는 upstream 의 의미이다. 이를 한 번 설정해놓으면 이 다음부터 git push, git pull 등을 main 브랜치에서 실행하면 remote의 브랜치를 굳이 타이핑하지 않아도 자동으로 지정된다.

다만 이 때 git branch -M main 명령어는 main 이 아닌 브랜치에서 main 브랜치가 있을 경우 실행하면 기존 main 브랜치의 내용을 모두 덮어쓰기 해버리므로 안전하게 -m 옵션을 사용하는 것이 더 나아보인다.

이를 각각의 git 레포지토리들에 대해 반복하여 세팅을 완료하였다.

회고

Gitlab을 직접 세팅하고 여러 기능들을 만져보다 보니 모르고 있었던 기능들도 여러가지 발견할 수 있었다. 특히 개인별로 각자의 namespace가 있어서 거기서 자유롭게 레포지토리를 만들고 실험할 수 있다는 것을 알게 되었다. 이는 지금까지 한 작업을 무의미하게 만드는 부분이기도 했지만 동시에 이 작업을 통해 Gitlab에 대한 이해도가 높아졌기 때문일테니 얻은 게 없지는 않다. 또한, admin 권한으로 여러 작업을 해 보는 것은 이렇게 직접 세팅해보지 않고서는 사내 Gitlab 서버로는 불가능했을 것이다.

따라서 이왕 세팅한 김에 계속해서 사용해보기로 했다. 공식 업무와 관련된 내용들은 사내 Gitlab 서버를 이용해야겠지만 개인적인 incubator의 역할로 사용해 볼 예정이다. 운영하면서만 알 수 있는 부분들도 새롭게 발견할 수 있지 않을까 하는 기대감에서이다.