기존 방식의 한계
⇒ 데이터 센터의 등장(온프레미스) && 유휴자원 대여
물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여!
클라우드의 단점
클라우드 서비스의 형태
배포란? - 개발한 서비스를 사용자가 이용 가능하게 하는 과정
배포를 위한 다양한 플랫폼
ex) AWS, heroku, DigitalOcean, Microsoft Azure, Firebase …
배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요!!
클라우드 컴퓨팅 - 인터넷(클라우드)를 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스
장점
AWS에서 빌리는 컴퓨터를 Instance라고 한다.
AMI는 소프트웨어 구성이 기재된 템플릿입니다. 이미지 종류로는 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있습니다. (우분투 + node.js, 윈도우 + JVM 등)
AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌린다!
AWS에서 제공하는 관계형 데이터 베이스 서비스
이때, 파일은 키-값 페어 형식으로 데이터를 저장 → 파일의 값에는 실제 데이터 저장 (최대 크기 5TB), 파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할
메타 데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터
AWS 서비스 중 하나인 S3를 이용해서 사용자에게 client application을 제공할 수 있다. (EC2 인스턴스 사용할 필요 X)
CloudFront를 통해 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스 제공 가능
S3, EC2를 이용해서 배포된 서비스는 IP 주소 혹은 AWS에서 제공하는 나의 서비스와는 전혀 상관 없는 긴 도메인 주소를 통해 접근하게 됨
이때, AWS에서 제공하는 Route 53서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근 가능
🫥 SSH 프로토콜을 통한 원격접속과 키 페어 (.pem파일)
SSH(Secure Shell) Protocol은 PC와 PC가 인터넷과 같은 Public Network를 통해 보안상 안전하게 통신하기 위한 통신 규약입니다.
주고받는 데이터를 암호화해서 해당 키 페어를 가지지 않은 사람은 통신되는 데이터를 알아볼 수 없기 때문에 보안상 안전합니다.
EC2 프라이빗 키파일 (.pem파일)
인스턴스 생성 마지막 단계에서 다운로드 한 파일은 SSH 통신을 위한 키 페어 중 프라이빗 키가 기록된 파일입니다. (.pem 확장자를 가짐) ⇒ 관리에 유의 필요!
EC2 Instance 생성
→ 많은 인스턴스가 있을 경우, 인스턴스 ID를 통해 구분 가능하지만, 인스턴스 name을 설정하여 구분을 보다 더 용이하게 가능
EC2 Instance 연결
연결 버튼 클릭→ 해당 3가지의 연결 방법들이 나옴
$ bash
$ cd ~
✶ chmod란?
Linux의 기본 명령어로 change mode의 축약어입니다.
4 (소유자=나) / 0 (그룹) / 0 (전체) ⇒ chmod 뒤 3개의 숫자의 의미
권한은 읽기(4), 쓰기(2), 실행(1) 세가지 숫자의 조합으로 권한 부여
ex) chmod 700 → 소유자에게 (4+2+1) 읽기, 쓰기, 사용 권한 부여함
ex) chmod 400 AWS_Deploy_Practice.pem = 나에게만 읽기 권한이 있도록 권한 부여
.pem의 권한을 수정하지 않은 경우, 권한이 너무 open되었다는 경고 메시지와 함께 접속이 거절됨
이 때, chmod 400 [다운로드한 키 페어 파일(.pem)의 경로] 명령어를 입력하여 키 페어 파일(.pem)의 권한을 수정합니다.
파일 권한을 설정했다면, ssh 명령어를 통해 인스턴스에 접속 가능
OR ssh 접속을 위한 주소는 인스턴스를 클릭하면 보이는 세부 정보 탭에서도 확인 가능
$ sudo apt update //업데이트 진행
//nvm 설치
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.2/install.sh | bash
//or
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.2/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 설치가 정상적으로 끝났는지 확인
nvm --version
//node.js 설치
$ nvm install node
//npm 명령어가 정상적으로 입력되지 않는 상황 방지
$ sudo apt install npm
//가상 EC2 인스턴스 터미널 창에서 키 페어 생성
ssh-keygen
//공개키 복사 한 뒤 github에서 ssh key 생성해주기
cat ~/.ssh/id_rsa.pub
// 홈 디렉토리로 이동
ubuntu@ip-172-31-41-164:~$ cd ~
// git clone (SSH code 복사해서 가져오기)
ubuntu@ip-172-31-41-164:~$ git clone https://github.com/codestates-seb/fe-sprint-practice-deploy.git
Cloning into 'fe-sprint-practice-deploy'...
...
//정상적으로 클론했는지 확인?
ls
//server 폴더로 이동한 뒤 npm install
cd fe-sprint-practice-deploy/server/
sudo npm start
명령어로 서버 실행
npm start
로 하면 에러가 뜨는 이유는, 관리자 권한이 필요하기 때문!
퍼블릭 IPv4 주소와 퍼블릭 IPv4 DNS는 형태만 다를 뿐 같은 주소입니다. 둘 중 어떤 주소를 사용하셔도 문제가 없습니다.
보안그룹이란 AWS에서 임대한 인스턴스의 가상 방화벽입니다. (인바운드 & 아웃바운드에 대한 규칙 설정)
인바운드 = 인스턴스로 들어가는 트래픽
아웃바운드 = 인스턴스에서 나가는 트래픽
보안 그룹 탭에서 인스턴스 탭에서 확인한 보안 그룹을 클릭하면 해당 보안 그룹의 규칙을 설정 가능
SSH나 서비스 매니저로 프로세스를 따로 켜놓지 않아도 백그라운드에서 프로세스를 작동시킬 수 있는 프로세스 매니지먼트 도구입니다.
✪ 프로세스란?
컴퓨터 프로그램이 실행될 때 프로그램 실행에 필요한 내용이 컴퓨터 메모리에 적재된다는 의미, 즉 “실행 중인 프로그램”
- 프로세스를 보는 방법 ⇒ 작업 관리자, 활성 상태 보기, “ps” 명령어
이 때, node 프로세스가 ssh 접속 여부와는 상관없이 늘 실행되게 하려면?
linux/unix 계열 운영체제에서는 “&”라는 키워드를 명령 뒤에 붙여 백그라운드 실행으로 만들어준다.
ex) PID(Process ID) = 29364 , fg = 실행중인 프로그램을 포어그라운드로 불러오기, kill = 백그라운드에서 실행 중인 프로세스 종료
node index.js & ⇒ output으로 PID가 나옴
상기 방법 대신 프로세스를 전문적으로 관리해주는 PM2
npm install pm2 -g
pm2 start [파일이름] //터미널을 종료해도 프로세스로 실행됨
//이외의 명령어들
"pm2 stop" 프로세스 중지
"pm2 restart" 프로세스 재시작
"pm2 ls" 프로세스 목록 보기
"pm2 log" 프로세스 로그 보기
pm2 start ⇒ error 발생 시, 관리자 권한으로 실행하지 못해서 생긴 문제일 가능성이 있음
이 때, authbind라는 패키지를 추가적으로 설치해야 함!
//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의 설치를 완료한 뒤, 'pm2 ls' 명령어를 통해 어떤 프로그램이 PM2의 프로세스 리스트에 등록되어 있는지 확인!
'app' 프로세스가 리스트에 있다면 'pm2 delete app.js' 명령어를 통해 프로세스를 삭제합니다. authbind 설치 전에 실행되고 있던 프로세스에는 관리자 권한을 부여하지 못하기 때문입니다.
PM2에 관리자 권한을 부여하기 위해서는 'authbind --deep' 명령어를 앞에 추가해야 합니다.
'authbind --deep pm2 start app.js' 명령어를 통해 서버를 다시 실행하면 이번에는 문제없이 작동할 것!
//.env
REACT_APP_API_UTL=http://ec2-13-125-236-22.ap-northeast-2.compute.amazonaws.com
npm install
, npm run build
스크립트 실행🔅 정적 웹 사이트 호스팅 과정
1. 정적 웹 페이지 빌드
2. 버킷 생성 및 정적 웹 사이트 호스팅 용으로 구성
3. 빌드된 정적 웹 페이즈 업로드
4. 퍼블릭 액세스 차단 해제 및 정책 생성
1. 정적 웹 페이지 빌드
빌드 전, 환경 변수를 담은 .env 파일 확인하기 (.env 파일의 파일명이 제대로 적혀있는지, 환경 변수에 담긴 서버의 주소는 문제가 없는지 확인하기. 요청을 보내는 서버의 주소를 환경 변수에 담을 때는 필히 'http://' 나 'https://'를 포함해야 함)
client directory로 이동 후 npm run build 명령어 입력 ⇒ “Compiled Successfully” 문구 나오면 끝!
2. 버킷 생성 및 정적 웹 사이트 호스팅 용으로 구성
AWS 콜솔에서 S3 검색 후 메인 화면 접속
“버킷 만들기” 버튼 클릭 → “일반 구성” 옵션 → 각 리전에서 고유한 버킷 이름 작성 → “버킷 만들기” 버튼 클릭
만들어진 버킷 클릭 → “속성” 메뉴 이동 → 정적 웹 사이트 호스팅 “편집” → “활성화” 옵션 선택 → (optional) 혹시 모를 오류 발생 시 메인 페이지를 반환하기 위해 인덱스 문서 “index.html” 기입 후 “저장” → 앤드포인트 생성
에러 메세지 확인 (403 Forbidden: 버킷에 정적 웹 페이지 파일을 아직 업로드하지 않았고, 퍼블릭 액세스 설정 변경과 정책 생성을 하지 않았기 때문)
3. 빌드된 정적 웹 페이즈 업로드
“객체” 메뉴로 이동 → client/build 안의 파일들 모두 드래그 하여 업로드, NOT build 폴더 그 자체 (항상 drag&drop 형식으로!)
4. 퍼블릭 액세스 차단 해제 및 정책 생성
S3의 생성한 버킷 클릭 → “권한” 메뉴로 이동 → '퍼블릭 액세스 차단(버킷 설정)’ “편집” 버큰 클릭 → '모든 퍼블릭 액세스 차단' 옵션의 체크 박스를 해제 → “변경 사항 저장” 버튼 클릭
”권한” 메뉴 → “버킷 정책” 옵션에서 “편집” 버튼 클릭 → “정책 생성기” 버튼 클릭 →
'Select Type of Policy' 옵션에서는 'S3 Bucket Policy'를 선택!
'Principal' 옵션은 권한을 적용할 사용자를 정합니다. 우리는 모두에게 공개할 것이므로 *(별표)를 입력!
'Actions' 옵션에서는 'GetObject'를 선택합니다. GetObject 옵션을 선택하게 되면, 버킷에 접근하는 모든 사용자가 버킷 내에 저장된 객체 데이터를 읽을 수 있게 됩니다. 버킷을 웹 사이트 용도로 구성할 때 선택해 주시면 좋습니다.
→ 'Generate Policy' 버튼을 누르면 정책이 생성됩니다 → 생성된 JSON 형태의 정책 복사 후 “close”→ 버킷 정책 편집 페이지로 돌아가서 생성한 버킷 정책을 붙여 넣기
“속성” 메뉴에서 앤드 포인트 주소를 클릭하여 테스트 진행!