새로 시작하는 프로젝트의 워크로드를 설계하면서 AWS의 App Runner 보다 GCP의 Cloud Run이 더 효율적이라는 것을 알게되어 '로컬 Gitlab CI Pipeline - Image Registry - Web Service - HTTPS' 로 이어지는 무중단 배포 파이프라인을 GCP에서 구축해 보고자 이 가이드를 작성함.
[GCP] 2. CI/CD 파이프라인 구축 및 Cloud Run 실전 배포
지난 포스팅에서 GCP의 인증 체계와 창고(Artifact Registry)를 준비했습니다. 이번 장에서는 이미 구축된 GitLab Pipeline을 활용하여 코드를 컨테이너로 빌드하고, Cloud Run에 서비스를 올리는 실전 과정을 다룹니다.
2.1 GitLab CI를 이용한 이미지 빌드 및 Push
이미 GitLab Runner와 기본적인 파이프라인 환경이 갖춰져 있다면, .gitlab-ci.yml에 GCP용 로직을 채워 넣을 차례입니다.
.gitlab-ci.yml 구성 전략
GCP Artifact Registry는 일반적인 docker login 방식 외에도 _json_key라는 약속된 ID를 통해 인증할 수 있습니다. AWS 관련 로직을 제거하고 아래와 같이 구성합니다.
# Build & Push 단계 핵심 스크립트
homepage_build:
stage: build
script:
# 1. 환경 변수 설정
- export REGISTRY_URL="$GCP_REGION-docker.pkg.dev/$GCP_PROJECT_ID/$GCP_REGISTRY_NAME"
# 2. Docker 로그인 (GCP 전용 고정 ID인 _json_key 사용)
- echo "$GCP_SERVICE_KEY" | docker login -u _json_key --password-stdin https://$GCP_REGION-docker.pkg.dev
# 3. 이미지 빌드 및 푸시
- docker build -t $REGISTRY_URL/image-cyaninn-inn-webpage-prod:$HOMEPAGE_TAG ./staging/homepage
- docker push $REGISTRY_URL/image-cyaninn-inn-webpage-prod:$HOMEPAGE_TAG- 포인트: 이미지 주소 체계(
[리전]-docker.pkg.dev/[프로젝트ID]/[저장소]/[이미지])를 정확히 지켜야 Push 오류를 방지할 수 있습니다.
2.2 Cloud Run 서비스 배포 (웹 대시보드 상세 가이드)
이미지가 성공적으로 Push 되었다면, 이제 웹 대시보드에서 첫 번째 서버를 기동해 봅시다.
1단계: 서비스 생성 및 이미지 선택
- Cloud Run 메뉴 접속: GCP 콘솔에서 'Cloud Run'을 검색하여 이동한 뒤
[+ 서비스 만들기]를 클릭합니다. - 이미지 선택:
[선택]버튼을 눌러 Artifact Registry에 있는image-cyaninn-inn-webpage-prod패키지와 원하는 태그(버전)를 지정합니다.
2단계: 서비스 설정 및 보안
- 서비스 이름 및 리전: 서비스 이름을 지정하고, 리전은 반드시 저장소와 동일한 asia-northeast3 (서울)로 설정합니다.
- 인증: 일반 사용자가 접속하는 웹사이트이므로 [미인증 호출 허용]을 선택합니다.
- 인그레스: 인터넷 전체의 접속을 허용하기 위해 [전체]를 선택합니다.
3단계: 네트워크 및 보안 유의사항 (중요)
하단의 [컨테이너, 네트워킹, 보안] 섹션을 확장하여 아래 내용을 반드시 점검해야 합니다.
- 컨테이너 포트 매칭: 현재 Dockerfile에서
EXPOSE 8080을 사용 중이므로, 설정 창의 컨테이너 포트 역시 8080으로 되어 있어야 합니다. 이 포트가 어긋나면 배포는 성공해도 실제 사이트는 뜨지 않는 '연결 거부' 상태가 됩니다. - HTTPS 자동 관리: Cloud Run은 외부에서 들어오는 HTTPS(443) 요청을 컨테이너 내부의 8080 포트로 변환하여 전달합니다. 따라서 컨테이너 내부 소스 코드나 SSL 설정은 전혀 건드릴 필요가 없습니다.
- 인그레스 제어: 웹 서비스의 경우 '전체'가 맞지만, 내부 API 서버라면 '내부'로 제한하여 보안을 강화할 수 있습니다.
2.3 배포 자동화: 지속적 배포(CD) 구현
웹 대시보드에서 첫 배포를 마쳤다면, 이제 주석 처리해 두었던 deploy 스테이지를 활성화하여 자동 배포를 완성합니다.
homepage_deploy:
stage: deploy
image: google/cloud-sdk:latest
script:
# 1. 서비스 계정 인증 및 프로젝트 설정
- gcloud auth activate-service-account --key-file=$GCP_SERVICE_KEY
- gcloud config set project $GCP_PROJECT_ID
# 2. Cloud Run 배포 실행 (무중단 배포 자동 수행)
- gcloud run deploy homepage-service \
--image $GCP_REGION-docker.pkg.dev/$GCP_PROJECT_ID/$GCP_REGISTRY_NAME/image-cyaninn-inn-webpage-prod:$HOMEPAGE_TAG \
--region $GCP_REGION \
--platform managed \
--allow-unauthenticated무중단 배포의 작동 원리
gcloud run deploy 명령이 떨어지면 Cloud Run은 기존 서버를 유지한 채 새로운 리비전(Revision)을 생성합니다. 새 버전이 완전히 준비(Healthy)되었다고 판단될 때만 로드밸런서가 트래픽을 새 버전으로 100% 전환하므로, 사용자는 중단 없는 서비스를 경험하게 됩니다.
💡 2장을 마치며
이로써 AWS에서 GCP로의 웹 서비스 이전을 위한 모든 인프라 구축과 자동화 설정이 끝났습니다. 이제 개발자는 인프라 운영 부담을 덜고 오직 코드 작성에만 집중할 수 있는 서버리스(Serverless)의 혜택을 누리게 되었습니다.
추후에는 AWS Route53 도메인을 이 Cloud Run 엔드포인트에 연결하여 커스텀 도메인 환경을 구축해 볼 예정입니다. 시스템 엔지니어로서 한 단계 더 성장한 이번 실습이 여러분의 노트 정리에도 큰 도움이 되길 바랍니다!
