Day 36

배포의 기본

프런트엔드(ssr) 다이나믹한 부분
스토리지에 올릴 (ssg) 다이나믹 하지 않은 부분

이걸 로드밸런서로 묶어서 프런트엔드로 배포해야한다.

(이미 백엔드와 디비는 올라가져있음)

그래서 로드 밸런서에 아이피가 달려있는데 아이피주소로 들어갈 수 없으니까 우리가 구입한 도메인과 연결한다 -> 이부분이 DNS, .com, .me 등등등 으로 연결함

배포연습을 해보자
순서는

1. 스토리지에 배포
2. 로드 밸런서에 연결
3. DNS 적용
4. http의 문제점 발견, https로 바꾸기

스토리지에 업로드하기

VS 코드에서 폴더를 만들어서 시작하자

터미널에서

npx create-next-app class_build

그럼 새 폴더 및 기본파일들이 생성된다.
이후 api부분은 삭제한다
이후 index.js 에서 맨 위쪽의 Image들을 주석처리해준다
(지금은 정적인것들만 올릴꺼기때문)
그걸 사용하고있는 부분도 주석한다

이제 빌드라는걸 해야한다.

package.json으로 이동,

이런 파일들이 보이는데
dev는 우리가 여태 했던 yarn dev다
dev는 코드가 바뀐대로 바로 실행하지만

배포된 이후에는 빌드 후 , start로 실행해야한다.
(네이버가 코드가 바뀐대로 계속 화면이 바뀐다고 생각해보자)
이렇게 해야 안정적인 개발, 배포가 가능해진다, 해야만한다.

그니까 배포하고나서는 yarn dev만이 아니고 yarn build, 이후 yarn start해야됨

지금은 빌드 파일을 스토리지에 연결시켜서 할꺼임

(이번엔 ssg만 한다) yarn dev를 하면 next dev를 실행됐었음!!

그러니 ssg는 nextbuild 그리고 next 를 export해온다고 쓴다.
이렇게하면 yarn build:ssg 하면 뒤의 명령어가 실행된다.
next export로 정적파일을 내보낸다는 뜻

여기서 설정도 하나 더 해줘야한다.
next.config.js에서

module.exports = {
  reactStrictMode: true,
  trailingSlash: true, 
}

trailingSlash 로 각각 폴더에 해당하는 html파일들을 가져올 수 있게 된다.

이제 터미널에서 class_build로 가보자
(ls -al 했을때 .git이 없어야한다. )

yarn build:ssg

하면 out폴더에 index.html이 있어야한다.(없으면 trailingSlash부분이 잘됐나보자)

이렇게 되면 배포 준비가 된거다. (물론 useQuery같은 api부분은 안들어간 부분)

next export를 통해서 생긴게 out 폴더인데, ssg는 이게 필요하고 ssr은 next export가 필요하지 않다.

build를 하면 .next가 생성되는데 서버를 실행할껀지(next start)
파일을 가져올껀지(next export) -> out폴더

이제 gcp로 들어가보자

Cloud Storage - 브라우저 - 버킷만들기를 해보자

버킷이름은 내 도메인에 맞게 하는게 편하지만 맘대로해도된다.
위치를 아시아로 바꾼다
기본 스토리지 클래스를 standard 로 설정(자주 엑세스)
균일한 엑세스 제어 (지금은 기본값으로 씀)
없음

이렇게 만들었으면 out폴더를 여기에 넣으면 된다.

finder에 표시 후 out폴더로 들어가서 안의 내용물을 넣는다.

잘 올라간 모습
만약 드래그앤드롭으로 되지 않으면 터미널 명령어를 사용해야한다.

저기 >_ 버튼을 누르면 구글 클라우드의 터미널인 Cloud Shell을 이용할 수 있다.

알아보기 - 가이드에 보면 이렇게 있다. 여기 file_path를 out폴더라고 생각하면된다.

out폴더를 먼저 생성 + 그리고 vscode에 있는 out폴더가 git에 올라가있어야한다.
(git add, commit, push까지 한다)

주소를 복사한다음 cloud shell 에서 git clone + 내주소를 하면된다.

out폴더는 어디서든 만들 수 있기 때문에 ignore에 올라가있으므로
yarn install 이후 yarn build:ssg 를 해줘야한다.

근데 install 하면 버전이 안맞는단다. 이건 gcp의 클라우드쉘의 문제인것
해결은 노드버전만 올려주면된다.

+++ 이런 버전문제는 매우 빈번하다 -> 해결책은 docker를 이용해서 모두의 버전을 통일해서 이미지로 만들어두는 것.

해결은 일단 NVM(Node Version Manager)로 하면 된다.
nvm list 를 쳤을 때 버전이 나온다면 깔려있다는 뜻인데 없으면 설치를 하자(구글검색하면 잘나옴)

vs 코드에서 node-verion 으로 내가 사용한 버전을 확인 후에
nvm install 14.18.2 내가 쓴 버전을 gcp에 입력한다

그리고나서 yarn install을하면 다시 될 것
(gcp에서 node --version으로 맞는 버전인지 확인)

다시 yarn build:ssg를 해보자

그럼 out 폴더가 생긴다

gsutil cp -r out/* gs://내버킷이름

이렇게하면 내 버킷 안, out폴더의 내용물을 다 업로드 한다는 뜻이다

이렇게 하고 로드 밸런서에 연결하면 되지만 이전에 storage(버켓)의 공개상태를 바꿔야한다.

(공개아님)

cloud Storage - 브라우저 - 점세개 - 엑세스 설정

공개 엑세스로 바꾸기 위해서 전체유저 , 저장소 개체 뷰어로 역할을 지정한다.

이렇게 인터넷에 공개라고 떠야한다.

다시 점 세개 : 웹사이트 구성수정을통해 어떤 페이지를 보여줘야할지 설정해야한다.

기본페이지는 index.html, 오류 페이지는 404/index.html
(next가 기본으로 제공해주고있음)

이렇게하면 스토리지 부분은 설정이 끝났다.

로드 밸런서 사용하기

compute Engine API 사용해보기가 뜬다면 사용을 누름 (시간이 걸린다)

-부하 분산기 만들기

이렇게 세가지 부하분산이 보인다.

TCP는 연결 이후에 데이터를 주고나서 확인하는것, 그래서 안정성이 좀 더 높다 , 속도는 좀 더 느림
UDP는 주고 확인은 안함, 안정성은 떨어지나 속도는 좀 더 빠름

우리가 쓸껀 HTTP다
용도에 다르게 쓴다고 보면 된다. 일단 구성 시작

인터넷에서 VM또는 서버리스 서비스를 고른다

++ 여기서 서버리스 서비스란
서버를 안쓰는 것 처럼 느껴지게 하는 것 여기서는 백엔드 api들을 하나하나 function , 함수로 만들어서 실행이 필요할때만 실행되고 항상 켜져있는 서버가아니라 필요할때만 켜지는 (cold start)방식이라고 알아두면 좋다. aws의 lambda가 있다. 이전에 살짝 해봤었는데 이해가 좀 더 된다.

이후 사용하기로 오면 front/back 을 고를 수 있다. 밸런서의 front/back 이니 착각 ㄴㄴ

이름을 입력하고(버켓이름-lb-http)

프런트엔드 구성
프런트엔드의 구성도 이름을 지정하고(버켓이름-lb-http-frontend)
포트를 80포트로 한다
http는 기본적으로 80포트라고 생각하면된다. https는 443
http://www.naver.com:80 이라고 하면 접속된다 근데 포트번호는 생략이 가능한것

IP주소를 임시가 아니고 새로 하나 만들어야한다. (버켓이름-lb-http-static-ip) -> 사실 이름 어떻게든 지어도되지만 이렇게 보기 쉬어야 나중에 안헷갈림 -> 이후 예약 , 완료 이렇게 하면 프런트는 끝이다

백엔드 구성, 백엔드 버킷만들기
이름은 버킷-lb-http-backend-bucket

이후 Cloud Storage 버킷 부분에서 아까 만들었던 버킷을 선택하면된다

+++ CDN은 뭐임?

Contents Delivery Network

만약 나는 한국에서 살고 내 서비스는 미국에서 배포했다고 하자
근데 일본이나 중국에서 접속했다면, 미국에 있는 스토리집에서 받아와야하니까 그만큼 느릴 수 밖에 없다(심지어 나도)
근데 CDN을 쓰면 전세계에 있는 컴퓨터(aws나 gcs) 미국에서 배포한 파일을 전체에 다 뿌리는 거다(CDN 캐싱)
그리고 나서 요청이 들어오면 가장 가까운 곳에서 받아다 쓰게되고, 당연히 빠르다.

일단 우리는 CDN안쓰고 만들자

만든거 체크 하고 확인 누르면 된다.

호스트 및 경호 규칙

이제 호스트 및 경호 규칙을 설정해야한다.
/market, /board 들을 이동했을 떄 하는 설정들이다
근데 지금은 SSR(서버사이드렌더링)을 안쓰니 그냥 일단 만든다.

이후 네트워크 서비스 - 부하 분산에서 백엔드 버킷 1개가 정상적으로 연결되고 있다면 적용된거다.

이름을 클릭하면 아이피주소가 나온다.

http://내 아이피 주소 이렇게 쳤을 때 next.app페이지가 뜬다면 배포에 성공한모습이다.

근데 아이피주소를 안치고 주소를 치면 이 페이지로 이동할 수 있게 해보자 (DNS)

DNS 설정

네트워크 서비스 - Cloud DNS API - API 사용 설정 , DNS 영역 만들기까지 들어온다.

이름은 버킷이름 +zone

DNS이름은 아까 구매한 도메인 이름을 입력하면된다.

DNSSEC는 보안관련인데 일단 기본설정으로는 사용안함으로 하자 .

Logging은 로그를 기록하는 기능인데 로그를 남기는데 비용이 든다(물론 진짜 서비스할때는 해야되고)
지금은 꺼두자

이후 만들기

DNS에 들어가면 잘 만들어져있다.

이 유형이 레코드라고 부르는 것들인데
+레코드세트를 추가하기로 가면 유형들을 더 볼 수 있다.

레코드 유형 : 주소를 치고 들어갔을 때 실행되는것
A는 ipv4, AAAA는 ipv6 CNAME은 www.naver같은걸 실제 네이버 주소로 바꾸게 해주것 MX(메일관련 설정) TXT(텍스트 실행됨, 외부에서 사이트 인증이 필요할 때 쓰임, 텍스트 부분에 ㅁㅁㅁ입력해주세요, 해서 인증하기)
TTL 얼만큼 유지될 것인가. 변경이일어나도 설정된 유지시간은 같다는 뜻 (기본 5분)

SOA 권한의 시작점, 필수요소다 (Start Of Authority)

NS 네임서버
여기 있는 네가지 기본값을 내가 구매한 도메인에 넣어야한다.
이후 넣어야지 이 도메인의 설정을 여기서 사용하겠다는 뜻이 된다.

일단 내가 산 도메인(나는 gabia)에서 샀다
내 도메인 관리를 보면 네임서버가 다르게 생겼다. gcp 와 같이 적용해야 gcp에서 이 도메인을 관리할 수 있게된다.

(복사한 네임서버의 주소들의 맨 뒤에 .은 삭제하도록한다)

중요한 문제기때문에 인증은 해야한다. 이후 적용을 시키면 된다.

확인방법은 터미널을 열어서 dig(domain information grabbper??) 도메인 정보를 가져오는 명령어다

dig 내가구매한도메인 NS
라고 쓰면

이렇게 내가 입력한 네임서버들이 뜨면 완료된 것.

A 레코드 적용하기

이후 네트워크 서비스 - 부하 분산 - 로드 밸런서의 ip주소를 가져오고
Cloud DNS - 레코드 모음 만들기 - 아이피 주소를 아까 가져온 로드 밸런서의 주소로 넣는다
(레코드는 A로 함)

A레코드는 도메인 주소와 매핑되는 것을 이야기한다.
내 도메인 엔터 -> A레코드를 찾음 - > 연결된 로드밸런서 주소
그래서 주소창에 입력한 A레코드에 해단하는 조소로 접속되게 해준다.
이게 없어도 배포는 된거지만 이런 연결을 해줘야 실제 작동이 된다.
어떤 로드밸런서, 어떤 IP와 연결해야된지 모르기 때문에 필수필수

이후 터미널에서도 확인 할 수 있다.
그리고 나서 http://내도메인주소 이렇게 접속해보면

뜬다 뜬다 뜬다 (http:// 는 입력하면 생략된다)

물론 이렇게 하지 않고 파이어베이스나 build를 도와주는 것들이 있다.
하지만 제대로 빌드를 하고 올바른 서비스를 올리기 위해서는 이렇게 정식으로 올려야함 + 이게 실무적인 방법이기 때문에 배워두는 것이 좋다)

요약

배포의 기본
스토리지에 배포하기
로드 밸런서에 연결하기
DNS 적용해서 사이트 띄우기