무중단 배포 스크립크 작성 (issue #456) #480
Conversation
|
기존 PR 닫고 커밋들만 체리 픽 해서 새로 PR 만들었어요 @alstn113 |
| public ResponseEntity<ApiResponse<String>> health() { | ||
| return ResponseEntity.status(200).body(new ApiResponse<>("up")); | ||
| } |
There was a problem hiding this comment.
[Approve]
ResponseEntity.ok 레츠고?
| findPreviousImageVersion: | ||
| name: 🔎Find Previous Docker Image Version | ||
| runs-on: [ self-hosted, devel-up-prod-a ] | ||
| outputs: | ||
| previousImageVersion: ${{steps.find_version.outputs.name}} | ||
| steps: | ||
| - id: find_version | ||
| run: | | ||
| PREVIOUS_IMAGE_NAME=$(docker ps --format "{{.Image}}") | ||
| echo "name=$PREVIOUS_IMAGE_NAME" >> $GITHUB_OUTPUT | ||
| echo $PREVIOUS_IMAGE_NAME |
There was a problem hiding this comment.
[Commnet]
build job이 해당 작업 안기다려줘도 되는건지 궁금하네요. 👀
만약, build job -> deployToA job까지 수행 했어요.
그리고 healthCheckA 수행 이전에 컨테이너가 잠깐 실행되었고 실패했다고 했을때, docks ps를 찍으면 실패한 최신 도커 이미지 버전이 롤백 대상 버전이 될 가능성은 없나요??
There was a problem hiding this comment.
그런 시나리오가 원천적으로 불가능한 건 아니라고 생각해요. 그런데, 현실적으로 빌드 작업과 롤백 버전 찾는 작업이 동시에 트리거되면 그 작업의 부하 차이가 워낙 커서 롤백 버전 찾는 작업이 먼저 수행되게 되요. 위에 사진 보시면 속도 차이가 엄청 나요
There was a problem hiding this comment.
굳굳 좋아요. 그럴 가능성이 적긴하네요. 👍
cd 과정에 평균 find previus docker image version 잡 수행 시간이 추가되는 것보다는 자동 롤백 실패 비용이 더 작겠네요.
graceful shutdown 논의는 슬랙으로 이어나가시고, 헬스 체크 api 선택적으로 반영해주시고 다시 요청 주시면 approve 처리할게요.
이 PR이 머지된 이후 main에 머지되기 전에 작업해야되는 내용
product 환경 DB 연동
현재 새로 요구받은 프로덕션 DB환경으로의 연동이 Java 코드에 반영되어있지 않아 임시로 product 환경에서도 local 프로파일로 동작하게 되어있습니다.
다만 이는 아직 main에 배포되지 않았기 때문에 원래 프로덕션 서버는 기존 DB와 연동되고있습니다.
신규 배포 환경은 우선 api2.devel-up.co.kr로 연동해놨어요.
product 환경 로깅 및 모니터링 시스템 연동
구현 요약
Rolling 방식의 무중단 배포를 구현했습니다.
배포 과정은 크게 다음과 같습니다.
알림은 4가지 시나리오에서 발생합니다.
두번째 시나리오는 극단적인 상황이라 재현이 힘들어서 따로 테스트하지 못했습니다.
연관 이슈
참고
코드 리뷰에
RCA 룰을 적용할 시 참고해주세요.