Quick Comparison
| 목적 | bind mount | named volume | tmpfs |
|---|---|---|---|
| 개발 중 소스 코드 즉시 반영 | 적합 | 부적합 | 부적합 |
| DB·업로드 파일 영속 | host 경로 관리가 필요 | 적합 | 부적합 |
| host 경로 없이 이식성 확보 | 부적합 | 적합 | 부적합 |
| 종료·재시작 뒤 데이터 제거 | 부적합 | 부적합 | 적합 |
# 명시적인 bind mount: source가 없으면 오류
docker run --mount type=bind,src="$(pwd)/src",dst=/app/src,readonly node:22-alpine
# Docker daemon이 관리하는 persistent volume
docker run -e POSTGRES_PASSWORD=example \
--mount type=volume,src=pgdata,dst=/var/lib/postgresql/data postgres:16
# host 메모리에만 존재하는 임시 mount
docker run --tmpfs /tmp:rw,size=64m my-appbind mount는 daemon host의 실제 경로를 연결하고, volume은 Docker가 수명주기를 관리하며, tmpfs는 container가 멈추거나 host가 재시작되면 사라집니다.
mount 동작
bind mount는 기존 container 파일을 가린다
bind mount를 container 안에 이미 파일이 있는 경로에 붙이면 기존 파일은 삭제되지 않지만 mount 뒤에 가려집니다. mount를 제거해 그 파일을 다시 보려면 해당 mount 없이 container를 새로 만들어야 합니다. 소스 코드를 /app 전체에 붙여 image가 설치해 둔 의존성까지 가리는 문제가 자주 생기는 이유입니다.
# image의 /app/node_modules까지 host ./app 내용으로 가릴 수 있음
docker run --mount type=bind,src="$(pwd)/app",dst=/app node:22-alpine반대로 비어 있는 volume을 image 안의 비어 있지 않은 경로에 처음 mount하면 Docker가 기존 파일을 volume으로 복사해 초기화할 수 있습니다. image가 제공한 기본 데이터가 필요한지, 비어 있는 저장소가 필요한지 먼저 정합니다.
--mount와 -v는 없는 경로를 다르게 다룬다
bind mount에 --mount type=bind를 쓰면 source path가 없을 때 오류가 납니다. -v host-path:container-path의 짧은 문법은 없는 host path를 directory로 자동 생성할 수 있어, 파일을 기대했는데 빈 directory가 생기는 실수를 만들 수 있습니다. 운영 명령과 자동화에서는 의도를 확인하기 쉬운 --mount를 우선합니다.
host 경계와 권한
bind mount는 Docker client가 아니라 Docker daemon이 실행 중인 host의 path를 mount합니다. remote daemon을 쓰면 local laptop 경로를 바로 연결할 수 없습니다. Docker Desktop은 Linux VM 안에서 daemon을 실행하지만, 설정된 file sharing을 통해 macOS·Windows host path를 전달합니다. 이 경계 때문에 native host와 Linux container의 파일 권한·대소문자·성능이 다르게 보일 수 있습니다.
기본 bind mount는 쓰기 가능합니다. container process가 mount된 host 파일을 수정·삭제할 수 있으므로 설정 파일처럼 읽기만 필요한 것은 readonly 또는 :ro로 붙입니다. root로 실행한 container의 UID/GID가 host 파일 소유자와 맞지 않으면 개발 환경에서도 permission error나 root-owned 파일이 생깁니다.
docker run --mount type=bind,src="$(pwd)/config.yml",dst=/app/config.yml,readonly my-app데이터 선택
volume은 container를 제거해도 남고 daemon이 관리하므로 DB, 업로드 파일, 장기 데이터를 두기에 적합합니다. volume의 실제 storage path를 host에서 직접 수정하는 것은 지원되는 관리 방식이 아니며, backup·inspect·임시 container를 통해 다룹니다. volume backup은 volume backup과 restore 카드에서 다룹니다.
tmpfs는 host 메모리에만 존재하므로 disk에 남기지 않을 임시 파일에는 유용하지만, 비밀 정보를 영구적으로 안전하게 관리하는 수단은 아닙니다. container 종료·재시작과 host 재부팅 뒤 데이터가 없어도 되는 경우에만 선택합니다.
bind mount는 host 파일시스템에 직접 쓰는 권한을 container에 줄 수 있습니다. 운영 DB에 임의 host directory를 쓰기 가능하게 붙이거나, source path가 없는 -v 명령을 그대로 자동화에 넣지 마십시오.
참고 링크
3 sources