Docker 로그 용량 제한이 적용되지 않을 때: Compose logging과 컨테이너 재생성

로그 용량 제한을 설정했는데도 파일이 계속 커진다면, 먼저 설정 파일에 적힌 값과 실행 중인 컨테이너에 적용된 값을 구분해야 한다. Docker 데몬의 기본값을 바꿔도 기존 컨테이너가 자동으로 새 로그 설정을 물려받는 것은 아니다.

또 하나의 함정은 로그의 종류다. Docker가 수집하는 표준 출력·표준 오류와, 애플리케이션이 볼륨에 직접 쓰는 파일은 같은 보존 정책으로 관리되지 않는다.

이 글은 2026-10-20 Docker 공식 문서를 기준으로 작성했다. 명령은 Linux Docker Engine과 Compose 플러그인을 전제로 한다. 이번 작성 환경에는 Docker 실행 환경이 없어 실제 로그 회전과 서비스 재생성은 실행하지 않았다. 아래 수치는 설명용 설정이며 mLog 운영 서버의 관측값이나 권장 보존 기간이 아니다.

1. 로그부터 지우지 말고 대상 서버를 확인한다

먼저 어떤 Docker 데몬에 연결돼 있는지 확인한다. 로컬 셸이라고 해서 로컬 데몬을 보고 있다는 보장은 없다.

docker context show
docker version
docker compose version
docker info --format '{{.LoggingDriver}}'
docker compose ps -a

명령은 실제 배포 때 사용한 프로젝트 디렉터리와 동일한 -f, --env-file, -p, profile 조건에서 실행한다. Portainer로 관리하는 스택이면 원래 스택 정의를 수정해야 한다. 별도 디렉터리에서 같은 서비스명을 새로 띄우는 방식은 피한다.

전체 용량 문제라면 Ubuntu 서버 디스크 용량 확인·정리에서 먼저 파일시스템과 데이터 영역을 나눈다. 이미지 캐시, DB 볼륨, 컨테이너 로그를 같은 문제로 묶어 삭제하지 않는다.

2. 데몬 기본값과 컨테이너 적용값을 각각 본다

docker info의 LoggingDriver는 데몬의 기본 드라이버다. 개별 컨테이너의 생성 당시 설정은 별도로 확인한다. 아래 app은 예시 서비스명이다.

docker compose ps -a -q app

출력된 ID 하나를 직접 선택해 다음 조회를 한다. 복제본이 여러 개면 각 ID를 따로 확인한다.

docker inspect --format '{{json .HostConfig.LogConfig}}' CONTAINER_ID
docker inspect --format '{{json .Mounts}}' CONTAINER_ID

예를 들어 json-file인데 옵션에 max-size가 없다면 Compose 파일을 수정했더라도 그 컨테이너에 반영됐는지 다시 확인해야 한다. 옵션 출력과 실제 동작 검증은 다른 단계다. 값이 보인다는 사실만으로 회전까지 관찰했다고 쓰지 않는다.

Docker 공식 로그 드라이버 설정은 기본 설정 변경이 새로 생성되는 컨테이너에 적용되며 기존 컨테이너는 재생성이 필요하다고 설명한다.

3. json-file 제한과 local 드라이버를 구분한다

json-file은 기본적으로 크기 제한 없는 로그를 기록한다. max-size가 회전 기준이고 max-file은 보관 파일 수를 제한한다. max-file만 지정해서는 충분하지 않다.

기존 서비스 아래에 다음 logging 블록을 추가하는 예다. 이 조각으로 기존 Compose 전체를 덮어쓰면 안 된다. image, volumes, networks, environment 등 원래 설정은 유지한다.

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

10m, 3은 설명용이다. 이 설정은 컨테이너별 정책이며 서버 전체 디스크를 일정 크기로 고정하는 장치가 아니다. 애플리케이션 로그·볼륨 데이터·다른 컨테이너·기타 저장 공간까지 제한하는 것도 아니다.

공식 json-file 문서의 경고대로 Docker가 관리하는 내부 로그 파일을 외부 도구로 직접 수정하는 방식은 피한다. truncate, 직접 rm, 내부 파일에 별도 logrotate 적용을 일반적인 해결 절차로 제시하지 않는다.

Docker는 많은 일반 사용 환경에서 회전을 기본 제공하는 local 드라이버도 권장한다. local 문서에는 기본 파일 크기 20MB, 파일 수 5개와 자동 압축이 설명돼 있다. 압축 전 보존량 기준 설명을 실제 디스크 사용량의 고정 보장으로 해석하지 않는다.

기존 수집기가 JSON 파일 형식을 전제로 한다면 바로 전환하지 않는다. 수집 경로·드라이버 호환성을 확인한 뒤 선택한다. 위 YAML의 드라이버만 local로 바꾸고 다른 드라이버 전용 옵션을 그대로 남겨 두는 변경도 피한다.

4. restart가 아니라 설정 반영을 위한 재생성이 필요하다

Compose의 logging 항목은 서비스별 드라이버와 옵션을 정의한다. 그러나 파일 수정은 실행 중인 컨테이너의 교체와 같지 않다.

먼저 변경 범위를 검토한다.

docker compose config --quiet
docker compose config --services

전체 docker compose config 결과를 확인할 때는 환경변수 값이 펼쳐져 비밀정보가 나타날 수 있으므로 공개 채팅이나 로그에 그대로 붙이지 않는다. --quiet 성공은 구성 검증이지 서비스 정상 동작 보장이 아니다. config 문서

재생성 전에 확인할 사항은 다음과 같다.

• 실제 서비스가 app인지, 다른 Compose 프로젝트를 보고 있지 않은지
• DB·업로드 파일이 영속 볼륨 또는 의도한 bind mount에 있는지
• 컨테이너 쓰기 계층에만 남은 필요한 데이터가 없는지
• 현재 이미지와 배포 정의를 복원할 수 있는지
• 필요한 장애 로그를 별도 안전한 위치에 보존했는지
• 단일 인스턴스 중단을 허용할 점검 시간이 있는지

조건을 확인한 뒤 해당 서비스만 재생성하는 예다. 중단이 발생할 수 있는 변경 명령이다.

docker compose up -d --no-deps --force-recreate --no-build --pull never app

--no-deps는 의존 서비스를 시작하지 않도록 범위를 좁히는 옵션이지, 의존성이 준비됐다는 검증이 아니다. DB 등이 이미 정상이어야 한다. --no-build --pull never는 이번 변경에 이미지 빌드·다운로드를 섞지 않기 위한 선택이며 로컬 이미지가 없으면 먼저 계획을 재검토한다. 태그가 이미 다른 이미지로 바뀌었다면 같은 태그만으로 같은 이미지가 보장되지 않으므로 배포 정의와 digest도 확인한다.

compose up 문서에서 재생성과 옵션 의미를 확인할 수 있다. 설정 반영 없이 재시작만 하는 명령과의 차이는 기존 Compose 환경변수 글에 정리했다. restart 공식 문서도 Compose 설정 변경은 restart로 반영되지 않는다고 설명한다.

로그 정책을 바꾸기 위해 down -v나 prune --volumes를 실행할 이유는 없다. 영속 데이터 삭제 위험만 더해진다.

5. 성공 기준은 컨테이너 ID와 설정, 서비스 응답이다

docker compose ps -a app
docker compose ps -q app
docker inspect --format '{{json .HostConfig.LogConfig}}' NEW_CONTAINER_ID
docker compose logs --since 5m --tail 100 app

이전과 다른 컨테이너 ID인지, 의도한 logging 값이 있는지, 앱의 정상 응답과 의존 서비스 연결이 유지되는지 함께 본다. 최근 로그가 보인다는 것만으로 회전 임계값을 넘는 상황까지 검증한 것은 아니다.

운영 서버에 대량 로그를 강제로 흘려 테스트하지 않는다. 별도 시험 환경에서 작은 제한으로 회전을 확인하고, 운영에서는 자연스러운 로그 증가와 모니터링으로 추적한다. 회전은 오래된 로그를 제거하므로 보안 감사·장애 분석에 필요한 기록은 별도 보존 정책이 필요하다.

문제가 생기면 이전 Compose 정의와 동일한 이미지로 되돌린 뒤 대상 서비스를 다시 재생성한다. 이것은 설정 복구이며, 이미 제거된 로그나 쓰기 계층 데이터를 복원하는 방법은 아니다.

6. 제한 후에도 디스크가 찬다면 로그 종류를 다시 나눈다

Docker의 로그 드라이버는 컨테이너 표준 출력·표준 오류를 다룬다. 앱이 /logs 같은 볼륨에 직접 기록하는 파일은 앱 자체 회전 정책을 확인한다. 호스트의 journald, DB 파일, 백업 파일도 각각 별도 문제다.

파일을 이미 삭제했는데 공간이 돌아오지 않는 상황은 df·du 차이와 열린 삭제 파일 진단으로 이어간다. 로그 정책을 바꾸는 작업과 열린 파일의 공간 회수는 같은 작업이 아니다.

마지막으로 기억할 것은 세 가지다. 로그의 종류를 확인하고, 컨테이너에 적용된 값을 조회하고, 필요한 대상만 재생성한 뒤 서비스 정상 상태를 검증한다. 설정 파일 한 줄을 추가한 사실과 운영에서 검증한 결과를 구분해야 같은 장애를 반복하지 않는다.