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
오래된 자료의 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.vhdxDocker Desktop을 완전히 종료한다. (트레이 아이콘 → Quit Docker Desktop)
신규 경로 만들기
mkdir D:\Docker\wsl\data기존 데이터 백업(export)
wsl --export docker-desktop-data "D:\Docker\wsl\data\docker-desktop-data.tar"기존 디스크 등록 해제
wsl --unregister docker-desktop-data새 위치로 가져오기(import)
wsl --import docker-desktop-data "D:\Docker\wsl\data" "D:\Docker\wsl\data\docker-desktop-data.tar" --version 2Docker 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 dockerdocker 그룹은 사실상 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.log3-1. 데몬 전체에 기본값 주기
/etc/docker/daemon.json 에 설정하면 이후에 만드는 모든 컨테이너에 적용된다.
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}sudo systemctl restart dockermax-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.0Compose 에서는 이렇게 쓴다.
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 같은 드라이버로 바꾼다.