Skip to content

Latest commit

 

History

History
43 lines (29 loc) · 3.63 KB

도커 스토리지.md

File metadata and controls

43 lines (29 loc) · 3.63 KB

여러 작업 중 컨테이너 내부에서 생성한 정보, 파일은 컨테이너가 종료된 후에 모두 사라진다. 이러한 데이터를 저장하려면 별도의 저장공간이 필요한데, 컨테이너가 동작 중인 상태에서는 접근이 제한되기 때문에 직접 옮기기는 쉽지 않다.

도커는 스토리지에 파일을 저장하여 컨테이너가 종료되더라도 파일을 유지할 수 있도록 한다. 스토리지는 원본 이미지를 수정 하는 대신 변경된 정보를 따로 저장하고, 원본 데이터와 변경된 정보를 조합해서 복원하는 식으로 데이터를 읽는다. 이렇게 하여 원본 이미지를 수정 할 필요 없이 각 컨테이너마다 다른 정보를 저장 할 수 있다.

스토리지 종류

도커 스토리지의 종류는 3가지가 있다. Volume, bind mount, tmpfs mount이다. 아래 그림은 각 방식을 나타내는 그림이다.

image

종류 설명
Volume 도커에 의해 관리되는 호스트 파일 시스템에 저장하는 방식이다. 호스트 내의 도커 프로세스가 아닌 다른 프로세스들은 Volume 관련 파일 시스템을 수정할 수 없다.
Bind mounts 호스트 파일 시스템의 특정 경로를 컨테이너로 마운트하는 방식이다. Volume만큼 해당 파일이 엄격하게 관리되진 않아서, 도커 내의 모든 프로세스가 접근 수정할 수 있다.
tmpfs mounts 호스트 시스템의 메모리에 저장하는 방식이다.

1. Volume

볼륨은 Docker 컨테이너에서 생성하고 사용하는 데이터를 유지하기 위한 기본적인 방법이다. Docker에서 완전히 관리하고 있는 공간에 저장된다. Volume의 특징은 다음과 같다.

  • 보안이 철저하고, 백업이나 마이그레이션이 쉽다.
  • Docker CLI나 Docker API 명령어를 사용해 관리할 수 있다.
  • 다른 OS간에 정보를 옮길 수 있다. (ex: Linux -> Window)
  • 성능이 좋다.
  • 컨테이너가 정지 또는 제거되더라도 그에 대한 volume은 삭제되지 않는다.
  • 여러 컨테이너들이 동일 volume에 대하여 마운트 할 수 있다.

2. bind mounts

일반적인 경우에는 Volume을 사용하는 것을 추천한다. 하지만 특정 경우에 bind mount를 사용하는 경우가 있는데, 아래와 같은 경우이다.

  • Host Machine에서 Container로 설정 파일을 공유해야하는 경우 Docker는 Host Machine의 /etc/resolv.conf를 각 Container에 bind mount하여 DNS Resolution을 제공하고 있다.
  • Docker Host 개발 환경과 Container 간 소스코드 또는 빌드된 아티팩트를 공유하는 경우 Maven의 target/ 디렉토리를 Container에 Mount하면 Docker Host에서 Maven Project를 빌드할 때마다, Container에서 재작성된 JAR/WAR에 접근할 수 있다. 만약 이런 방식으로 개발을 진행한다면, Production Dockerfile은 bind mount에 의존하지 않고도, Production-Ready 아티팩트를 Image에 직접 복사할 수 있다.
  • Docker Host의 파일 또는 디렉토리 구조가 Container가 요구하는 bind mount와 일치하는 경우
  • 호스트 시스템에서 컨테이너로 구성 파일을 공유하는 경우

3. tmpfs mounts

tmpfs 마운트는 데이터가 호스트 시스템이나 컨테이너 내에서 유지되지 않도록 하려는 경우에 사용된다.보안적으로 오래 유지하면 안되는 데이터거나, 애플리케이션이 많은 양의 비영구 상태 데이터를 써야 할때 성능상 이점을 위해 사용할 수 있다.