AWS Codebuild를 이용한 Jenkins 분산 빌드환경 구축하기
안녕하세요.
이번에는 Jenkins에서 agent로 Codebuild를 활용해서 쉽게 CD 환경을 구축한 사례를 소개드립니다.
왜 CD 환경을 구축하게 됐는지?
AS-IS
기존에는 개발자들이 local에서 직접 도커를 빌드 후 배포하는 방식으로 배포 중이었습니다.그렇기 때문에배포 과정에서 문제가 생기거나 보안적인 문제가 발생 했습니다.
배포 과정에서의 문제: local directory에서 엉뚱한 내용이 들어간채로 배포되고 있었고 slack webhook 외에는 배포 이력이 남지 않았습니다.
보안적인 문제: 많은 개발자들이 배포 권한을 가지고 있었기 때문에 IAM Role에서 많은 권한이 부여된 상태였습니다.
TO-BE
CD 환경을 구축해서 그곳에서 배포한다면 배포 과정에서 생기는 문제들을 방지할 수 있고 IAM Role을 운영상 꼭 필요한 권한만 부여하고 나머지 권한은 회수할 수 있다고 생각했습니다.
CD 개발시 요구사항은 다음과 같았습니다.
- 서비스간 관계가 복잡하기 때문에 자동 배포가 아닌 수동 배포가 가능해야 한다.
- 개발자들이 직접 CD에 접속해서 배포할수 있어야 한다.
위 요구사항을 해결하기 위한 도구로 jenkins를 선택 했습니다.
Jenkins를 선택한 이유
수동으로 배포하기 위해 제공해야 하는것들이 무엇인지 먼저 정리 했습니다.
- 버튼으로 클릭해서 trigger 가능한 Web UI를 제공한다.
- 배포할때 phase, service, docker image 등을 선택할 수 있게 변경 가능해야 한다.
- Role base로 관리하기 위해 AWS 위에서 직접 관리할 수 있어야 한다.
- Reference가 많아야 한다.
- 저렴한 비용
여러 도구를 확인한 결과 AWS Codebuild와 Jenkins가 적합하다고 판단했습니다. 다만 Codebuild의 경우 배포 가능한 개발자들에게 모두 IAM 계정을 발급하고 권한을 부여해야 하고 UI가 불편하다는 의견이 많아서 Jenkins로 선택하게 됐습니다.
Jenkins의 분산 빌드환경
Jenkins에서 개발자들이 40개 이상의 서비스를 배포하고 리소스는 ecs 뿐만 아니라 serverless 자원들도 배포해야 합니다.
master에 부하가 심할것으로 예상되기 때문에 slave agent를 추가해서 작업을 분산해야 했습니다.
master에서는 jenkins 사이트만 관리하는 역할을 하고 build는 slave에게 위임하는 구조 입니다.
Jenkins의 slave로 Codebuild를 선택한 이유
- STS를 사용해서 더 안전한 방법으로 사용 가능합니다. CD에서 여러 aws account의 리소스에 접근하기 때문에 AccessKey를 발급했다면 보안적으로 위험했을 것입니다.
- 운영하기 더 편리합니다. EC2, ECS와 같이 서버로 구축하기 보다는 가급적이면 serverless worker 형태로 사용하는게 관리 포인트를 줄일수 있습니다.
- 개발자가 접근해서 사용하는 UI와 실제 CD 구현체를 분리할 수 있습니다. Web UI와 관련해서 의견이 분분하고 Jenkins 외 다른 도구를 선택하고 싶어하는 개발자들이 있습니다. UI적인 부분은 개발팀에 위임하고 실제 배포는 Codebuild를 trigger 하는 방법으로 운영하는것을 고려중입니다.
구현하는 방법은 AWS Blog 와 AWS Document에 자세히 나와있어서 본 글에서는 따로 정리하지 않았습니다.
추후에 IaC 코드를 추가적으로 공유할 수 있도록 하겠습니다.
감사합니다.