written by yechoi

[도커] volume(볼륨) vs bind-mount(바인드 마운트) 본문

Born 2 Code/Docker, Kubernetes

[도커] volume(볼륨) vs bind-mount(바인드 마운트)

yechoi 2021. 7. 1. 11:32
반응형

➰ Docker Docs 번역입니다.

volume

볼륨은 도커 컨테이너에서 생산되고 사용되는 데이터를 영구적으로 저장하기 위한 방법이다. 바인드 마운트가 호스트 머신의 디렉토리 구조나 OS에 의존적인 반면, 볼륨은 도커에 의해 완전히 관리된다. 볼륨은 바인드 마운트에 비해 다음의 장점을 가진다.

  • 바인드 마운트보다 백업하거나 마이그레이트 하기 휩다
  • Docker CLI 커맨드나 Docker API를 활용해 관리할 수 있다.
  • 리눅스, 윈도우 컨테이너 모두에서 작동한다.
  • 여러 컨테이너 간 공유할 때 더 안전하다.
  • 볼륨 드라이버는 리모트 호스트나 클라우드 공급사에 볼륨을 하거나, 내용을 해독, 다른 기능을 더할 수 있도록 한다.
  • 새로운 볼륨은 컨테이너에 의해 이미 생성된 컨텐트를 가질 수 있다.
  • Docker Desktop의 볼륨은 백, 윈도우 호스트의 바인드 마운트보다 성능이 높다.

또한, 볼륨은 컨테이너의 쓰기 가능한 레이어의 영속적 데이터보다 괜찮은 선택지다. 왜냐하면 볼륨은 사용한닼고 컨테이너의 용량을 늘리지 않으며, 컨테이너 생명주기 밖에서 볼륨의 컨텐츠가 존재하기 때문이다.

컨테이너가 영속적이지 않은 데이터를 생산한다고 하면, 데이터를 어딘가에 영구적으로 저장하는 것을 막고 컨테이너의 쓸 수 있는 레이어에 쓰는 것을 피하기위해 tmpfs mount를 사용하는 걸 고려해보라.

🔗 원문: Use volumes(en/docs)

bind mounts

바인드 마운트는 Docker 초기 부터 있었던 존재다. 볼륨에 비해서는 기능이 제한돼있다. 바인드 마운트를 사용하면 host machine의 파일과 디렉토리가 컨테이너에 마운트된다. 파일 또는 디렉터리는 호스트 머신의 절대 경로로 참조된다. 반대로 볼륨을 사용하면 호스트 머신 상의 도커의 스토리지 디렉토리에 새로운 디렉토리가 생성된다. 그리고 도커가 해당 디렉토리의 컨텐츠를 관리한다.

파일 또는 디렉토리는 도커 호스트에 미리 존재하고 있을 필요는 없다. 만약 존재하지 않는다면 온디맨드로 생성된다. 바인드 마운트는 성능이 좋지만, 호스트 머신의 파일 시스템에 의존적이며 특정 디렉토리 구조를 필요로 한다. 도커 어플리케이션을 개발 중이라면, 이것 대신에 볼륨을 사용할 것을 고려해보라. 바인드 마운트를 직접적으로 관리하기 위해 Docker CLI 커맨드를 사용할 수 없다.

🔗 원문: Use bind mounts(en/docs)

 

docker-compose로 환경을 구성하던 중, 로컬의 파일을 컨테이너에서 그대로 연동할 수 없을까해서 찾아본 방법. 개발 과정이라 시시각각 변하는 파일을 컨테이너가 반영했으면 하는 바람이었다. bind-mounts로 가능은 하지만, 결과적으로는 그렇게 하지 않기로 했다. 저장소의 관리 주체가 local, container 두 개로 나뉘어지기도 하고, 마운트했다가 해제한 후 다시 마운트했을 때 에러 상황이 있을 수 있기 때문이다. 결정적으로 컨테이너를 사용하는 취지와 어긋난다는 판단이 들었다. 개발은 개발환경에서, 배포는 컨테이너 환경에서 하는 걸로.

 

기타 참고한 자료들
🔗 Docker 컨테이너에 데이터 저장 (볼륨/바인드 마운트)(ko/blog)
🔗 docker 데이터 활용 - bind mount(1)(ko/blog)

 

반응형