원래는 azure를 사용해서 webApp 배포를 했는데 회사에서 azure에서 google cloud platform으로 비용측면으로 전환 작업을 진행하게 되었다.

그래서 Google cloud Platform(GCP)를 공부하게 되면서 배포를 진행하게 되었다.

생각보다 사용자가 적어서 그런지 정보가 많이 없었으며 찾아보니 대부분 도커를 활용해서 같이 빌드를 했다.
그리고 cloud Run ? cloud Engin등 다양하게 이용하는 것 같았는데 이름들이 생소해서 찾아보게 되었다.

출처는 공식문서 페이지 이다.

Cloud Run

Cloud Run은 Google의 확장 가능한 인프라에서 직접 컨테이너를 실행할 수 있게 해 주는 관리형 컴퓨팅 플랫폼이다.
컨테이너 이미지를 빌드 와 소스 기반 배포를 할수가 있다.
컨테이너 이미지는 도커 를 활용하는 것 같다.

Cloud Run 서비스를 사용해야 하는 경우

Cloud Run 서비스는 요청 또는 이벤트를 처리하는 코드에 매우 효과적입니다. 사용 사례의 예를 들면 다음과 같습니다.

웹사이트 및 웹 애플리케이션

원하는 스택을 사용해서 웹앱을 빌드하고 SQL 데이터베이스에 액세스하고, 동적 HTML 페이지를 렌더링합니다.

API 및 마이크로서비스

REST API나 GraphQL API 또는 HTTP 또는 gRPC로 통신하는 비공개 마이크로 서비스를 빌드할 수 있습니다.

스트리밍 데이터 처리

Cloud Run 서비스는 Pub/Sub 푸시 구독에서 메시지를 수신하고 Eventarc에서 이벤트를 수신할 수 있습니다.

cloud engin

cloud engin 은 VM으로 가상 머신을 빌리는 것이다. 다양한 옵션으로 컴퓨팅을 빌릴 수가 있다.

cloud Run 시스템은 이미 구축된 시스템에서 배포파일들을 빌려서 배포를 할수 있게 하는 것이고
Cloud engin측면에서는 컴퓨터를 빌려서 환경설정을 다 마치고 배포를 진행하는 것이었다.

간략하게 사용하고 싶어서 Cloud Run을 선택했다.

자료를 찾아보니 cloud Run 보다 cloud Engin을 사용하는 사람들이 많았고 자체적으로 도커환경을 배포해서 만들었다.

자료를 찾아보니 도커를 공부해야 해서 배포를 해야 하나 걱정도 있었으며 자료들이 오래된 자료들 2020년, 2021년 들이 많아서 직접 부딪혀보며 빌드를 해보기로 마음먹었다.

이제부터 시작합니다.

Cloud Run으로 Next js 빌드 하기

무작정 작업한 코드들로 빌드를 하기에는 충돌 이슈도 있고, 설치된 라이브러리도 많아 오래걸릴것 같아서 더미를 만들어서 진행하게 되었다. 바로 next js를 새롭게 만들어서 빌드 테스트를 진행하게 되었다.

테스트 환경은 이렇다
순수 nextjs 14 버전

1. 우선 빌드를 진행하기 위해서는 GCP에 계정이 있어야 한다. 계정은 구글 계정으로 바로 가입이 가능한것 같은데 이미 회사에서 계정을 만들어 둔게 있어서 나는 생성하는 과정을 생략할수 있었다.

처음 으로 들어오면 프로젝트 부터 만들자

프로젝트 이름과 조직만 선택하면 만들어 지니 간단하게 만들수 있다.

옆에 메뉴에서 cloud run을 선택해주자

그리고 바로 서비스 만들기가 보이니 서비스 만들기를 클릭해주자

다행이도 github저장소에 지속적 배포가 있었다.

Github를 선택하면 오른쪽에 새로운 창이 생기면서 연결을 위해 설치 과정을 하게 한다.
GitHub앱을 설치 해주자. 그대로 다 설치 하라는거 설채해주면 된다.

연결을 하게 되면 저장소도 가져올수 있는데 전체 접근할건지 선택적으로 접근할건지 선택할수 있다.
나는 리포지토리가 많기 때문에 선택적으로 깔끔하게 원하는 것만 선택해서 가져왔다.

저장소 까지 선택하면 분기는 자동으로 가져온다 분기가 branch 인것 같다.
나는 더미 nextjs로 우선 빌드를 했는데 생각보다 간단해서 캡쳐를 못했고 바로 내가 작업한 브랜치로 빌드를 진행해서
이미지상 dev와 main이 분기 되어 있는 것이 보인다.

dev를 선택하게 되면 빌드 유형을 선택할수 있다. 여기에서도 도커를 활용하던지 google Cloud빌드팩을 사용하던지 선택할수 있다.
나는 빌드팩을 선택했다. 빌드팩을 선택하면 yaml 파일이 자동으로 생성이 되는데 진입점도 그대로 빈칸으로 놔두면 자동으로 package.json의 bulid , start 명령어를 사용해서 빌드와 start를 진행해준다.

완료 되면 리전을 선택하고 아래 옵션들을 선택할수 있다. 인증만 ‘인증되지 않은 호출 허용’을 선택해주고 나머지는 기본 값으로 세팅해 두었다. 나는 api호출할때 아직 까지 azure에서 받은것을 사용해야 했기 때문에 인증되지 않은 호출 허용으로 선택해두었다.

아래 세부사항으로 포트 , 리소스 등등 건들일수 있는데 그냥 기본값으로 세팅해서 진행을 했다.

완료를 누르면 바로 배포가 진행된다.

azure서비스와 비교해봤을때 진짜 훨씬 배포가 빠르다.
도커를 다뤄야 하나 걱정했는데 yaml파일도 자동으로 next에 맞춰서 생성해줘서 간편하게 빌드를 진행할수 있었다.

빌드가 3분대로 엄청 빠르게 진행되었고 결과 또한 잘 나오게 되었다.

이렇게 바로 진행하면 도커를 사용안하고 바로 빌드와 배포를 진행할수가 있다.

처음에는 더미로 해서 진짜 빠르고 간편하고 쉽다 라고 생각하게 되었다.
내가 제작한 코드에서 아래 결과를맞이하기 전까지는 ..

마지막에는 성공할수 있었지만 혼돈의 빌드 실패 들이 등장하게 되었다.

오늘 포스팅은 그냥 GCP를 이용해서 빌드 및 배포하기니 내가 직면한 빌드 오류 해결은 다음 포스팅으로 넘기기로 한다.

오늘은 끝

GCP 장점

• 빌드가 간편하다. 빌드가 빠르다(azure와 비교 했을때)
• 기존 순수 유저라면 yaml파일도 바로 생성해줘서 간편하게 빌드를 진행할수 있다.

단점

• UI 가 깨진다.
• 순수 유저가 아니라면 yaml 파일 빌드에서 많이 헤멜 것이다.