Skip to content
isdnetworks
Go back

배포는 됐는데 아무것도 안 바뀌었다

수정한 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 이 옛날 시각을 냈다. 이 시험을 안 하면 확인 절차가 언제나 통과만 하는 것인지 알 수 없다.

정리


Share this post on:

Previous Post
단계마다 자료 형태가 바뀌고 있었다
Next Post
자바에서 받은 문자열을 안 놓아 줬다