수정한 CSS 와 이미지를 올렸는데 새로고침해도 그대로였다. 캐시를 지우고 브라우저를 바꿔도 마찬가지였다.
이 서비스는 Apache 가 정적 파일을 내고 JSP 는 mod_jk 로 Tomcat 에 넘긴다. 내가 올린 것은 Apache 쪽이었다.
Table of contents
Open Table of contents
명령은 성공했다
배포는 scp 한 줄이었고 오류가 없었다. 파일 개수도 맞았다.
서버에 들어가 ls -l 로 보니 수정 시각이 방금이었다. 파일은 올라간 것이다. 그런데 화면은 옛날 것이었다.
서비스가 다른 곳을 봤다
httpd.conf 를 열어 보는 대신 apachectl -S 를 쳤다. 돌고 있는 설정이 그대로 나온다. DocumentRoot 가 내가 올린 경로와 달랐다.
VirtualHost configuration:
10.0.0.31:80 adsvc.example.com (/etc/httpd/conf.d/adsvc.conf:1)
...
Main DocumentRoot: "/var/www/adsvc"
ls -l 로 보니 전에는 두 경로가 심링크로 이어져 있었다. 서버를 정리하면서 그 링크가 끊겼고 배포 스크립트는 그대로였다.
명령의 성공은 명령이 실행됐다는 뜻이다. 의도한 상태가 됐다는 뜻이 아니다. scp 는 없는 대상에도 성공한다. 없으면 만들어 놓고 끝낸다.
서비스 주소로 되읽었다
올렸다는 사실 말고 반영됐다는 사실을 확인할 방법을 넣었다. 빌드할 때 시각을 담은 version.txt 를 같이 만든다. 배포 뒤에 curl 로 그 파일을 불러 본다.
$ curl -s http://10.0.0.31/version.txt
2012-01-20 21:44:03
시각이 방금이면 반영된 것이고 옛날이거나 404 면 아니다. cat 이 아니라 curl 로 확인하는 것이 요점이었다. 올린 경로에서 cat 하면 방금 내가 쓴 것을 다시 읽는 것뿐이다.
빠진 단계와 대조군
왜 굳이 중간 경로에 올리는지 물어보니 이유가 있었다. 배포 계정에 /var/www 쓰기 권한이 없다. 중간 경로에 올린 뒤 sudo 로 옮기는 구조였다.
그 sudo mv 가 스크립트에서 빠져 있었다. 심링크가 있을 때는 필요가 없었으니 지워졌던 것이다. 배포 절차가 여러 단계면 한 단계가 빠져도 앞 단계는 성공한다.
확인 방법을 만들고 나서 그것이 정말 거르는지도 시험했다. 일부러 틀린 경로로 scp 하니 curl 이 옛날 시각을 냈다. 이 시험을 안 하면 확인 절차가 언제나 통과만 하는 것인지 알 수 없다.
정리
- 파일 복사가 성공해도 대상이 서비스 경로가 아니면 아무 일도 안 일어난다
- 명령의 성공은 의도한 상태가 됐다는 뜻이 아니다
- 서비스가 읽는 경로는 문서가 아니라
apachectl -S가 내는 것에서 확인한다 - 심링크가 끊겨도
scp는 성공한다. 없으면 그 이름의 디렉터리를 만든다 - 반영 확인은
cat이 아니라curl로 한다 - 빌드 시각을 담은
version.txt를 같이 올리면 반영 여부가 한 줄로 갈린다 - 배포 절차가 여러 단계면 한 단계가 빠져도 앞 단계는 성공한다
- 확인 방법을 만들었으면 일부러 틀린 상태로 돌려 거르는지 본다