React 앱에 Next.js 끼얹기 + EC2 배포하기

Woowa Techcourse/Missions

React 앱에 Next.js 끼얹기 + EC2 배포하기

mingule 2021. 10. 6. 02:58

들어가기 전에..

이번 접근성 미션을 하면서 React로 구현해놓은 페이지를 Next.js를 이용해 Migrate하고, EC2로 배포하라는 미션을 받았다!

본격적으로 들어가기 전에, Next.js와 우리가 배포할 AWS EC2가 도데체 뭔지 한 번 짚고 넘어가보자.

✔️ Next.js가 뭘까?

The React Framework for Production
Next.js gives you the best developer experience with all the features you need for production: hybrid static & server rendering, TypeScript support, smart bundling, route pre-fetching, and more. No config needed. - Next.js 공식 문서

Next.js 공식문서에 들어가면 처음으로 보이는 문구다. 대충 한 문장으로 해석해보면, 겁나 편리한 React Framework라는 거다.

그럼 도데체 뭘 제공해주길래 이렇게 당당하게 편리하다고 하는걸까? 한번 알아보자.

React의 Framework, Next.js

우리는 React를 Framework가 아니라 Library로 부른다.

나는 보통 Framework와 Library를 비교할 때에, 제어권을 통해 설명한다.

Framework는 이미 만들어져서 내가 전체를 제어할 수 없어 그 안에서만 무언가를 개발 할 수 있는 어떤 틀이고,

Library는 내가 이런 전체적인 개발 흐름을 제어할 수 있어 언제든지 내가 원하는 곳에 가져다가 사용할 수 있는 도구라고 말할 수 있다.

Next.js는 자신을 React의 Framework라고 말한다.

예전에 Django, Django-Rest-Framework(DRF), Ruby on Rails 와 같은 Web Framework를 공부한 적이 있다.

Django와 DRF는 Python 기반의 Web Framework이고, Ruby on Rails는 Ruby 기반의 Web Framework이다.

뭔가 처음에는 React의 Framework라고 하니까, 라이브러리 기반 프레임워크?! 뭐지?! 이렇게 생각해서 신기했는데

생각해보면 그냥 Web Framework에 React Library를 메인으로 얹어 사용하는 거라고 생각하면 될 것 같다. (하하)

React로 개발하려면 우리는 Webpack이나 Babel, Code Splitting, SEO 등을 직접! 설정하고 고려해주어야한다.

앞서 작성한 성능 최적화 포스팅이나.. CRA 없이 React로 프로젝트 세팅하기를 보면 이 귀찮은 일을 정말 잘 느낄 수 있다.

CRA를 사용하면 귀찮음을 덜 수는 있지만, 너무 필요없는 설정이 많이 들어가있기도 하고.. 해서 실무에서는 잘 사용하지 않는다고 들은 적이 있다. 또, React는 기본적으로 Client Side Rendering을 지원하기 때문에 Server Side Rendering을 원한다면 직접 설정해줘야한다. (물론 나도 지금까지 실제로 해본적은 없다 하하하!)

Next.js의 장점

Next.js는 React를 사용했을 때 전반적으로 생길 수 있는 이러한 불편함들을 해결해준다고 한다. (굉장한데)

몇가지 나열해보자면, 아래와 같은 장점이 있다. (더 다양한 기능은 여기 공식문서에서!)

- Page Based Routing System

- Pre rendering, Static Generation

- Automatic Code Splitting

- Built in CSS, SASS support (CSS in JS)

- Fast Refresh

- Fully Extendable(Node, Express 등의 서버와 빠르게 혼용 가능)

Static Generation란?

*Static Generation이라는 건 생소해서 따로 찾아봤다. (~~쓱배송은아니다~~)

Static Generation에 대해서 이해하려면, 먼저 Pre rendering에 대해 알아야한다.

Pre rendering한다는 건, 빌드 시점에 각 페이지들을 미리 HTML 문서로 생성해 가지고 있는 것이다.

Next는 브라우저에 렌더링할 때, 기본적으로 Pre rendering을 사용한다.

이 Pre-rendering에는 두가지 방식이 있는데, 요게 Static Generation과 Server Sider Rendering이다.

Static Generation은 HTML을 빌드 타임에 미리 생성해두고, 요청할 때마다 재사용하는 방법이다.

Static Generation을 사용하면, build시 만들어놓은 HTML 파일을 서버에서 요청이 들어올 때마다 재사용해서 보여준다.

바뀌는 내용이 없어 사용자의 요청마다 같은 페이지를 보내줘야한다면, Static Generation 방식을 권장한다.

Next는 Static Generation 방식을 Default로 채택하고 있다. 결국 우리는 이걸 사용하고 있는 것 .. !

Server Side Rendering은 우리가 익히 아는, 요청시마다 HTML을 생성해주는 방법이다.

Server Side Rendering을 사용하면 서버에서 요청이 올 때마다 HTML을 생성해 보내준다.

요청에 따라 응답할 내용이 달라 항상 최신의 상태를 유지해야하는 경우에 SSR 방식을 권장한다.

우리가 React에서 Client Side Rendering(이하 CSR)을 할 때, index.html 하나만을 가지고 내용물을 계속 바꿔주었다면,

Next는 Pre rendering을 통해 페이지 진입시 First Meaningful Paint를 앞당기고,

그 안에서는 Javascript로 내용을 바꿔 interact 함으로써 CSR의 장점도 살린다.

여기까지 Next js에 대해 찾아봤는데, 되게 흥미로운 내용이었다. 엄청난 걸 발견한 느낌..?!

기본적으로 개발자가 개발하면서 불편할 수 있는 점들을 다 해결해놓은 집합체같다.

그런데 살펴보면서 문득 궁금해진 점이 하나 있었는데, CRA도 약간 이런 귀찮은 내용들을 다 해결해주지 않나..?

그럼 약간 CRA + SSR 느낌인가? 싶었다. 하하하!

그래서 찾아봤는데, 여기에 아주 잘 정리해준 사람이 있었다.

뭐 내가 궁금했던 부분만 정리해보자면, 요정도다!

CRA - SSR 제공 안함 / babelrc, eslintrc 등 커스터마이징 불가능

Next.js - SSR 제공 / babelrc, eslintrc 등 커스터마이징 가능

아, Next.js도 CNA라고 Create Next App을 제공한다.

아래와 같은 코드로 생성이 가능하다.

npx create-next-app [프로젝트 명]

dependency가 쥼멜로 많은 create-react-app과는 달리 create-next-app은 ZERO dependency다. (미쳣다)

하지만 나는 이번에 CNA를 사용하지는 않을 것이고, 기존에 있는 React 앱에 Next를 넣어보겠다.

그리고 이번 미션에서는 Next.js가 제공하는 기능에서 Page Based Routing을 중심으로 사용할것이다.

딱 이미 React로 만들어져있는 프로젝트에 어떻게 Next JS를 도입할 수 있는지 알아보고 끝낼 것이..다.. ^^...

할 게 너무 많다.. 기본에 충실하자... 다음에 근데 꼭 써보고 싶다. 다음 뿌로젝트는 Next 너로 정했따!!!

자.. Next에 대해 알아봤다. 하지만 아직 EC2의 개념이 남았다^^;;;;ㅋㅋㅋㅋㅋㅋㅋ 빠르게 고고링!

✔️ AWS EC2(Amazon Elastic Compute Cloud)가 뭘까?

Amazon EC2는 웹 서비스 인터페이스를 사용해 다양한 운영 체제로 인스턴스를 시작하고, 이를 사용자 정의 애플리케이션 환경으로 로드하며, 네트워크의 액세스 권한을 관리하고, 원하는 수의 시스템을 사용해 이미지를 실행할 수 있는 진정한 가상 컴퓨팅 환경을 제공합니다.

AWS EC2는 배포할 때 가장 범용적으로 사용되는 서비스다.

어떤 서비스냐면, 저 멀리 외국 어딘가에 있는 AWS에 있는 컴퓨터를 한 대 빌려서 사용하는 거다.

요 빌린 컴퓨터를 우리는 인스턴스(instance)라고 부른다. 그냥 우리가 생각하는 컴퓨터랑 똑같은 컴퓨터다!

뭐 실제로 우리가 사용하는 컴퓨터처럼 생긴건 아니고, 가상 컴퓨터라고 생각하면 된다.

그래서 인터넷을 통해서만 접속이 가능하다. 구입하는 것도 쉽고, 구입하면 바로 생성된다. 삭제도 마찬가지!

이 컴퓨터가 어떤 운영체제를 가지는지, 어떤 환경을 가질지는 우리가 다 고를 수 있다.

만약 컴퓨터를 직접 사려면 부품도 다 사고 해야하는데, 이런 초기 구입비가 필요없다는 장점이 있다.

그냥 우리가 그 컴퓨터를 얼마나 사용하는지에 따라 과금이 된다.

즉, 내가 얼마나 많은 것들을 그 컴퓨터에서 돌리고 있는 지에 따라 과금이 되기 때문에... 조심해야한다.

친구들중에 공부하면서 EC2에 인스턴스를 몇개 만들었다가 인스턴스가 계속 돌아가는 것을 까먹고 요금 폭탄을 맞은 친구들도 여럿 봤다. 흔하진 않지만 해킹을 당하는 경우도 있다. 조심해야된다!

물론 이런 경우는 AWS에 문의를 넣으면 조치를 해주긴 한다. 나는 대학생때 프리티어를 쓰다가 괜히 친구들 요금폭탄 맞는거 보고 무서워져서 계정을 삭제하기도 했었다.

어쨌든, EC2는 눈에 보이는 컴퓨터가 아니고 AWS에서 세계 지역마다 만들어놓은 데이터 센터에 만들어지는 컴퓨터다.

그렇기 때문에 네트워크를 통해 제어할 수 있다. 서울은 2016년에 데이터 센터가 생겼다! 야호!

EC2는 정말 다양한 기능을 제공한다. (참고 - AWS 문서)

이 중에서, 전체를 다 아는 건 현실적으로 힘들다.

이번에는 React + Next로 만들어진 웹 사이트를 이곳에 띄우는 웹 호스팅에 관한 내용만 짚고 넘어가겠다.

아래에서 따라해보면서 한 번 하나하나 짚어보자.

React 앱에 Next.js 적용하기

Create React App을 사용하지 않고 그냥 React 프로젝트를 만들었기에,

이 조건에 맞추어 Next.js를 적용했다. 적용하는건 크게 어렵지 않았다. 조금 귀찮을 뿐... 하핫..

1. 프로젝트에 next 최신 버전을 다운받는다.

npm install next@latest 

yarn add next@latest

2. package.json을 수정한다.

기존에 webpack으로 시작하도록 만들어놓은 내용들을 next를 사용하도록 수정해준다.

{
  ...
  "scripts": {
    "dev": "next",
    "start": "next start",
    "next build": "next build",
  }
  ...
}

3. page 폴더를 만들어준다.

Next.js에서는 메인 디렉토리 하위에 'pages' 라는 폴더가 필요하다.

이 안에 있는 index.js라는 파일을 통해 진입하고, 페이지가 동작하게된다.

아래와 같이 꼭 메인 디렉토리 하위에 만들어야 한다.

index.js는 그냥 우리가 기존에 만들던 내용과 똑같이 만들어주면 된다.

import React from 'react';

const Index = () => {
  return (
    <div>
      <h1>그루밍의 페이지</h1>
    </div>
  );
};

export default Index;

이렇게 하고 앱을 실행해보면 아래와 같은 에러가 뜬다. 머선일이구..!!!!!

찾아보니 이 에러는 @babel/plugin-transform-runtime을 다운받고, regenerator를 true로 만들어주면 되는 거였다.

터미널에 아래 코드를 쳐서 다운받고,

npm install -D @babel/plugin-transform-runtime

yarn add -D @babel/plugin-transform-runtime

.babelrc에 아래와 같이 플러그인을 설정해주면 된다.

{
  ...
  "plugins": [
    [
      "@babel/plugin-transform-runtime",
      {
        "regenerator": true
      }
    ]
  ]
}

그러면 짜쟌!

이렇게 그루밍의 페이지가 잘 뜨는 것을 볼 수 있다.

자 그러면 이제부터 페이지를 한 번 만들어보즈아~!

Page 폴더 아래에 내가 원하는 폴더나 파일을 만들어주면 된다.

아래처럼 만든다면, 이제 우리는 https://localhost:3000/hi, https://localhost:3000/Introduction 이라는 페이지에 접근이 가능하다.

그런데 뚜둔!

Introduction 페이지에 접근하려니, 에러가 났다.

Introduction/index.js에 아래와 같이 작성해두었는데, 이런 식으로 CSS 파일을 import하는 게 안된다는 에러였다.

import './index.css';

import React from 'react';

const Introduction = () => {
  return <div>안녕하세요! 그루밍입니다! 😆</div>;
};

export default Introduction;

무언가 다른 방법이 있는가봉가 하고 에러메시지를 읽어보니, Pages 폴더에 _app.js를 만들어 사용하라는 것 같았다.

조금 더 찾아보니, 공식문서에 어떻게 사용하라는지 더 자세히 나와있었다.

정리해보면 그냥 index.css같이 사용할거면,

이건 Global Style에 적용되는거니까 _app.js를 만들어 글로벌 스타일에 적용시키라는 거였고,

내가 원하는대로 Component 별로 style을 줄거면, [name].modules.css와 같이 사용하라는 것이었다.

그래서 그 말대로 했다.

Global Style에 적용할 부분은 폴더 최상단에 styles.css를 만들어 넣었고,

pages 폴더에 _app.js를 만들어서 아래와 같이 코드를 작성했다.

(공식문서에 다 나와있다)

import '../styles.css';

export default function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

근데 안되더라! 보니까 서버 껐다 켜야된다고해서 껐다 켰더니 잘 동작했다. 뿌듯 *-__-*

그리고 컴포넌트마다 다른 css를 주기 위해서

파일 이름을 index.module.css로 변경하고, 아래와 같이 코드를 작성했더니, 잘 동작했다.

.hi {
  color: yellow;
}

import React from 'react';
import styles from './index.module.css';

const Introduction = () => {
  return <div className={styles.hi}>안녕하세요! 그루밍입니다! 😆</div>;
};

export default Introduction;

글씨가 너무 노래서 잘 안보인다 ^^;;;;; 하지만 CSS가 잘 먹혔다는 것이 중요할 뿐..

아, 그리고 얘네는 그냥 pure한 selector를 moedule.css에 못쓰게 한다. 귀찮아서 className안달아주려고 했는데 block당함.. 힝..

만약 pure한 selector를 사용해서 스타일을 주려고하면 아래와 같은 에러가 뜬다.

찾아보니, module.css는 기본적으로 pure selector를 사용하지 못하게 한다고 한다. → module이 아닌 global style css에는 가능!

여기에서 읭? CRA에서도 module 사용하는데 pure selector 잘만 썼는데? 하시는 분들은 CRA에서는 사용할 수 있게 만들어놨다고 한다.. 나도 module을 몇번 사용해봤었는데 이런 건 처음봐서 신기했다.

Next.js 깃헙에서 관련 discussion에도 비슷한 오류를 겪은 사람이 있어서 링크를 살포시 가져와봤다.

혹시나 있을 겹침에 대해 방어를 되게 잘 해주는 느낌이라, 개발할 때에도 훨씬 편할 것 같다.

휴...

여기까지 위 내용들을 활용해.. 별거 아닌 페이지 3개를 만들었다. 이제 이걸 EC2에 업로드 할 일만 남았다리~~~!!!

조금 더 힘을 내보자. . . 어려워보이지만 . . .

😵‍💫 EC2에 업로드하기

1. AWS EC2에 Instance 생성하기

아까 위에서 말해줬던 Instance, 즉 컴퓨터 한 대를 빌리기 위한 작업이다. 컴퓨터 만들기, 시작해볼까요우?

시작은 단순하다. EC2 Dashboard에 들어가 주황색 Launch Instance 버튼을 누르면 된다.

Template을 활용해 만드는 것과 그냥 만드는 옵션이 있었는데, 따로 Template이 없기 때문에 나는 그냥 만드는 것을 선택했다.

Template은 이미 만들어진 Instance가 있고, 그 안의 환경세팅을 복사하고 싶을 때, 템플릿으로 만들어 빠르게 인스턴스를 만들 수 있도록 제공하는 역할 같았다.

✔️ 1-1. AMI(Amazon Machine Image) 선택하기

Amazon Machine Image!가 뭘까? 직역하면 아마존.. 기계.. 이미지.. ㅎ r.. 이름.. 왜.. 이따위.. ㅎ.. 이해 1도 안간다...

내가 바보가 아니라 네이밍을 구리게 지어서 다들 이해 못하는 것 같다. 구글에 ami aws 치면 meaning 뜬다 ㅋ

각설하고, 그래서 AMI의 정의를 가져와봤다.

An Amazon Machine Image (AMI) provides the information required to launch an instance. You must specify an AMI when you launch an instance. You can launch multiple instances from a single AMI when you need multiple instances with the same configuration. You can use different AMIs to launch instances when you need instances with different configurations.

이렇게 봐도 쉽지는 않지만, 쉽게 이해하자면 우리가 만든 Instance를 Launch 하는 어떤 Image라고 볼 수 있는 것 같다.

그러니까, 마치 캡쳐하는 것을 떠올리면 된다. 우리가 만든 Instance, 즉 하나의 서버에 우리가 설치해 놓은 세팅들을 그대로 캡쳐해 이미지화하고, 이걸 사용할 수 있게 만드는 것이라고 생각하면 편하다.

AMI에는 3가지가 있는데, 이렇게 만들어놓은 설정을 비공개하고 나만 쓸 수 있도록 하는 private, 공개적으로 누구나 쓸 수 있게 하는 public, 내가 열심히 만들어놓은 이미지를 가져다가 사고 팔 수 있게 하는 Marketplace가 그것이다.

우리는 일단 뭐 이미지도 없으니 이미지부터 만들어야한다. 나만의 인스턴스 꾸미기 이런 느낌! ~~슈의 옷입히기라고 생각하고 해보자.~~

본인이 원하는 대로 선택하면 된다. 나는 Ubuntu Server 18.04를 선택했다.

✔️ 1-2. 원하는 Instance 유형 선택하기

여기에 유형이 자세히 나와있다.

T2는 보통 프리티어 계정일 때 많이 사용한다. 나는 프리티어는 아니지만 T2 micro를 선택했다.

간단히 올리는건데 굳이 큰 용량, 좋은 성능이 필요없을 것이라고 판단했다. 프리티어라고 써있어서 더 눈이 가기도 했고!

✔️ 1-3. 인스턴스의 세부 정보 구성하기

인스턴스 세부 구성에서는 네트워크, 서브넷, Auto Assign Public IP 부분을 수정했다.

네트워크는 가상의 프라이빗 클라우드 공간을 설정하는건데, 각각의 VPC는 완전히 독립된 네트워크처럼 작동한다고 한다.

서브넷은 하나의 IP 네트워크 주소를 지역으로 나누어 하나의 네트워크 IP주소가 여러개로 연결된 지역 네트워크로 사용할 수 있도록 작동한다. 요 두가지 내용에 대해서는 이미 만들어진 친구들에서 골라 사용했다.

마지막으로 Auto Assign Public IP는 외부 IP에서 Instance에 접속할 수 있는지 여부를 지정하는 것이다. 나는 외부에서 접속할 수 있게 해주려고 Enable 속성을 추가했다.

✔️ 1-4. 스토리지 추가

이제 스토리지를 지정한다. 프리티어의 경우는 30GB까지 무료로 사용이 가능하다고 한다.

Volumne Type은 General SSD, Provisioned IOPS SSD, Magnetic을 지원하는데, Provisioned IOPS SSD는 추가로 IOPS를 지정할 수 있고 추가비용도 부과될 수 있다. Magnetic은 SSD보다 성능이 좀 떨어진다고 한다. 그래서 General SSD를 사용했다.

✔️ 1-5. 태그 추가하기

태그는 인스턴스가 많을 때, 어떤 인스턴스가 있는지 확인할 때 사용한다.

라이브서버에서 서비스용도로 태그이름을 생성해 구분지을 수 있다고 한다.

우아한 테크코스 계정은 정말 인스턴스가 많고 혼잡하기때문에 이름을 붙여줬다. ㅎㅎ

✔️ 1-6. 보안 그룹 구성하기

보안 그룹은 어떤 IP, PORT를 오픈할 것인지를 구성할 수 있다.

기존에 보안그룹이 이미 있기 때문에, Select an existing Security Group 안에서 골라줬다.

혹시 몰라서 세부 내용은 가렸다.

✔️ 1-7. 인스턴스를 시작하기 전에, 지금까지 선택한 것들을 검토하기!

내가 고른 것들을 한번 쭉 살펴보고, 잘못된 점이 없다면 우측 하단의 파란색 Launch 버튼을 누른다.

✔️ 1-8. Key Pair 생성

Key Pair는 SSH 접속시 필요한 Key이다. 한번 발급받은 후, 분식하면 찾을 수 없으니 잘 보관해두어야한다!

이 Key를 통해서 우리가 만든 Instance에 터미널로 접근할 수 있다. ㅎㅎ

2. EC2에 인스턴스가 잘 생성된 것을 볼 수 있다!

3. SSH에 접속하기

2에서 만든 인스턴스를 클릭하고, 우측 상단의 [Connect(연결)] 버튼을 눌러준다.

SSH Client Tab에 들어가면 SSH 연결을 할 수 있도록 Terminal Command를 알려준다.

알려준대로 따라하면 된다.

$ chmod 400 grooming-ec2-practice.pem

$ ssh -i "grooming-ec2-practice.pem" .......

그럼 아래와 같이 실행되고, 중간에 나오는 질문은 yes를 선택하면 된다.

크크크 원격지 Host Computer인 EC2 Instance에 잘 접속했다!

그러면 이제 이 원격 컴퓨터에 우리가 아까 위에서 만들어서 github에 올려둔 페이지(Next.js 앱)를 clone받는다.

그리고 일단 EC2에 Node를 설치해주고, 확인도 해준다.

$ sudo apt-get update # 기본적인 업데이트 진행
$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash
$ . ~/.nvm/nvm.sh
$ nvm install node

# 설치 확인작업
$ node -v
$ npm -v # npm은 node를 설치하면 따라 설치된다.
$ node -e "console.log('Running Node.js ' + process.version)"

이제 우리가 만든 a11y-airline 폴더로 들어가 패키지들을 다운받아준다.

$ cd a11y-airline/ # 우리가 만든 a11y-airline 폴더로 들어간다.
$ npm install

패키지를 다운받았으면, 이제 프로젝트를 빌드해준다!

$ npm run build

그러고 우리가 배포할 페이지를 이렇게 시작해준다.

$ npm run start

이제 가상의 컴퓨터에서 내가 만든 앱이 돌아가고 있따!!!!

4. Reverse Proxy 설정

아아.. Proxy는 또 무엇이란말인가.. 예전에 잠깐 사용해 본 기억은 있으나 개념만 스쳐지나갈 뿐 잘 모르겠다.. 정리해보자..

프록시는 익명성을 위해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용프로그램을 말한다.

클라이언트와 서버 사이에 프록시가 존재하고, 그 프록시가 중간에서 대리로 통신을 수행한다.

https://www.psychz.net/client/question/en/what-is-a-reverse-proxy.html

위처럼 생겼다고 생각하면 되는데, 이건 정방향 프록시의 예시다.

어떤 사용자가 프록시 서버를 통해 웹사이트에 들어가려고 하면, 프록시 서버로 요청이 이동한다음 웹 사이트로 전달된다. 서버와 클라이언트가 직접 통신하지 않도록 중간에서 클라이언트의 요청을 자기가 가져가서 서버에 요청을 보낸다. 이렇게되면 요청이 프록시 서버에서부터 시작된걸로 보이기 때문에 서버는 사용자를 알 수가 없게 된다.

반면 Reverse Proxy는 Internet과 Proxy의 위치가 달라진다.

Reverse Proxy는 사용자에게 들어온 요청에 대한 응답을 중간에서 가로채서 마치 자기가 응답해주는 것처럼 행동한다. 즉, 서버가 감춰져서 사용자가 실제 서버의 정보를 알 수 없게된다. 서버의 익명성 유지를 도와주는 친구다.

프록시의 개념에 대해 알아봤다. 다시 프로젝트로 돌아가보자.

그러면 이제 우리가 아까 만들어놓은 인스턴스 링크!를 들어가면 아무것도 안나온다. (What the...)

왜냐하면 우리가 서버를 시작해놨으니, 뒤에 포트 번호를 붙여야 페이지가 로드된다.

이제 리버스 프록시를 적용해 포트 번호를 숨겨주자.

우분투에서는 기본적으로 Redirect를 지원해주기 때문에, 별다른 도구(예를들면 nginx)를 사용하지 않아도 된다.

아래 코드를 입력해 Reverse Proxy를 해주자.

$ `sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3000`

그러면 이제 Public IPv4 DNS 주소로 바로 접속이 가능하다! 헤헤

그런데 여기에는 큰 문제점이 도사리고 있는데.. 바로.. 터미널을 끄거나 내 작고 귀여운 맥북이 자러가게되면 이 배포도 중단된다는 것이다.

이 얼마나 큰 문제란말인가..! 그렇기 때문에 우리는 무중단 배포를 해줄거다.

5. 무중단 배포하기 - pm2 이용하기

무중단 배포를 위한 방법은 정말 여러가지가 있지만, 나는 그 중에서 (가장 쉬워보이는) pm2를 사용했다.

PM2는 Node.js 프로세스 매니저이다. 즉, Node.js로 만들어진 앱에 대한 프로세스 관리를 편하게 해주는 도구다.

PM2 is a daemon process manager that will help you manage and keep your application online. Getting started with PM2 is straightforward, it is offered as a simple and intuitive CLI, installable via NPM. - pm2 공식 홈페이지

PM2는 아래와 같은 특징을 가진다.

- 프로세스를 관찰하다가 프로세스가 종료되면 다시 실행해준다.

- js파일을 수정했을 때, 자동으로 프로세스를 껐다 켠다.

- node.js는 single thread인데 pm2는 cluster라는 기능으로 CPU 코어 수만큼 프로세스를 동시 지원해준다.

- 백그라운드에서도 실행을 유지시켜준다.

- 오류가 나더라도 자동으로 다시 시작된다.

자자 그럼 이제 PM2를 적용해보자!

pm2를 글로벌로 설치해준다.

$ npm install pm2 -g

아래 코드로 pm2 프로세스를 설정해준다.

$ pm2 start npm --name "next" -w -i max -- start

-w 는 파일의 변경이 있으면 알아서 재시작하는 옵션이다.

-i max 는 클러스터모드로, 모든 CPU를 확장시키는 역할을 한다.

--name "next" 는 이름을 next로 하겠다는 것이다.

요 프로세스를 설정해주면, 어마어마한 내용들이 나오면서 프로세스가 설정된다. 이게 끝이다.

이제 무중단 배포가 완료됐다! 와!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

http://ec2-3-36-103-153.ap-northeast-2.compute.amazonaws.com/

ec2-3-36-103-153.ap-northeast-2.compute.amazonaws.com

와 진짜 너무 길고 힘든 여정이었다.

만들고 배포하는건 어렵지 않았지만 세부 내용들을 직접 하나하나 까보면서 하니까 시간 소요가 엄청났다.

그런데 진짜 뭔가 좋았던 건, 몇 년전에 EC2 배포하면서 그냥 까만건 글씨요 하얀건 화면이요 했었는데

지금은 그래도 조금 뭐가 뭔지 알게된 것 같아서 너무 좋았다.

프론트 입장에서 사실 S3 Cloudfront를 거의 썼었는데, EC2에 올리는 방법도 이렇게 같이 알게되니 힘들었지만 꽤나 뿌듯하기도 하고,

마음 한 구석이 든든해졌다. 나도 이제 EC2에 올릴줄 안다 이말이야!!!!!!!!!!!!!!!!!!!!!!!!!!! 이!!!!!!제!!!!!!나!!!!!!!!!!도!!!!!!!!!!EC2!!!!!!!!!!!! 배!!!!!!!!포!!!!!!!할!!!!!!!!!줄!!!!!!!!!!!!!알!!!!!!!!!!!!!!!아!!!!!!!!!!!!

네.

아마 나의 이 Deploy Guide Book이 여기서 멈추진 않을 것 같다 . (오픈 엔딩)

EC2를 통해 또 배포를 할 수 있는 기회가 오면, 틈틈이 다시 보면서 내가 배운 내용들을 하나씩 채워넣고 싶다.

AWS의 세계는 너무 깊고도 넓어 마치 우주같아 ~~ 🪐🪐

그럼 끗!

저작자표시 비영리 변경금지