[docker] storage driver

하나의 docker 이미지는 여러 컨테이너에서 사용되며, 각 컨테이너는 데이터을 생성하거나 삭제하는 프로세스를 통해 원래의 이미지에서 변경된다. 원본 이미지를 유지하면서, 각 컨테이너마다 다른 데이터를 유지하기 위해서 도커에서는 '유니온 파일 시스템'을 사용한다. 

유니온 파일 시스템

: docker에서는 루트 파일 시스템을 read-only로 마운트하고, 그 read-only 파일시스템 위에 read-write 파일 시스템을 추가하여 union mount 한다. union mount를 지원하는 파일시스템을 union file system이라고 한다.

겹겹이 쌓인 여러개의 read-only 파일시스템이 있을 수 있으며, docker는 이들 파일시스템을 layer로써 생각한다. 

낮은 레이어에서 존재하는 파일이 업데이트 될 필요성이 있을때, 파일이 상위 레이어로 복사되고(새로운 레이어 생성), 변경사항은 복사본으로 이동한다. 

원본 이미지를 수정하는 대신 변경된 정보를 따로 저장하고, 원본 데이터와 변경된 정보를 조합해서 복원하는 식으로 데이터를 읽는다. 이 방식을 사용하면, 원본 이미지를 수정하지 않고, 각 컨테이너마다 다른 정보를 저장 할 수 있다.

Docker Storage Drivers

docker의 스토리지 드라이버는 docker 레이어 이미지를 각각의 union file system을 통해 구현한 것이다. 

Union File System(Technology)	Storage driver name
OverlayFS	overlay or overlay2
AUFS	aufs
Btrfs	btrfs
Device Mapper	devicemapper
VFS	vfs
ZFS	zfs

Backing File System

backing filesysystem은 docker 호스트의 로컬 저장 영역인 '/var/lib/docker'을 생성하는 데 사용되는 파일시스템을 참조한다.

docker 호스트의 로컬 스토리지 영역에 사용할 backing file system에 따라서 스토리지 드라이버를 결정한다.

예를 들어, 로컬에서 ext4 file system을 사용하려면, 가능한 storage driver는 overlay, overlay2, aufs가 된다.

일부 스토리지 드라이버는 다른 backing filesystem에 상단에서 작동할 수 있다. 

그러나, 나머지 스토리지 드라이버는 스토리지 드라이버와 동일한 backing filesystem을 요구한다. 

예를 들어, overlay는 ext4, xfs에서 작동할 수 있지만, btrfs는 btrfs에서만 작동한다.

그리고 일부 스토리지 드라이버는 특정 backing filesystem에서 실행될 수 없다.

예를 들어, aufs는 brtfs, aufs, eCryptfs 상단에서는 사용할 수 없다.

Storage driver	주로 사용되는 backing filesystem	사용 불가능한 backing filesystem
overlay	ext4 xfs	btrfs aufs overlay zfs eCryptfs
overlay2	ext4 xfs	btrfs aufs overlay zfs eCryptfs
aufs	ext4 xfs	btrfs aufs eCryptfs
btrfs	btrfs only	N/A
devicemapper	direct-lvm	N/A
vfs	debugging only	N/A
zfs	zfs only	N/A

aufs

- 최초의 스토리지 드라이버

- AUFS가 mainline 커널에 포함되어 있지 않아 ubuntu, debian 에서만 지원

- 안정적

- production-ready

- 빠른 컨테이너 시작 시간

- 효율적인 스토리지, 메모리 사용

- 좋은 use case : PaaS^[각주:1]-type 작업

- 나쁜 use case : 높은 write 활동

devicemapper

- centos, redhat 포함 범용 스토리지 드라이버

- RHEL 및 CentOS에서 실행하는 상업적으로 지원되는 도커 엔진(CS-Engine)은 devicemapper를 사용해야함

- mainline 커널에 포함 (커널 2.6.9 버전 이후)

- thin provisioning 기능

- 스냅샷 기능

- direct-lvm모드는 block device를 사용하여 thin pool 생성

devicemapper(loop) 

- 좋은 use case : lab 테스팅

- 나쁜 use case : production 배포, 성능

devicemapper(direct-lvm) 

- 좋은 use case : production 배포

- 나쁜 use case : PaaS-type 작업

overlay

- 최신 스토리지 드라이버

- 단순한 디자인

- mainline 커널에 포함 (커널 3.18버전 이후)

- 커널 4.0 이전 버전에서는 overlay, 커널 4.0 이상에서는 overlay2

- 대부분의 Linux 파일 시스템에서 작동하지만, producrtion 환경에서는 ext4 권장

- aufs, devicemapper 보다는 덜 안정적이지만, 더 빠름

- 효율적인 메모리 사용

- 파일 및 디렉토리 삭제시에 '화이트 아웃'파일이 생성되어 삭제할 파일의 존재를 가린다.

- 좋은 use case : lab 테스팅

- 나쁜 use case : container 변경이 잦을때

1. 서비스로서의 플랫폼(PaaS): 서비스로서의 플랫폼을 사용하면 조직은 기본 인프라(일반적으로 하드웨어와 운영 체제)를 관리할 필요가 없어 애플리케이션 개발과 관리에 집중할 수 있습니다. 즉, 애플리케이션 실행과 관련된 리소스 구매, 용량 계획, 소프트웨어 유지 관리, 패치 또는 다른 모든 획일적인 작업에 대한 부담을 덜어 더욱 효율적이 되도록 해줍니다. [본문으로]