27일차 aws

Sprint 1 - 3 Tier Architecture (HTTP)

 

Prerequisite

앞선 슬라이드를 통해 S3, EC2, RDS에 대한 개념 학습을 완료했습니다. 이번 스프린트에서는 코드 작성이 완료된 애플리케이션을 AWS 서비스를 통해 배포하는 스프린트를 진행하겠습니다.

Bare Minimum Requirement

• Sprint Repository의 소스코드를 이용하여, 어떤 구조로 구성되어 있는지 확인합니다.
• HTTP 스프린트의 테스트를 모두 통과해야 합니다.
• 웹 애플리케이션이 배포 상태에서 잘 작동해야 합니다.

Getting Started

• EC2, S3, RDS와 Repository의 소스코드를 가지고 웹 애플리케이션을 배포하기 위해 어떤 아키텍처를 가져야하는지 이해해야 합니다.
  • 아키텍처에 따라 어떤 과정을 먼저 진행해야 할지 확인합니다.
• 먼저 각 client , server 디렉토리에서 dependencies를 npm install 을 통해 설치합니다.
• 클라이언트와 서버 디렉토리에 각각 위치한 .env.example 파일을 보며 어떤 환경변수들이 정의되어 있는지 확인합니다.
• .env.example 파일을 .env 파일로 생성하여 REACT_APP_API_URL에 EC2에 배포한 서버 주소로 설정합니다.
• S3를 통해 client 디렉토리에 있는 소스코드를 먼저 정적 웹 호스팅 방식으로 배포합니다.
• .env 파일의 테스트에 필요한 환경변수를 채워넣습니다.
• client 디렉토리에서 npm run test1 명령을 사용해 테스트를 전부 통과하는지 확인하고, 웹 애플리케이션이 정상적으로 배포되어 작동하는지 확인합니다.
• 테스트가 모두 통과되면 제출하고, 다음 HTTPS 스프린트로 넘어갑니다.

 

s3 ec2 rds를 이용해 3티어 아키텍처를 만드는 실습을 하였다. 

 

먼저 깃허브에서 클론을 하여 클라이언트 폴더와 서버를 npm i를 한 후 .env를 수정했다.

 

그후 aws에 들어가 ec2를 만들었다. 

 

SSH로 연결해서 인스턴스를 연결한 뒤 npm, node 등 필요한 파일을 다운 받고 EC2에 돌릴 서버 파일도 다운 받고 설치까지 마쳤다.

 

 

그 후 서버를 실행 시킨 후 EC2의 IP로 들어가니 서버가 잘 실행되는 모습을 확인할 수 있었다.

 

 

이제 S3를 프론트앤드로 만들 차례다.

 

먼저 버킷을 퍼블릭으로 만든 후 정적 웹 사이트 설정과 권한 설정을 해주었다.

 

기본페이지는 index.html로 하였고 권한은 와일드카드를 써서 읽기 권한만 주었고 그 후 EC2의 ip주소를 클라이언트 폴더의 env에 적고 빌드를 하였다. 그 후 빌드에 파일을 s3 버킷에 다 넣었다.

 

그 후 정적 웹 사이트로 가니 s3에 올린 index.html 파일이 기본페이지로 되어있었다.

 

그 다음 데이터베이스랑 백앤드서버랑 연결 할 차례이다. 데이터베이스는 RDS로 구성한다.

 

mysql로 rds를 만들었고 이제 ec2랑 rds를 연결해야하기때문에 ec2에서 환경변수파일에 rds값을 넣어줬다.

 

그 후 s3에 들어가서 로그인하면 성공이 뜬다.

 

 

 

Sprint 2 - 3 Tier Architecture (HTTPS)

 

Prerequisite

• Sprint1인 HTTP 배포를 완료해야 합니다.
• HTTPS에 대한 이해와 학습이 선행되어야 합니다.
• AWS Route53을 통해 구매한 도메인이 있어야 합니다.

Bare Minimum Requirements

• HTTPS로 웹 애플리케이션을 배포할 수 있어야 합니다.
• CloudFront, Certificate Manager, Elastic Load Balancer, Route53 등의 서비스에 대해서 이해합니다.
• 모든 테스트를 통과하고, 제출해야 합니다.

Getting Started

• HTTPS를 적용하기 위해서는 어떤 아키텍처와 어떤 AWS 서비스가 필요한지 구상합니다.
  • 구상한 내용을 draw.io 등을 이용해 다이어그램으로 그리고, 해당 이미지파일을 S3에 httpsdiagram 이라는 이름으로 업로드합니다.
  • 이때 해당 객체에 대한 퍼블릭 액세스를 허용해야 테스트를 통과할 수 있습니다.
• .env파일에 HTTPS 적용을 위한 환경설정으로 적절하게 작성합니다.
• npm run test2 명령을 사용해 테스트가 통과하는지 확인합니다.
• 실제로 웹 애플리케이션이 브라우저 상에서 HTTPS 프로토콜로 작동하는지 확인합니다.

1. Certificate Manager를 통한 도메인 인증서 발급

• 구매한 도메인을 기준으로 인증서를 발급 받습니다.
  • 인증서는 프론트엔드 Cloudfront 사용 리전인 us-east-1과 백엔드 Load Balancer 사용리전인 ap-northeast-2에서 발급 받아야 합니다.
  • 발급 시, DNS 검증 가이드로 레퍼런스를 참고하세요.
  • 이후에 DNS 공급자로 Route53을 이용합니다. Route53에 레코드 생성과정을 반드시 거쳐야합니다.
• 인증까지 최소 30분의 시간이 소요될 수 있습니다.

2. 백엔드 HTTPS 적용

• 애플리케이션 로드밸런서(Application Load Balancer)를 생성합니다.
• ALB의 리스너, 가용영역, 인증서를 설정합니다.
• 대상 그룹(target group)을 등록합니다.
• 로드밸런서 DNS 주소로 접속해, 테스트를 진행합니다.
• 아래 레퍼런스를 참조하여, 스프린트를 진행합니다.

3. 프론트엔드 CDN 및 HTTPS 적용

• Cloudfront는 서울 리전을 지원하지 않습니다.
• Origin Domain을 설정해야 합니다.
• Viewer protocol policy는 Redirect HTTP to HTTPS로 지정해야 합니다.
• Certificate Manager에서 발급받은 인증서를 사용해야 합니다.
• Default root object 부분에 index.html을 작성해야 합니다.
• 대체도메인과 인증 받은 도메인의 이름이 같아야 합니다.
• 생성된 배포의 Distribution domain name으로 접속이 되는지 확인합니다.
• 아래 레퍼런스를 참조하여, 스프린트를 진행합니다.

4. Route53 레코드 등록

• 백엔드와 프론트엔드의 별칭 레코드를 Route53 호스팅 영역에 생성합니다.
• 백엔드는 https://api.yourdomain.click으로 접속 시, 로드밸런서로 연결되어야 하며, 프론트엔드는 https://www.yourdomain.click으로 접속 시, Cloudfront로 연결되어야 합니다.

 

 

 

 

먼저 시간이 오래 걸리는 인증서를 신청한 후 서울리전과 cloud front 사용 리전인 버지니아에 각각 신청을 한 후 로드밸런서를 만들었다.

 

그 후 로드밸런서 주소로 들어가보니 백앤드서버랑 잘 연결 된 것을 확인 할 수 있었다.

그 후 cloud front에 가서 조건에 맞게 생성하였다.

그 후 route53에 가서 레코드 정의를 하였다.

왼쪽은 백앤드, 오른쪽은 프론트앤드며 각각 해당 레코드 이름으로 들어가면 

접속이 잘 되는 것을 볼 수 있으며 마지막으로 데이터베이스 연결까지 해보겠다. 일단 클라이언트에 가서 env 파일을 수정 후 새로 빌드하여 s3 버킷에 올리면 된다.