[Docker] Storage driver & 데이터 관리

whatSup CheatSheet·2022년 9월 29일
0

Container

목록 보기
4/9
post-thumbnail
post-custom-banner

Storage driver

  • 도커는 UFS(Union File System)기반의 Storage driver를 사용하여 컨테이너와 이미지를 관리합니다.

    UFS(Union File System)이란?

    • 하나의 디렉토리 위치에 여러 개의 디렉토리를 마운트하여도, 하나의 통합된 디렉토리처럼 보이게 하는 방법
      (원래는 기존 디렉토리 위치에 새로운 파일 시스템을 마운트하면 새롭게 마운트된 내용만 보이게 됨)
    • UFS에서 사용하는 주요 개념으로 Image LayerCoW가 있습니다.
  • 도커를 통해 Image Layer의 구조를 알아봅시다.
    • 위 그림에서 하단에는 Read Only의 이미지 레이어가 존재합니다.
    • 위 그림에서 상단에는 Writable한 컨테이너 레이어가 존재합니다.
  • 이러한 Image Layer는 효율적으로 하나의 도커 이미지로 여러 개의 컨테이너를 생성하고, 각 컨테이너를 사용자의 입맛에 맞게 관리할 수 있게 해줍니다.
    Read Only의 이미지 레이어와 Writable한 컨테이너 레이어와의 Union으로 최종 컨테이너들을 생성하는식으로 말이죠.
  • 즉, 이미지를 레이어 형식으로 쌓는다고 하여 Image Layer라고 부릅니다.
  • 이제 효울적인 Write를 위한 CoW 전략에 대해서 알아봅시다.

CoW(Copy on Write), RoW(Redirect on Write) 전략

이미지 출처

  • 다음 이미지와 같이 Process1은 physical memory로부터 page A, B, C를 사용하고 있습니다.

  • 이때, page A, B, C에 대해 읽기 작업을 수행하는 새로운 Process 2가 생성된다면, 다음 그림처럼 Process 2는 그저 physical memory에 접근하여 파일들의 내용을 그저 읽으면 됩니다.

  • 그러나 process가 기존 파일들에 쓰기 작업을 해야 할 경우, 상황이 조금 달라집니다. 원본 파일을 유지하면서 쓰기를 저장할 수 있어야 하기 때문입니다.

  • 이를 해결하기 위해, 쓰기 요청을 수행해야 할 경우에는 다음 그림처럼 physical memory에서 원본 파일을 복사(Read & Write)한 뒤 요청을 반영하게 됩니다. 이것이 바로 Copy on Write 전략입니다.

  • RoW는 CoW와 비슷하지만, 쓰기 작업 시 Copy(Read & Write)를 하는 것이 아니라, 변경점만을 저장(Write)한다는 차이가 있습니다. 따라서 CoW와는 다르게 한 번의 쓰기 작업만 일어납니다.

  • 이제 위에서 살펴봤던 도커 storage driver의 구조를 다시 한 번 보겠습니다.

    • 도커에서 아래 Image Layer들은 위 예시에서 '원본 파일'에 해당합니다.
    • 만약 새로운 컨테이너를 생성하는 등 변경사항이 생긴다면 Container Layer에 변경점을 저장하게 됩니다.
    • 만약 변경된 내용으로 새로운 이미지를 build하게 된다면, 원본 파일 + 변경점이 하나의 원본 파일(layer)이 될 것입니다.
  • 도커는 드라이버에 따라 CoW 또는 RoW 개념을 사용합니다. 이제 도커에서 사용하는 Union FileSystem을 지원하는 대표적인 드라이버(AUFS, OverlayFS)에 대해서 알아보도록 하겠습니다.

AUFS Driver

  • AUFS는 Container에서 원본 파일을 변경해야 한다면, 컨테이너 레이어로 전체 파일을 복사하고, 이 파일을 변경함으로써 변경사항을 반영합니다.
  • 이미지 레이어는 계층형태로 되어있으며, 복사할 파일을 찾기 위해 가장 위의 레이어부터 찾기 시작하게 됩니다. 따라서 복사할 파일이 이미지 레이어의 아래쪽에 있다면, 시간이 더 오래걸릴 수 있습니다.

OverlayFS Driver

  • OverlayFS는 AUFS와 비슷한 원리로 동작하지만, 이미지 레이어에 계층이 없는 구조로 되어있습니다.
    (overlay2는 현재 지원되는 모든 Linux배포판에 대해 선호되는 스토리지 드라이버입니다.)
  • AUFS와 유사하게 (파일 변경점에 대해)lowedir(이미지 레이어)에 존재하는 file을 upperdir에 복사하여 사용합니다.
    • 그러나 AUFS와는 다르게 계층화된 레이어 구조가 아니기 때문에 복사할 파일을 찾는 과정이 AUFS보다 빠릅니다.
    • upperdir에는 container에서 발생한 변경 사항을 담고 있습니다(overlayfile 파일이 존재).
  • docker diff 명령어를 통해, lowerdir로부터 upperdir에 어떤 변화가 있었는지를 확인할 수 있습니다.
    • A: 추가됨
    • C: 변경됨
    • D: 삭제됨

도커에서의 데이터 관리

  • 기본적으로 도커 컨테이너 내부에서 생성된 모든 파일은 writable한 컨테이너 레이어에 저장됩니다.
  • 그러나 해당 컨테이너 레이어가 더 이상 존재하지 않게 되면, 데이터 또한 유지되지 않습니다.
  • 이러한 문제를 해결하기 위해 도커는 호스트 시스템에 파일을 저장할 수 있는 두 가지 옵션과 호스트 시스템의 메모리에 파일을 저장하는 한 가지 옵션을 제공하고 있습니다.

docker 마운트 타입

bind

-v </host/directory>:</container/directory>

  • 호스트가 선언한 디렉토리가 컨테이너에 마운트됩니다.
    • 사용자가 원하는 경로를 지정할 수 있으나, 디렉토리 경로가 분산되어 관리가 어려워질 수 있습니다.
    • 컨테이너에서 실행되는 프로세스를 통해 호스트 파일 시스템을 변경할 수 있습니다. 이는 호스트 보안에 영향을 미칠 수 있습니다.
  • :<ro 혹은 rw>을 붙여서 사용하여 '읽기 전용' or '쓰기 가능'의 권한을 설정할 수 있습니다.
    • ex) -v /host/name:/container/directory:ro

volume

-v <volume-name>:</container/directory>

  • Docker에서 관리하는 호스트 파일 시스템에 저장됩니다.
    • ex. 리눅스: /var/lib/docker/volumes/
    • 도커 공식 문서에서는 volume이 도커에서 데이터를 관리하는 가장 좋은 방법이라고 말하고 있습니다.
  • 커맨드
    • 볼륨 생성 : docker volume create <volume-name>
    • 볼륨 확인 : docker volume ls
    • 볼륨 정보 : docker volume inspect <volume-name>
    • 볼륨 삭제 : docker volume rm <volume-name>
  • :<ro 혹은 rw>을 붙여서 사용하여 '읽기 전용' or '쓰기 가능'의 권한을 설정할 수 있습니다.
    • ex) -v volume-name:/container/directory:ro

tmpfs

--tmpfs </container/directory>

  • 호스트의 시스템 메모리에 저장됩니다.

Reference

profile
AI Engineer : Lv 0
post-custom-banner

0개의 댓글