본문
AWS EC2 IP 변경 사고와 GitLab/Runner 정상화 과정
클라우드 인프라를 운영하다 보면 예기치 않은 순간에 '식은땀'이 흐르는 경험을 하게 됩니다. 이번에는 작업자의 실수로 인해 운영 중인 GitLab 서버(EC2)의 공인 IP가 변경되는 이슈가 발생했습니다.
순간적인 실수로 IP가 52.79.152.xxx에서 43.201.65.xxx로 바뀌어버렸고, 그 즉시 팀의 저장소 접근과 CI/CD 파이프라인이 모두 중단되었습니다.
단순히 "IP만 바꿔서 다시 띄우면 되는 것 아니냐"라고 할 수 있지만, 데이터 무결성이 생명인 형상 관리 도구에서는 기존 데이터를 안전하게 지키면서 설정을 변경하는 것이 무엇보다 중요합니다. 이번 글에서는 당황스러운 상황 속에서도 침착하게 데이터를 백업하고, GitLab 서버와 Runner를 정상화했던 과정을 정리해 보았습니다.
1. GitLab Server: 최우선 원칙은 '데이터 보호'
IP가 바뀌었으니 당장 컨테이너를 내리고 다시 올리고 싶은 마음이 굴뚝같겠지만, 그전에 반드시 선행되어야 할 작업은 백업입니다. Docker 컨테이너는 언제든 사라질 수 있는(Stateless) 존재지만, 그 안에 마운트 된 볼륨 데이터만큼은 영구적이어야 하기 때문입니다.
[Step 1] 안전한 백업 (Snapshot & Tar)
가장 확실한 방법은 AWS EBS 스냅샷을 찍는 것이지만, OS 레벨에서도 이중으로 백업을 진행했습니다. 특히 gitlab-secrets.json 파일은 DB 암호화 키를 포함하고 있어 유실 시 데이터 복구가 불가능하므로 별도로 챙겨야 합니다.
# 1. 컨테이너 중지 (데이터 정합성을 위해 권장)
sudo docker stop gitlab
# 2. 전체 데이터 백업 (sudo 권한 필수)
# /srv/gitlab 디렉토리를 날짜 기반 파일명으로 압축합니다.
sudo tar -cvpzf ~/gitlab_backup_$(date +%Y%m%d).tar.gz /srv/gitlab
# 3. 핵심 설정 파일 별도 보관 (Priority 1)
# 만약 전체 백업이 실패하더라도, 이 파일만 있으면 복구의 희망이 있습니다.
sudo cp /srv/gitlab/config/gitlab-secrets.json ~/gitlab-secrets.json.bak
### 백업 파일 확인
ls -lh ~/gitlab_backup_*.tar.gz
[Step 2] IP 변경 및 컨테이너 재기동
데이터가 안전하다고 판단되면, 이제 과감하게 기존 컨테이너를 삭제하고 변경된 IP(43.201.65.2)를 주입하여 다시 실행합니다. 이때 중요한 것은 볼륨 마운트(-v) 경로를 기존과 동일하게 유지하여 이전 데이터를 그대로 불러오게 하는 것입니다.
# 1. 기존 GitLab 컨테이너 정리
# 실행 중인 컨테이너를 중지하고 삭제합니다. 데이터는 호스트의 /srv/gitlab에 있으니 안심해도 됩니다.
sudo docker stop gitlab 2>/dev/null || true
sudo docker rm gitlab 2>/dev/null || true
# 2. GitLab 컨테이너 실행 (변경된 IP 적용)
# hostname과 EXTERNAL_URL 환경변수를 새로운 IP로 변경합니다.
sudo docker run --detach \
--hostname 43.201.65.xxx \
--publish 443:443 --publish 80:80 --publish 2222:22 \
--name gitlab \
--restart always \
--volume /srv/gitlab/config:/etc/gitlab \
--volume /srv/gitlab/logs:/var/log/gitlab \
--volume /srv/gitlab/data:/var/opt/gitlab \
--shm-size 1g \
--memory 6g \
-e EXTERNAL_URL="http://43.201.65.xxx" \
xxx.dkr.ecr.ap-northeast-2.amazonaws.com/ks2-kai-dev-kabie/kbsec-ai/gitlab:latest
# 3. 기동 상태 모니터링
echo "GitLab 기동 중... 약 5-10분 정도 소요됩니다."
sudo docker logs -f gitlab2. GitLab Runner: 끊어진 연결고리 잇기
GitLab 서버가 살아났어도, CI/CD를 담당하는 Runner들은 여전히 이전 IP(52.79.152.198)를 찾고 있어 'Offline' 상태일 것입니다. Runner들이 바라보는 서버의 주소를 갱신해 주어야 합니다.
[Step 1] 설정 파일 일괄 수정
Runner가 여러 개 등록되어 있다면 일일이 파일을 열어 수정하는 것은 비효율적입니다. sed 명령어를 활용해 설정 파일(config.toml) 내의 모든 구 주소를 신규 주소로 한 번에 치환합니다.
# GitLab Runner 설정 파일 경로: ~/.gitlab-runner/config.toml (또는 /etc/gitlab-runner/config.toml)
# sed를 이용한 일괄 치환 (Old IP -> New IP)
sed -i 's/52.79.152.xxx/43.201.65.xxx/g' ~/.gitlab-runner/config.toml
[Step 2] Runner 서비스 재시작
설정 변경 사항을 반영하기 위해 Runner 서비스를 재시작합니다.
sudo gitlab-runner restart
잠시 후 GitLab Admin 페이지의 Runners 메뉴에서 상태 표시등이 초록색(Online)으로 바뀌는 것을 확인하면 모든 복구 절차가 완료됩니다.
마무리하며
인프라를 운영하다 보면 IP 변경과 같은 이슈는 언제든 발생할 수 있습니다. 이번 장애 복구 과정에서도 다시 한번 느낀 점은 "시스템은 언제든 변할 수 있지만, 데이터는 변하지 않아야 한다"는 것입니다.
혹시 모를 상황에 대비해 탄력적 IP(Elastic IP) 할당을 고려하는 것도 좋겠지만, 근본적으로는 데이터 백업과 복구 프로세스를 손에 익혀두는 것이 DevOps 엔지니어의 가장 강력한 무기임을 잊지 말아야겠습니다.
댓글