배포 자동화의 필요성
팀 프로젝트를 하면서 api가 수정될 때 마다 배포를 하다보니 배포를 수도 없이 많이 하게 됐다.
그리고 프로젝트가 커짐에 따라 이미지 파일을 빌드를 하는데 7~10분 가량이 걸리면서 시간적으로 손해가 상당히 많이 발생됐다.
3주동안 174번을 배포했다.
도입하는 것은 문제가 없었지만 일부로 사용하질 않았는데
오류 사항이 확인되지 않은 상태에서 올라가면 서버가 먹통이 된다는 이유였다.
그런데 한번 더 코드를 검증하고 올리면 된다는 사실을 망각하고 있었다.
Branch의 분리
현재 프로젝트 깃허브의 Branch들인데 3개로 나눔에 따라 걱정없이 자동화를 넣을 수 있게 됐다.
Branch의 역할
- Dev
1-1. 팀원들은 모두 Dev에서 작업을 하고, 작업된 모든 사항들이 머지가 될 경우
그리고 Dev단에서 문제가 없는지 코드를 확인을 한 후 Release로 PR을 보내게 된다. - Release
2-1. Release 브랜치에는 CI / CD 가 걸려 있어서 배포 자동화가 이루어지게 된다. - Master
3-1. 모두 정상적으로 작동을 할 경우에 최종적으로는 Master 브랜치로 PR을 보내게 되며 실 서비스 배포 자동화가 이루어진다.
GCP의 Cloud-Build를 사용해보자.
현재 활용하고 있는 클라우드가 GCP라서 GCP 기준으로 설명이 진행된다.
1. Cloud Build 사용 설정하기
왼쪽 사이드의 스크롤을 내리다보면 CI/CD 항목이 있다.
Cloud Build를 누른 후 API 사용을 체크하자.
2. Trigger 만들기
참 많이 쓰이는 용어 Trigger가 또 다시 나왔다.
이번에 트리거의 순서는 레포지토리의 커밋이 되었을 경우를 기준으로 트리거가 발생하게 된다.
기록 탭을 선택하여 트리거 만들기 버튼을 누른다.
이름이 중복되지 않고, 한눈에 무엇인지 알아볼 수 있도록 입력하고
리전은전역설정, 이벤트는브랜치로 푸시로 설정을 한다.
그 다음은 깃허브와의 연동 작업이 필요하다. 소스에 새 저장소 연결을 누르자.
소스 선택에서는 제일 위를 체크하고 계속 버튼을 누른다.
계정이 연동되었다면 계정을 선택한 후 저장소를 한번에 모든 것을 다 쓰거나
한개만 고른 후 연결 버튼을 누른다.
CI/CD를 적용 시키고 싶은 브랜치를 입력한 후
구성에는 Cloud Build 구성 파일(YAML 또는 JSON)
위치는 저장소를 선택한 후 하단의 만들기를 누른다.
마지막으로 Cloud Build
설정탭을 들어가서 Kubernetes Engine을 사용 설정을 누르면 GCP 상에서의 설정은 끝이 난다.
cloudbulid.yaml 생성하기
gcp와 깃허브 연동이 되었으면 트리거가 발생되었을 경우에 실행하는 옵션이 적혀있는 설정파일이 필요하다.
위 사진의 Cloud Build 구성 파일 위치 * 라고 적혀있는 곳에
/ cloudbuild.yaml 이라는 문자가 적혀있는데, 저 yaml 파일을 읽는 것이다.
내용을 잘 보면 스탭이 나눠져있는 것을 확인할 수 있다.
- docker-compose build
1-1 docker compose -f docker-compose.prod.yaml build - docker-compose push
2-1. docker compose -f docker-compose.prod.yaml push - set image deployment
3-1 kubectl set image deployment/snsteam-backend-api-resource team-sha256-1=asia.gcr.io/evocative-tube-352516/team:2.5.0
이 순서대로 적어나가면 된다.
하지만 여기서 중요한 점은 args가 나눠지는 기준이 공백이라는 것인데
공백 기준으로 나눠서 입력을 하면 된다.
마지막으로 kubectl의 env 옵션은 쿠버네티스 엔진의 클러스터 이름과 리전을 넣는다.
이렇게 적용을 한 후, 커밋을 올리면 배포 자동화가 이루어진다.
진행 확인을 하는 방법
어떻게 진행되는지 확인을 하고 싶다면, GCP의 Cloud Build를 들어가서 대시보드를 들어가면 확인을 할 수 있다.
실시간으로 어떻게 작업이 되고 있는지 모두 확인을 할 수 있으며
어떤 트리거의 이름으로 실행이 되고 있는 것인지
어떤 깃허브와 연동이 되어있는지, 브랜치는 어떤 것인지 커밋 이름은 어떤 것인지
빌드당 소모 시간, 빌드를 시작한 시간 그리고 성공 및 실패 여부를 모두 확인할 수 있다.
고민을 조금만 더 했다면 몸과 마음이 편해졌을텐데 이제야 걸어서 너무 아쉽다(...)
지금까지 한 10분 가량에 배포시간이 소모되었다면 자동화를 건 후
5분 내외로 배포가 이루어지는 것을 확인해서 행복해졌다!
끝!
