도커 로그가 디스크를 채운다면: json-file 용량 제한과 로테이션 확인

이미지를 새로 배포하지 않았는데 서버의 디스크 사용량이 계속 늘어나는 경우가 있습니다. 컨테이너가 내보내는 로그도 확인할 대상이죠. 다만 디스크가 찼다는 사실만으로 도커 로그가 원인이라고 결론 내리면, 다른 저장 공간을 놓칠 수 있습니다.

이 글은 Linux 서버의 Docker Engine에서 json-file 드라이버를 사용하는 컨테이너를 중심으로 설명합니다. 로그가 쌓이는 대상을 확인하고, 크기 제한과 적용 시점을 읽는 순서예요.

도커 로그는 어떤 경우에 디스크를 계속 사용하나요?

json-file이 제한 없이 컨테이너 출력을 기록하면 로그 증가가 디스크 사용 증가로 이어질 수 있습니다.

Docker의 json-file 문서는 컨테이너의 표준 출력(stdout)과 표준 오류(stderr)를 JSON 형식으로 기록한다고 설명합니다. 로그 파일은 컨테이너별로 관리되죠.

따라서 이미지의 크기와 실행 중 누적되는 로그는 구분해서 살펴봐야 합니다. 이미지 경량화 방법은 기존 글 컨테이너 이미지 다이어트: distroless·멀티스테이지로 크기와 공격면 줄이기에서 다룹니다. 여기서는 이미지를 다시 만드는 대신 현재 컨테이너의 로그 저장 조건을 확인합니다.

또한 docker logs 안내의 기본 확인 대상은 컨테이너의 표준 출력·표준 오류입니다. 애플리케이션이 별도 파일로 쓰는 기록까지 같은 설정 하나로 모두 관리된다고 생각하면 안 돼요. 이번 제한값이 어떤 출력에 적용되는지부터 맞춰 보세요.

기본 드라이버와 컨테이너 설정은 어떻게 대조하나요?

데몬의 현재 기본 로그 드라이버를 확인한 뒤 대상 컨테이너의 드라이버와 옵션을 따로 조회합니다.

아래는 설정을 바꾸지 않고 정보를 조회하는 명령입니다. CONTAINER_NAME은 확인할 컨테이너의 실제 이름이나 ID로 바꿉니다.

Docker의 로그 설정 안내에 따르면 컨테이너는 데몬 기본값과 다른 드라이버나 옵션을 사용할 수 있습니다. 기본값이 json-file이라는 결과만으로 모든 컨테이너의 제한값까지 확인한 것은 아니죠.

docker inspect 문서는 대상을 컨테이너로 한정하는 --type 옵션과 구조체를 JSON으로 출력하는 형식을 안내합니다. 조회 결과의 Type과 Config를 함께 읽어, 이 글의 json-file 옵션 설명을 적용할 대상인지 확인하세요.

명령을 실행하는 PC와 확인하려는 서버가 같다고 가정하지도 않습니다. Docker context는 하나의 클라이언트에서 여러 데몬에 연결할 수 있도록 합니다. 현재 context뿐 아니라 --context·--host 인자나 관련 환경변수로 연결 대상이 달라졌는지 확인해야 해요. 여기서 사용한 명령을 실제 운영 서버에서 실행한 것은 아닙니다.

max-size와 max-file은 어떻게 함께 동작하나요?

max-size는 로그 파일 교체의 크기 기준이고 max-file은 함께 유지할 파일의 최대 개수입니다.

로테이션은 로그를 계속 한 파일에 덧붙이는 대신 파일을 교체하며 관리하는 방식입니다. 허용 개수를 넘으면 오래된 파일을 제거한다고 공식 문서는 설명합니다. max-file만 지정하고 크기 기준을 빠뜨리면 기대한 제한이 되지 않죠.

문서의 설정 예시는 log-driver를 json-file로 두고 log-opts에 "max-size": "10m", "max-file": "3"을 넣습니다. daemon.json의 log-opts 값은 숫자처럼 보여도 문자열로 작성해야 합니다. 여기서 10m와 3은 공식 예시를 읽기 위한 값이며 모든 서버에 권하는 기준은 아닙니다.

이 설정을 컨테이너 전체나 서버 전체의 디스크 사용 상한으로 확대해서 읽지 마세요. 적용 대상은 해당 드라이버가 관리하는 로그입니다. 보관할 시간 범위도 별도로 정해야 하죠. 같은 파일 크기와 개수라도 출력이 많으면 과거 기록이 더 빠르게 교체될 수 있어요. 이는 크기·개수 기준에서 도출한 운영상 해석입니다.

설정을 바꾸면 기존 컨테이너에도 바로 적용되나요?

데몬 로그 설정 변경은 기존 컨테이너에 자동 반영되지 않으며 새 옵션을 쓰려면 재생성해야 합니다.

공식 안내는 Docker를 재시작한 뒤 새로 생성되는 컨테이너에 변경 사항이 적용된다고 설명합니다. 기존 컨테이너를 단순 재시작하는 것과 원하는 옵션으로 다시 생성하는 것은 다릅니다.

먼저 현재 실행 중인 컨테이너와 다음 배포에 사용할 생성 설정을 따로 비교해 보세요. 배포 정의를 고쳤다는 사실과 지금 실행 중인 대상의 설정이 바뀌었다는 사실도 구분해야 하죠. 재생성 뒤에는 앞서 소개한 inspect 조회로 다시 확인하는 순서를 제안합니다.

재생성을 검토할 때는 볼륨·데이터 보존 조건과 서비스 중단 영향을 확인해야 합니다. 이 글은 운영 중인 컨테이너를 일괄 중지하거나 삭제하는 명령을 제시하지 않습니다. 로그 제한을 적용하는 작업과 이미 쌓인 기록을 어떻게 보존할지는 함께 정할 항목이에요.

다른 선택지를 검토한다면 local 드라이버 문서도 참고할 수 있습니다. local은 기본 로테이션과 압축을 제공하지만, 이를 json-file의 기본 동작과 섞어 설명하면 안 됩니다. 드라이버를 바꿀 때도 수집 도구와 조회 방식, 기존 컨테이너 적용 범위를 함께 점검하세요.

로그를 직접 지우기 전 무엇을 확인해야 하나요?

Docker 관리 로그를 직접 조작하기보다 대상·실제 설정·보관 필요 기록과 변경 영향을 먼저 확인합니다.

Docker는 json-file 저장 파일을 데몬이 전용으로 관리한다고 명시합니다. 외부 도구로 직접 다루면 로그 시스템에 예상하지 못한 동작이 생길 수 있으므로 피하라고 안내하죠. 따라서 파일 삭제나 truncate를 용량 문제의 공통 처방으로 제시하지 않습니다.

이 표는 변경 전에 정보를 맞추기 위한 기록 제안입니다. 제한값을 정하는 일은 장애 원인을 확정하는 일과 다르죠. 바이트 용량과 inode를 함께 살피는 방법은 디스크 여유가 있는데 파일을 못 만든다면: df -h와 df -i를 함께 보는 이유에서 확인할 수 있습니다.

로그의 중앙 수집·보관·분석 체계는 클라우드 로그 관리, 쌓기만 하고 분석은 못 하는 기업을 위한 실무 가이드에서 별도로 다룹니다. 여기서는 해당 컨테이너에 어떤 제한이 적용돼 있는지와 언제 바뀌는지에 집중합니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)