참고사항
- 해당 배포 방식은 SPA 로 만들어진 프로젝트를 S3, CloudFront 로 배포했을 때 배포 자동화를 구성하는 방법입니다
- 해당 글은 우테코에서 제공해준 AWS 의 정책을 기준으로 해결해나간 과정입니다
(배포 자동화 흐름도는 팀원 무빈이 그려줬습니다 😄)
배경
이전 프로젝트에서는 AWS Amplify 를 이용하여 클릭 몇 번으로 깃허브 특정 브랜치와 연동하여 배포 자동화가 매우 쉽게 구축이 되었는데 이번에는 Amplify는 허용되지 않았다.
우테코 프로젝트를 진행하며 AWS 금액 일부를 지원해주기에 유료 서비스도 사용해볼 수 있었기에 다른 방법을 찾아봤고 대략 3가지 방법이 있을거 같다.
1. github action 으로 ssh 접속하여 배포 (git clone, docker pull 등등)
2. github의 self-hosted runner 를 이용
3. aws codeBuild, codePipeline 이용1. github action 으로 ssh 접속하여 배포
가장 간단한 방법인거 같은데 access key 또는 ssh 비대칭키를 제공해주지 않기에 해당 방법은 이용할 수 없었다.
(여담이지만 아마 누군가의 실수로 키가 유출되면 금액적 부담과 회사 이미지 타격이 있기에 해당 방법은 제공해주지 않는거 같다)
2. github의 self-hosted runner 를 이용
1번 방법이 막혀있어 이전 기수 크루들이 많이 사용한 방법인거 같다.
github action 에 정의된 yml 코드를 내 서버(EC2)에서 동작시키는 방법으로 EC2 에서 S3 로 접근하여 파일 수정이 가능하기에 배포 자동화를 구성할 수 있다.
self-hosted runner 의 동작은 아래와 같다.
1. github 에서 self-hosted runner 설정을 한다
2. 내 서버(EC2)에 self-hosted runner 설정을 추가한다.
3. 개발자가 정의한 트리거가 발생하면 정의된 action 을 내 서버에서 실행시킨다.Jenkins을 써보진 않았지만 동작이 Jenkins과 비슷한거 같다.
충분히 좋은 방법이지만 개인적으로 EC2 에 백엔드 서버를 배포하게 되는데 self-hosted runner 가 추가적으로 리소스를 사용하여 동작하는게 마음에 들지 않았다.
그리고 해당 동작을 생각했을 때 배포 자동화를 시키는 리소스가 적지 않을것이라 판단하여 해당 방법은 선택하지 않았다.
3. AWS codeBuild, codePipeline 이용
위에서 언급한 AWS Amplify 는 S3, cloudfront, codePipeline, codeBuild 를 쉽게 구성하기 위해 도와주는 플랫폼이다. 그 말은 즉 codePipeline, codeBuild 를 이용하여 배포 자동화를 구성할 수 있다고 생각하였다.
그리고 이번 기회에 공부하면서 해당 서비스를 이용해보고 싶었기에 해당 방법을 이용하기로 했다 😄
AWS 서비스 소개
우선 시작하기전 codePipeline, codeBuild, codeDeploy 가 무슨 서비스인지 알아야 흐름을 파악하기 쉬울거 같다.
codePipeline
말 그대로 파이프라인을 구성해주는 서비스이다. 위의 사진과 같이 각각의 작업을 파이프라인으로 연결하여 유기적으로 동작하도록 도와주는 역할을 한다.
codePipeline 에서 codeBuild, codePipeline 말고도 정말 많은 서비스를 파이프라인으로 구성할 수 있다.
codeBuild
소스코드를 빌드해주는 서비스이다. 특정 위치(github repo 등)에 있는 코드를 가져와 빌드하여 결과물을 S3 등에 저장해준다.
codeDeploy
코드를 배포해주는 서비스이다. 배포 대상 서비스는 EC2, Lambda, ECS, On-premises 등으로 EC2에 배포할 때 필요하지만 S3에 배포하는 경우엔 사용할 필요가 없다.
그래서 나는 codeDeploy를 사용하지 않았다.
구성 방법
구성 방법부터 내용이 길어질거 같아 글을 나눠서 게시하려고 한다. 배포 자동화 흐름도의 순서에 따라 codeBuild -> codeDeploy -> lambda 순서대로 어떻게 서비스를 구성하고 필요한 옵션에 대해서 살펴볼 예정이다.
