서론
MSA구조를 만드는 개인 프로젝트를 진행중이다.
서비스 중 하나인 User서비스(자바 스프링)가 독립적으로 존재하는 EC2서버를 github action으로 배포해보자.
AWS에서 제공하는 자습서에서도 다양한 정보를 얻을 수 있다.
github-action을 이용한 배포의 동작 과정은 다음과 같다.
- Git repository에
Event발생(push/pull request) - github action에서
Workflow동작- build, test가 성공하면
- S3에 레포지토리가 압축형태로 업로드된다.
- CodeDeploy에서 S3의 파일을 이용해 배포를 시작한다.
- EC2에 배포된 파일 내의 스크립트를 통해 필요한 프로그램(java project) 실행됨
이 과정은 EC2, CodeDeploy를 활용한 본 글에 해당하는 경우로, 다른 서비스를 이용할 경우 workflow이후의 과정은 다를 것이다.
배포 성공/실패 여부를 Slack알림으로 보낸다거나, DB관련 작업을 수행한다거나...
❓github action이란?
CI/CD를 간편하게 할 수 있게 github에서 제공하는 서비스다.
workflow를 정의하면서 시작된다.
workflow는 여러job들로 이루어지고
job은 여러step으로 이루어진다.
이러한 작업들은runner라는 가상머신에서 이루어진다.
workflow는 레포지토리 최상단에서 .github/workflows 폴더에 있는 yaml파일에 정의한다.
Docs 👉 https://docs.github.com/ko/actions/quickstart
workflow에서 수행할 다양한 작업들을 간단히 불러와서 사용할 수 있는 marketplace도 존재한다. 👉 https://github.com/marketplace?type=actions
시작해보자
#1 레포 개설 및 spring백엔드 개설
먼저 Repository를 파서 간단한 java project를 만든다.
필자는 RDS에 입력해놓은 user List를 반환하는 응답도 추가적으로 만들었다.
👉 modelmapper를 설명한 글에 프로젝트 코드가 포함되어있다.
로컬에서 포스트맨으로 get요청을 보내면 잘 동작한다.
추가적으로 필자가 사용하는 application.yml을 첨부한다.
{{~}}처리된 항목은 자신에게 맞게 직접 입력한다.
spring:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://{{rds엔드포인트}}:3306/{{사용할 스키마}}?serverTimezone=Asia/Seoul&characterEncoding=UTF-8
username: {{rootid}}
password: {{rootpw}}
jpa:
hibernate:
ddl-auto: update
dialect: org.hibernate.dialect.MySQLDialect
logging:
file:
name: runtime.log#2 [EC2, RDS] instance 생성
프리티어 요금제로 개설한다. 보안그룹 설정도 잘 해주자. 자세한 내용은 생략한다.
EC2 : Amazon Linux 운영체제로 생성하였다. pem키를 발급하고 MobaXterm등의 SSH연결 도구로 접속이 잘 되는지 테스트하자.
RDS : MySQL 8.0.33으로 생성하였다. '마이너버전업그레이드', '자동백업' 같은 옵션들을 제거해야 결제를 피할 수 있다. 마찬가지로 로컬 워크벤치 등에서 정상작동을 테스트해보자.
#3 [EC2] CodeDeploy 설치
EC2의 직렬 콘솔이나 MobaXterm등으로 인스턴스에 codedeploy-agent를 설치한다.
패키지 관리자로 dnf를 사용했는데 많이들 사용하는 ubuntu의 경우 apt를 사용하면 된다.
sudo dnf upgrade --releasever=2023.3.20240108 #작성일 기준 최신버전
sudo dnf install ruby
wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo service codedeploy-agent status
마지막줄을 실행하면 deprecated관련 워닝이 뜨는데 마지막줄을 보면 PID와 함께 정상 실행중이라는 메세지를 확인했다👍
#4 [IAM] 역할 생성
역할 role : EC2, CodeDeploy에 할당할 role이다. S3, CodeDeploy 접근권한을 부여한다.
EC2와 CodeDeploy에 할당할 role을 각각 만들것이다.
정책은 S3FullAccess, CodeDeployFullAccess
이름도 식별하기 좋게 지어주자. 필자는 role-ec2-user라 명명했다.
CodeDeploy용 role도 생성한다.
위 사진에서 아래쪽에 빨간색으로 표시된 '서비스 또는 사용 사례'의 드롭다운리스트에서 CodeDeploy를 선택하면 정책도 자동으로 지정된다.
적절한 이름을 지어주고 생성한다.
role 생성을 완료했다면 EC2의 인스턴스를 클릭해서 방금 만들었던 EC2용 역할을 할당해준다.
#5 [IAM] 사용자 생성, 키 저장
사용자 : github-action에서 CodeDeploy, S3를 접근할 수 있는 키를 발급하기 위한 주체
이름을 지어주고,
직접 정책 연결에서 S3FullAccess, CodeDeployFullAccess 지정하고 생성한다.
생성된 사용자의 보안자격증명에서 액세스키를 만든다.
'AWS외부에서 실행되는 애플리케이션' 선택하고 생성한다.
비밀 액세스 키는 나중에 확인할 수 없으므로 바로 기록해둔다.
기록하지 않았거나 사라졌으면 secret에 등록할 때 다시 발급하면 된다.
#6 [github] secret에 키 등록
레포지토리 - Settings - Security and variables - Actions 에서 'New repository secret'버튼을 눌러서 방금 발급받은 액세스 키와 비밀 액세스 키를 등록한다.
secret에 등록해놓으면 민감정보들을 레포지토리에 노출할 필요 없이 변수형식으로 사용할 수 있다.
${{secrets.변수명}} 과 같이 사용하면 된다. 이어서 작성될 두번째 게시글의 workflow파일에서 사용법을 확인할 수 있다.
ex) ${{ secrets.USER_SECRET_ACCESS }}
필자는 프로젝트의 application.yml파일과 RDS서버의 root비밀번호도 등록해놓았다. 프로젝트의 application.yml(properties)파일이 레포지토리에 올라가있다면 등록하지 않아도 되고, 올라가있지 않다면 등록해주자.
#7 [S3] 버킷 생성
버킷을 생성한다.
추가로 다른 서비스들이 추가될 것을 생각해 전용 폴더를 생성한다.
#8 [Codedeploy] 애플리케이션, 배포그룹 생성
생성된 애플리케이션을 클릭해서 아래와 같이 배포그룹을 생성한다.
서비스 역할에 #5에서 생성했던 codedeploy용 역할을 선택해주고
환경구성에선 Amazon EC2 인스턴스를 체크하고 배포될 EC2 인스턴스를 선택한다.
로드밸런싱은 체크해제한다. (추가요금이 있는 것으로 알고있다.)
그 외에는 기본값으로 진행했다.
이어서!
이렇게 AWS관련 작업을 마쳤고, 다음 게시글에서 workflow정의, codedeploy작업 설정을 마무리 할 것이다.
여기까지 한두단계를 빼면 AWS관련 작업으로 장장 6단계를 밟았는데,
AWS를 처음 접한다면 필요 이상으로 시간을 잡아먹을 수도 있겠지만 용어나 기본 세팅에 익숙하다면 '딸깍' 몇번만 하면 되는 아주 간편한 작업이고 이러한 간편함이 AWS를 이용하는 주된 이유라고 할 수 있겠다.
그렇다고 품질이 떨어지는 것도 아니고 문의를 하면 보통 2시간 내로 답변이 돌아오니 많은 기업들도 사용하고 있지 않나 싶다.
