[3주차 마지막] 끝인줄 알았지?아니었다. AWS 사용하기

LSA·2022년 4월 17일
클론사이트팀프로젝트
4

1차 팀 프로젝트

목록 보기
6/6

회고록을 쓸때까지만 해도 자잘한 버그나 리팩토링이 남아서, 마음의 여유가 생겼습니다.
그때는 그걸 몰랐기 때문이죠.
배포...

1차 프로젝트 작업 파일을 AWS를 통해 배포하는 것이 프로젝트의 진정한 완성이었습니다.

배포가 제일 어렵다

진짜 어려움

AWS를 이용해 파일을 올리는 것은 여러 방면의 지식, 특히 네트워크 통신 지식이 필요하기 때문에 가이드를 보면서도 왜 이렇게 해야하는가 에 대한 명확한 이유를 이해하기 힘들었습니다.
노션에 있는 가이드를 보면서 옵션값을 따라하는게 최대 아웃풋이었다고 할 수 있겠습니다.
일단 제가 진행했던 과정을 천천히 되짚어보겠습니다.

01. 가입

AWS, 즉 아마존 웹 서비스를 이용하면 가입부터 해야겠죠?
가입까지는 페이지가 한국어로도 자동 번역되어 크게 어렵지 않지만 중요한 것은
해외 결제가 가능한 카드 등록을 해야한다는 것입니다.
왜냐하면, 우리가 서버를 이용하는만큼 AWS는 우리의 카드에서 자동으로 돈을 청구할 것이기 때문입니다.
다행히 인스턴스 생성 후 서버를 더 늘리지 않는 한 1년간은 무료로 사용이 가능합니다.

02-1. 기본 세팅- 인스턴스 위치

로그인은 '루트 사용자' 옵션으로 해줍니다.
로그인을 끝내고 콘솔 대시보드 화면으로 오면 가장 먼저 해주어야 할 것은 인스턴스의 위치를 국가에 맞게 설정해주는 것입니다.

인스턴스가 뭔데요
AWS를 이용한다는 것은 한마디로, AWS에다가 가상의 컴퓨터를 한 대 빌려 그 컴퓨터에서 DB도 쓰고 서버도 돌리겠다는 계약을 하는 겁니다.그 컴퓨터가 인스턴스가 되는거고요.

02-2. 기본 세팅 - 보안 그룹 세팅

콘솔 검색창에다가 ec2를 검색한 후 클릭합니다.
왼쪽에 보면, '네트워크 및 보안' 토글바에서 '보안 그룹'이라는 메뉴가 있을텐데 그쪽으로 들어갑니다.
이후 보안 그룹 생성이라는 버튼을 찾아 눌러 새 그룹을 만들어줍니다.

이런 페이지가 나오는데..옵션별로 어떻게 적었는지 써둡니다.

1.기본 세부 정보

  • 보안 그룹 이름 : wecoview-sg-internet이라고 적었습니다. sg는, security group의 줄임말이라고 합니다. 이런 보안 그룹 이름은 멘토님들께서 컨벤션을 추천해주셔서 해당 방식을 사용했습니다.
  • 설명 : 보안 그룹에 대한 설명을 적는 곳입니다. 대충 internet connect 라고 썼는데, 한글로 써도 될지도..
  • vpc : vpc-0af04be8029dcd944 로 되어 있습니다. 딱히 건드리지 않았습니다.

2. 인바운드 규칙

  • 유형 : SSH
  • 프로토콜 : TCP
  • 포트 범위 : 22
  • 소스 : 사용자 지정
  • ip 적는 곳 : 0.0.0.0/0(이렇게 쓰면 아무 ip에서나 접속이 가능함)
  • 설명 -선택 사항: 어떤 규칙인지에 대한 간단한 설명을 적는 곳입니다. 유형에 SSH라고 썼으니, SSH라고 써도 무방합니다.

인바운드 규칙은 총 2개, 최대 3개까지 써주는게 안전합니다. 방금 쓴 SSH는 우리가 외부 인스턴스에 접속하기 위한 규칙으로 기본적으로 만들어주어야 하는 규칙 중 하나입니다.
최종 형태는 이렇습니다.

중요한 게 하나 있다면, 아웃바운드 설정은 절대로 손대면 안된다는 것입니다.
애초에 무서워서 못건드렸습니다.
보안 그룹 설정은 이것으로 끝입니다.

03. RDS 설정

콘솔 검색창에다가 'RDS'라고 치니까 RDS라는 목록이 바로 보이네요!
정확히는 Amazon Relational Database Service(Amazon RDS) 입니다. DB를 설치하기 위해 필요한 세팅입니다.
대시 보드 를 클릭해 들어가면..

뭔가 많은데 우리는 데이터베이스 생성을 해야하니까, 데이터베이스 생성 버튼을 눌러줍니다.
22년 4월 16일 기준 화면 레이아웃입니다. 그 이전에는 다른 방식으로 화면이 구성되어서,다른 곳에서 적어준 가이드와 스크린샷이 달라 옵션이름 매칭시키는게 좀 까다로웠습니다.
이것도 언제 바뀔지 모르기 때문에 옵션명으로 구분해봅니다.

1. 데이터베이스 생성 방식 선택 : 표준 생성 (옵션 전부를 커스텀한다는 뜻입니다.)

2. 엔진 옵션

  • 엔진 유형 : 저희는 MySQL을 사용하기 때문에 MySQL을 선택했습니다.
  • 에디션 : 뭐야 넘어가
  • 버전 : MySQL 8.0.23을 선택했습니다.

3. 템플릿

  • 프리 티어를 선택했습니다. 다른 옵션들은 금액이 청구될겁니다.

4. 설정

  • DB 인스턴스 식별자 : 아래 설명을 읽어보면, 1자~60자의 영숫자 또는 하이픈으로 구성되며 첫 번째 문자는 글자가 되어야 합니다. 맨앞엔 프로젝트 명으로 구분하면 좋을테니 wecoview-rds-1 이 되겠네요.
  • 자격 증명 설정(해당 정보 기록필수)
    - 마스터 사용자 이름 : admin으로 기본 세팅되어있을겁니다. mysql에서 root에 해당하는 이름입니다. 꼭 admin일 필요도 없지만,그대로 사용합니다.
    • 마스터 암호 : DB 안에 들어가기 위한 비밀번호입니다. MySQL에서 처음에 세팅하는 비밀번호인 셈입니다. 지금 적어두지 않으면 잊어버리니 꼭 다른곳에 적어둡시다.
    • 암호 확인: 잘 해주세요.

5. DB 인스턴스 클래스: 버스터블 클래스로 설정, db.t2.micro 옵션을 선택합니다.

6. 스토리지

  • 스토리지 유형: 범용 SSD(gp2) 선택. 뭔지 모르겠습니다.
  • 할당된 스토리지 : 20 GiB
  • 스토리지 자동 조정
    - 스토리지 자동 조정 활성화 옵션을 체크해줍니다. 이 기능을 활성화하면 지정한 임계값 초과 시 스토리지를 늘릴 수 있습니다.(돈나가는거 아뉴?)
    • 최대 스토리지 임계값 : 1000 GiB

7. 가용성 및 내구성 : 대기 인스턴스 생성으로 자동 선택되어있을텐데, 내버려둡니다.

8. 연결

  • Virtual Private Cloud(VPC) : Default VPC (vpc-0어쩌구 되어있음)으로 설정
  • 서브넷 그룹 : 기본값
  • 퍼블릭 액세스 : 예
  • VPC 보안 그룹 : 기존 항목 선택
  • 기존 VPC 보안 그룹 : 아까 우리가 만들어주었던 wecoview-sg-internet을 선택해줍니다.
  • 가용 영역 : ap-northeast-2a (아까 인스턴스 위치를 서울로 설정해주었다면 이게 뜰지도..)
    8-1. 연결-추가 구성 : 열어보면 3306으로 되어있을겁니다. 내버려둡니다.

9. 데이터베이스 인증

  • 데이터베이스 인증 옵션 : 암호 인증

10. 추가 구성

  • 데이터베이스 옵션
    - 초기 데이터베이스 이름 : wecoview (로컬 DB에서 이용했던 DB 이름을 동일하게 써주어야 나중에 파일을 고칠 필요가 없습니다.)
    • DB 파라미터 그룹 : default.mysql8.0
    • 옵션 그룹 : default.mysql8.0
  • 백업, 모니터링, 로그 내보내기 : 체크박스가 비어있도록 합니다.
  • IAM 역할 : 막혀서 딱히 건드릴 곳도 없음
  • 유지 관리 :
    - 마이너 버전 자동 업그레이드 사용에 체크
    • 유지 관리 기간 : 기본 설정 없음
  • 삭제 방지 :
    - 삭제 방지 활성화에 체크 해제

마지막으로 월별 추정 요금사항을 확인하고, 데이터베이스 생성 버튼을 클릭하면 끝입니다!
이렇게 만들어진 RDS 엔드포인트를 확인합니다. 엔드포인트는, 외부에 만들어진 우리의 새 DB 주소입니다.(로컬 mysql 말고)
RDS 페이지 왼쪽의 '데이터베이스' 목록에서 확인이 가능합니다.


이제 저 엔드포인트 주소를, 백단 파일의 .env파일에다가 넣어줄겁니다.

원래 DATABASE_URL 주소는 localhost로 되어있었지만, 이부분을 새로 생성된 엔드포인트로 바꿔줍니다.

DATABASE_URL="mysql://admin:<RDS_비밀번호>@<DB_ENDPOINT>:3306/<database명>"

.env의 시크릿 키까지 보여졌지만 현재 저의 .env는 사용되지 않기 때문에 털릴 것도 없습니다.
그다음 우리의 스키마를 넣어주기 위해 터미널을 연 후

npx prisma db push

를 써줍니다.
Generated Prisma Client ( 3.6.0.| libray) to 어쩌고...
라는 문구가 뜬다면 성공. 스키마도 바로 넣어 봅니다.

npx prisma generate

성공한다면, 로컬에서 prisma.schema 파일이 잘 넣어졌을때와 동일하게 초록색 글씨로 무언가가 뜹니다.

04. EC2 설정

가상의 컴퓨터가 되어줄 인스턴스를 설정하기 위해 보안 그룹 설정할때처럼 다시 EC2페이지로 들어갑니다.
노란색 버튼으로 되어 있을, 인스턴스 시작 이라는 버튼을 누르면...

또다시 여러 창과 함께 알수없는 설정들이 있습니다.
화면이 최근에 바뀌었으므로, 스크린샷 대신 옵션명을 매칭시켜 적어두겠습니다.

1. 이름 및 태그 :프론트 쪽 레포와 백쪽 레포를 둘다 집어넣을 것이기 때문에,
wecoview-ec2-front/back-1 로 컨벤션을 맞춰 작성.이렇게 되면 name이라는 key 값에 wecoview-ec2-front/back-1라는 value가 들어가게 됩니다

2. 애플리케이션 및 OS 이미지(Amazon Machine Image)

  • 아무것도 모르니까 검색바는 쓸일이 없음
  • Quick Start 탭에서,Amazon Linux 2 AMI(HVM)-Kernel 5.10, SSD Volume Type 을 선택합니다. 애초에 프리 티어 사용 가능한 옵션이 별로 없는데다가 그게 기본으로 설정되어 있습니다. (목록에 윈도랑 맥 OS도 있는데 그걸 선택하면 안되나요? -> 저도 그게 궁금합니다.)
  • 설명에 Amazon Linux 2 Kernel 5.10 AMI 2.0.20220406.1 x86_64 HVM gp2 라고 되어있으면 OK
  • 아키텍처는 64비트(x86)로.

3. 인스턴스 유형 : t2.micro로 설정하는게 과금 위험이 제일 적다고 배웠습니다.

4. 키 페어(로그인) 아주아주 중요한 항목.
새 키 페어 생성이라는 버튼을 누르면, 팝업창이 하나 뜰텐데

  • 키 페어 이름(수정 불가) : key 라고만 해도 무방합니다.간단하게 설정하는게 좋겠죠..
  • 키 페어 유형 : RSA 선택
  • 프라이빗 키 파일 형식 : .pem 선택
    이후 키 페어 생성 버튼을 누르면 인스턴스에 접속할 수 있는 로그인 정보인 key.pem 이 다운로드 됩니다. 이 키는...잃어버릴 시 재다운로드도 안되므로 인스턴스에 접속자체를 못하는 파멸이 일어납니다. 꼭 백업본을 만들어두고 소중히 대해 주세요.

5. 네트워크 설정
다른 항목들은 기본적으로 값이 채워져있을 수 있습니다.

  • 보안 그룹(방화벽) 에서 셀렉트바가 활성화되어 있다면 아까 만들어준 커스텀 보안 그룹 규칙(wecoview-sg-group)을 선택해줍니다.
  • 에서 SSH 트래픽 허용 에 체크.
  • 셀렉트바에서, 위치는 무관으로 선택합니다. 여러 ip에서 접속할 수 있게 열어두는것.(혼자만 확인하고 싶다면 내 ip가 되어야 함)
  • 인터넷에서 HTTPs 트래픽 허용, 인터넷에서 HTTP 트래픽 허용 : 둘다 체크 안했습니다. 상황에 따라 체크할 일도 생기겠죠?

6. 스토리지 구성

  • 8 Gib, gp2 루트 볼륨이 될 수 있도록 선택합니다. 프리 티어를 사용하는 고객은 최대 30GB의 스토리지를 사용할 수 있다고 하는데, 30gb까지 갈 수나 있을지 모르겠습니다.
    스토리지 구성이라는 제목 옆에 있는 어드밴스드 텍스트를 클릭해보면 또다른 설정을 할 수 있습니다.
    크기, 볼륨 유형, 종료시 삭제, 암호화됨 등의 옵션을 선택할 수 있는데 기본값 그대로 내버려두었습니다.

7. 고급 세부 정보

  • 구매 옵션 : 기본값(스팟 인스턴스 요청에 체크 해제)
  • IAM 인스턴스 프로파일 : 기본값 (선택)
  • 호스트 이름 유형 : 리소스 이름
  • DNS 호스트 이름 : 리소스 기반 IPV4(A 레코드) DNS 요청 활성화 에 체크.
  • 인스턴스 자동 복구 : 기본값
  • 종료 방식 : 종료 (중지랑 종료랑 무슨 차이죠?)
  • 종료 방지 : 비활성
  • 세부 CloudWatch 모니터링 : 미선택, 대충 확인해보니 돈나가는 서비스인 것 같아 비활성으로 해도 괜찮을 듯 싶습니다.
  • 탄력적 GPU : 미선택
  • Elastic Inference : 체크 안함
  • 크레딧 사양 : 미선택(무제한이면 요금 나가게 생겼죠?)
  • 배치 그룹 이름 : 미선택
  • EBS 최적 인스턴스 : 미선택
  • 용량 예약 : 없음
  • 테넌시 : 공유됨- 공유된 하드웨어 인스턴스 실행
  • RAM 디스크 ID : 미선택
  • 커널 ID : 미선택
  • Nitro Enclave : 선택불가
  • 라이선스 구성 : 미입력
  • 메타데이터 액세스 가능 : 활성화됨
  • 메타데이터 버전 : V1 및 V2(토큰 선택 사항)
  • 메타데이터 응답 홉 제한 : 1
  • 메타데이터에서 태그 허용 : 비활성화
  • 사용자 데이터 : 미입력, 하단의 사용자 데이터가 이미 base64로 인코딩되어 있음도 체크 해제로 내버려둡니다.

오른쪽에 요약 패널을 보면, 인스턴스 개수가 1개로 되어있을텐데,
이 개수에 따라 요금이 결정되는 것 같습니다. 1개로 유지해둔 후 인스턴스 시작 버튼을 누릅니다. 인스턴스가 하나 만들어졌습니다.

빨간색 박스의 '인스턴스' 목록을 클릭하면 해당 화면으로 진입 가능합니다.
제가 만든 인스턴스가 목록에 있네요!인스턴스 ID를 통해 자세한 정보를 확인해봅니다.

다른 건 잘 모르겠고, 빨간색 박스 안의 퍼블릭 IPv4 주소를 많이 쓰게 될겁니다.
아까 다운로드받은 pem 키로 정상 접속이 되나 확인해봅니다.

pem키는 사실 어디에 있든간에 상관은 없지만, 되도록이면 프로젝트랑 같은 폴더선상에 있는게 편하겠죠? 터미널로 pem키가 있는 폴더로 이동해준 뒤 ls -al 옵션으로 키가 잘 있는지 확인합니다.

맨 앞에 -rwxrwxrwx@ 라고 써져 있는 것은 pem 키의 권한입니다. 우선 권한을 저렇게 낮춰주기 위해 터미널 명령어로 

chmod 400 key.pem

을 적어줍니다. 권한이 변경되었을거에요.
이번엔

ssh -i key.pem ec2-user@(나의 public ip)

로 인스턴스에 접속합니다. 퍼블릭 ip는 아까 빨간박스 안에 있던 바로 그 주소를 뜻합니다. 정상적으로 로그인된다면 이 화면이 뜹니다.

이후에는 git과 linux 패키지 다운로더, node 등을 가상 컴퓨터(인스턴스)에 설치해주어야 합니다.

sudo yum update -y // 를 입력하여 yum (linux 패키지 다운로더)을 업데이트 해줍니다.
  • git 설치 및 github 저장소 연동
sudo yum install git
git clone <repo_front_github url>
git clone <repo_back_github url>
  • 노드 설치(뭔소린지도 모르겠음)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/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 install --lts
nvm use --lts

node -v
// 16.x.x

이러한 과정을 거치면, 인스턴스에서 git과 npm 등의 명령어를 사용할 수 있습니다.

key.pem 키가 외장하드에 있다면 권한변경이 안된다!

이 글을 쓰면서 갑자기 알게 된건데... key.pem 파일을 외장하드에 복사 후, 외장하드에서 인스턴스에 접근 시도 시
권한이 공개되었다는 오류문구와 함께 접속이 불가합니다.
아까 제가 분명 권한을 400으로 바꾸었는데 왜 아직도 권한 코드가 0777일까요?그래서 pem 파일을 여러 개 복사하여 권한 변경을 시도해보았습니다.

  1. pem 키가 외장하드에 위치한 경우 : chmod 명령어가 아예 작동하지 않음(명령어를 제대로 입력해도 권한이 변경되지 않습니다.)
    ls -al로 파일들을 보면 ._key.pem 이라는 이상한 숨겨진 파일도 하나 추가되어 있네요.

  2. pem 키가 데스크톱에 위치한 경우 : chmod 명령어가 잘 작동되고, 처음에 권한을 400으로 설정한 상태도 그대로 복사되어짐

이러한 차이로, 외장하드에 있는 key.pem 키는 제가 아는 한도 내에서 무슨 짓을 해도 권한 변경이 되지 않는다는 것을 확인하였습니다. 외장하드 pem 키는 정말 보관용으로만 사용해야할 듯 싶네요.

생각해보니, 이 pem 키의 권한 변경이 적용되지 않는것은 제가 애초에 pem 파일의 권한을 400(현재 사용자만 사용 가능하게) 바꿔서 그런게 아닐까 싶습니다..

05. 프로젝트 세팅

이제 본격적으로 프로젝트 파일 내에서 변경해줍니다.

프론트 단 세팅,BASE_URL 만들어주기


여기서 15번째 줄을 보시면 fetch 함수로 데이터를 끌어오는 명령을 하고 있는데, 이 부분은 사실

fetch(`http://localhost:8000/products/alllist`, { method: 'GET' })

이렇게 되어있었습니다!
${BASE_URL} 이라는 변수를 새로 설정해주어야 할 차례입니다. 우리 가상 인스턴스의 서버 주소로요.
폴더 최상단에 .env 파일을 하나 만들어줍니다. 안에는 이러한 내용이 들어갑니다.

REACT_APP_BASE_URL=http://(public ip) : (PORT NUMBER)
// ex ) REACT_APP_BASE_URL=http://3.8.210.219:8000

그다음 똑같이 최상단에 config.js 파일을 만들어줍니다. 안에는 이러한 내용이 들어갑니다.

const BASE_URL = process.env.REACT_APP_BASE_URL;

다음엔 package.json 파일로 들어가 스크립트를 추가해줍니다.

// package.json
{
  ...
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "distribute": "npm i && npm run build && pm2 serve build 3000 --name <project-front> --spa" // <- 추가
  },
  ...
	"devDependencies": {
		...
		"pm2": "^5.1.2" // ► npm i -D pm2를 하면 프로그램 설치와 동시에 추가가 됩니다.
	}
}

--name 옆에 들어가는 부분은 프로젝트 이름이 들어갈 거라서, 저는 wecoview-front 라고 바꿨습니다.
pm2라는 패키지가 서버를 항상 가동시켜주는 역할을 하는 것 같습니다.

백단 세팅, 스크립트 추가해주기

허무할정도로 간단합니다. 이쪽은 package.json에 스크립트만 추가해주면 됩니다.

// package.json
{
  ...
  "scripts": {
		...
		// 아래 부분 추가
		"distribute": "npm i && prisma generate && pm2 start server.js --name <project-back> -i max" // <- 추가
  },
  ...
	"devDependencies": {
		...
		"pm2": "^5.1.2" // ► npm i -D pm2를 하면 프로그램 설치와 동시에 추가가 됩니다.
	}
}

마찬가지로 --name 다음 들어갈 프로젝트 명만 변경하여 wecoview-back 으로 변경했습니다.

06. 배포

아까 만들어준 ec2로 접속합니다.(key.pem을 사용한 ssh 접속)

ls 명령어로 폴더를 확인하면 저희 프로젝트의 백단과 프론트단 레포가 복사되어있습니다.

front

프론트 레포로 먼저 들어간 후, .env를 한번 더 생성해줍니다.

cd <front-repo> 
vim .env

위에서 만들었는데 왜 또 만드냐면, .env는 .gitignore 파일의 목록에 들어가 원격 저장소에 올라가지 않았기 때문이죠... 아까의 내용 그대로 붙여넣기.

back

백단 레포로 이동하여, 해당 명령어를 실행해 줍니다.

npm run distribute

백단 서버주소는 http://3.8.210.219:8000/ 이 될 것입니다.

front again

다시 프론트 레포로 돌아와 화면 구동을 시켜줍니다.

npm run distribute

프론트단 서버주소는 http://3.8.210.219:3000/ 이 될 것입니다.

이 주소로 들어가면, 저희가 지금까지 만들어낸 화면이 보이는 게 정상입니다.

저는 안됐습니다.

팀원 5명 모두가 같은 가이드를 보고 같은 명령어로 실행했으나, 배포에 성공한 분은 딱 1분이었습니다.
1. 프론트 쪽 서버만 켜지거나
2. 백쪽 서버만 켜지거나
이러한 현상들이 팀원들에게서 일어났기에, 저희는 다행히 성공한 팀원분의 배포 ip를 사용하기로 했습니다.

이제 아시겠나요? 배포가 왜 제일 어려운지...
똑같은 조건에서 각자의 ip만 다르게 입력한건데도 되거나 안되는게 배포인 것 같습니다. 하지만 aws를 이용해 프로젝트를 배포한다는 경험 자체만으로도 또다시 성장했으며, 다음에 또 프로젝트를 해도 버벅거리진 않을 거라는 믿음이 생겼습니다.
이제 이 경험을 가지고 2차 프로젝트도 진행해야겠네요.
정말로 여기까지 다 읽으신 분이 있다면, 읽느라 고생하셨고 감사합니다.

profile
LSA
진짜 간단하게 작성한 TIL 블로그
이전 포스트

[3주차 시작] 프로젝트 회고하기

0개의 댓글