Part 2. 레퍼런스

Docker 환경 설정

Docker Desktop(Windows) 사용 시 알아두면 유용한 환경 설정을 정리한다.

1. 이미지 저장 경로 변경 (Windows / WSL2)

Docker Desktop for Windows는 이미지·컨테이너 데이터를 WSL2 가상 디스크(ext4.vhdx)에 저장한다. 기본 경로가 C 드라이브이므로 이미지가 쌓이면 시스템 드라이브 용량이 빠르게 줄어든다.

권장 — Docker Desktop 설정에서 옮기기

Settings → Resources → Advanced → Disk image location 에서 경로를 바꾸고 Apply & restart 를 누르면 Docker Desktop이 기존 데이터를 옮겨준다. 별도의 백업·복원 절차가 필요 없다.

Settings → Resources → Advanced 의 Disk image location

Settings → Resources → Advanced 의 Disk image location

오래된 자료의 wsl --export / --import 절차는 최신 버전에서 동작하지 않는다.

Docker Desktop 4.30부터 docker-desktop-data 라는 별도 WSL 배포판이 없어졌다. 데이터가 docker-desktop 배포판 안으로 통합됐기 때문에 wsl --export docker-desktop-data 는 "배포판을 찾을 수 없음" 으로 실패한다.

# 내 환경에 docker-desktop-data 가 있는지 먼저 확인한다
wsl -l -v

목록에 보이지 않으면 위의 Disk image location 설정을 사용한다.

구버전(4.30 미만) — WSL 배포판을 직접 옮기는 절차

wsl -l -v 목록에 docker-desktop-data 가 있는 경우에만 해당한다.

기존 저장 경로

%USERPROFILE%\AppData\Local\Docker\wsl\data\ext4.vhdx
  1. Docker Desktop을 완전히 종료한다. (트레이 아이콘 → Quit Docker Desktop)

  2. 신규 경로 만들기

    mkdir D:\Docker\wsl\data
  3. 기존 데이터 백업(export)

    wsl --export docker-desktop-data "D:\Docker\wsl\data\docker-desktop-data.tar"
  4. 기존 디스크 등록 해제

    wsl --unregister docker-desktop-data
  5. 새 위치로 가져오기(import)

    wsl --import docker-desktop-data "D:\Docker\wsl\data" "D:\Docker\wsl\data\docker-desktop-data.tar" --version 2
  6. Docker Desktop을 다시 실행하고 docker image ls 로 기존 이미지가 그대로 남아있는지 확인한다.

wsl --unregister 는 되돌릴 수 없는 명령이다. 반드시 4단계 이전에 3단계 export가 정상적으로 끝났는지 확인하고 진행한다. tar 파일 크기가 0이 아닌지 확인할 것.

import가 끝난 뒤에는 백업용 docker-desktop-data.tar 파일을 삭제해도 된다. 다만 용량 여유가 있다면 한동안 보관해두는 편이 안전하다.

2. 리눅스 — 비 root 사용자로 docker 실행

Docker 데몬은 root 로 돌기 때문에 기본적으로 모든 docker 명령에 sudo 가 필요하다. docker 그룹에 사용자를 넣으면 sudo 없이 쓸 수 있다.

# 현재 사용자를 docker 그룹에 추가
sudo usermod -aG docker $USER

# 변경 사항 적용 (재로그인 또는 아래 명령어 실행)
newgrp docker

docker 그룹은 사실상 root 권한과 같다. 이 그룹에 들어간 사용자는 sudo 없이도 호스트의 루트 파일 시스템을 컨테이너에 마운트할 수 있다.

# docker 그룹만 있으면 sudo 없이 호스트 전체를 읽고 쓸 수 있다
docker run -it -v /:/host alpine chroot /host sh

즉 docker 그룹 추가 = 그 계정에 무제한 sudo 를 주는 것으로 봐야 한다. 개인 개발 PC 에서는 편의상 쓰지만, 여러 사람이 쓰는 서버에서는 아무에게나 넣어 주면 안 된다. 서버에서는 누가 이 그룹에 들어가 있는지 관리하고, 자동화용 키처럼 새어 나갈 수 있는 접속 수단은 할 수 있는 일을 좁혀 둔다. 데몬을 root 로 돌리지 않는 rootless 모드도 검토할 만하다.

3. 컨테이너 로그 크기 제한 — 로그 드라이버 설정

컨테이너가 표준 출력으로 찍는 로그는 기본적으로 호스트에 JSON 파일로 무한히 쌓인다. 오래 돌아가는 컨테이너 하나가 디스크를 채워 서버 전체를 멈추게 하는 일이 실제로 자주 일어난다.

docker logs 가 읽는 그 파일의 경로는 이렇게 확인한다.

docker container inspect <컨테이너명> --format='{{.LogPath}}'
# /var/lib/docker/containers/<id>/<id>-json.log

3-1. 데몬 전체에 기본값 주기

/etc/docker/daemon.json 에 설정하면 이후에 만드는 모든 컨테이너에 적용된다.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
sudo systemctl restart docker

max-size 는 파일 하나의 최대 크기, max-file 은 보관할 파일 개수다. 위 설정이면 컨테이너 하나가 쓰는 로그는 최대 30 MB 로 묶인다.

이미 돌고 있는 컨테이너에는 적용되지 않는다. 로그 옵션은 컨테이너를 만들 때 고정되므로, 기존 컨테이너는 지우고 다시 만들어야 새 설정을 받는다.

docker container inspect <컨테이너명> --format='{{json .HostConfig.LogConfig}}'

로 실제로 적용됐는지 확인할 수 있다.

3-2. 컨테이너 하나에만 주기

docker run -d \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  --name myapp myapp:1.0

Compose 에서는 이렇게 쓴다.

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

호스트의 logrotate 로 이 파일을 돌리지 않는다. Docker 가 파일 핸들을 열고 있어서 로테이트한 뒤에도 계속 옛 파일에 쓰는 일이 생긴다. 컨테이너 로그는 로그 드라이버로 관리하는 것이 맞다.

로그를 서버 바깥으로 보내야 한다면 json-file 대신 awslogs(CloudWatch)·fluentd·syslog 같은 드라이버로 바꾼다.

마지막 수정 2026년 10월 22일