정리 목적

이번에 AWS에 배포 테스트를 하며 UI가 변경된 부분도 좀 있었고 이전에는 도메인 구매 후 접근 테스트만 해본 반면 이번에는 여러 환경을 설정하고 처리했기 때문에 이전 정리 내용을 지우고 새로 다시 정리.

 

처리 환경 정리

Project

  • BackEnd - Spring Boot 3
  • FrontEnd - React
  • 빌드 방식 - 통합빌드

AWS

  • EC2 t2.micro
    • ubuntu 22.0.4
  • Application Load Balancer
  • AWS Certificate Manager(ACM)
  • Route53
  • S3
  • RDS(MySQL)
  • ElastiCache(Redis)

CI / CD

  • Jenkins
  • Git Webhook

WebServer

  • Nginx

Domain Register

  • Gabia

 

정리 순서

  1. S3 Bucket 생성 후 Local에서 테스트
  2. RDS MySQL Database Instance 생성 후 Local Workbench와 연결 테스트 및 프로젝트 연결 테스트
  3. EC2 Instance 생성 후 설정
    1. swap 메모리 설정
    2. JDK 17 설치
    3. nvm 설치 및 node 21.7.1 설치
    4. Nginx 설치 및 설정
    5. Jenkins 설치 및 빌드 Job 설정을 제외한 나머지 처리
    6. ElasiCache Redis OSS Cache 생성 및 Redis 설치
  4. Gabia 도메인 구매 후 Route53, ACM 처리
  5. Load Balancer 대상 그룹 생성 및 ALB 생성 후 대상 그룹 설정
  6. A레코드 생성 및 도메인 접근 테스트
  7. git clone을 통해 사전 테스트 이후 Jenkins Job 설정과 Build 테스트
  8. Git Webhook 연동 및 테스트

RDS MySQL Database Instance 생성

RDS instance를 생성하기 전 보안그룹을 먼저 생성하는게 편하다.

테스트이기 때문에 하나의 보안그룹을 통해 모든 환경에서 사용하도록 했으나 각 환경에 따라 분리하는 것이 더 좋을 수 있다.

 

생성하는 보안그룹은 모든 AWS 환경에 적용할 것이다.

AWS EC2로 이동해 네트워크 및 보안 -> 보안 그룹으로 이동해 보안 그룹 생성 버튼을 눌러 생성해준다.

인바운드 규칙과 아웃바운드 규칙을 설정해준다.

아래 이미지를 보면 두개씩 설정된 유형이 있는데 각각 IPv4와 IPv6에 대한 설정이기 때문.

그리고 아래 이미지와 동일하게 설정한다면 모든 포트 접근에 대해 누구나 접근할 수 있는 설정을 해주는 것이다.

즉, 테스트니까 이렇게 해도 되는거지 이 방법이 맞는 방법은 아니다.

HTTP, HTTPS의 경우 사용자의 아이피를 특정해 모두 작성할 수 없기 때문에 아무나 접근할 수 있어야 하지만 EC2 인스턴스에 접근 할 수 있는 SSH 같은 경우는 자신의 아이피만 설정해준다거나 하는 처리가 필요하다.

열어준 인바운드 규칙을 보면 유형으로 유추 할 수 있는 규칙을 제외하고 8080과 9095 두개가 더 있다.

8080은 프로젝트 서버 포트고 9095는 추후 Jenkins 포트로 사용한다.

아웃 바운드 규칙에 대해서는 모든 트래픽에 대해 허용하는 설정 그대로 둔다.

이전에 테스트했을 때는 아웃바운드 규칙이 따로 분리가 안되어있어서 처음에 설정 안하고 삭제했더니 EC2에서 뭐 설치할 때 막힌다..

아웃바운드 규칙 다 삭제하고 막아두었다가 EC2 인스턴스 한 5번은 재생성 한 것 같으니 절대 열어준다!!!!

인바운드 규칙은 해당 포트로 접근하는 것에 대한 보안 설정이라면 아웃바운드는 서버에서 외부로 요청하는 것에 대한 설정이기 때문에 완전히 폐쇄적으로 외부 요청을 차단하는 경우가 아니라면 설정해줘야 하며, 내부에서 관리가 잘 되어야 한다.

 

 

그럼 이제 RDS를 생성한다.

RDS로 이동해 대시보드에서 데이터베이스 생성 버튼을 클릭

 

데이터베이스 생성 방식은 표준 생성을 통해 생성했다.

엔진 옵션으로는 MySQL을 선택.

 

엔진 버전에서는 사용할 MySQL 버전을 선택한다.

템플릿은 기본으로 프로덕션에 선택이 되어있는데 테스트이기 때문에 프리티어를 선택해준다.

프리티어 계정이라면 프리티어를 사용해야만 요금이 발생하지 않는다.

그리고 프리티어가 끝난 계정이더라도 프리티어로 생성하는게 싸다.

프리티어를 선택하는 경우 가용성 및 내구성에 대한 설정은 할 수 없게 된다.

 

 

설정 탭에서는 필수 입력으로 DB 인스턴스 식별자와 마스터 사용자 이름, 암호 및 확인이 필요하다.

입력해주고 자격증명 관리는 자체 관리를 선택했다.

마스터 암호는 프로젝트 서버의 설정 파일에도 필요하고 로컬에서 Workbench에 연결할때도 필요하다.

마스터 사용자 이름과 암호는 그냥 흔히 로컬에서 root 계정과 암호라고 보면 된다.

인스턴스 구성 탭에서는 프리티어를 선택하는 경우 버스터블 클래스로 고정되기 때문에 그대로 두면 된다.

 

 

스토리지는 테스트 용도이기 때문에 따로 손대지 않았고 기본값으로 유지.

 

연결 탭에서는 EC2 컴퓨팅 리소스에 연결 안함을 택했다.

네트워크 유형의 경우 IPv6까지 해줄 필요는 없었기 때문에 IPv4를 선택.

퍼블릭 액세스를 ' 예 ' 로 체크해줬다.

 

보안 그룹에서는 기존 보안 그룹을 선택하는데 인스턴스 생성 전 만들었던 보안그룹을 선택한다.

보안그룹 하단의 추가 구성을 누르면 포트 설정이 나오고 변경할 수 있는데 기본 포트를 사용할 것이라면 그대로 두고 수정할 계획이라면 수정. 대신 수정하는 경우 보안 그룹에서 3306 포트가 아닌 수정한 포트 설정으로 인바운드 규칙을 설정해줘야 한다.

데이터베이스 인증은 암호 인증으로 선택해 마스터 암호로 접근할 수 있도록 해ㅑㅆ다.

 

테스트기 때문에 모니터링도 따로 활성화 하진 않았다.

모니터링 탭 하단의 추가 구성은 닫혀있을 건데 열어서 초기 데이터베이스 이름을 작성해준다.

필수까지는 아니지만 작성하지 않는다면 RDS에서 데이터베이스를 생성하지 않기 때문에 미리 작성하는게 편하다.

배포할 프로젝트에 연결할 데이터베이스 이름을 작성해준다.

백업도 따로 필요하진 않았지만 체크된 상태로 유지했다.

그럼 모든 설정이 끝났다.

최하단에는 요금에 대한 설명이 나오니 한번 확인하고 데이터베이스 생성 버튼을 클릭해 생성한다.

 

 

생성이 완료되었다면 데이터베이스명을 클릭해 정보로 들어가 연결 및 보안 탭에서 엔드포인트를 복사한다.

 

 

RDS를 프로젝트와 Local Workbench에 연결

 

RDS 엔드포인트는 두군데서 사용한다.

  1. 프로젝트 application.yml
  2. Workbench

 

설정에 따라 조금씩 차이가 있을 수 있지만 아래와 같은 구조일텐데 localhost 부분에 엔드포인트를 붙여넣기 해주면 된다.

datasource:
  url: mysql://localhost:3306/database_name?....
  username: RDS 마스터 사용자 이름
  password: RDS 마스터 사용자 암호

 

그럼 프로젝트와 연결을 끝!!

 

다음은 Workbench와 연결한다.

Workbench를 열어주고 MySQL Connections 옆에 보면 + 버튼이 있다.

클릭!

 

버튼을 눌러 열리는 창에서 Connection Name은 원하는 이름으로 작성해주고 Hostname에는 RDS 엔드포인트, Username에는 RDS 마스터 사용자 이름을 넣어준다.

그리고 Store in Keychain을 눌러 RDS 마스터 사용자 암호를 입력한다.

다 설정했다면 하단의 Test Connection을 눌러 연결상태를 확인한다.

결과 창에 Successfully made the MYSQL connection이 나온다면 연결이 성공한 것이다.

들어가서 데이터베이스까지 체크하면 연동 끝~

+ Recent posts