깃랩 서버 이전 (On-Premise → EC2)

main

date

Jan 20, 2026

slug

gitlab-server-migration

author

status

Public

1. EC2 초기 세팅 & Docker 설치

우선 EC2 인스턴스에 접속하여 필요한 패키지 파일을 다운로드 받자


sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release unzip

# 도커 설치
curl -fsSL https://get.docker.com | sudo sh

설치 후 Docker 상태를 확인했는데 바로 에러 발생.


# 도커 체크
docker version
## 초기 에러 발생
permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

Docker 그룹에 ubuntu 유저가 없어서 발생한 문제였다.


sudo usermod -aG docker ubuntu
# 이후 SSH 재접속

패키지 설치 항목 정리

ca-certificates → HTTPS 통신을 위한 SSL 인증서

(Docker 설치, GitLab Registry, Let’s Encrypt 등)

curl

curl -fsSL <https://get.docker.com> | sudo sh

Docker 설치
GitLab Runner 등록
Webhook 테스트

gnupg

Docker 공식 GPG 키 검증

APT repo 신뢰성 확인 (보안 핵심)

lsb-release

OS 정보 확인용

예: lsb_release -cs # jammy / focal / bookworm

Docker / GitLab 설치 시 OS에 맞는 repo 자동 선택

unzip → 압축 해제

GitLab Runner 바이너리

AWS CLI

각종 플러그인

2. GitLab 컨테이너 볼륨 구조 파악

GitLab 컨테이너의 핵심 데이터 위치부터 확인했다.


docker inspect gitlab | grep -A 30 Mounts


"Mounts": [
            {
                "Type": "bind",
                "Source": "/root/gitlab/config",
                "Destination": "/etc/gitlab",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/root/gitlab/logs",
                "Destination": "/var/log/gitlab",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/root/gitlab/data",
                "Destination": "/var/opt/gitlab",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],
        "Config": {
            "Hostname": "git.sample.com",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,

Source = 실제 서버에 있는 경로

Destination = 컨테이너 내부 경로

기존 서버 깃랩 경로 /root/gitlab/config → GitLab 설정 /root/gitlab/logs → GitLab 로그 /root/gitlab/data → 모든 Git 데이터 / DB / artifacts

정리하면 구조는 아래와 같다.

Host 경로	역할
`/root/gitlab/config`	GitLab 설정
`/root/gitlab/logs`	GitLab 로그
`/root/gitlab/data`	Git 데이터 / DB / CI / artifacts

즉 /var/opt/gitlab = 모든 핵심 데이터.

3. EC2에서 디렉토리 구성 & 권한 문제 시작

기존 서버와 EC2 서버 디렉토리 위치를 동일하게 구성


sudo mkdir -p /root/gitlab/{config,logs,data}

# 권한 부여
sudo chown -R root:root /root/gitlab

기존 서버와 동일한 구조를 만들려고 했지만 EC2는 root SSH 접속이 막혀 있어 문제가 발생했다. (permission denined )

결국 경로를 아래처럼 변경.


sudo mkdir -p /ubuntu/gitlab/{config,logs,data}
# 권한 부여
sudo chown -R ubuntu:ubuntu /ubuntu/gitlab

4. GitLab 데이터 rsync 복사


# docker-compose.yml Copy
rsync -avz -e "ssh -i /root/aws.pem" /root/gitlab-docker/ ubuntu@IP:/home/ubuntu/gitlab-docker/
# gitlab 데이터 파일 Copy
rsync -avz -e "ssh -i /root/aws.pem" /root/gitlab/ ubuntu@IP:/home/ubuntu/gitlab/

⚠️

EC2에 22번 포트가 열려있는지, .pem key 권한이 정상적인지 체크! 먼저 .pem 에 권한이 제대로 되어있지 않아 키를 못 읽는 문제 발생

> chmod 400 aws.pem

권한 변경 후에 키는 읽히지만 ssh 접속이 되지 않음 위에서 언급한대로 현재 깡통 EC2, 즉 보안 규칙에 아무 작업도 되어있지 않은 상태 기본적인 인바운드 규칙 설정 필요!!

여기까지 프로젝트 파일을 다 옮기고 도커를 실행시키면 도커가 실행되는 것 처럼 보여지지만 status는 unhealthy 상태 ㅎㅎ

5. 컨테이너 unhealthy 상태 & 접근 권한 없음 . . .


# 도커 상태 체크
docker logs -f gitlab
docker inspect gitlab --format='{{.State.Health.Status}}'

로그 확인 결과 permission denied 에러 발생으로 정상적으로 읽기 쓰기가 이루어지지 않는 상태

컨테이너 내부에서 GitLab 실행 유저 확인


docker exec -it gitlab bash

id git
# > uid=998(git) gid=998(git)

gitlab을 읽는 아이디는 998 식별값을 가지고 있다.

ubunut/gitlab 디렉토리의 경우 현재 권한은 ubuntu로 되어있기 때문에 접근 권한이 없어서 에러가 발생한다.


drwxr-xr-x 5 ubuntu ubuntu 4096 Jul 29  2024 gitlab

6. 서비스별 UID 맞추기

로그를 따라가며 서비스별 UID를 맞췄다.


sudo chown -R 998:998 /home/ubuntu/gitlab

sudo chmod -R 700 /home/ubuntu/gitlab
sudo chown -R 998:998 /home/ubuntu/gitlab/config/ssl
sudo chmod 600 /home/ubuntu/gitlab/config/ssl/*.pem
sudo chmod 600 /home/ubuntu/gitlab/config/ssl/*.crt

에러 토대로 각각 권한을 부여해도 좀 처럼 사라지지 않는 permission denined

계속 로그를 따라 권한을 변경해줬다.


# 호스트에서 데이터 디렉토리 전체 퍼미션 확인
ls -lR /home/ubuntu/gitlab

==> /var/log/gitlab/postgresql/current <==
2026-01-16_02:14:59.11849 PANIC:  could not open file "global/pg_control": Permission denied

# 아래와 같이 각각 권한 재조정 후
# PostgreSQL
sudo chown -R 996:998 /home/ubuntu/gitlab/data/postgresql

# Redis
sudo chown -R 997:998 /home/ubuntu/gitlab/data/redis
sudo chown -R 997:998 /home/ubuntu/gitlab/data/redis-exporter

# Prometheus
sudo chown -R 992:998 /home/ubuntu/gitlab/data/prometheus
sudo chown -R 992:998 /home/ubuntu/gitlab/logs/prometheus

# Nginx
sudo chown -R root:docker /home/ubuntu/gitlab/data/nginx
sudo chown -R root:docker /home/ubuntu/gitlab/logs/nginx

# GitLab Rails/Workhorse 등 일반 서비스
sudo chown -R 998:998 /home/ubuntu/gitlab/data/gitlab-*
sudo chown -R 998:998 /home/ubuntu/gitlab/logs/gitlab-*

원래 이렇게 하는건가…?? 의문이 들긴했지만 일단 로그에서 보이는대로 권한을 변경해줬다.

그리고 나서 리빌드 했을 경우 드디어 깃랩 사이트가 열림

그치만 로그인이 안된다ㅎㅎ


/var/log/gitlab/nginx/gitlab_error.log <==
2026/01/15 10:09:41 [crit] 559#0: *7 connect() to unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket failed (13: Permission denied) while connecting to upstream,

7. 깃랩 데이터베이스

지금까지 깃랩 데이터 파일을 rysnc로 파일 복사를 해줬다. 이 때 데이터베이스 파일은 복사가 안된다.

그렇기 때문에 기존 계정으로 로그인이 안되는 것

GitLab Cli에서는 백업 파일을 생성할 수 있는 명령어를 제공하고 있다. 마이그레이션 대상 서버로 들어가서 기존 백업 파일을 생성해준다.


docker exec -it gitlab gitlab-backup create

# 컨테이너 내부 경로를 따라 /var/opt/gitlab/backups에 생성되는데
## 아래와 같이 마운트를 해놨기 때문에 
volumes:
  - ./gitlab/data:/var/opt/gitlab
  
# /root/gitlab/data/backups/ 하위에 TIMESTAMP_gitlab_backup.tar 생성된다

gitlab/data/backups > 1768530941_2026_01_16_17.5.1_gitlab_backup.tar

1768530941_2026_01_16_17.5.1_gitlab_backup.tar 파일을 다시 EC2에 Copy 한다.


scp -i aws.pem /root/gitlab/data/backups/1768530941_2026_01_16_17.5.1_gitlab_backup.tar ubuntu@IP:/home/ubuntu/

백업 파일이 정상적으로 왔는지 체크


# tar 파일 이동 후 체크
ls -lh /home/ubuntu/1768530941_2026_01_16_17.5.1_gitlab_backup.tar

전달 받은 백업 파일을 깃랩 컨테이너 내부에서 리스토어 해줘야한다.


docker stop gitlab

docker exec -it gitlab gitlab-backup restore BACKUP=1768530941_2026_01_16_17.5.1_gitlab_backup

위 명령어를 쳤을 경우 경로를 못찾는 에러가 발생하였다.

그래서 컨테이너에 파일을 복사해주고 컨테이너 내부에서 리스토어를 실행시키기로 했다.


docker cp /home/ubuntu/1768530941_2026_01_16_17.5.1_gitlab_backup.tar gitlab:/var/opt/gitlab/backups/

# /var/opt/gitlab/backups/ 경로에 들어가서 아래 명령어를 실행하거나
gitlab-backup restore BACKUP=1768530941_2026_01_16_17.5.1_gitlab_backup
# 또는
docker exec -it gitlab gitlab-backup restore BACKUP=1768530941_2026_01_16_17.5.1

⚠️

gitlab 백업을 할 때 커맨드에서 자동으로 _gitlab_backup을 찾아서 붙인다 그렇기 때문에 현재 샘플 기준으로 1768530941_2026_01_16_17.5.1 만 작성해준다.

정상적으로 리스토어가 됐다면 레포지토리, 로그인 정보 등 모두 정상적으로 동작할 것이다.

—

이번 서버 이전 작업을 진행하면서 들었던 생각은, 깃랩의 강점은 온프레미스 환경에서 유효하다는 점이었다.

온프레미스 환경에서는 깃랩 서버를 직접 구축하고, 프로젝트 코드를 외부 서비스가 아닌 자체 서버에 저장·관리할 수 있다는 점은 분명한 장점이다.

하지만 이번처럼 AWS EC2에 깃랩 서버를 구축해야 하는 상황이라면 판단은 달라진다고 느꼈다.

EC2 역시 클라우드 환경이고, 결국 외부 인프라에 의존하는 구조인데, 이런 조건이라면 깃랩 서버를 직접 운영할 이유는 크지 않다고 판단했다.

이 경우에는 차라리 GitHub Team 플랜을 사용하는 편이 운영·관리 측면에서 더 합리적이라고 생각했다.

(Team 플랜 기준 명당 4 달러인데 개발팀이라고 해봐야 5명이니까.. 월 3만원 EC2 서버 보다 훨씬 낫지)

이 생각을 바탕으로 이번 미팅에서 해당 이슈를 공유했고, 논의 결과 GitHub로 이전하는 방향으로 빠르게 결정되었다.

빠르게 결정될 수 있었던 이유는 깃랩을 소스 코드 관리용으로만 쓸 뿐.. 큼지막한 기능들은 사용하지 않기도 하고 이전 하는데 문제가 될 요소가 없어서 빠르게 결정되었다.

물론.. 환경변수, 각종 스크립트 수정은 있겠지만 저게 나은것 같다.

뭐.. 이틀동안 삽질해서 서버를 옮겨놨지만 결국엔 깃허브라는 최종 결론이 났지만, 아무튼 좋은 경험이였음 🙃

다음으로 이어서할 부분은 세션/캐시(Redis) 서버 이전 작업이 될 것 같다.