서버 배포 (EC2)
- EC2 콘솔을 통해 EC2 인스턴스를 생성해야 한다
- 간단한 서버 애플리케이션을 생성하고 EC2 인스턴스에 코드를 배포해야 한다
- 서버를 실행시키고 브라우저에서 서버에 접속할 수 있어야 한다
클라이언트 배포 (S3)
- S3 콘솔을 통해 버킷을 생성해야 한다
- 클라이언트 파일을 빌드하고 결과물을 버킷에 업로드 해야 한다
- 정적 웹 호스팅 기능을 이용하여 클라이언트 코드를 배포해야 한다
데이터베이스 연결 (RDS)
- RDS 콘솔을 통해 RDS 인스턴스를 생성해야 한다
- 로컬 터미널 혹은 EC2 인스턴스가 실행되고 있는 터미널을 통해 RDS 인스턴스에 연결해야 한다
1. 백엔드 배포
EC2 인스턴스 생성/연결 Hands-on
AWS 메뉴에서 EC2 서비스를 검색하고 접속하여 인스턴스 시작 버튼을 클릭하여 인스턴스 생성을 시작할 수 있다
용도에 맞게 AMI를 선택하는 과정이다
이번 과정에서는 Ubuntu 인스턴스를 생성해보자
프리티어 사용 가능 태그를 확인하여 과금이 되지 않도록 유의합니다.
- Ubuntu 인스턴스를 생성할 때 18버전을 권장, 이후 배포 자동화 실습때 20 버전은 이슈가 발생할 수 있다
인스턴스 유형을 선택하는 과정이다
생성하는 인스턴스의 CPU, RAM, 용량에 대한 선택이 가능하다
실습 과정에서는 프리티어 사용 가능 태그를 확인하여 과금되지 않는 유형을 선택한다
검토 및 시작 버튼을 클릭했다면 다음과 같은 화면이 보인다
생성되는 인스턴스를 원격으로 제어하기 위해서는 SSH 연결을 통한 원격접속이 필요하다
원격접속을 위해서 필요한 Key를 생성하고 다운로드하는 과정이다
새 키 페어 생성 메뉴를 확인한 후 키 페어의 이름을 정한 뒤 키 페어를 다운로드하면 인스턴스 시작 버튼이 활성화된다
SSH 프로토콜은 서로 다른 PC가 인터넷과 같은 Public Network를 통해 통신을 할 때 보안상 안전하게 통신을 하기 위한 통신 규약이다
주고받는 데이터를 암호화해서 해당 키 페어를 가지지 않은 사람은 통신되는 데이터를 알아볼 수 없기 때문에 보안상 안전한 통신 방법이다
PEM 파일은 인스턴스 연결에 사용되는 키 정보가 담긴 파일이므로 관리에 유의해야 한다
인스턴스 생성 마지막 단계에서 다운로드 한 파일은 SSH 통신을 위한 키 페어 중 프라이빗 키가 기록된 파일이다
.pem 확장자를 가지고 있다
해당 키 페어 파일은 EC2 인스턴스에 연결을 할때 사용하는 암호가 담긴 파일이다
따라서 pem파일은 관리에 유의해야 한다
많은 인스턴스가 생성되어 있는 경우 인스턴스를 생성하면서 알려주는 인스턴스 ID를 통해 인스턴스를 구분할 수 있다
우측 하단의 인스턴스 보기 버튼을 클릭하여 생성한 인스턴스를 확인해 보자
인스턴스 탭에서 생성된 인스턴스를 확인할 수 있다
인스턴스 ID를 통해 인스턴스를 구분할 수 있지만 생성된 인스턴스가 많아지는 경우 알아보기 힘들 수 있다
Name 컬럼에서 해당 인스턴스의 이름을 알아보기 쉽도록 설정해두면 각 인스턴스를 구분하기 용이해진다
이제 인스턴스가 생성되었다
하지만 지금 앞에 놓인 PC와 다르게 인스턴스는 직접 조작할 수 없다
어떻게 인스턴스를 제어할 수 있을까?
SSH 연결을 통한 EC2 인스턴스 원격접속을 실습해 보자
생성한 인스턴스에 원격접속하여 원격으로 인스턴스를 제어할 수 있다
인스턴스에 원격접속을 하기 위해서 필요한 것이 인스턴스를 생성할 때 다운로드한 키 페어 파일(.pem)이다
이제 SSH 연결을 통해서 인스턴스에 접속해 보자
인스턴스 탭에서 연결하고자 하는 인스턴스를 선택한 후 연결 버튼을 클릭하면 인스턴스에 연결하는 방법을 확인할 수 있다
이번 실습과정에서는 SSH 연결을 실습해보겠다
로컬 터미널에서 SSH프로토콜을 이용해서 인스턴스와 연결이 가능하다
하지만 먼저 다운로드했던 키 페어 파일(.pem)의 권한을 수정해 줘야 한다
pem 파일에 누구나 접근할 수 있는 권한이 부여되어 있다면 인스턴스는 연결을 거부한다
파일 권한을 설정하지 않은 경우 권한이 너무 open되어 있다는 경고 메세지와 함께 접속이 거절된다
chmod 400 [다운로드한 키 페어파일(.pem)의 경로] 명령어를 입력하여 키 페어 파일(.pem)의 권한을 수정한다
파일 권한을 설정했다면 ssh명령어를 통해 인스턴스에 접속할 수 있다
ssh 접속을 위한 주소는 인스턴스를 클릭하면 보이는 세부정보 탭에서도 확인할 수 있다
ssh 명령어를 통해 인스턴스에 접속해 보자
SSH 명령어를 올바르게 입력하면 위 화면과 같은 메세지가 터미널에 출력된다
해당 메세지는 EC2 인스턴스에 처음 접속할 시 나오는 경고 메세지다
'yes' 를 입력하여 다음 과정으로 넘어간다
위와 같이 나오면 SSH프로토콜을 이용한 원격접속이 성공적으로 연결된 것이다
이제 명령어를 통해 AWS에서 빌린 가상 PC를 사용할 수 있다
EC2 인스턴스 상에서 서버 실행
EC2 인스턴스를 이용하여 서버를 실행하고 접속한다
1. 인스턴스에 개발 환경 구축하기
우리는 EC2 인스턴스를 생성하는 것이 가상 PC 한 대를 임대하는 것이라고 배웠다
컴퓨터 운영체제를 처음 구입하면 필요한 프로그램을 설치해야 하듯이, EC2 인스턴스에 처음 접속하면 서버를 구동하는 데 필요한 개발 환경을 구축하는 것부터 시작해야 한다
저번 실습에서 EC2 인스턴스와 연결한 터미널에서 아래 명령어를 입력한다
패키지 매니저가 관리하는 패키지의 정보를 최신 상태로 업데이트하기 위해서 아래 명령어를 사용한다
패키지의 정보를 최신 상태로 업데이트
$ sudo apt update
어느 정도의 시간이 지나고 업데이트 과정이 끝나면 nvm, node.js를 설치해야 한다
먼저 nvm 설치는 NVM GitHub 페이지의 Install & Update Script 부분을 참조하여 진행한다
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
추가 표기
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 설치가 정상적으로 끝났는지 확인
nvm --version
명령어를 입력했는데 오류가 난다면 nvm 설치 과정이 정상적으로 마무리되지 않은 것이다
다음으로는 node.js를 설치한다
터미널에 아래 명령어를 입력하여 설치를 진행한다
node.js를 설치
$ nvm install node
node.js의 설치가 끝나면 npm 명령어가 정상적으로 입력되지 않는 상황을 방지하기 위해서 터미널에 명령어를 입력해서 npm 설치를 진행한다
npm 명령어가 정상적으로 입력되지 않는 상황을 방지
$ sudo apt install npm
위 과정이 모두 끝나면 node.js 기반 서버를 실행하는 데 필요한 개발 환경 구축이 완료된다
2. git을 통해 서버 코드 클론 받기
스프린트 코드가 저장된 깃헙 레포지토리 주소를 복사하고, git clone 명령어를 통해 EC2 인스턴스에 스프린트 코드를 클론 받는다
ubuntu@ip-172-31-41-164:~$ git clone https://github.com/codestates/im-sprint-practice-deploy.git
Cloning into 'im-sprint-practice-deploy'...
Username for 'https://github.com': kimcoding
Password for 'https://kimcoding@github.com:
...
정상적으로 클론했는지 확인하기 위해 터미널에 ls 명령어를 입력한다
스프린트 코드 폴더명이 보이면 정상적으로 다운로드가 완료된 것이다
터미널을 통해 스프린트 코드 안의 server 디렉토리로 이동한다
토큰인증 방식으로 변경
비밀번호 란에 토큰을 복사하여 붙여넣기 하면된다
디렉토리 이동
cd im-sprint-practice-deploy/server/
server 폴더로 이동한 뒤, npm install 명령어를 입력해서 필요한 모듈을 다운 받는다
3. EC2 인스턴스에서 서버 실행하기
npm install 명령어를 이용한 설치 과정이 완료되면 npm start 명령어를 이용해서 서버를 실행한다
그럼 아래와 같은 오류 메세지가 터미널에 보인다
위 오류 메세지가 보이는 이유는 1024번 아래의 포트 번호를 이용해서 서버를 실행하려면 관리자 권한이 필요하기 때문이다
관리자 권한으로 서버를 시작하기 위해서는 sudo npm start 명령어를 입력해야 한다
위와 같은 메시지를 통해 정상적으로 서버가 실행되었음을 확인할 수 있다
이제 EC2 인스턴스의 IP 주소로 접근해서 테스트를 진행한다
IP 주소는 EC2 대시보드에서 생성한 EC2 인스턴스를 클릭하면 확인할 수 있다
아래 화면에서 보라색으로 강조된 부분을 보시면, 두 가지 형태의 주소가 존재하는 것을 확인할 수 있다
퍼블릭 IPv4 주소와 퍼블릭 IPv4 DNS는 형태만 다를 뿐 같은 주소다
둘 중 어떤 주소를 사용하셔도 문제가 없다
이번 실습에서는 퍼블릭 IPv4 DNS 주소를 이용하여 접속 테스트를 진행해 보자
EC2 인스턴스의 IP 주소로 접속하면 로딩 끝에 아래와 같은 오류 메세지를 보인다
위 오류 메세지가 보이는 이유는 아직 '보안 그룹' 설정을 하지 않았기 때문이다
Security Group
보안그룹이란 인스턴스로 들어가고 인스턴스에서 나가는 트래픽에 대한 가상 방화벽이다
인스턴스로 들어가는 트래픽은 인바운드
인스턴스에서 나가는 트래픽을 아웃바운드라고 한다
인바운드규칙은 EC2 인스턴스로 들어오는 트래픽에 대한 규칙이다
인바운드 규칙에 허용되지 않은 규칙은 인스턴스로 접근하지 못하도록 필터링 된다
EC2 인스턴스를 생성하면 기본적으로 SSH 접속을 위한 SSH 규칙만 생성되어 있다
아웃바운드 규칙은 EC2 인스턴스에서 나가는 트래픽에 대한 규칙이다
EC2 인스턴스를 생성하면 기본적으로 나가는 모든 트래픽을 허용한다
인스턴스 탭의 우측에서 해당 인스턴스가 어떤 보안그룹에 속해 있는지 확인할 수 있다
보안그룹 탭에서 인스턴스 탭에서 확인한 보안그룹을 클릭하면 해당 보안그룹의 규칙을 설정할 수 있다
인바운드 규칙을 설정해보자
인바운드 규칙은 필요에 따라 규칙을 추가하고 제거하는 과정이 자유롭다
규칙 추가 버튼을 눌러 규칙을 추가해보자
EC2 인스턴스에서 실행중인 서버가 인터넷에서 요청을 받을수 있도록 인바운드 규칙을 설정해야 한다
슬라이드를 참고하여 인바운드유형과 이때 허락하는 포트의 범위를 지정한다
보안그룹은 소스에 따라 인바운드/아웃바운드 요청을 허락할 수도, 거절할 수도 있다
슬라이드에서 표시된 부분은 모든 주소에 대해 요청을 허락하는 설정이다
이때 소스는 특정 보안그룹 일수도, 특정 IP주소 일수도 혹은 슬라이드처럼 둘 다 아닐 수도 있다
'규칙 저장' 버튼을 누르면 보안 그룹을 설정하는 과정이 완료된다
모든 과정이 마무리되면 브라우저 혹은 Postman을 통해 접속 테스트를 진행하여 정상적으로 응답을 받는지 확인한다
PM2
프로세스 매니지먼트 도구 PM2
PM2의 사용법을 말하기 이전에, 프로세스가 무엇인지 짚고 넘어가자
"프로세스"라는 말을 들어봤을 거다
프로그램이란 말이 있는데, 프로세스는 프로그램과 무엇이 다른 걸까?
프로세스는 엄밀하게 이야기하면, 컴퓨터 프로그램이 실행될 때 프로그램 실행에 필요한 내용이 컴퓨터 메모리에 적재된다는 의미를 담고 있다
이 말이 조금 어렵다면, "실행 중인 프로그램"이라는 의미로 기억해도 무방하다
운영체제는 다양한 프로세스 관리 툴을 제공하는데, 이 중 기억해야 할 것은 ps 명령어다
ps 명령어의 사용법을 통해 프로세스를 확인하는 법을 알아두면 서버 운영에 큰 도움이 된다
ssh 프로그램을 통해 EC2에 접속하고, 터미널을 강제 종료한다고 가정해보자
이 때 과연 어떤 일이 발생할까
첫 번째로는, 로컬에 띄워져 있던 ssh 프로세스가 강제 종료된다
ssh 프로세스는 강제 종료 시, EC2 상의 프로세스도 같이 종료시킨다
따라서 EC2 상의 node 프로세스도 종료된다(다른 말로 실행되고 있던 서버가 종료된다)
포인트는, 웹 서버가 구동 중인 node 프로세스가 종료되지 않게끔 하여야 한다는 것이다
node 프로세스가 ssh 접속 여부와는 상관없이 늘 실행되게 만들 수는 없을까?
사실, 프로그램을 백그라운드에서 실행하는 방법은 linux/unix 계열 운영체제에서는 &라는 키워드를 명령 뒤에 붙여 백그라운드 실행으로 만들어줄 수 있다
예를 들어 node.js 앱을 실행할 경우, 마지막에 & 를 붙여주면 되는 것이다
Output으로 등장하는 29364와 같은 숫자는 PID, 즉 프로세스 ID다
PID를 알면, fg 명령을 통해 실행 중인 프로그램을 포어그라운드로 부를 수도 있고, kill 명령을 통해 백그라운드에서 실행중인 프로세스를 종료할 수도 있다
이런 명령어 대신에 프로세스를 전문적으로 관리해주는 프로그램을 하나 소개하고자 한다
바로 프로세스 매니저(Process Manage) PM2다
PM2는 node.js로 실행되는 프로그램(프로세스)를 관리해주며, 백그라운드에서 실행되게 만들 수 있다
단순히 백그라운드 실행뿐만 아니라 슬라이드에 언급된 것처럼, 다양하고 강력한 기능을 제공한다
이중 Hot Reload와 같이
프로그램이 변경될 때 자동으로 재시작하게 도와준다거나,
프로그램 실행 중 에러가 나서 서버가 종료되면, 다시 자동으로 실행시켜주는 기능을 제공한다
또한,
서버 운영에서는 필수라고 할 수 있는 로그 관리를 좀 더 전문적으로 할 수 있다
클러스터 모드와 같이 멀티코어 CPU를 최대한 활용하는 옵션도 있다
서버를 접속한 상태에서 PM2를 설치하는 법
npm install pm2 -g 명령으로 PM2를 설치한다
PM2 설치
npm install pm2 -g
PM2를 전역에 설치하고 나면, "pm2 start 파일 이름" 명령을 이용해 node.js 앱을 백그라운드로 실행할 수 있다
PM2를 통해서 정상적으로 프로세스가 실행된 것을 확인할 수 있다
PM2로 서버를 실행하면, 이제 터미널을 종료하더라도, node.js 애플리케이션이 프로세스로 실행된다
중단 및 재시작, 또는 상태를 보기 위한 명령어는 반드시 기억해야 한다
"pm2 start" 명령어 외에 유용한 명령어로
"pm2 stop" 프로세스 중지
"pm2 restart" 프로세스 재시작
"pm2 ls" 프로세스 목록 보기
"pm2 log" 프로세스 로그 보기
등이 있다
SysOps (시스템 운영자) 및 DevOps (개발 운영) 등의 직무를 하기 위해서는 다양한 옵션들을 더 찾아보고 보다 전문적인 프로세스 관리를 할 줄 알아야 한다
현재 단계에서는 위 명령어들만 먼저 잘 알아두어도 문제없다
우리는 이미 전 실습을 통해 1024번 아래의 포트번호를 이용해서 서버를 실행 시키는 경우, 관리자 권한이 필요한 것을 알고 있다
일반적인 'pm2 start' 명령어로 프로세스를 실행할 경우, 위 화면과 같이 'errored' 상태가 되며 서버가 정상적으로 실행되지 않는 것을 확인할 수 있다
'pm2 log' 명령어를 통해 어떤 문제가 생겼는지 확인해보자
log를 확인해보니 pm2가 프로세스를 실행시킬 때 관리자 권한으로 실행하지 못해 생긴 문제로 보인다
PM2에 관리자 권한을 부여하기 위해서는 'authbind' 라는 패키지를 추가적으로 설치해야 한다
터미널에서 아래 명령어를 차례대로 입력하여 authbind를 설치한다
sudo apt-get update
업데이트sudo apt-get install authbind
authbind installsudo touch /etc/authbind/byport/80
authbind 80포트에 적용sudo chown ubuntu /etc/authbind/byport/80
(chown 명령어는 파일의 Owner 또는 Group을 변경하는 명령어)sudo chmod 755 /etc/authbind/byport/80
권한 설정authbind --deep pm2 update
authbind 업데이트기존 pm2 ls 삭제
authbind 관리자 권한 부여 및 pm2 재실행
authbind의 설치를 완료한 뒤, 먼저 'pm2 ls' 명령어를 통해 어떤 프로그램이 PM2의 프로세스 리스트에 등록되어 있는지 확인한다
'app' 프로세스가 리스트에 있다면 'pm2 delete app.js' 명령어를 통해 프로세스를 삭제한다
authbind 설치 전에 실행되고 있던 프로세스에는 관리자 권한을 부여하지 못하기 때문이다
PM2에 관리자 권한을 부여하기 위해서는 'authbind --deep' 명령어를 앞에 추가해야 한다
'authbind --deep pm2 start app.js' 명령어를 통해 서버를 다시 실행하면 이번에는 문제없이 작동할 것이다
2. 프론트엔드 배포
S3 호스팅 (Hosting a Static Website)
정적 웹 사이트 호스팅 과정
- 정적 웹 페이지 빌드
- 버킷 생성 및 정적 웹사이트 호스팅 용으로 구성
- 빌드된 정적 웹페이지 업로드
- 퍼블릭 엑세스 차단 해제 및 정책 생성
먼저 정적 웹 사이트를 호스팅하는 과정은 4 단계로 요약된다
첫번째로 구현이 완성된 정적 웹 페이지를 빌드한다
빌드 과정이 끝나면 S3 대시보드에 접속하여 버킷을 생성하고, 생성한 버킷을 정적 웹 사이트 호스팅 용으로 구성한다
그 다음으로 빌드된 정적 웹 페이지를 버킷에 업로드한다
업로드가 완료되면 퍼블릭 액세스 차단 설정을 해제하고, 다른 사용자의 접근 권한을 부여하는 버킷 정책을 생성한다
모든 과정이 끝나면 다른 사용자들이 버킷에 업로드된 정적 웹 페이지에 접속할 수 있다
정벅 웹 페이지 빌드
먼저 정적 웹 페이지를 빌드하는 과정부터 시작해보자
먼저 '빌드(build)' 에 대해 잠시 알아보자
빌드란 작성한 코드의 불필요한 데이터를 없애고, 통합 및 압축하여 배포하기 이상적인 상태를 만드는 과정을 말한다
빌드 과정을 통하여 코드를 담고 있는 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다
- 빌드하기에 앞서 환경 변수를 담은 .env 파일을 확인한다
- .env 파일의 파일명이 제대로 적혀있는지,
- 환경 변수에 담긴 서버의 주소는 문제가 없는지 확인한다
참고로 요청을 보내는 서버의 주소를 환경 변수에 담을 때는 필히 'http://' 나 'https://' 를 포함해야 한다
환경 변수를 제대로 설정하지 않으면 서버에 요청을 제대로 보내지 못하게 되고, 그 결과로 정상적인 응답을 받아올 수 없다
이 부분을 주의한다
환경 변수 관련 설정이 완료되면, 터미널에 'npm run build' 명령어를 입력하여 빌드 과정을 진행한다
얼마간에 시간이 지나면 터미널 화면에 'Compiled Successfully' 라는 문구가 보이며 빌드 과정이 마무리된다
빌드 과정이 끝나면 client 디렉토리에 'build' 폴더가 생성된 것을 확인할 수 있습다
이것으로 빌드 과정이 완료됐다
그럼 다음 단계로 S3 콘솔에 접속하여 버킷을 생성해보자
버킷 생성 및 정적 웹사이트 호스팅 용으로 구성
1. S3 메인 화면에 접속
AWS 홈페이지에서 로그인을 한다
메인 콘솔 창에서 S3를 검색하여 S3 메인 화면에 접속한다
2. '버킷 만들기' 버튼 클릭
S3 메인 화면으로 이동하면, 위와 같이 보이는 화면과 같은 페이지를 확인할 수 있다
여기에서 '버킷 만들기' 버튼을 클릭한다
3. 버킷 이름 입력 및 리전 선택
버킷 만들기 버튼을 클릭하면 여러 옵션을 지정할 수 있는 페이지에 이동한다
우리는 '일반 구성' 옵션에 있는 내용만 완성하면 된다
먼저 버킷 이름을 작성한다
버킷 이름은 각 리전에서 고유해야 한다
다른 말로 위의 이미지에 사용하는 버킷 이름을 이용하여 버킷을 생성하지 못한다
원하는 이름으로 버킷 이름을 작성한다
위 이미지에서는 'practice-bucket-deploy'라는 이름으로 버킷 이름을 작성한다
4. 버킷 생성
버킷 이름 작성이 완료되면, 화면을 가장 아래로 이동한다
'버킷 만들기'라는 버튼을 클릭한다
5. 버킷 생성 확인 및 속성 메뉴로 이동
버킷 만들기 버튼을 클릭하고 일정 시간이 지나면 버킷이 성공적으로 생성되었다는 메세지와 함께 위 그림과 같이 보이는 화면으로 이동된다
만들어진 버킷을 클릭한다
6. 속성 메뉴로 이동
속성 메뉴를 눌러 이동한다
7. 정적 웹 사이트 호스팅 메뉴로 이동한 뒤 '편집'기능 클릭
8. 정적 웹 사이트 호스팅 활성화
속성 메뉴 화면에서 페이지의 스크롤을 가장 아래로 내리면, 슬라이드에 있는 화면과 같이 '정적 웹 사이트 호스팅' 옵션이 보인다
'편집' 버튼을 클릭한다
편집 버튼을 클릭하면 정적 웹 사이트 호스팅의 활성화/비활성화 여부를 묻는 창이 등장한다
'활성화' 옵션을 선택한다
9. 인덱스 문서 지정 및 변경사항 저장
활성화를 선택하면 여러 옵션을 추가로 변경할 수 있다
여기서 저희는 인덱스 문서를 작성해야 한다
인덱스 문서 부분에는 웹 사이트 주소에 처음 접속했을 때 보일 기본 페이지를 지정한다
'인덱스 문서' 기입란에 'index.html' 을 작성한다
'오류 문서' 부분은 공란으로 비워두셔도 좋지만, 혹시 모를 오류 발생 시 메인 페이지를 반환하기 위해서 'index.html'을 기입한다
그런 뒤 '변경 사항 저장' 버튼을 클릭한다
10. 생성된 버킷 웹 사이트 엔드포인트 주소 확인
변경 사항이 저장되면, 정적 웹 사이트 호스팅 옵션을 성공적으로 편집했다는 메세지와 함께 속성 메뉴 페이지로 리디렉션 된다
이번에도 페이지의 가장 아래로 스크롤을 내리서 방금 편집했던 정적 웹 사이트 호스팅 옵션 부분으로 이동한다
예전에 존재하지 않았던 버킷 웹 사이트 엔드포인트가 생성되어 있다
해당 주소를 클릭한다
11. 에러 메세지 확인
위와 같은 에러 메세지를 확인할 수 있다
왜 그럴까?
핵심 이유로는 버킷에 정적 웹 페이지 파일을 아직 업로드 하지 않았고, 퍼블릭 액세스 설정 변경과 정책 생성을 하지 않았기 때문이다
빌드된 정적 웹 페이지 업로드
1. 객체 메뉴로 이동
속성 메뉴 옆에 있는 '객체' 메뉴를 클릭해서 이동한다
2. 업로드 버튼 클릭
객체 메뉴로 이동하여 '업로드' 버튼을 클릭한다
3. Build 디렉토리에 있는 정적 파일들 업로드
위와 같은 화면이 보인다
여기에 build 폴더 안에 포함된 내용을 업로드 한다
client 폴더 안에 있는 build 폴더를 열어 안에 있는 파일을 모두 드래그하여 선택한다
객체를 업로드 하는 페이지에 필요한 파일을 드래그& 드랍 형식으로 업로드한다
이 과정에서 주의해야 할 점은 build 폴더 자체를 업로드 하는 게 아닌 build 폴더 안에 저장된 파일만 업로드 해야 한다는 점이다
그럼 슬라이드 화면과 같이 build 폴더 안에 있는 파일들이 업로드 대기 목록에 추가된다
'업로드' 버튼을 눌러서 다음 과정을 진행한다
업로드가 완료되면 슬라이드 화면처럼 '업로드 성공 메세지'를 확인할 수 있다
퍼블릭 액세스 차단 해제 및 정책 생성
1. 권한 메뉴로 이동
이제 정적 웹 호스팅의 마지막 과정으로 퍼블릭 액세스 차단 옵션을 해제하고 정책을 생성한다
먼저 S3 메인 화면으로 이동하여 생성한 버킷을 클릭한다
'권한' 메뉴를 클릭
2. 퍼블릭 엑세스 차단 메뉴의 '편집' 클릭
권한 메뉴에서 '퍼블릭 액세스 차단(버킷 설정)'이라는 옵션을 찾아, '편집' 버튼을 클릭한다
3. 퍼블릭 엑세스 차단 해제 및 변경 사항 저장
'모든 퍼블릭 액세스 차단' 옵션의 체크 박스를 해제한다
다음 '변경 사항 저장' 버튼을 클릭한다
'변경 사항 저장' 버튼을 클릭하면 경고창이 뜨는데, '확인'을 기입하고 다음 과정으로 넘어간다
4. 권한 메뉴의 버킷 정책 부분 편집
버킷 퍼블릭 액세스 차단을 변경하고 나면 다시 권한 메뉴로 리디렉션이 되어 있다
퍼블릭 액세스 차단(버킷 설정) 옵션 밑에 있는 '버킷 정책' 옵션을 찾는다
'편집' 버튼을 클릭한다
5. 정책 생성기 클릭
'정책 생성기' 버튼을 클릭한다
6. 정책 생성
그럼 새로운 창이 뜨면서 위와 같은 화면에 보이는 것과 같은 페이지에 접속된다
여기서 버킷 정책을 생성한다
'Select Type of Policy' 옵션에서는 'S3 Bucket Policy' 를 선택한다
'Principal' 옵션은 권한을 적용할 사용자를 정한다
우리는 모두에게 공개할 것이므로 *(별표)를 입력한다
'Actions' 옵션에서는 'GetObject'를 선택한다
GetObject 옵션을 선택하게 되면, 버킷에 접근하는 모든 사용자가 버킷 내에 저장된 객체 데이터를 읽을 수 있게 된다
버킷을 웹 사이트 용도로 구성할 때 선택해주시면 좋다
그리고 최종적으로 'Generate Policy' 버튼을 누르면 정책이 생성된다
7. 생성된 정책 복사하고 붙여넣기
정책은 JSON 형태로 생성된다
생성된 정책을 드래그해서 복사한 뒤 Close 버튼을 누른다
다시 버킷 정책 편집 페이지로 돌아가서 생성한 버킷 정책을 붙여 넣는다
그리고 '변경 사항 저장' 버튼을 클릭한다
8. 속성 메뉴로 이동하여 테스트 진행
그럼 모든 과정이 완료되었다
성공적으로 완료 되었는지 테스트하기 위해서 속성 메뉴로 이동한다
정적 웹 사이트 호스팅 옵션을 찾은 뒤, 버킷 웹 사이트 엔드포인트 주소를 클릭하여 테스트를 진행한다
브라우저에 정상적으로 화면이 출력된다면 성공적으로 마무리 된 것이다
3. 데이터베이스 연결
RDS 인스턴스 생성/연결 (Create & Access RDS Instance)
인스턴스 생성 및 연결 과정
1. DB 인스턴스 생성
2. 데이터베이스 연결
RDS 과정을 전체적으로 간략하게 요약해보자
먼저 MySQL 데이터베이스 엔진을 사용하는 DB 인스턴스를 생성한 뒤, 로컬 환경에서 MySQL 클라이언트를 활용하여 DB 인스턴스에 연결한다
인스턴스 생성
1. AWS 메인 콘솔 창에서 RDS 메인 화면으로 이동
먼저 AWS 메인 콘솔 창에서 RDS를 검색하여 RDS 메인 화면으로 이동한다
2. 데이터베이스 클릭
사이드 바에 위치한 '데이터베이스' 메뉴를 클릭하여 이동한다
3. '데이터베이스 생성' 버튼 클릭
데이터베이스 메뉴로 이동한 뒤, 화면에 보이는 '데이터베이스 생성' 버튼을 클릭한다
4. 엔진 옵션에서 'MySQL' 선택
데이터베이스 생성 버튼을 클릭하면 DB 인스턴스의 생성과 관련해서 여러 가지 옵션을 지정할 수 있는 페이지가 보일 것이다
여기서 우리는 필요한 부분에만 집중하면서 진행해 보자
먼저 데이터베이스 엔진 옵션을 선택해야 한다
우리는 MySQL을 사용하여 실습을 진행할 것이기에 MySQL 을 선택한다
5. 템플릿 옵션에서 '프리 티어' 선택
데이터베이스 엔진을 MySQL로 선택하고 페이지의 스크롤을 살짝 아래로 내리시면 템플릿 옵션 화면을 보실 수 있다
프리 티어 옵션을 선택한다
6. 연결 옵션에서 식별자, 사용자 이름과 암호 기입
설정 옵션 창으로 이동하여 DB 클러스터 식별자 이름, 마스터 사용자 이름과 마스터 암호를 기재한다
마스터 사용자 이름과 암호는 나중에 데이터베이스를 연결할 때 쓰이는 정보다
반드시 기억하자
7. 연결 옵션에서 '퍼블릭 에세스 기능' 부분 변경
연결 옵션으로 이동하셔서 퍼블릭 액세스 가능 부분을 '예'로 설정한다
8. 보안 그룹 확인 및 포트 번호 수정
보안 그룹 같은 경우는 기본값인 'default' 보안 그룹을 선택한다
다른 보안 그룹을 선택 시 로컬 환경 터미널에서 테스트가 불가능하다
'추가 연결 구성' 토글을 여시면 데이터베이스 포트 번호를 지정할 수 있는 창이 보일거다
여기서는 흔히 사용되는 3306번 포트 대신, 포트번호 노출을 방지하려는 목적으로 13306번으로 지정한다
9. '추가 구성' 토글 열어서 초기 데이터베이스 이름 지정
포트 번호 변경이 완료된 뒤, 페이지의 스크롤을 아래로 내린다
'추가 구성' 토글 창을 찾아 클릭한다
추가 구성 토글을 열면 여러 옵션을 추가로 확인 가능하다
여기서 우리는 초기 데이터베이스 'test' 라는 이름으로 설정한다
서버 코드가 'test' 데이터베이스를 찾도록 작성되어 있으니, 다른 이름은 사용하지 않는다
10. 데이터베이스 생성
초기 데이터베이스 이름을 기입하고 나면 모든 설정이 끝났다
'데이터베이스 생성' 버튼을 클릭하여 DB 인스턴스를 생성한다
DB 인스턴스가 생성되기까지 시간이 오래 걸리기에 여기서 잠시 기다려야한다
슬라이드에서 확인할 수 있는 '상태' 부분이 현재 '생성 중'으로 보인다면 잠시 대기한다
이 부분이 '사용 가능'으로 변화하면 DB 인스턴스 생성이 완료된다
데이터 베이스 연결
1. 엔드포인트 확인
MySQL 클라이언트를 통해 RDS의 DB 인스턴스에 연결하기 위해서는 세 가지 정보가 필요하다
1. DB 인스턴스 생성 시 기재한 마스터 이름, 마스터 비밀번호
2. 포트 번호
3. 생성한 DB 인스턴스의 엔드포인트 주소
여기서 포트 번호와 마스터 유저 정보 부분은 생성 과정에서 직접 기재했기 때문에 설명을 생략하도록 하자
엔드포인트 주소를 확인하기 위해서 생성한 DB 인스턴스를 클릭한다
연결 & 보안 메뉴 부분을 보시면 엔드포인트 주소를 확인할 수 있다
엔드포인트 주소를 복사하여 저장한다
2. 터미널에서 MySQL 실행해서 연결
MySQL 을 통해서 DB 인스턴스에 접속하자
'mysql -u [마스터 이름] --host [엔드포인트 주소] -P 13306(포트번호) -p' 명령어를 입력하면 된다
해당 명령어를 입력하면 비밀번호를 요구하는데, 마스터 비밀번호를 입력하면 된다
정상적으로 진행이 된다면 슬라이드 화면과 같은 메시지가 뜨며 MySQL에 접속이 된다
데이터베이스 연결 테스트를 하기 위해 터미널에 'show databases;' 를 입력한다
아까 DB 인스턴스를 생성할 때 만들었던 초기 데이터베이스 'test'가 보인다면 정상적으로 연결이 된 것이다
서버 환경 설정
EC2 인스턴스에서 실행되고 있는 서버는, 그 자체로는 작동하고 있지만, 아직 데이터베이스에 연결하지는 않았다
서버의 환경 설정을 통해 지난 실습에서 생성한 RDS 인스턴스에 접속하고, 클라우드 데이터베이스를 사용할 수 있게 해보자
1. 서버 코드에 저장된 .env 파일에 환경 변수 설정하기
EC2 인스턴스에서 실행하고 있는 서버를 종료한다
- PM2를 이용해 프로세스로 실행 중인 경우
pm2 stop <id> - node나 npm 명령을 통해 서버를 실행한 경우 Ctrl + C
이제 환경 설정 파일을 수정해보자
먼저 .env.example의 파일명을 .env로 바꿔줘야 한다
mv .env.example .env
터미널에서 스프린트 코드의 server 디렉토리로 이동한 뒤, nano를 통해 .env파일을 열어보자
nano .env
.env 파일에는 아래와 같이 4개의 환경변수가 저장되어 있다
각 환경 변수에 특정 값을 저장해주어야 한다
- DATABASE_HOST 변수에는 생성한 DB 인스턴스의 엔드포인트 주소를 넣는다
- DATABASE_USER 변수에는 마스터 사용자 이름을 넣는다
- DATABASE_PASSWORD 변수에는 마스터 암호를 넣는다
- DATABASE_PORT 에는 DB 인스턴스의 port 번호를 넣는다
위 스크린샷에 보이는 것처럼 환경 변수를 할당하는 과정이 끝나면, Ctrl + X 키를 입력하여 변경 내용을 저장한다
위와 같은 화면이 보이면 y를 입력하고 Enter 키를 통해 파일을 저장한다
.env 파일을 통한 환경 설정이 완료되면, 서버를 재실행한다
2. 서버 실행
- sudo npm start 명령어를 입력하여 서버를 재실행한다
- PM2를 이용해서 프로세스로 실행할 수도 있다
- authbind --deep pm2 stop app.js명령어를 이용하여 프로세스를 정지한다
- authbind --deep pm2 start app.js명령어를 이용하여 프로세스를 시작한다
서버를 실행하고 다시 s3 버킷의 엔드포인트 주소로 접속해서 연결 테스트를 진행한다
뭔가 제대로 되고 있지 않을때
아래 사항을 체크해보자
- DB 인스턴스가 정상적으로 실행되고 있는지
- 환경변수에 제대로 된 값을 할당하지 않았는지(DB 인스턴스의 엔드포인트 값을 환경 변수에 넣을 때, 앞에 http://를 붙이면 안 됩니다. 위 스크린샷의 예시를 참고)
- .env.example 파일명이 .env로 정상적으로 변경되었는지 확인
- 크롬 개발자 도구의 Network 탭에 들어가서 요청, 응답 과정에서 어떤 오류가 발생하는지 확인
