0. AWS + Spring Boot + React 프로젝트 근데 이제 배포 자동화를 곁들인

사내 스터디로 AWS를 학습하게 되었다.

아래와 같은 이유로 프로젝트 주제와 기술을 선정하였다.

 

• 프론트와 백을 나눠보고 싶다 근데 A+B 조합은 많이 보이는데 A+C 조합은 잘 안 보인다 내가 해봐야겠다
• 배포 자동화가 얼마나 편한지 알고 싶다
• 클라우드도 써보고 싶다

 

좋은 튜토리얼은 많이 있으니 이 포스트에서는 헤매던 부분과 전체적인 흐름에 대해 공유하고자 한다.

나처럼 시작부터 막막함을 느끼는 사람들이 있다면 이 글이 도움이 되었으면 좋겠다.

 

0. 목표 및 구조
1. React & Spring Boot
2. AWS S3/EC2
3. 배포 자동화 - Github Actions & AWS CodeDeploy
4. 정리

 

0. 목표 및 구조

클라우드 환경 필요성

1. 특정 데이터를 테스트 DB에 당장 추가해야 하는 상황. 테이블스페이스 공간 부족 에러 발생.

찾아보니 테이블스페이스 공간을 늘릴 수 있는지 확인하고 테이블스페이스를 늘리면 된다고 한다. 간단하다.

하지만 우리 회사 개발자에겐 권한이 없었고 임시방편으로 다른 방법을 찾아야 했다.

예전부터 DB 용량 관련 이슈가 있던 오래된 시스템이었다.

 

2. 대코로나 시대가 열리고 재택근무를 하게 되었다.

망분리 환경(고객사)에서 개발을 하다가 재택근무를 하려고 보니 개발 환경이 대비되어있지 않았다.

회사 서버에 개발 환경이 구성되는 걸 기다리느라 일정이 지체되었다.

실제 개발 환경이 바뀔 때마다 매번 회사 서버도 동기화해줘야겠지?

근데 회사 서버가 뻗기라도 한다면? 사무실로 출근하신 분을 찾아야 하나?

 

클라우드 환경이었다면 어땠을까. 뭐가 좀 다를까?

 

 

배포 자동화, 외부 설정 파일 분리

1. Application.properties 하나의 외부 설정 파일에 real, dev, local 정보가 주석 처리로 관리되고 있는 Spring Framework 프로젝트.

주석 처리를 빼먹어서 실수로 개발 서버에 로컬 환경으로 배포한 경험이 있다.

 

2. 빌드, ftp 파일 전송, 톰캣 재실행 - 확인 - 수정 - 빌드, 배포 - 확인 - 수정 - 빌드, 배포 ... 무한 반복

배포 자동화하면 편하지 않을까요 물어봤더니 러닝 커브가 낮지 않다, 작은 규모라 필요가 없다는 반응이 대부분이었다.

언젠간 꼭 배포 자동화를 써보고 싶다고 생각했다.

 

 

웹 서비스의 전체적인 흐름 학습

1. 한 번쯤은 시스템의 A부터 Z까지 겪어보고 싶었다.

2. 특히 웹 서버에서 백엔드와 프론트를 같이 개발하다보니 백엔드과 프론트를 분리하는 환경이 궁금했었다.

 

 

구조

 

사용 기술

프론트: React, AWS S3 정적 웹 호스팅
백엔드: Spring Boot, MySQL, AWS EC2 인스턴스
CI/CD: Github Actions, AWS CodeDeploy

 

구현 코드

백엔드

GitHub - leelee31/my-app-backend: Spring Boot Repository for AWS + Spring Boot + React 프로젝트 근데 이제 배포 자동

프론트엔드

GitHub - leelee31/my-app-frontend: React Repository for AWS + Spring Boot + React 프로젝트 근데 이제 배포 자동화를