📕 목차
1. 문제 원인 분석
2. Docker overlay
3. jounal log
4. 결과
1. 문제 원인 분석
평소처럼 was에 배포하는데 image를 받아오다가 디스크 공간이 부족해서 실패했다.
가장 단순한 방법은 EC2를 up-scaling하면 되겠지만, 방학 중엔 학교에서 지원금을 받지 못 하는 관계로 디스크 공간을 최대한 활용할 필요가 있다.
df -h
사용 중인 메모리를 보니..난리가 났다.
만약 여기서 사용 중인 메모리는 별로 없는데 no space 에러가 뜨면, df 명령어에 i 옵션을 주고 inode 개수 한계에 도달했는지 확인해보면 된다.
여튼 나는 어디선가 메모리를 실컷 잡아먹고 있는 게 확실해졌으므로, 루트 디렉토리부터 탐색하기로 했다.
sudo du -h / --max-depth=1 | sort -rh
여기까지만 해도 log 파일이 넘치는 거겠군 싶어서 여유 만만하게 /var 디렉토리의 디스크 사용량을 확인했는데
log는 얼마 되지도 않는데, lib 쪽이 터졌다고 한다.
뭔가 느낌이 쎄했는데..저쪽에서 용량이 저정도로 나올만한 건 docker밖에..
별로 마주하고 싶지 않은 상황이 왔다.
2. Docker overlay
docker 디렉토리에서 용량이 나올만한 부분은 보통 image와 overlay 쪽일 텐데, 서버는 현재 주기적으로 prune을 실행해서 사용하지 않는 컨테이너와 이미지를 제거해주고 있다.
그럼에도 디스크를 저 정도로 먹으면 이미 해결할 방도가 없다.
그래도 정확한 상황을 파악은 해야하므로 마저 확인을 해주기로 했다.
역시나 overlay2가 4.9G나 먹고 있다.
저 overlay는 어디서 사용하고 있길래 1.2G나 먹고 있는 걸까?
문득 궁금해져서 찾아보기로 했다.
docker inspect ${container_name} | grep ${overlay}그런데 웬걸, was, rdb, cache 컨테이너 전부 돌렸는데 해당 overlay를 사용하지 않고 있다고 한다.
이건 또 무슨 소리여.
다시 확인해보니 webview 팀의 컨테이너가 WAS 컨테이너에 띄워져 있었다. 😊....이게 왜 대체 여깄지...?
아무래도 웹뷰 팀에서 배포하고 싶다고 할 때, 인프라 맡은 팀원하고 이야기하면 된다고 하고 보냈는데
웹뷰도 WAS 서버에 띄워버린 것 같다.
근데 이건 그냥 public subnet에 있는 EC2 띄워도 되는 거잖아...
추가로 docker를 설치하면 root 디렉토리의 /var/lib/docker를 기본 경로로 삼는데, 이를 바꿔줄 필요가 있다고 한다.
Docker 데이터 저장 위치 변경하기.
Docker를 설치하면 root 드라이브를 사용하도록 설정됩니다. 이 경우 나중에 스토리지가 부족하게 야기하게 될 수 있기 때문에 데이터를 저장하는 위치를 변경해 두는 것이 좋습니다. 특히, 운영
bitlog.tistory.com
이건 몰랐는데 이번에 알게 돼서 다음엔 덜 고생해도 될 것 같다 ㅎㅎ
3. journal log
지금 당장은 713M 정도밖에 차지하지 않는 journal log도 거슬리니 이참에 정리해주자.
syslog와 journal log 차이는 해당 블로그에서 잘 설명해주고 있다.
용량 제한을 걸까, 로그 날짜 제한을 걸까 하다가 운영 서버도 아니고 기껏해야 개발 서버..깔끔하게 일주일 지난 로그는 모두 날리기로 결정했다.
sudo journalctl --vacuum-time=7d
journalctl --disk-usage
무려 64M까지 줄여버렸다.
4. 결과
겨우겨우 성공.
그래도 여전히 root 디렉토리가 사용하는 디스크 용량이 너무 큰데, 더 줄일 수 있는 방법이 있는 지 미리미리 찾아둬야 할 것 같다.