220325(28) D+67(68) 백엔드&프론트엔드 배포, 데이터베이스 연결

1. 백엔드 배포

① EC2 인스턴스 생성 및 연결

 

EC2를 검색하여 EC2 메뉴에 들어온 다음, 리전을 현재 있는 위치와 가깝게 지정해준다(지금은 아시아 태평양(서울)).

그 다음 인스턴스 시작 버튼을 클릭한다.

 

 

용도에 맞게 AMI를 선택해준다.

프리 티어만 체크박스에 체크해주고, Ubuntu Server 18.04(우분투 인스턴스를 생성하기 위해)를 선택해준다.

(20버전은 이슈가 발생할 수 있기 때문에 18버전을 권장한다.

프리티어만 체크박스에 체크하지 않았을 시, 요금이 부과될 수 있다.)

 

인스턴스 유형을 선택하는 과정으로 생성하는 인스턴스의 CPU, RAM, 용량에 대한 선택이 가능하다.

이번 실습 과정에서는 프리티어 사용 가능 태그를 확인하여 과금되지 않은 유형인 t2 micro를 선택했고,

검토 및 시작을 누른다.

 

시작하기 버튼을 누르면 다음과 같은 창이 뜬다.

생성되는 인스턴스를 원격으로 제어하기 위해 SSH 연결을 통한 원격 접속이 필요하다.

원격 접속을 위해 필요한 키를 생성하고 다운로드하는 과정.

새 페어 생성을 하고 키 페어 이름을 설정한 후 키 페어를 다운로드 하면 인스턴스 시작이 활성화되어

인스턴스 시작 버튼을 누르면 인스턴스를 시작한다.

 

 

인스턴스 탭에 들어가면 생성된 인스턴스를 확인할 수 있다.

Name 부분을 아까 지정한 키 페어 이름으로 수정해주면 알아보기 편하다.

 

로컬 터미널에서 SSH 프로토콜을 이용하여 인스턴스와 연결을 해줄 수 있다.

먼저 터미널을 켜서 chmod 400 ~/다운로드한 키 페어 파일(.pem)의 경로 

명령어를 입력하여 키 페어 파일의 권한을 수정해준다.

그 다음 위의 사진에 나와있는 예시 링크를 복사하여 터미널에 붙여넣어준다.

 

SSH 명령어를 올바르게 입력하면

Are you sure you want to continue connecting(yes/no/[fingerprint])?라는 문장이 나오는데,

yes를 타이핑하고 엔터를 친다.

 

터미널에 이렇게 나오면 SSH 프로토콜을 이용한 원격 접속이 성공적으로 연결 된 것이고,

명령어를 통해 AWS에서 빌린 가상 PC를 사용할 수 있다.

 

✷ SSH 프로토콜

서로 다른 PC가 인터넷과 같은 Public Network를 통해 통신을 할 때 보안상 안전하게 통신을 하기 위한 통신 규약.

주고받는 데이터를 암호화해서 해당 키 페어를 가지지 않은 사람은 통신되는 데이터를 알아볼 수 없기 때문에

보안상 안전한 통신 방법.

 

✷ .pem 확장자를 가지고 있는 파일은 SSH 통신을 위한 키 페어 중 프라이빗 키가 기록된 파일.

EC2 인스턴스에 연결할 때 사용하는 암호가 담긴 파일이기 때문에 관리에 유의할 것.

 

 

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

패키지 매니저가 관리하는 패키지의 정보를 최신 상태로 업데이트하기 위해서 아래 명령어를 사용한다.

sudo apt update

 

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
명령어 둘 중 하나 사용할 것

터미널 껐다가 다시 시작해서 ec2 인스턴스 터미널 들어간 후에
nvm --version 명령어로 nvm 버전 확인
nvm install node 명령어로 node.js 설치

sudo apt install npm으로 npm 명령어가 정상 입력되지 않는 상황을 방지해준다.

 

git clone으로 깃헙 레포지토리 주소를 클론 받는다.

원하는 경로로 이동한 후 npm install 명령어로 필요한 모듈을 다운받는다.

 

node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by node)

 

 

③ 보안 그룹 설정하기

(아직 sudo npm start 명령어를 사용한다고 해서

제대로 된 서버가 열리지 않기 때문에 보안 그룹부터 설정해줘야 함)

 

✷ 보안그룹

인스턴스로 들어가고(인바운드) 나가는 트래픽(아웃바운드)에 대한 가상 방화벽

⇒ EC2 인스턴스를 생성하면 기본적으로 SSH 접속을 위한 SSH 규칙만 생성되어 있고,

    나가는 모든 트래픽을 허용한다.

 

‣ 인바운드 규칙

: EC2 인스턴스로 들어오는 트래픽에 대한 규칙으로

규칙에 허용되지 않은 규칙은 인스턴스로 접근하지 못하도록 필터링된다.

 

‣ 아웃바운드 규칙

: EC2 인스턴스에서 나가는 트래픽에 대한 규칙.

 

인바운드 규칙 편집 버튼을 눌러 인바운드 규칙을 설정한다.

 

규칙 추가를 눌러 인바운드 유형과 허락하는 포트의 범위를 지정하여 추가하고, 끝났으면 저장을 해준다.

 

 

④ pm2

: node.js로 실행되는 프로그램(프로세스) 관리, 백그라운드에서 실행되게 만들 수 있음.

npm install pm2 -g 명령어로 pm2 설치
pm2 start 파일이름
pm2 stop 프로세스 중지
pm2 restart  프로세스 재시작
pm2 ls   프로세스 목록 보기
pm2 log  프로세스 로그 보기

차례대로 입력하여 authbind 설치
sudo apt-get update
sudo apt-get install authbind
sudo touch /etc/authbind/byport/80
sudo chown ubuntu /etc/authbind/byport/80
sudo chmod 755 /etc/authbind/byport/80
authbind --deep pm2 update
authbind --deep pm2 start app.js

 

2. 프론트엔드 배포

① 정적 웹 페이지 빌드

✷ 빌드

: 작성한 코드의 불필요한 데이터를 없애고,

통합 / 압축하여 배포하기 이상적인 상태를 만드는 과정.

⇒ 빌드 과정을 통해 코드를 담고 있는 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다.

 

EC2 인스턴스를 종료하고, 로컬 터미널로 들어와 레포지토리를 다시 클론해온 후,

client 파일 내에 있는, 환경 변수를 담은 .env 파일의 이름이 .env.example로 되어 있다면 .env로 바꿔주고

내용을 수정해준다.

REACT_APP_API_URL은 http://퍼블릭 IPv4 DNS 로 수정하고 저장한다.

npm run build 명령어로 빌드 과정을 진행한다.

Compiled successfully 가 뜨면서 빌드 과정이 마무리되고, build라는 폴더가 생성된 것을 알 수 있다.

 

② S3 콘솔에 접속하여 버킷 생성하기

S3를 검색하고 버킷 만들기 클릭.

 

버킷 만들기 버튼을 클릭하고

버킷 이름은 각 리전에서 고유해야 하기 때문에 똑같이 따라하면 생성이 안 됨.

이름은 알아서 생성할 것.

가장 아래로 이동하여 버킷 만들기 버튼 클릭.

 

만들어진 버킷 이름을 클릭하여 속성 탭으로 들어가서

제일 아래로 내려 정적 웹 사이트 호스팅 메뉴의 편집 기능 클릭,

정적 웹 사이트 호스팅 비활성화 되어 있는 것을 활성화로 바꾸고

밑에 있는 인덱스 문서와 오류 문서는 전부 index.html로 기입하기.

그 다음 변경 사항 저장.

 

정적 웹 사이트 호스팅 옵션을 성공적으로 편집했다는 메시지와 함께 속성 메뉴 페이지로 리디렉션 되고,

페이지의 가장 아래로 스크롤을 내려서 방금 편집했던 정적 웹 사이트 호스팅 옵션 부분으로 이동한다.

버킷 웹 사이트 엔드 포인트 생성된 것을 클릭하면 403 Forbidden이 나오는데,

버킷에 정적 웹 페이지 파일을 아직 업로드하지 않았고, 퍼블릭 액세스 설정 변경과 정책 생성을 하지 않았기 때문이다.

 

 

③ 퍼블릭 액세스 설정 변경 및 정책 생성하기

객체 탭을 누르고 업로드 클릭하여

client에 생성된 build 폴더 내의 있는 폴더와 파일들을 전부 드래그 앤 드롭하여 업로드 버튼 클릭.

(폴더 자체를 가져가는 것이 아닌 안에 있는 것들을 가져가는 것이다. 다른 것!)

 

업로드에 성공하면 상태에 성공이라고 뜬다.

 

다시 버킷을 클릭하여 권한 탭으로 간다.

편집 버튼을 누르고 체크 박스를 해제하고 변경 사항 저장 버튼을 클릭한다.

경고 창에 확인 기입하고 다음 과정으로 넘어간다.

 

버킷 퍼블랙 액세스 차단 변경 후 다시 권한 탭으로 리디렉션 되는데,

버킷 정책 옵션을 찾아 편집 버튼 - 정책 생성기 클릭.

 

Principal 옵션은 권한을 적용할 사용자를 정하는 것이다. 모두에게 공개하려면 *

GetObject 옵션을 선택하면 버킷에 접근하는 모든 사용자가 버킷 내에 저장된 객체 데이터를 읽을 수 있게 된다.

버킷을 웹 사이트 용도로 구성할 때 선택해 주면 좋다.

Generate Policy 버튼까지 누르면 json 형태로 정책이 뜨는데, 그대로 복붙하기.

 

정책 붙여넣고 변경 사항 저장하기.

잘 실행되는지 확인하려면 속성 탭으로 가서 정적 웹 사이트 호스팅 옵션에서 버킷 웹 사이트 엔드 포인트 주소 클릭.

화면이 정상적으로 출력되면 마무리.

 

클라이언트 배포 후, S3 버킷에서 엔드포인트를 클릭하여 들어가

아이디에 김코딩, 비밀번호에 1234를 입력하고 로그인했을 때 이런 메시지를 볼 수 있다면

일단 클라이언트 배포까지는 성공한 것이다.

다음으로 RDS 데이터베이스 생성 및 연결까지 해주어야 완성.

 

 

3. 데이터베이스 연결

① RDS 인스턴스 생성

AWS 메인 콘솔 창에 RDS를 검색하고 사이드 바에 위치한 데이터베이스 클릭.

데이터베이스 생성 클릭.

 

엔진 옵션에서 MySQL 선택 후 밑으로 내려서 템플릿 옵션에 프리 티어 선택.

 

마스터 사용자 이름과 암호는 데이터베이스를 연결할 때 쓰이는 정보이므로 꼭 기억해둘 것

(꼭 영어+숫자로 섞어 쓰지 않아도 상관은 없었음)

 

보안 그룹을 launch-wizard-1로 지정해주지 않았더니 mysql 연결 시 ERROR 2003 떴음.

그리고 연결 옵션에 퍼블릭 엑세스 가능 부분을 "예" 로 설정할 것.

추가 연결 구성 토글을 열어 데이터베이스 포트를 13306으로 지정하여 포트 번호 노출을 방지한다.

+) 아예 안될때는 rds 데이터베이스를 완전히 삭제하고 다시 만들어보는 것도 도움이 됨.

무조건 launch-wizard 보안그룹으로만 하지 않고 default로 해도 잘 되는데 이유를 모르겠다.

알게 되면 이유도 추가해서 적어넣어야지.

 

추가 구성 토글을 열어 데이터베이스 이름을 test로 설정할 것.

(서버 코드가 test 데이터베이스를 찾도록 작성되어 있으므로 다른 이름 사용 X)

생성하는 데에는 시간이 오래 걸리기 때문에 사용 가능이라고 뜨면 DB 인스턴스 생성 완료.

 

 

② MySQL 클라이언트를 활용하여 DB 인스턴스에 연결하는 과정

연결 & 보안 메뉴 부분에 엔드포인트와 포트 번호를 확인할 수 있다.

주소 복붙 후 로컬 터미널에 다음의 명령어를 입력한다.

mysql -u 마스터이름 --host 엔드포인트 주소 -P 포트번호 -p

P와 p 대소문자 틀리게 쓰면 연결 안됨.

 

잘 연결되면 이런 문구가 뜬다.

데이터베이스 연결 테스트를 위해 SHOW DATABASES; 명령어를 통해 데이터베이스 목록에 test 있으면 성공.

 

③ 서버 환경 설정

EC2 인스턴스에서 pm2 혹은 node / npm 명령을 통해 실행되고 있는 서버는

그 자체로만 작동되고 있을 뿐 데이터베이스에 연결한 것은 아니다.

서버의 환경 설정을 통해 rds 인스턴스에 접속하고 클라우드 DB를 사용할 수 있게 해본다.

 

(혹시 pm2나 node / npm 명령을 통해 서버가 실행되고 있다면 꼭 서버를 종료해준다!)

 

.env 파일명이 .env.example로 되어있다면 .env로 바꿔준다.

mv .env.example .env

 

server 디렉토리로 이동 후 .env 파일을 열어준다.

nano .env

(vim을 열어도 상관은 없는 것 같다. 나는 nano가 익숙하다.)

 

.env 파일에는 4개의 환경변수가 저장되어 있으므로, 특정 값을 저장해주어야 한다.

첫번째 변수 DATABASE_HOST에는 아까 생성해준 DB 인스턴스의 엔드포인트 주소를 넣어준다.
RDS > 데이터베이스 > 연결 & 보안 탭으로 가면 엔드포인트가 적혀있으니 복붙할 것.
여기서 http나 https는 앞에 붙이지 않은채로 엔드포인트만 복붙해줄 것.

두번째 변수 DATABASE_USER에는 아까 RDS 인스턴스에서 데이터베이스 생성했을 때 
지정해주었던 마스터 사용자 이름을 넣어준다
(나의 경우에는 admin)

세번째 변수 DATABASE_PASSWORD에는 마찬가지로 지정해주었던 마스터 암호를 넣어준다.

네번째 변수인 DATABASE_PORT에는 DB 인스턴스의 포트 번호를 넣는다.
(나의 경우 13306)

특정 값 입력 후 ctrl+X 버튼으로 y, 엔터 키를 차례대로 눌러주면 저장된다.

 

그 다음

sudo npm start
혹은
authbind --deep pm2 stop app.js // 프로세스 정지
authbind --deep pm2 start app.js // 프로세스 시작

명령어로 서버(프로세스)를 실행해준다.

 

④ S3 버킷 엔드 포인트 주소로 접속하여 연결 테스트 진행.

이번 스프린트에서는 이름에 김코딩, 비밀번호에 1234를 넣어 진행했다.

라는 메시지를 보며 데이터베이스 연결에 성공한 것을 확인할 수 있었다.

 

🌟 처음 EC2 인스턴스 생성 후 Postman을 통해 GET 요청을 통해 hello world라는 메시지를 확인할 수 있다는

유어클래스의 내용을 보고 해봤을 때, getaddrinfo EAI_AGAIN mysql:3306 이라는 에러 메시지가 떴다.

제너럴 채널과 아고라 스테이츠 에서 나와 같은 문제를 겪었던 분의 질답글을 보고 해결할 수 있었다.

결론은 내가 EC2 인스턴스 생성 직후 RDS 데이터베이스를 연결하지도 않고

바로 Postman을 켜서 GET 요청을 보냈기 때문이었다...

 

이로 인해 모든 일에는 순서가 있으며,

순서를 내 마음대로 뛰어넘으면 절대 컴퓨터는 제대로 된 응답을 주지 않는다는 것을 새삼 깨달았다.

급하게 먹는 물이 체한다는 말이 있듯이, 신속하게 할 수 있으면서도 실수는 최대한 줄이는 방향으로 해야겠다.