데이터가 다른 곳에 있는데 컨테이너가 시스템 디스크를 가득 채우는 이유は 무엇인가요?

로그, 캐시, 임시 파일 또는 실수로 인한 쓰기가 Docker의 로컬 스토리지에 남아 있으면 컨테이너가 시스템 디스크를 가득 채울 수 있습니다.

미디어 라이브러리나 데이터베이스 볼륨을 다른 풀로 이동해도 컨테이너 이미지, 쓰기 가능 계층, JSON 로그, BuildKit 캐시, 메타데이터 또는 마운트 목록에서 누락된 경로까지 이동되지는 않습니다. 외부 마운트에 실패하면 예상한 호스트 디렉터리가 비어 있을 수 있으며, 이로 인해 애플리케이션이 명확한 오류 없이 시스템 디스크에 새 데이터를 기록할 수도 있습니다.

애플리케이션 데이터를 조사하기 전에 Docker 루트 측정하기

Docker 데이터 루트가 포함된 파일 시스템을 확인하고, 호스트 디렉터리 크기를 Docker의 이미지, 컨테이너, 볼륨 및 빌드 캐시 사용량과 비교하세요. 삭제하기 전에 사용량을 기록해 두세요.

한 Cloudron 사용자는 /var/lib/docker/overlay2가 눈에 보이는 모든 애플리케이션 데이터보다 더 많은 공간을 차지하는 것을 발견했습니다. 이는 외부 라이브러리와 별도로 Docker 스토리지 루트를 측정해야 하는 이유를 보여 줍니다.

시스템 디스크가 가득 찼지만 외부 풀에 여유 공간이 있다면, 컨테이너, 오버레이 계층, 볼륨, 이미지 또는 빌드 캐시 중 어디에서 증가했는지 확인하세요. 활성 데이터와 복구 가능한 데이터를 분류하기 전에는 광범위한 정리 명령을 실행하지 마세요.

제한 없이 증가하는 컨테이너 JSON 로그 확인하기

로그 드라이버와 각 컨테이너 로그 파일의 크기를 확인하세요. 서비스가 기본 데이터를 다른 곳에 저장하더라도 stdout 및 stderr가 Docker의 로컬 컨테이너 디렉터리에서 끝없이 증가할 수 있습니다.

Code Maven은 기본 로그 파일이 Docker의 해당 요약 외부에서 계속 증가했기 때문에 docker system df로는 주요 문제가 드러나지 않았던 사례를 소개합니다. 숨은 공간 소비자는 계속 증가하는 컨테이너 로그였습니다.

로그를 순환시키거나 잘라내기 전에 오류를 과도하게 발생시키는 애플리케이션 문제를 찾아 해결하세요. 이후 컨테이너에는 제한된 로그 순환을 구성하고, 새 파일이 예상 한도에서 증가를 멈추는지 확인하세요.

컨테이너의 쓰기 가능 계층에 기록된 데이터 찾기

의도한 영구 저장 경로를 애플리케이션의 실제 캐시, 트랜스코딩, 다운로드, 데이터베이스, 썸네일, 백업 및 임시 디렉터리와 비교하세요. 마운트되지 않은 쓰기는 모두 시스템 디스크의 컨테이너 쓰기 가능 계층에 남습니다.

Docker 포럼의 한 설명에 따르면 쓰기 작업과 변경된 이미지 파일은 쓰기 가능 계층에 저장되고, 순환되지 않은 대용량 로그는 컨테이너 메타데이터에 저장됩니다. 외부 데이터 볼륨이 있어도 이 두 가지로 인해 하나의 컨테이너가 로컬 공간을 거의 모두 차지할 수 있습니다.

컨테이너별 크기 보고를 사용하고 컨테이너 내부에서 변경된 경로 중 가장 큰 항목을 조사하세요. 영구적으로 보존해야 하는 데이터에만 명시적인 바인드 마운트나 이름 있는 볼륨을 추가한 다음, 중요한 데이터를 백업하고 컨테이너를 다시 만들어 더 이상 필요하지 않은 쓰기 가능 계층 콘텐츠를 제거하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

컨테이너 시작 시 외부 마운트가 존재했는지 확인하기

Docker가 컨테이너를 시작하기 전에 SSD, NAS 공유 또는 스토리지 풀이 예상한 호스트 경로에 마운트되었는지 확인하세요. 장치 식별자와 마운트 출력을 컨테이너가 확인하는 디렉터리와 비교하세요.

외부 마운트가 없더라도 시스템 파일 시스템의 기반 빈 디렉터리는 여전히 존재할 수 있습니다. 컨테이너는 이 대체 디렉터리에 정상적으로 쓸 수 있으므로, 외부 풀이 전혀 사용되지 않은 것처럼 보이는 동안 시스템 디스크가 계속 증가할 수 있습니다.

데이터가 채워진 대체 디렉터리 위에 스토리지를 다시 마운트하기 전에 컨테이너를 중지하세요. 숨겨진 파일을 안전하게 이동하거나 조정하고, 마운트 종속성 또는 시작 확인을 추가하며, 예상한 장치가 없을 때는 애플리케이션이 시작되지 않도록 하세요.

이미지 계층, 빌드 캐시 및 방치된 객체 조사하기

사용하지 않는 이미지, 중지된 컨테이너, 익명 볼륨 및 BuildKit 캐시를 검토하세요. 애플리케이션의 영구 데이터가 다른 곳에 올바르게 마운트되어 있어도 잦은 업데이트나 로컬 빌드로 인해 여러 계층이 누적될 수 있습니다.

Moby 프로젝트 포럼의 한 설명은 오버레이 마운트로 인해 디스크 수치가 혼란스러워질 수 있으며 기반 파일 시스템 사용량을 신중하게 해석해야 한다고 설명합니다. 별도의 Home Assistant 사례에서도 시간이 지나면서 로그와 계층으로 인한 overlay2 증가가 확인되었습니다.

현재 Compose 프로젝트와 백업에서 사용되지 않는 것으로 확인된 객체만 제거하세요. Docker의 메타데이터 참조가 일관되지 않게 될 수 있으므로 개별 overlay2 디렉터리를 수동으로 삭제하지 마세요.

증가 기준선으로 수정 사항 검증하기

문제를 일으킨 경로를 수정한 후, 이전에 증가를 유발했던 워크로드를 실행하는 동안 일정한 간격으로 Docker 루트 사용량, 로그 크기, 컨테이너 쓰기 가능 크기 및 외부 풀 사용량을 기록하세요.

ZimaSpace의 대규모 NAS 전송 스테이징 워크플로는 데이터가 의도한 풀에 저장되는지 확인할 수 있는 반복 가능한 부하를 제공합니다.

시스템 디스크 증가량이 예상되는 이미지 및 로그 동작과 일치하고, 영구 애플리케이션 데이터가 외부 풀에서 증가하며, 외부 마운트가 없을 때 루트 파일 시스템에 조용히 쓰는 대신 안전하게 시작에 실패할 때에만 문제가 해결된 것입니다.