설정이 여러 자리에 있었고 한 번에 훑으니 어느 자리 것인지가 안 보였다. 결과가 수십 줄 나왔는데 같은 값이 여러 자리에 있는 것인지 다른 값인지도 갈리지 않았다.
Table of contents
Open Table of contents
자리별로 나눈 열거
디렉터리 목록을 돌면서 자리마다 헤더를 찍고 그 아래에 결과를 들여 쓰게 바꿨다. 세 자리에 있었고 값이 두 종류였다.
$ 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같은 결과를 자리로 묶기만 했는데 어느 것이 다른지가 드러났다. 합쳐서 보면 줄 수만 보이고 분포가 안 보인다.
실제로 쓰이는 값
값이 둘이면 어느 쪽이 실제로 쓰이는지를 확인해야 한다. 컨테이너 안에서 환경 변수를 찍어 보니 한쪽 값이었다.
다른 하나는 옛 설정이라 안 쓰이고 있었다. 지우기 전에 이름을 바꿔 두고 재시작해 정상 동작을 확인한 뒤 일주일을 두고 지웠다.
자리 목록의 작성
정리한 결과를 자리와 내용과 사용 여부로 표를 만들어 남겼다. 다음에 찾을 때 이 표를 먼저 본다.
같은 방식으로 로그와 백업과 인증서도 봤는데 셋 다 여러 자리에 있었다. 로그는 네 자리에 같은 내용이 저장되고 있어서 디스크를 네 배로 쓰고 있었고 파일로 안 쓰게 바꿔 두 벌을 없앴다.
자리별 크기와 관리 주체
자리별로 크기도 쟀다. 합쳐서 보면 디스크가 찼다는 것만 알고 어디인지 모르는데 나눠 보니 백업이 대부분이었다.
관리 주체도 자리마다 달랐다. 배포가 넣는 자리와 예전에 손으로 넣고 지금은 아무도 안 건드리는 자리와 배포 스크립트가 만드는 자리가 있었다. 주체가 없는 자리는 아무도 안 고치고 안 지우므로 계속 남는데 자리를 나눠 보니 그것이 드러났다. 각 자리에 담당을 적고 담당이 없는 것은 없애거나 담당을 정했다.
새 자리의 유입 차단
정리하고 나서 새 자리가 생기는 것도 막았다. 정기적으로 최근에 생긴 설정 파일을 찾아 목록에 없는 것이 나오면 물어봤다.
한 번 나왔는데 시험하다 만들고 안 지운 것이었다. 목록이 있어야 새로 생긴 것을 구분할 수 있으므로 앞의 표가 이 점검의 전제가 됐다.
정리
- 한 번에 훑으면 자리마다 다른 것을 놓친다
- 자리마다 따로 열거하면 어느 것이 다른지 보인다
- 실제로 쓰이는 것은 도는 것에서 확인한다
- 지우기 전에 이름을 바꿔 보고 일주일 둔다
- 자리 목록을 만들면 다음에 찾을 때 거기를 본다
- 같은 것이 여러 자리에 중복될 수 있다
- 자리별 크기를 봐야 어디가 큰지 안다
- 자리를 나누면 관리 주체가 없는 것이 드러난다