CI Tool 도입하기
팀 프로젝트를 처음 설계 했을 때 'CI툴을 사용해보는 게 좋아보여요!'라는 말로 젠킨스와 Travis CI를 고민했다.
본인은 젠킨스를 쓰자는 쪽에 속했다. 하지만 Travis CI, 젠킨스를 둘다 사용해보지 않았으므로 확실한 근거가 없었다. 또 팀원들의 생각은 컴퓨팅자원을 사용하지않고 서비스를 제공해주는 Travis CI의 손을 들어줬다.
Github PR기반 코드리뷰를 하고 있어서, Travis CI는 빌드체크가 매우 간편했다.
Travis CI를 사용하여, 좌충우돌 배포 파이프라인 구축기를 적어보려고 한다.
CI/CD 미션
팀프로젝트에서도 미션이 기다리고 있었다. 그 중 'CI/CD구축하기'미션이 있었다. 우리팀은 '미리 구축해놨으니 어렵지 않겠다.'라는 생각으로 별 생각이 없었다.
하지만 'Github Action 혹은 AWS Codedeploy 툴 사용금지'라는 제약이 따라왔다.
트래비스 CI를 통해 배포자동화를 구축하려고 하는데, Codedeploy를 사용하지 못한다니... 충격이었다.
어떻게하면 PR에서 merge되는 시점에서 배포를 시작할 수 있을까? 고민하게 되었다.
검색을 통해 Github에서 특정 Action이 있을 때 Hook을 날려주는 Github webhook이라는걸 알게 되었고,
PR이 merge되는 시점을 잡아서, 배포서버에 메시지를 전송해주는게 좋다고 생각했다.
우리는 배포서버에서 웹훅(HTTP요청)을 받을 수 있는 별도의 서버를 만들어서, 배포를 진행하게 만들었다.
구성은 아래 사진과 같다.
이때 'Webhook을 받는 서버가 Product에 있는게 괜찮을까?' 라는 생각이 들었다. 'Github에서 Webhook을 ssh로 지원하면 좋겠다'라고 생각했지만 안되는거니 직접 구축 필요했다.
Master가 Push되면 바로 배포가되서 너무 기뻤다. 다른 툴을 사용하지않고, 직접 파이프라인을 구축한 것에 기쁨을 느꼈다.
너네 안좋아보이는데?
너네는 Travis에서 Build를 통해 CI를 하는데, 배포서버에서도 Github를 Pull하고 Build하네? 이거 비효율적인 것 같아. 또 배포서버에서 Build를 해서 그런지 SecretKey를 배포서버에서 가지고 있는데, 그게 괜찮을까?
옆에 있던 크루의 피드백이 있었다. 충격에 빠졌다..!
모두 맞는말이었다. 기존에 배포가 된다고해서 기뻐하고 있었는데, 새로운 문제점을 발견했다.
예전 기술에 되게 좋다고 생각했던 내 자신에게 기술적 부채를 느꼈다ㅠㅠ
아래는 Travis가 포함된 사진
팀원들과 상의를 하다보니, 소니는 'Codedeploy를 사용하면 Travis가 빌드하는 시점에 jar파일을 S3에 올리는데...'라는 말을 들었다.
우리는 Codedeploy를 사용할 수 없는 상황이었고, '트래비스에서 jar파일을 Webhook서버로 옮기면 되지 않을까?' 라는 생각이 들었다. 이때 트래비스에서 SSH 프로토콜을 통해서 jar파일을 전송하려고 했다.
쉽지 않았다.
일단 가장 큰 문제점은 트래비스에서 SSH 요청을 보내기 위한 웹훅서버의 보안설정이 안되어있었다.ㅠㅠ
도커를 사용하면 어떨까?
우리는 컴퓨팅자원 1대에서 데이터베이스 서버, WAS, Web server를 돌려야하는 환경이었다. 그래서 그 전부터 Docker를 통해서 컨테이너화해서 관리하면 좋을 것 같다는 생각을 했었다.
주변 크루들에게 조언을 구한 결과, 'Dockerhub를 이용해보는건 어떻겠냐?'라는 조언을 들었다.
'트래비스에서 빌드와 프로젝트를 이미지화해서 도커허브에 올리면 되지 않을까?'라는 생각이 들었다.
예상 파이프라인
이렇게하니 빌드도 트래비스가 해주고, Secret key로 트래비스에서 가져고 있을 수 있었다.
엥? PR도 배포를 해버리네?
트래비스를 빌드하는시점을 PR과 PUSH시점을 걸어놨는데, PR에 설정해야 코드리뷰때 신뢰성있는 코드인지 확인할 수 있다.
또 PUSH의 경우 develop, master에 걸어놔서 실질적으로 내놓을 수 있는 코드가 신뢰성있는코드를 확인할 수 있어야했다.
하지만 우리는 develop, master에 push(merge)가 된 시점에 배포를 하고 싶었는데, travis는 모든 동작해서 배포를 해버리려고 했었다ㅠㅠ
# .travis.yml
after_success:
- if [ $TRAVIS_PULL_REQUEST == "false" ]; then
# deploy script
fi트래비스는 PR일 경우 배포스크립트를 실행하지 않도록, 쉘스크립트를 작성했다.
$TRAVIS_PULL_REQUEST 는 트래비스환경에 있는 환경변수인데, PR번호 혹은 false를 갖고 있는 특이한 친구다. 이 환경변수를 통해서 분기를 해야했다. 아래 사진 참고
또 delpoy script를 사용할 때 라인마다 세미콜론을 찍어주자.
yml파일이 스크립트를 제대로 인식하지 못한단다. - Stackoverflow
느낀점
시작된 프로젝트에서 적용된 기술을 바꾼다는 비용이 많이 들어서 바꾸기가 힘들다. 어떤 기술을 사용할 때 장단점을 확실하게 생각하고 선택해야겠다.
처음에 트래비스 CI를 사용할 때는 간편해서 사용했지만, 결국 Webhook을 쏴주는 컴퓨팅자원을 추가로 이용했다는 건, '차라리 젠킨스를 써도 됐겠네?'라는 생각이 든다.
트래비스는 단점은 서비스에서 운영해주는 친구(SaaS와 가깝게 느꼈다.)라서 자유도가 낮다. 젠킨스는 도입이 어렵지만 큰 장점이 있는 것 같다. 지원하는 기능과 자유도 등 젠킨스가 장기적으로는 좋다고 생각했다.
트래비스를 사용하면서 삽질을 참 많이했는데, 그와중에 많이 배웠다. 코치님들이 Codedeploy, Github Action같은 애플리케이션 서비스를 사용을 지양하는 뜻을 알것 같다.
배포 파이프라인을 구축하면서 사용되고있는 편리한 배포툴의 파이프라인을 쉽게이해할 수 있게 되었다.
끝
다음에는 HTTPS 및 Nginx 적용기를 올려보려고한다.
