배포하고 나서 한 서버만 옛 코드로 돌고 있는 것을 발견했다. 배포는 성공으로 끝났는데 그 서버가 대상에 안 들어 있었던 것이다.
Table of contents
Open Table of contents
증상 — 옛 코드로 돌던 한 대
왜 빠졌는지를 보니 deploy.sh 안에 HOSTS="web01 web02 web03" 로 대상 서버 목록이 하드코딩돼 있었다. 서버를 한 대 늘렸을 때 그 목록에 추가하는 것을 빠뜨린 것이었다.
목록이 스크립트 안에만 있으면 서버를 늘릴 때 그 파일을 고쳐야 한다는 것을 아는 사람만 안 빠뜨린다. 그 지식이 사람 머릿속에만 있는 것이 문제였다.
원인 — 스크립트에만 있던 대상
실제 대상이 무엇인지를 확정하려고 두 곳에서 목록을 뽑았다. 각 서버의 ps -ef | grep php-fpm 에서 뽑은 것과 앞단 nginx.conf 의 upstream 블록에서 뽑은 것이었다.
두 목록을 맞춰 보니 어느 쪽에도 없는 서버가 하나 있었는데 예전에 쓰다가 지금은 아무것도 안 받는 상태였다. 목록을 만들면서 안 쓰는 서버가 함께 드러난 셈이다.
조치 — 표를 스크립트가 읽게 한다
프로젝트별로 어느 서버에 나가는지를 deploy-targets.tsv 표로 만들고 deploy.sh 가 그 표를 읽게 바꿨다. 스크립트 안의 목록을 고쳐 두는 것 대신 표로 빼는 쪽을 골랐다. 이유는 서버를 늘릴 때 표만 고치면 되고 스크립트는 안 건드려도 돼서다.
한 대만 두는 프로젝트에는 왜 한 대인지를 표에 적어 뒀다. 이유가 없으면 다음 사람이 빠뜨린 것으로 보고 임의로 추가한다.
검증 — 앞단 설정과의 대조
표를 만들고 나서 upstream 이 트래픽을 보내는 대상과 배포 대상이 같은지 diff 로 확인했다. 이 둘이 다르면 배포가 안 된 서버로 트래픽이 가거나 반대가 된다.
실제로 한 프로젝트에서 두 목록이 어긋나 있었는데 앞단에는 있고 배포에는 없는 서버가 있었다. 이번에 발견된 것과 같은 성격의 문제가 다른 프로젝트에도 있었던 것이다.
재발 방지 — 배포 뒤 확인과 서버 증설 절차
배포가 끝난 뒤에 모든 대상의 REVISION 파일이 같은 판인지를 md5sum 으로 확인하는 단계를 넣었고 하나라도 다르면 exit 1 로 실패로 끝내게 했다. 배포 명령이 성공했다는 것과 전부 같은 판이 됐다는 것은 다른 말이다.
마지막으로 서버를 늘릴 때 무엇을 해야 하는지를 절차로 적었다. deploy-targets.tsv 에 추가하고 upstream 에 넣고 배포해서 확인하는 세 단계를 적어 두니 빠뜨리는 것이 없어졌다.
정리
- 배포 대상이 스크립트에만 있으면 서버를 늘릴 때 빠진다
- 도는 것과 앞단 설정에서 실제 대상을 찾는다
- 프로젝트별 대상을 표로 만들고 스크립트가 그 표를 읽게 한다
- 한 대만 두는 것에는 이유를 적는다
- 앞단과 배포 대상이 같은지 확인한다
- 배포 뒤 전부 같은 판인지 확인한다
- 하나라도 다르면 실패로 끝낸다
- 표를 만들면 목록에 없는 서버가 드러난다