Skip to content

[FE] ☁️ GCP를 활용한 배포 방식 및 내부 아키텍쳐

Junhyeok Park(박준혁) edited this page Feb 25, 2025 · 1 revision

작성자 : FE 박준혁

🍀 배포 Platform

Google Cloud Platform

💁 Platform을 선택한 이유

  • Fe와 Be 모두 Google Maps API를 사용하였습니다.
  • Google Maps API를 활성화하면 40만원 상당의 크레딧이 제공되었습니다.
  • SaaS 서비스도 많이 있지만, 직접 Deploy를 해보고, 웹서버를 운영해보고 싶었습니다.

Build

1. Multi Stage Build

image

저는 Build 단계를 두가지 Stage로 나누었습니다.

Stage 1: 빌드 및 정적 파일 추출

React 애플리케이션은 빌드 시 HTML, JavaScript, CSS 등 정적 파일을 생성합니다. 하지만, 일반적인 빌드 결과물에는 빌드 도구나 개발 의존성(예: node_modules, 소스 코드 전체)이 함께 포함될 수 있습니다. Stage 1에서는 이러한 불필요한 잔여물들을 제거하고, 오직 정적 파일만을 포함하는 최종 산출물을 생성하는 과정입니다.

Stage 2: 배포를 위한 Image 생성

Stage 1에서 생성한 정적 파일만을 가져와서, 경량 이미지(5MB)인 alpine으로 복사하였습니다. 가벼운 Image로 이미지 크기를 줄이고, 정적 파일만을 가져와 서비스를 해주는 웹서버 image를 만들 수 있습니다.

2. Github Cache 활용

      - name: Docker 이미지 빌드 및 푸시
        uses: docker/build-push-action@v3
        with:
          context: .
          file: uniro_frontend/Dockerfile
          push: true
          tags: gcr.io/${{ env.GCP_PROJECT_ID }}/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

빌드하는 단계에서, github cache를 활용해 동일한 과정은 따로 재생성하지 않고 CACHE 데이터를 활용하도록 하였습니다.
Github Cache를 활용한 PR
첫번째 빌드에 대해서는 동일했지만, 두번째의 변경사항이 많이 없다면 빌드가 시작되는 시점이 빨라졌습니다.
스크린샷 2025-02-18 17 43 56

3. Google Container Registry를 활용해 image 업로드

Google Container Registry(GCR)는 Google Cloud Platform에서 제공하는 Docker 이미지 저장소입니다. Google Cloud IAM과 통합되어 있어, 보안이 강력하고, Compute Engine(GCP의 EC2와 동등)에 쉽게 배포가 가능해, 이미지 저장소로 선정하였습니다.

Deploy

Deploy 과정은 Compute Engine(GCP의 EC2와 동등)의 ssh를 연결하여 진행하였습니다.

  1. Google Cloud Platform에서 돌아가고 있는 Compute Engine에 ssh 연결
  2. 기존 docker image를 중지하고, 새로 pull 받아 새로운 컨테이너로 교체
  3. 새로운 컨테이너를 실행
  4. reverse proxy를 담당하는 nginx 컨테이너가 연결된 network에 새로운 컨테이너의 network를 connect
  5. reverse proxy를 담당하는 nginx 컨테이너안의 nginx를 reload

배포 환경 구성도

Deploy

구성 요소

Reverse Proxy Container

역할

클라이언트가 요청한 정적 컨텐츠를 subdomain에 따라서 UNIRO APP 혹은 UNIRO ADMIN으로 대신 라우팅 해줍니다. 클라이언트 입장에서는 이 컨테이너가 APP, ADMIN 두개를 호스팅 하는 것처럼 보이지만, 실제로는 APP, ADMIN 대신 앞에서 요청을 받아 클라이언트 입장를 속이고, APP, ADMIN 컨테이너 입장에서는 대신 자신을 대변하기 때문에 역(Reverse) Proxy 역할을 같이 하게 된다.

Base Image

  • nginx image를 사용

지원되는 기능

  • Certbot을 사용해 SSL 인증서 발급받아 https 통신이 가능하도록 제작
  • HSTS를 보장해 https로만 통신 가능
  • http 2.0을 지원, 가능한 브라우저는 모두 2.0으로 통신 설정
  • 라우트 별로 cache를 설정해 정적 자원들이 최대한 cache를 활용할 수 있도록 header 삽입
  • static route로 요청시, 정적 파일을 호스팅 할 수 있는 기능 제공 (UNIRO의 OG Tag Image 호스팅 방법)

UNIRO Client/Admin용 Container

역할

  • 실제로 정적 컨텐츠를 제공하는 컨테이너, Reverse Proxy가 전달해준 사용자의 요청을 응답해 다시 Reverse Proxy로 전달한다.

Base Image

  • alpine (배포 속도 향상을 위해 경량 Image 선택(5mb) (Alpine Image)
  • brolti 파일 호스팅 지원을 위해, nginx-mod-http-brotli 패키지 추가 설치

지원되는 기능

Clone this wiki locally