현재 루빗의 서버 상태는 아래와 같습니다.
현재 WAS의 자동 배포를 Jenkins로 하고 있는데, 계속 Jenkins를 사용하다 보니 문제가 하나 둘 보이기 시작했습니다.
- 요금이 계속 나온다.
사실 젠킨스 인스턴스 하나 켜 둔다고 요금이 얼마나 나온다고 의문을 가질 수도 있지만, 회사 규모가 작을수록 비용에 민감해질 수 밖에 없습니다. 게다가 도커 이미지를 빌드해야 하는 인스턴스이기 때문에 사양이 낮으면 빌드 도중 메모리 부족으로 Jenkins가 다운됩니다.
2. 지속적인 관리가 필요하다.
말 그대로 하나의 인스턴스이기 때문에 주기적으로 AMI 백업하고, 젠킨스가 죽었나 수시로 점검하고, 도커 캐시가 쌓여서 빌드가 안 되지는 않는가 등등 계속 관리를 해줘야 합니다. 사실 위의 작업들은 자동화로 해결할 수 있는 부분이긴 합니다. 하지만 관리가 필요하다는 것은 리소스가 드는 작업이므로, 최대한 줄였으면 좋겠다는 생각이 들었습니다.
위와 같은 내용으로 보아, 배포환경을 이전해야 할 필요성이 생겨서 다른 배포 도구로 넘어가기로 했습니다.
배포 도구 선정하기
배포 도구로 사용할 것 중 가장 중요한 것은 관리의 필요성이 적은 도구였습니다. 왜냐하면 인력의 충원이 힘든 상태에서는 관리를 대신 할 개발 도구가 제일 효율적이기 때문입니다. 두 번째로는 Github와의 연동입니다. 그냥 루빗의 코드가 Github에 있기 때문이여서, Github를 잘 지원하는 도구였으면 좋겠다고 생각했습니다.
해당 조건들을 생각하고 도구들을 찾아본 결과, Github Action이 가장 적합해 보였습니다. 배포 횟수도 많은 편이 아니고, 관리할 필요도 거의 없으며, Github 안에 있는 도구이기 때문에 연동은 두말하면 아픕니다.
배포 설정하기
배포도 그렇게 어렵지 않았습니다. 다음 일련의 작업들만 수행하면 되었습니다.
- 코드 체크아웃 확인하기
- 환경변수 적용하기
- 도커 이미지 빌드하기
- aws-cli 환경 적용하기
- 도커 이미지 ecr에 업로드하기
- eb환경 업데이트하기
- 배포 결과 슬랙으로 전송하기
1번, 2번, 3번은 Github Action의 대표 예제로도 나와있고, 공식 문서에도 친절하게 설명이 되어 있어서 제작에 큰 문제가 없습니다.
하지만 4번, 5번, 6번, 7번의 경우에는 공식 예제를 찾을 수 없어서 라이브러리를 사용했습니다. Github Action은 다른 사람이 만들어 둔 일련의 액션(작업)들을 확장 프로그램처럼 끌어다가 쓸 수 있습니다..
4번, 5번, 6번같은 경우에는 aws-actions/configure-aws-credentials@v1 이라는 확장 액션(라이브러리)를 끌어다 사용했습니다. access-key-id, secret-access-key, region의 3개의 설정값만 입력하면 자신의 aws 계정을 cli와 연동해서 사용할 수 있게 되어 있습니다. 또한 나머지 명령어 같은 경우에는 aws의 공식 문서를 보고 작성했습니다.
7번의 슬랙 메시지 확장 액션은 다양한 종류가 있습니다. 그 중에서 편하게 사용 가능한 8398a7/action-slack@v3 을 사용했습니다. 성공과 실패 시 다르게 보이는 컬러, 배포한 PR 또는 커밋에 대한 모든 정보 제공, 사용성의 간편함 등의 장점들이 있어서 사용하게 되었습니다. 이제 배포에 실패하면 오류 메시지가, 배포에 성공하면 성공 메시지가 배포할 때 마다 슬랙으로 옵니다.
결과
성공했을 때 수신 메시지
실패했을 때 수신 메시지
취소했을 때 수신 메시지
슬랙 메시지와 더불어 도커 환경까지 관리할 필요가 없는 Github Action 환경을 사용해 보았습니다. 지금까지 보이는 단점은 딱히 없는 것 같습니다. 신경써야 할 것은 배포를 오래 할수록, 무료로 제공하는 Limit에 걸릴 확률이 높아져서 프로덕트 환경이라면 마음 편하게 결제를 하는 것을 권장합니다.
위 글은 아래 포스트를 참고했습니다.
