맡은 프로젝트가 넷이었는데 배포 방식이 전부 달라서 옮길 때마다 배포 방법을 다시 확인해야 했다. 그중 하나는 scp로 손으로 파일을 올리는 방식이라 무엇을 올렸는지 기록조차 없었다.
Table of contents
Open Table of contents
문제 — 넷의 차이
무엇이 다른지를 표로 만들어 여섯 항목을 나란히 놓았다. 방식과 되돌리기 가능 여부와 기록 유무와 배포 뒤 확인과 설정 분리와 소요 시간이다.
여섯 항목이 프로젝트마다 갈렸는데 그중 되돌리기와 기록이 없는 것이 가장 위험했다. 손으로 올리는 프로젝트는 그 둘이 다 없어서 사고가 나면 무엇을 되돌려야 하는지조차 알 수 없는 상태였다.
판단 기준 — 방식이 아니라 조건
두 가지 방법이 있었는데 가장 나은 방식 하나로 통일하는 것과 만족해야 할 조건만 통일하는 것이다. 뒤쪽을 골랐다. 이유는 프로젝트 사정이 달라서 방식까지 같게 만들기는 어려워서다. 대신 프로젝트마다 deploy.sh가 따로 남아 손볼 곳이 여럿인 것을 감수했다. 조건은 되돌릴 수 있고 무엇을 배포했는지 기록에 남으며 배포 뒤 확인이 자동으로 되고 설정이 코드와 분리돼 있는 넷이다.
방식을 통일하는 것이 아니라 조건을 통일한 것이다. 넷을 만족하면 방식은 달라도 상관없게 뒀다.
조치 — 위험한 것부터
조건을 하나도 못 채우던 프로젝트부터 손댔다. 손으로 올리던 것을 없애고 releases/<rev> 폴더와 ln -sfn 링크 교체 방식으로 바꾸면서 deploy.log 기록과 /health 확인까지 deploy.sh에 넣었다.
ssh "$HOST" "cd /app && tar xzf releases/release-$rev.tgz -C releases/$rev && ln -sfn releases/$rev current"
echo "$rev $(date -Is)" >> deploy.log
curl -sf "https://$HOST/health" | grep -q "$rev" || { echo "확인 실패"; exit 1; }네 조건을 다 채우면서 소요 시간도 십여 분에서 몇 분으로 줄었다. 나머지도 조건을 못 채운 개수 순으로 정리했고 전부 하는 데 몇 주가 걸렸는데 하나씩 했으므로 그 사이에 다른 일도 병행했다.
결과 — 공통 흐름과 덮어쓰기
조건을 채우고 나니 각 스크립트가 자연히 비슷해져서 공통 흐름으로 묶을 수 있었다. build·upload·switch·verify·record를 공통 함수로 두고 프로젝트별로는 deploy.conf만 달리했다.
방식이 정말 다른 프로젝트는 해당 함수만 deploy.conf에서 덮어쓰게 했다. docker build를 쓰는 쪽은 build 함수만 바꾸면 나머지 흐름은 그대로 탄다.
표준을 지키는지 점검하는 check-deploy.sh도 만들어 월 1회 돌렸다. deploy.conf와 /health와 deploy.log의 유무를 프로젝트별로 찍어 주므로 새 프로젝트가 들어오면 여기서 걸린다. 두 달 뒤 새 프로젝트를 맡았을 때는 deploy-template/을 복사해 시작해서 처음부터 조건을 만족했다.
주의 — 못 지키는 경우의 기록
한 프로젝트는 조건 둘을 끝내 못 채웠다. 고객사 서버라 우리가 배포 구조를 바꿀 수 없었고 /health 경로도 만들 수 없었다.
억지로 맞추려다 그만두고 못 채운 것을 적은 뒤 그에 맞는 대비를 따로 했다. 되돌리기 대신 배포 전 백업을 우리 쪽에서 받아 두고 자동 확인 대신 배포 뒤 화면을 눈으로 확인한다.
전부 같게 만드는 것이 목적이 아니라 위험을 아는 것이 목적이었으므로 못 지키는 것을 숨기지 않고 적었다. 적어 두니 그 프로젝트를 다룰 때 더 조심하게 됐다.
정리
- 방식이 제각각이면 옮길 때마다 새로 배운다
- 무엇이 다른지 표로 만든다
- 방식을 통일하는 것이 아니라 조건을 통일한다
- 위험한 것부터 하나씩 조건을 채운다
- 조건을 채우면 자연히 비슷해지고 그때 공통 흐름으로 묶는다
- 정말 다른 것은 덮어쓰게 둔다
- 표준을 지키는지 확인하는
check-deploy.sh를 만든다 - 못 지키는 것은 숨기지 않고 적고 그에 맞는 대비를 한다