API_KEY 설정이 여러 자리에 있었고 grep -rn 으로 한 번에 훑으니 어느 자리 것인지가 안 보였다. 결과가 수십 줄 나왔는데 같은 값이 여러 자리에 있는 것인지 다른 값인지도 갈리지 않았다.
Table of contents
Open Table of contents
해결 — 자리별로 나눈 열거
두 가지 방법이 있었는데 grep 출력을 sort | uniq -c 로 값별로 세는 것과 디렉터리 목록을 돌면서 자리마다 헤더를 찍고 그 아래에 결과를 들여 쓰는 것이다. 뒤쪽을 골랐다. 이유는 앞쪽은 값이 몇 종류인지는 알려 주지만 어느 자리에 있는지는 지워서다. 대신 명령이 한 줄에서 for 루프로 길어지는 것을 감수했다. 세 자리에 있었고 값이 두 종류였다.
$ for d in /etc /app/config /home/deploy /var/lib/docker/volumes; do
echo "=== $d"; grep -rn "API_KEY" "$d" 2>/dev/null | sed 's|^| |'
done같은 결과를 자리로 묶기만 했는데 어느 것이 다른지가 드러났다. 합쳐서 보면 줄 수만 보이고 분포가 안 보인다.
검증 — 실제로 쓰이는 값
값이 둘이면 어느 쪽이 실제로 쓰이는지를 확인해야 한다. docker exec <컨테이너> env | grep API_KEY 로 찍어 보니 한쪽 값이었다.
다른 하나는 옛 /etc/app.env 라 안 쓰이고 있었다. 지우기 전에 mv 로 이름을 바꿔 두고 재시작해 정상 동작을 확인한 뒤 일주일을 두고 지웠다.
자리 목록의 작성
정리한 결과를 자리와 내용과 사용 여부로 LOCATIONS.md 에 표를 만들어 남겼다. 다음에 찾을 때 이 표를 먼저 본다.
같은 방식으로 로그와 백업과 인증서도 봤는데 셋 다 여러 자리에 있었다. 로그는 네 자리에 같은 내용이 저장되고 있어서 디스크를 네 배로 쓰고 있었고 파일로 안 쓰게 바꿔 두 벌을 없앴다.
원인 — 자리별 크기와 관리 주체
자리별로 du -sh 로 크기도 쟀다. df -h 로 합쳐서 보면 디스크가 찼다는 것만 알고 어디인지 모르는데 나눠 보니 백업이 대부분이었다.
관리 주체도 자리마다 달랐다. 배포가 넣는 자리와 예전에 손으로 넣고 지금은 아무도 안 건드리는 자리와 배포 스크립트가 만드는 자리가 있었다. 주체가 없는 자리는 아무도 안 고치고 안 지우므로 계속 남는데 자리를 나눠 보니 그것이 드러났다. 각 자리에 담당을 적고 담당이 없는 것은 없애거나 담당을 정했다.
조치 — 새 자리의 유입 차단
정리하고 나서 새 자리가 생기는 것도 막았다. 정기적으로 find -mtime -7 -name '*.env' 로 최근에 생긴 설정 파일을 찾아 목록에 없는 것이 나오면 물어봤다.
한 번 나왔는데 시험하다 만들고 안 지운 것이었다. 목록이 있어야 새로 생긴 것을 구분할 수 있으므로 앞의 표가 이 점검의 전제가 됐다.
정리
- 한 번에 훑으면 자리마다 다른 것을 놓친다
- 자리마다 따로 열거하면 어느 것이 다른지 보인다
- 실제로 쓰이는 것은
docker exec … env처럼 도는 것에서 확인한다 - 지우기 전에 이름을 바꿔 보고 일주일 둔다
- 자리 목록을 만들면 다음에 찾을 때 거기를 본다
- 같은 것이 여러 자리에 중복될 수 있다
- 자리별 크기를 봐야 어디가 큰지 안다
- 자리를 나누면 관리 주체가 없는 것이 드러난다