참조
https://docs.docker.com/engine/storage/bind-mounts/
https://docs.docker.com/engine/storage/volumes/
Docker를 주로 개발환경에서 사용하는데, 간단한 수정이나 테스트를 하는 경우에 해당되는 app 컨테이너만 재시작해서 확인 하다가, 이게 좀 번거롭기도하고 느리기도해서, 좀 효율적인 방법을 찾아보니 bind mount, volume을 적절히 사용하면 코드, 빌드된 소스가 연동되는 사실을 알게되었다.
호스트의 파일시스템과 컨테이너의 볼륨 연결을 하면 컨테이너와 연동되고, 개발 프레임워크테 따라 바로 refresh? rebuild가 되어서 시간을 효율적으로 사용할 수 있는걸 알고나서 Docker Volume에 대한 공식문서 내용을 좀 공부하려고함.
Volumes
Container의 Writable Layer에는 Container가 실행중인 Host Machine과 밀접하게 연결됩니다. 따라서 Data를 다른곳으로 쉽게 옮길 수 x
위 레이어에 데이터를 저장하기 위해서는 File System을 관리하는 Storage Driver가 필요함, Storage Driver는 리눅스 커널을 사용하고, 공용 파일 시스템을 제공합니다. 이 기능은 Host File System에 직접 쓰는 data volume보다 성능이 떨어집니다.
도커는 데이터를 안전하게 존속시킬 수 있는 방식으로, volume, bind mounts, tmpfs 의 3가지 방식을 제공합니다. 보통 volume 사용하긴함. 위 3개의 가장 큰 차이점은 Data가 도커 호스트내에서 어디에 존재하는지임니다.
도커 volume, bind mounts 사용 시 유의 사항
- File 또는 폴더가 있는 컨테이너 내의 비어있는 볼륨을 마운트하면, 해당 File or Directory가 volume으로 전달됩니다. 마찬가지로, 아직 존재하지 않는 특정 볼륨을 지정하고 컨테이너를 시작하면 비어있는 볼륨이 생성됩니다. 이는 다른 컨테이너에 필요한 데이터를 미리 갖출 수 있는 좋은 방법입니다.
- 위에서 volume 대신 build 마운트를 한다면, Linux Host에서 File을
/mnt에 저장합니다
docker run -d \
-it \
--name=nginxtest \
--mount source=nginx-vol, destination=/usr/share/nginx/html \
nginx:latest볼륨을 사용하는것이 더 빠르다
컨테이너의 Writable layer에 접근하려면 파일시스템을 관리하기 위한 스토리지 드라이버가 필요하고, 이는 Linux 커널을 사용하여 통합 파일 시스템을 제공합니다. 이러한 추가 추상화는 호스트 파일 시스템에 직접 쓰는 볼륨에 비해 성능이 좋지 않습니다.
볼륨의 수명주기
볼륨 콘텐츠는 지정된 컨테이너 수명 주기 외부에 존재합니다. 컨테이너가 제거되더라도 데이터가 유지된다.
파일이나 디렉터리가 존재하는 컨테이너의 디렉터리에 비어 있지 않은 볼륨을 마운트하는 경우 기존 파일은 마운트로 인해 가려집니다.
Bind Mount 대신 Volume을 사용해야하는 경우
먼저, 볼륨은 도커컨테이너에서 생성되고 사용되는 데이터를 유지하기 위해 선호됩니다. Bind Mount는 호스트시스템의 디렉터리 구조와 OS에 따라 달라지지만 볼륨은 도커에서 완전히 관리됩니다.
다음과 같은 사례에 적합합니다
- 백업 또는 마이그레이션을 쉽게 사용할 때
- Docker CLI, Docker API를 사용하여 관리할 때
- Linux, Window 컨테이너 모두 작동
- 여러 컨테이너 간에 볼륨을 더욱 안전하게 공유 가능
- 새 볼륨에는 컨테이너나 빌드에 의해 컨텐츠가 미리 채워질 수 있음
- 애플리케이션에 고성능 IO가 필요한 경우
볼륨은 Docker에 의해 관리되므로, 호스트에서 파일 액세스해야하는 경우에는 좋은 선택이 x, 컨테이너 호스트 모두에서 파일이나 디렉터리에 액세스해야 하는 경우 바인드 마운트를 사용
Volume 대신 Bind Mount를 사용해야하는 경우
바인드 마운트를 사용하면 호스트 시스템의 파일, 디렉터리가 호스트에서 컨테이너로 마운트됩니다.
- 도커 호스트의 개발환경과 컨테이너 간에 소스 코드 또는 빌드 아티팩트를 공유
- Container에서 파일을 생성하거나 생성하고 해당 파일을 호스트의 파일 시스템에 유지하려는 경우
- 호스트 머신의 구성 파일을 컨테이너로 공유함. Docker가 기본적으로 호스트머신에서 각 컨테이너로
/etc/resolve.conf를 마운트하여 컨테이너에 DNS 확인을 제공합니다.
빌드에도 Bind Mount를 사용할 수 있습니다. 호스트의 마운트 소스 코드를 빌드 컨테이너에 바인딩하여 프로젝트를 테스트, 린트 또는 컴파일 할 수 있습니다.
파일 또는 디렉터리가 존재하는 컨테이너의 파일 또는 디렉터리를 바인딩하면, 기존 파일은 마운트에 의해 가려집니다
이 가려진 파일을 다시 표시하기 위해 마운트를 제거하는 간단한 방법은 없습니다. 마운트없이 다시 만드는걸 추천하네요
Bind Mount 고려사항 및 제약사항
- 기본적으로 호스트 파일에 대한 쓰기 액세스 권한이 있습니다
- 중요한 시스템 파일이나 디렉터리 생성, 수정 또는 삭제를 포함하여 컨테이너에서 실행되는 프로세스를 통해 호스트 파일 시스템을 변경할 수 있습니다. 이 기능은 보안에 영향을 미칠 수 있슴니다. - Bind Mount는 클라이언트가 아닌 도커 데몬 호스트에 생성됩니다.
- 원격 도커 데몬을 사용하는 경우, 클라이언트 시스템에 있는 파일에 액세스 하기 위한 Bind Mount를 생성할 수 없습니다.
- Docker Desktop의 경우, 기본 호스트에서 실행되지 않고 Linux VM 내부에서 실행됩니다. 내부에는 매커니즘이 있어, 가상머신에서 실행되는 컨테이너와 기본 호스트 파일 시스템 경로를 공유할 수 있습니다. - Bind Mount가 있는 컨테이너는 호스트에 강력하게 연결되어있다.
개발 호스트에서 소스를 빌드할 때마다 컨테이너가 새 빌드에 접근해서 새로 빌드되길 원합니다.
바인드 마운트가 포함된 docker compose
services:
frontend:
image: node:lts
volumes:
- type: bind
source: ./static
target: /opt/app/static
volumes:
myapp: