들어가기 앞서
AWS 기초 시리즈에서 AWS의 구성을 살펴보았으니, 배운 것을 활용할 겸 AWS를 적극 사용하려한다.
물론 AWS에서 제공하는 Code Build나 Code Pipeline까지 활용해야 적극 활용이라 할 수 있지만, CI는 Jenkins를 이용하고 CD는 Code Deploy를 이용하여 구축하겠다.
AWS Code Deploy는 AWS에서 제공하는 배포 서비스로, EC2에서 사용하는 경우
무료이다.
On-premise에서 Code Deploy를 사용하는 경우는 업데이트당 0.02USD가과금된다.
1. Why Jenkins?
나는 처음에 다음과 같은 이유로 Travis를 사용하여 환경을 구축하려 했다.
- 무료(오픈소스에 한해서)
- GitHub와의 강력한 연동
- 추가적인 서버 필요 없음
하지만 다음과 같은 결정적인 단점이 존재하였고, 이는 굉장히 치명적이었다.
- 래퍼런스 문서가
없음
아무것도 아닌 문제처럼 보일 수 있으나, 정말 심각하게 내가 원하는 방향에 관련된 문서가 없었다.
Jenkins는 다양한 플러그인과 이를 Script로 표현하여 설정하는 다양한 문서들이 존재하는 반면에,
Travis는 Unity를 배포하는 방법에 관련된 문서가 없었다.
그나마 존재하는 문서들은 Mac 환경에서 진행된 개발이 전부였고, Window와 Ubuntu에서 진행하는 내게 이는 상당한 부담으로 다가왔다.
아무것도 안하고 이 일만 하면 모를까 회사일과 병행하며 삽질을 하기에는 무리였다..
결국 하루의 삽질과 고민 끝에 Jenkins로 노선을 변경했다. AWS를 공부하고 배웠으니 이렇게 된김에 free tier가 유지되는 동안에 적극 활용해보자는 다짐과 함께.
만약, AWS CI/CD에 관심이 있다면
AWS Code Build & Code Pipeline을 사용하는 것을 추천한다.
AWS도 훌륭한 빌드 툴과 전체적인 파이프라인을 관리하는 툴을 제공한다.
하지만 Code Build는 빌드 시간으로, Code Pipeline은 활성화된 파이프라인 개수로과금한다.
물론프리티어를 제공하지만, 장기적으로 생각을 잘해서 선택하기를 바란다.
여기 훌륭한 자료가 있어 링크를 공유한다.
2. 전체 구성
내가 구성한 CI/CD의 전체 구성도는 위와 같은데, Jenkins를 이용하여 CI를 구축하고 Code Deploy를 이용해 CD를 구축하기로 했다.
둘 사이의 연결은 Jenkins에서 제공하는 Code Deploy Pulgin을 사용할 계획이다.
이러한 파이프 라인을 통해 S3에 빌드 결과물을 저장하고, AWS Code Deploy에서 해당 결과물을 가지고 우리가 가동할 APP 서버에 배포하는 방식이다.
여기서 Jenkins Build Server와 배포를 위한 앱 서버는 모두 EC2를 사용할 것이며, VPC와 IAM 설정을 통해 해나갈 것이다.
App은 Unity를 사용하여 만들고 구글 플레이스토어에 배포할 계획이며, 하나의 App 서버를 두고 가동할 예정이다.
배포하는 방식은 이 글을 작성하는 시점에서 아직 다른 개발자와 협의가 이루어지지 않아
미완성으로 남겨놓았다.
추후, 논의되어 합의가 이루어지면업데이트할 예정이다.