데이터센터프로그래밍10(1)

10-이론: Docker Storage(1)

🔴 공부할 내용

• 컨테이너 내부에 파일을 저장할 때의 문제
• host machine에 파일 저장
• 컨테이너가 host machine에 파일 저장하는 옵션
  (1) volumes
  (2) bind mounts
  (3) tmpfs mount (for docker on Linux)
  (4) names pipe (for docker on Windows)

🟠 컨테이너 내부에 파일을 저장할 때 문제

• 해당 컨테이너가 더 이상 존재하지 않으면 데이터가 지속되지 않으며 다른 프로세스가 필요로 하는 경우 컨테이너에서 데이터를 가져오기가 어려울 수 있음
• 컨테이너의 writable layer는 컨테이너가 실행 중인 host machine과 밀접하게 연결되어 있으며, 데이터를 다른 곳으로 쉽게 이동할 수 없음
• 컨테이너의 writable layer에 쓰기 위해서는 파일 시스템을 관리하기 위한 storage driver가 필요함. storage driver는 Linux 커널을 사용하여 통합 파일 시스템을 제공함. 이 추가 추상화는 host filesystem에 직접 쓰는 데이터 볼륨을 사용하는 것과 비교하여 성능을 감소시킴

🟠 컨테이너 내부에 파일을 저장할 때 문제

• volumes 도커에서 관리하는 호스트 파일 시스템의 일부에 저장
• bind mounts host system의 모든 위치에 저장할 수 있음
• tmpfs mounts host system's의 메모리에만 저장되며 host system's의 파일 시스템에는 기록되지 않음
  

🟠 Volumes

• 도커에서 관리하는 호스트 파일 시스템의 일부에 저장
  : volumes은 도커에서 데이터를 유지하는 가장 좋은 방법
  : 도커가 아닌 프로세스는 파일 시스템의 부분을 수정해서는 안됨
• host machine의 도커 storage directory 내에 새로운 directory가 생성됨
  🙂 도커에서 Volumes를 만들면 컨테이너들이 서로 다른 이미지에서 나왔어도 동시 사용이 가능함
  🙂 명령어 사용함 docker volume create, docker volume prune

🟠 bind mounts

• host system의 아무 곳에나 저장할 수 있음
  : 중요한 시스템 파일 or directories 일 수도 있음
  : 도커 호스트 또는 도커 컨테이너의 도커가 아닌 프로세스는 언제든지 수정할 수 있음
• host machine의 파일 or 디렉토리가 컨테이너에 마운트됨
  : 도커 호스트에 이미 존재하지 않아도 됨
  : 존재하지 않는 경우 즉시 생성
• bind mounts를 직접 관리하기 위해 docker cli 명령을 사용할 수 없음
  🙂 도커에서 코드화된 명령어를 줘야지 동작이 실행함 즉, 타이핑으로 실행 NO!
• Bind mounts는 호스트 시스템의 모든 위치에 저장할 수 있음
• volumes 비해 제한된 기능
  : Bind mounts를 사용하면 호스트 시스템의 파일 or 디렉토리가 컨테이너에 마운트됨
  : 파일 or 디렉토리는 호스트 시스템의 전체 or 상대 경로에 의해 참조됨
• Bind mounts는 민감한 파일에 대한 액세스를 허용함

🟠 tmpfs mount (for docker on Linux)

• 컴퓨터의 램은 빨리 처리할 때 사용하는데, 이 tepfs는 램을 파일시스템처럼 사용하는 것임 즉, 휘발성으로 다 사라지기에 임시데이터들을 올려놓고, 종료되면 사라지는 기법
• 리눅스 위에서/본인 컴퓨터에서 사용가능함, (본인이 필요한 것만 사용할 것)

🟠 names pipe (for docker on Windows)

• Windows에서 도커를 띄운 경우, 도커를 통해서 띄어져 있는 컨테이너 밖-안에서 통신(주고-받는)하는 것