GitLab CI CD 파이프라인 구축을 통한 배포 자동화 경험 - DonggunLim/Petple_front GitHub Wiki
Petple 프로젝트는 3인이 협업한 풀스택 프로젝트로, 기능 구현뿐만 아니라 배포까지 직접 수행해야 했기 때문에 반복적인 수동 배포 작업이 큰 부담이었습니다. 이를 개선하기 위해 GitLab Runner와 Docker 기반의 CI/CD 파이프라인을 구축해 배포를 자동화했습니다.
현재 배포 상태
스크립트 작성
Dockerfile은 필요한 의존성(Dependencies)을 설치한 뒤, 프론트엔드는 Nginx를 통해 정적 파일을 실행하고, 백엔드는 진입점 자바스크립트를 실행하도록 구성하였습니다. 또한 빌드와 실행 스테이지를 나누어 최종 이미지 크기를 최적화했습니다.
gitlab-ci.yml 파일은 크게 두 가지 단계로 구성됩니다. 먼저 build_and_publish 단계에서는 Dockerfile을 통해 도커 이미지를 빌드하고, 빌드된 이미지를 도커허브(Docker Hub)에 업로드합니다. 이후 deploy 단계에서는 배포용 VM에 접근하여 도커허브에서 해당 이미지를 내려받아 컨테이너로 실행하는 구조입니다.
GitLab Runner 등록 및 변수 관리
build VM에 GitLab Runner를 설치한 뒤, 발급받은 Token으로 Runner와 GitLab 저장소를 연결했습니다
또한 Docker Hub 인증 정보와 deploy VM 접근 정보 등 민감한 값들은 GitLab의 Variables 기능을 사용하여 관리하였습니다.
Ningx 연결
현재 프론트엔드는 3001번, 백엔드는 3000번 포트를 사용 중이며, Nginx의 proxy_pass를 통해 요청을 프록시하도록 설정했습니다. 추가로 웹소켓(WebSocket)을 위한 별도의 proxy_pass 설정도 함께 적용하였습니다.
만났던 이슈
정적 파일 읽지 못하는 이슈
프론트엔드 정적 파일(js, css 등)이 프록시 과정에서 경로를 인식하지 못하는 문제가 발생했습니다. 원인은 Nginx 설정에서 Host 헤더 설정이 누락된 것이었으며, 다음과 같이 설정을 추가하여 해결하였습니다.
proxy_set_header Host $host;
소켓 프록시 연결 이슈
프론트엔드에서 별도의 경로 설정 없이 소켓 연결을 시도하자 Nginx에서 설정한 프록시가 제대로 동작하지 않는 문제가 있었습니다.
확인 결과, Socket.IO 클라이언트는 명시적인 경로 지정이 없을 경우 기본적으로 /socket.io/ 경로를 사용하고 있었습니다.
초기 설정은 아래와 같았습니다.
이 설정은 프론트엔드 기본 경로와 달라 소켓 연결에 실패했습니다.
이를 해결하기 위해 Nginx 프록시 설정을 다음과 같이 변경했습니다.
upstream socket-server {
server 127.0.0.1:3000;
}
...
location /socket.io/ {
proxy_pass http://socket-server;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
정확한 경로(/socket.io/)로 프록시 설정을 맞춰준 후 정상적으로 소켓 연결이 이루어졌습니다.
DevOps 영역에 대한 이해가 부족했던 터라 시행착오가 많았습니다. 특히 VM 환경 설정이나 리눅스 관련 기본 지식이 부족해 어려움을 겪었고, CI/CD 스크립트 작성 경험도 많지 않아 검색과 테스트에 많은 시간을 들이게 되었습니다. 그럼에도 처음부터 끝까지 CI/CD 환경을 직접 구성해보면서 배포 흐름 전반을 이해할 수 있었고, DevOps와 리눅스, 그리고 자동화 스크립트에 대한 학습의 필요성을 확실히 체감한 경험이었습니다.