✅ TIL

---

잘 만들어진 웹 서비스는 배포가 되지 않는다면, 더 이상 의미를 가질 수 없다.
따라서 웹 개발자는 배포에 대한 기본 지식을 탑재하고 있고, 간단한 배포 정도는 혼자 할 수 있어야 한다.

오늘은 배포를 위한 클라우드 서비스 Amazon Web Service(이하 AWS)를 이용해서 웹 애플리케이션을 배포한다.

가상화 기술의 발전과 AWS의 등장은 클라우드 컴퓨팅에 혁신을 불러일으켰다.
만일 AWS가 없었더라면 우리는 아래와 같이 직접 서버를 구축하고, 관리해야 했을지도 모른다.

하지만, 이제는 클릭 몇 번으로 서버를 사용할 수 있고, 확장할 수 있으며, 또한 사용한 만큼 돈을 지불할 수도 있다.

어떻게 이 모든 것들이 가능할까?

이제 클라우드 컴퓨팅의 기본과 배포의 개념, 그리고 AWS가 제공하는
주요 서비스를 직접 다뤄보면서, 이 모든 것이 어떻게 가능한지 배울 것이다.

Amazon Web Service

---

아마존 웹 서비스(AWS)란 아마존이 자사의 노하우를 살려 제공하고 있는 ‘클라우드 컴퓨팅 서비스’를 의미한다.

AWS에는 컴퓨팅, 스토리지, 데이터베이스, 분석, 네트워킹, 모바일, 개발자 도구, 관리 도구, IoT, 보안, 엔터프라이즈 애플리케이션 등 다양한 서비스가 준비되어 있으며, AWS의 다양한 서비스를 조합하여 모든 애플리케이션과 인프라를 구축할 수 있기도 한다. 일전에는 여러 사업자에게 각각 빌려야 했던 인프라를 일괄로 빌릴 수 있게 됐으며, 필요에 따라 운영체제(OS), 웹 서버, DB 서버 등 필요한 소프트웨어까지 통째로 사용할 수 있는 편리한 서비스이기도 하다.

아마존 웹 서비스(AWS)의 특징

AWS의 특징으로는,

• 서비스를 조합하기 쉽다. AWS에서만 제공하는 서비스로도 필요한 기능을 대부분 구축 가능하며, AWS와 AWS 외부 시스템을 조합하여 구축하기 쉽다.
• 앞으로 사용할 양을 미리 생각하지 않고 현재 필요한 만큼만 사용하고 부족해지면 그때마다 추가할 수 있으며, 같은 양을 계속 빌려야 하는 정액제와 차별점이 있다.
• 네트워크 및 서버가 매우 큰 규모가 아니라면 네트워크나 서버 전문가가 아니더라도 사용 가능하다.
• 현재를 기준으로 전 세계 31개의 지리적 리전 내에 99개의 가용 영역을 운영하고 있어, 글로벌로 확장 시 확장하고자 하는 지역과 지리적으로 가까운 리전에서 서비스 시작 가능하다.
• 한국어 지원 및 원화 결제 가능하며, 보안 관련하여 법령, 규정, 프라이버시 기준을 준수하고 있는 안전한 서비스이다.

이런 AWS는 165개 이상의 서비스를 제공하고 있으며, 목적에 따라 다양한 서비스를 사용할 수 있다.

그중 유명한 서비스로는 EC2, S3, RDS 등이 있다.

EC2

---

• 장점
  • 몇 번의 클릭만으로 PC를 구성하므로, 필요한 시간이 짧다.
  • AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능하다.
    • 운영체제뿐만이 아니라 CPU와 RAM, 용량까지도 손쉽게 구성할 수 있다.
  • 사용한 만큼만 비용을 지불한다.
    
    

EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있다.

빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에
만들어져 있기 때문에 컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해서 컴퓨터를 제어해야 한다는
차이점이 있을 뿐 일반적인 컴퓨터와 다른 점은 없다.

아마존 EC2를 통해서 할 수 있는 가장 기본적인 일은 웹서버를 설치하고
웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것이다.

인스턴스는 1대의 컴퓨터를 의미하는 단위이고, AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 한다.

RDS

---

RDS는 Relational Database Service의 약자로 AWS에서 제공하는 관계형 데이터베이스 서비스이다.

왜 RDS를 사용할까? 우리는 이전 슬라이드에서 EC2가 가상의 컴퓨터를 임대하는 서비스라고 배웠다.
EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진을 설치하면 굳이 RDS를 사용할 이유가 없지 않을까?

데이터베이스만 따로 분리해서 서비스를 이용해야 할 이유가 있을까?

EC2 인스턴스에 관계형 데이터베이스 엔진을 설치해서 데이터를 관리할 때와 RDS를 통해
데이터를 관리할 때의 차이는 개인 소유 차량과 렌터카 회사에서 대여한 차량으로 비유할 수 있다.

EC2 인스턴스에 데이터베이스를 설치하여 데이터를 관리하는 것은 개인 소유 차량을 이용하는 것과 비슷하다.
개인 소유 차량을 이용하면 유지 보수, 보험처리 같은 일들을 온전히 운전자가 부담한다.

차량 정비를 위해서 정비소에 주기적으로 방문해야 하고,
기타 차량과 관련된 다른 일이 생길 때 들여야 하는 시간과 수고가 크다.

EC2 인스턴스를 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기 때문에,
사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 한다.

게다가 가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로
사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어렵다.

그에 비해 RDS를 이용하는 것은 렌터카 회사에서 차량을 대여하는 것과 비슷하다.

렌터카 회사에서 차량을 대여하면 대여 차량과 관련하여 시간이 들어가는 일들을 렌터카 회사에서 대신 처리한다.
운전자는 차량을 관리하는 일에 대해서 시간을 따로 쏟을 필요 없이 운전만 하면 되기에 매우 편리하다.

RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리한다.

사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에
저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있다.

S3

---

S3가 무엇인지 알아보기 전에, 클라우드 스토리지 개념에 대해 잠시 알아보겠다. 클라우드 스토리지란 뭘까?

클라우드 스토리지란 쉽게 말해서 인터넷 공간에 데이터를 저장하는 저장소이다.
컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스이다.

우리는 알게 모르게 클라우드 스토리지 서비스를 이용해왔다.
구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스가 예시이다.

클라우드 스토리지 서비스는 뛰어난 접근성을 가지고 있다.
컴퓨터의 하드디스크에 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 한다.

그러나 클라우드 스토리지를 이용하면 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있다.
또한 컴퓨터뿐만 아니라 웹에 접속이 가능한 다른 전자기기를 활용하여 클라우드 스토리지에 접속할 수 있다.

S3는 Simple Storage Service의 약자로 AWS에서 제공하는 클라우드 스토리지 서비스이다.

• 장점
  1. S3도 마찬가지로 뛰어난 접근성을 가지고 있다.
  2. 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있는 높은 확장성이 있다.
     • 또한 S3에서는 스토리지의 용량을 무한히 확장할 수 있다.
       그리고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적이다.
  3. 내구성이 높으면 저장된 파일을 유실할 가능성이 적어진다. S3는 99.999999999%의 내구성을 보장한다.
     • (S3에 저장된 파일을 잃어버릴 확률보다, 길을 걷다가 벼락을 맞을 확률(약 0.0000007%의 확률)이 700배나 더 높다.)
  4. 가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어진다.
     S3는 연간 99.99%의 스토리지 가용성을 보장하도록 설계가 되어 있다.
  5. 다양한 스토리지 클래스를 제공한다. 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라진다. 대표적으로 많이 선택하는 스토리지 클래스는 두 가지가 있다.
     • Standard 클래스: 범용적인 목적으로 사용하기 좋다. 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르다. 대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아니다. 보관 비용이 높게 발생하기 때문이다.
     • Glacier 클래스: 장기적인 보관 목적으로 스토리지를 사용하실 때는 Glacier를 사용하는 것이 효율적이다. 비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있다.
  6. 정적(서버의 개입 X) 웹 사이트 호스팅(서버의 한 공간을 임대해 주는 서비스)이 가능하다.
     버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공한다. 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다.

버킷이란 S3에 저장되는 파일들이 담기는 바구니이다. 파일을 저장하는 최상위 디렉터리라고도 설명할 수 있다.

S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있다.
그리고 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 한다.

또한 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있다.

S3에서 버킷에 담기는 파일을 객체라고 부른다. 왜 객체라고 부를까?
S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문이다.

S3에 저장되는 객체는 파일과 메타데이터로 구성된다. 파일에 대해서 먼저 알아보겠다.
파일은 위에 설명한 대로 키-값 페어 형식으로 데이터를 저장한다.

• 파일의 값에는 실제 데이터를 저장한다. S3 객체의 값으로써 저장될 수 있는 데이터의 최대 크기는 5TB이다.

• 파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 한다.
  파일의 키를 이용하여 원하는 객체를 검색할 수 있다.

• 메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터이다.
  객체를 설명하는 데이터라고 이해하면 좋다.

모든 객체는 고유한 URL 주소를 가지고 있다.

URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고,
URL 주소를 통해서도 원하는 데이터에 접근할 수 있다.

배포 전략

---

작성한 Client 코드를 사용자들에게 어떻게 제공할지 생각해보자.

AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 Client를 제공할 수 있다.

로컬 환경에서는 자체 개발 서버 (예, create-react-app)를 이용해서 클라이언트 앱을 실행시키는 것이 보통이다.
그럼, 클라이언트를 위해서 EC2 인스턴스를 사용해야 할까?

그렇지 않다. 클라이언트 앱을 정적 파일로 빌드하여 제공한다.
따라서 S3를 이용해서 클라이언트를 배포해야 한다.

이때 필요한 것이 빌드이다.

빌드란 쉽게 말해서 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는
데이터들을 통합/ 압축하여 배포하기에 최적화된 상태를 만드는 것이다.

빌드 과정을 진행하기 전과 비교했을 때 데이터의 용량이 줄어들고,
웹 사이트의 로딩 속도가 빨라진다는 장점이 생긴다.

하지만 일반적인 의미의 빌드는, 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미한다.
웹 앱에서와같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다르다.

웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 한다.

그렇다면, 사용자들이 제공받은 Client Application을 통해서
요청을 전달할 Server Application은 어떻게 배포해야 할까?

AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있다.

백엔드 배포 실습

---

repository 주소의 main 브랜치를 이용한다.

• 서버 배포 (EC2)
  • EC2 콘솔을 통해 EC2 인스턴스를 생성해야 한다.
  • 간단한 서버 애플리케이션을 생성하고 EC2 인스턴스에 코드를 배포해야 한다.
  • 서버를 실행시키고 브라우저에서 서버에 접속할 수 있어야 한다.
• Getting Started
  • 이번 스프린트는 JWT 인증 방식을 사용한다.
  • 발급된 JWT 토큰을 Local Storage에 저장하는 방식을 사용하면 웹 사이트 주소에 HTTPS를 적용할 필요가 없다.
  • .env.example 파일을 보며 어떤 환경 변수들이 정의되어 있는지 확인한다. (나중에 실습을 진행할 때 주요한 역할을 한다)
• 서버 배포가 완료되었을 때 확인 방법
  • 
  • 서버 배포 성공 시 'hello World' 응답을 받는다.

IAM 확인 및 로그인 튜토리얼

메일로 전달받은 링크에 접속해서, 로그인이 잘 되는지 확인한다.

계정 ID와 같은 부분은 이미 지정이 되어 있는 부분이므로, 그 부분을 제외한
사용자 이름(메일로 전달받은 login)과 암호(메일로 전달받은 password)를 입력한다.

아래 화면이 잘 보인다면 IAM이 정상적으로 잘 생성되었다.
오른쪽 상단에, 현재 리전이 서울로 설정이 되어있는지 추가로 확인한다. 서울이 아니면, 리전을 서울로 변경한다.

IAM 확인 및 로그인 튜토리얼

이번 실습에서 사용하는 EC2는 미리 생성이 되어있다.
AWS 콘솔에서 EC2를 검색하거나, 직접 클릭해서 EC2 대시보드로 이동한다.

인스턴스(실행 중)을 클릭해 들어가 자신이 부여 받은 EC2 인스턴스를 검색한다.
EC2 인스턴스의 이름은 메일로 전달 받은 login에서 student를 제외한 나머지 부분이다.
(ex. 전달받은 login이 fe-student-0-kimploo라면, EC2 인스턴스 이름은 fe-0-kimploo 이다.)
이어 검색된 EC2 인스턴스를 클릭하고, "연결"을 클릭한다.

이어 터미널을 bash로 변경해주면 이후 실습 과정과 동일하게 진행할 수 있다.
아래는 bash로 변경해주고 제일 최상단 디렉토리로 올라가는 명령어이다.

$ bash
$ cd ~

EC2 인스턴스 상에서 서버 실행 튜토리얼

---

지난 튜토리얼에서는 부여 받은 EC2 인스턴스를 확인하고 브라우저로 열린 터미널을 통해 연결 상태까지 확인했다.
이번 튜토리얼에서는 부여 받은 EC2 인스턴스를 이용해 서버를 실행하고 접속해 보겠다.

1. 인스턴스에 개발 환경 구축하기

---

우리는 EC2 인스턴스를 생성하는 것이 가상 PC 한 대를 임대하는 것이라고 배웠다. 컴퓨터 운영체제를 처음 구입하면 필요한 프로그램을 설치해야 하듯이, EC2 인스턴스에 처음 접속하면 서버를 구동하는 데 필요한 개발 환경을 구축하는 것부터 시작해야 한다. 저번 실습에서 EC2 인스턴스와 연결한 터미널에서 아래 명령어를 입력한다. 패키지 매니저가 관리하는 패키지의 정보를 최신 상태로 업데이트하기 위해서 아래 명령어를 사용한다.

$ sudo apt update

어느 정도의 시간이 지나고 업데이트 과정이 끝나면 nvm과 node.js를 설치해야 한다.

먼저 nvm 설치는 NVM GitHub 페이지의 Install & Update Script 부분을 참조했다.

wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash // nvm 설치

export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s 
"${XDG_CONFIG_HOME}/nvm")" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" // This loads nvm

설치 과정이 마무리되면 터미널에 nvm --version 명령어를 입력하여 nvm 설치가 정상적으로 끝났는지 확인한다.
명령어를 입력했는데 오류가 난다면 nvm 설치 과정이 정상적으로 마무리되지 않은 것이다.

다음으로는 node.js를 설치한다. 터미널에 아래 명령어를 입력하여 설치를 진행한다.

$ nvm install node 

명령어를 사용하면 아래 그림과 같이 설치가 진행이 된다.

node.js의 설치가 끝나면 npm 명령어가 정상적으로 입력되지 않는 상황을 방지하기 위해서 터미널에

$ sudo apt install npm

명령어를 입력해서 npm 설치를 진행한다.

설치를 진행 후 npm --version 명령어를 입력하여 npm 설치가 정상적으로 마무리 되었는지 확인한다.
정상적으로 마무리 되었다면 nvm과 마찬가지로 버전이 출력 된다.

위 과정이 모두 끝나면 node.js 기반 서버를 실행하는 데 필요한 개발 환경 구축이 완료된다.

2. git을 통해 서버 코드 클론 받기

---

홈 디렉토리로 이동한 후, 과제 코드가 저장된 깃헙 레포지토리 주소를 복사하고,
git clone 명령어를 통해 EC2 인스턴스에 과제 코드를 클론 받는다.

클론 받기 전, 완전히 다른 환경의 터미널에서 클론을 받는 것이기 때문에 학습 초기에 로컬 컴퓨터에 git clone을 위해 진행했던 Git SSH 등록이 필요하다. 기존에 했던 과정을 다시 복습해 보며 SSH를 등록한 뒤, 과제를 클론받는다.

위 사항을 따라서 AWS SSH keys를 새롭게 등록해줬다.

💡 기존 SSH를 두고, 왜 SSH를 다시 등록할까?
👉 아마존 AWS EC2에서 새로 작업 환경을 부여받은 것이므로, 다시 설정이 필요하다.

// # 홈 디렉토리로 이동
ssm-user@ip-172-31-33-2:~$ cd ~

// # git clone
ssm-user@ip-172-31-33-2:~$ git clone git@github.com:codestates-seb/fe-sprint-practice-deploy.git
Cloning into 'fe-sprint-practice-deploy'...
...

// yes를 입력해야 정상적으로 clone이 진행된다.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
remote...

// 정상적으로 클론했는지 확인하기 위해, 터미널에 ls 명령어를 입력한다.
ssm-user@ip-172-31-33-2:~$ ls
fe-sprint-practice-deploy

// 터미널을 통해 스프린트 코드 안의 server 디렉토리로 이동한다.
cd fe-sprint-practice-deploy/server/
  
// server 폴더로 이동한 뒤, npm install 명령어를 입력해서 필요한 모듈을 다운로드한다.
ssm-user@ip-172-31-8-224:~/fe-sprint-practice-deploy/server$ npm install

added 99 packages, and audited 100 packages in 3s

8 packages are looking for funding
  run `npm fund` for details

2 moderate severity vulnerabilities

To address issues that do not require attention, run:
  npm audit fix

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.

3. EC2 인스턴스에서 서버 실행하기

---

npm install 명령어를 이용한 설치 과정이 완료되면 npm start 명령어를 이용해서 서버를 실행한다.
그럼 아래와 같은 오류 메시지가 터미널에 보인다.

위 오류 메시지가 보이는 이유는 1024번 아래의 포트 번호를 이용해서 서버를 실행하려면 관리자 권한이 필요하기 때문이다.
관리자 권한으로 서버를 시작하기 위해서는 sudo npm start 명령어를 입력해야 한다.

그럼 위와 같은 메시지를 통해 정상적으로 서버가 실행되었음을 확인할 수 있다.

4. EC2 인스턴스의 IP 주소로 접근하기

---

이제 EC2 인스턴스의 IP 주소로 접근해서 테스트를 진행한다.
IP 주소는 EC2 대시보드에서 생성한 EC2 인스턴스를 클릭하면 확인할 수 있다.

아래 화면에서 보라색으로 강조된 부분을 보면, 두 가지 형태의 주소가 존재하는 것을 확인할 수 있다.
퍼블릭 IPv4 주소와 퍼블릭 IPv4 DNS는 형태만 다를 뿐 같은 주소이다. 둘 중 어떤 주소를 사용해도 문제없다.

이번 실습에서는 퍼블릭 IPv4 DNS 주소를 이용하여 접속 테스트를 진행하겠다.

EC2 인스턴스의 IP 주소로 접속했을 때, hello world를 확인할 수 있으면 성공이다.

또한 EC2 서버를 확인해 보면 GET 요청이 찍혀 있는 것을 확인해 볼 수 있다.

프론트엔드 배포 실습

---

앞선 슬라이드를 통해 S3에 대한 개념 학습을 완료했다.

이번 스프린트에서는 코드 작성이 완료된 애플리케이션의
클라이언트 코드를 AWS 서비스를 통해 배포하는 실습을 진행하겠다.

repository 주소의 main 브랜치를 이용한다.

• 클라이언트 배포 (S3)
  • S3 콘솔을 통해 버킷을 생성해야 한다.
  • 클라이언트 파일을 빌드하고 결과물을 버킷에 업로드해야 한다.
  • 정적 웹 호스팅 기능을 이용하여 클라이언트 코드를 배포해야 한다.
• Getting Started
  • 이번 스프린트는 JWT 인증 방식을 사용한다.
  • 발급된 JWT 토큰을 Local Storage에 저장하는 방식을 사용하면
    웹 사이트 주소에 HTTPS를 적용할 필요가 없다.
  • .env.example 파일을 보며 어떤 환경 변수들이 정의되어 있는지 확인한다.
    (나중에 실습을 진행할 때 주요한 역할을 한다)
• 클라이언트 배포가 완료되었을 때 확인 방법
  • EC2 인스턴스로 서버를 켜둔 상태에서 S3 버킷으로 정적 웹을 호스팅한 뒤
    생성된 엔드포인트 주소에 접속하여 테스트를 진행한다.
  • 
  • 위 화면이 보인다면 이름 입력란에 "김코딩"을,
    비밀번호 입력란에 "1234"를 입력하여 로그인 테스트를 진행한다.

S3 정적 웹 호스팅 튜토리얼

---

이번 실습에서는 코드스테이츠에서 제공하는 자신의 S3 버킷을 사용하여 프론트엔드 배포 실습을 진행한다.
먼저 AWS 콘솔에서 S3를 검색한다.

아래 스크린샷을 참고하여 자신의 github login id로 검색하면 자신의 버킷을 검색할 수 있다. EC2와 마찬가지로 S3 버킷 이름 또한 메일로 전달 받은 login에서 student를 제외한 나머지 부분이며, 뒤에 s3가 붙어 있다. (ex. 전달받은 login이 fe-student-0-kimploo라면, S3 버킷 이름은 fe-0-kimploo-s3 이다.)

이번 실습에서는 클라이언트 번들을 업로드해야 한다. 클라이언트를 번들링할 수 있는 과제가 미리 준비되어 있다. 배포 과제의 client 디렉토리를 잘 클론해왔다면, 배포 시 정확한 서버로 요청을 보내기 위해 .env 파일을 생성하고, 아래 파일과 같이 작성한다. .env.example 파일을 참고하여 REACT_APP_API_URL의 값으로 아까 실습했던 EC2 서버의 주소를 넣는다.

.env 파일을 따로 제공하지 않는 이유는, .env 파일의 경우 중요 보안 정보를 담고 있는
경우가 많아서 .gitignore에 포함하여 외부에 공개하지 않는 것이 원칙이기 때문이다.

그리고 npm install, npm run build 스크립트를 실행한다. create-react-app으로 만든 프로젝트는 이렇게 바로 번들링이 가능하여 빠른 배포가 가능하다. 실행 결과는 build 디렉토리에서 확인할 수 있다.

이제부터 S3 버킷에 빌드한 파일들을 업로드하겠다. 먼저 build 디렉토리 내 모든 파일을 버킷의 루트 넣는다.
폴더와 파일을 구분해서 단위 별로 잘 업로드하도록 한다.

업로드가 성공했다는 초록색 박스가 위에 뜨는 걸 확인했다면, 닫기를 눌러 자신의 버킷으로 돌아간다.

추가적으로, 업로드 시 build 폴더 자체를 넣지 않도록 주의해야 한다.

build 폴더 자체를 넣게 되면 이후 정적 웹 사이트 호스팅 주소를 통해 접근 시,
업로드 된 객체들을 찾을 수 없게 되어 404 Not Found 화면이 출력된다.

다시 업로드가 잘 완료된 버킷으로 돌아온 후, 지금부터는 버킷을 외부에서도 접근할 수 있게끔 세팅을 해줘야 한다.

해당 버킷은 현재 "private" 상태이다. 한글로는 "버킷 및 객체가 퍼블릭이 아님" 상태로 떠 있는 것을 확인할 수 있다. 이 상태로는 정적 웹 호스팅이 활성화 되어 있더라도, 버킷에 외부에서 접근할 수 없기 때문에 403 Access Denied 라는 화면이 출력된다.

먼저 퍼블릭 엑세스 차단 부분을 수정하겠다. 퍼블릭 엑세스 차단 밑의 편집 버튼을 누른다. 그러면 아래와 같은 페이지가 뜬다. 그림처럼 체크박스를 클릭해 차단을 해제한다. 그리고 변경 사항을 저장하면 필드에 확인을 입력하라는 모달창이 뜬다. 확인이라는 단어를 입력하고 확인을 눌러준다.

다시 권한 설정 페이지가 뜬다. 새로고침을 해서 동기화를 시켜주면 아까와 달라진 점이 눈에 띈다. 버킷의 퍼블릭 엑세스 차단이 해제 되었기 때문에, 액세스 부분에는 "객체를 퍼블릭으로 설정할 수 있음" 이라고 상태가 변경이 되어 있고 모든 퍼블릭 액세스 차단 부분이 "비활성" 상태로 변경이 되어 있음을 확인할 수 있다.

이제 버킷 정책도 수정한다. 버킷 정책 옆에 편집 버튼을 눌러주면 아래와 같은 화면이 뜬다.

정책을 입력하는 필드에 아래와 같은 코드를 입력한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::{자신의 s3 버킷 이름}/*"
        }
    ]
}

글쓴이는 "widrns15"의 버킷 명을 입력했다. 위의 버킷 ARN을 보면 중간의 fe부터 s3 부분이 버킷 명임을 알 수 있다.

변경 사항을 저장하면 다시 권한 페이지로 돌아간다. 돌아가면 버킷 정책 섹션에 넣어준 정책을 확인할 수 있다.

이제 속성 탭으로 들어가, 맨 밑의 정적 웹 사이트 호스팅 섹션을 확인한다.
버킷 웹 사이트 엔드포인트가 생성되어 있는 걸 확인할 수 있다. 해당 링크로 접근한다.

접근하면 새로운 창이 열린다. 배포에 성공했다면 아래와 같은 화면이 출력되는 것을 확인할 수 있다.

🔥 Review

---

로그인 화면의 이름 부분에는 김코딩, 비밀번호 부분에는 1234를 입력하여 로그인이 되는지 확인해봤다.

정상적으로 클라이언트 브라우저 창은 로그인과 로그아웃이 되는 것을 확인했고,
서버는 클라이언트의 요청에 대해 응답을 잘 보내주고 있는 상태임을 확인할 수 있었다.

💡 Error Note.

---

💡 서버는 AWS EC2에, 클라이언트는 Vscode에.

• 초반에 EC2 터미널 창에서 cd/client로 클라이언트 폴더로 들어가서
  nano로 .env 파일을 만들고 한 번에 작업을 시도했으나, 실패해서 vscode로 구현했다.
• 서버는 작동하나, 만든 .env 파일이 인식되지 않는 것처럼 보였다.
  • 
  •