[Docker] 도커 볼륨 구조

도커 볼륨 구조

도커(Docker) 볼륨(Volume)은 컨테이너의 파일시스템 외부에 위치하는, 데이터를 영구적으로 저장하기 위한 특별한 메커니즘임.

도커 볼륨은 컨테이너가 재시작되거나 삭제되더라도 데이터를 유지할 수 있고, 여러 컨테이너 간에 손쉽게 데이터 공유도 가능함.

 

도커의 파일시스템

1. 레이어(Layer) 기반 이미지 구조

도커 이미지는 여러 읽기 전용 레이어(RO layer)의 합으로 이루어지며, 컨테이너를 실행할 때 읽기/쓰기(RW) 레이어가 추가됨.

컨테이너 내부에서 파일이 변경되면 RW 레이어에만 해당 변경 사항이 저장되고, 원본 이미지는 변경되지 않음.

이 RW 레이어는 일반적으로 일시적(휘발성)이기 때문에 컨테이너가 삭제되면 데이터도 함께 삭제됨.

 

2. 영속 데이터 문제

데이터베이스나 로그, 업로드 파일처럼 영구적으로 보관해야 할 데이터는 컨테이너가 재시작되거나 삭제되더라도 없어지지 않아야 함.

이를 위해 도커는 볼륨(Volume)과 바인드 마운트(Bind Mount)를 제공함.

 

바인드 마운트: 호스트의 특정 디렉터리를 컨테이너 내부에 연결

볼륨: 도커가 관리하는 별도의 디렉터리를 컨테이너 내부에 연결

 

도커 볼륨의 개념

1. 볼륨이란?

도커가 직접 관리하는 스토리지 영역으로, 호스트에 실제 디렉터리가 존재하지만 도커 데몬이 추상화하여 운영함.

볼륨은 컨테이너와 독립된 라이프사이클을 가지므로, 컨테이너를 삭제해도 볼륨의 데이터는 사라지지 않음.

명시적으로 제거하지 않는 한임.

 

2. 볼륨 관련 명령어

생성: docker volume create [OPTIONS] [볼륨이름]

리스트: docker volume ls

정보 조회: docker volume inspect <볼륨이름>

삭제: docker volume rm <볼륨이름>

# 예시
docker volume create mydata
docker run -d \
  -v mydata:/var/lib/mysql \
  --name mysql mysql:latest

위 예시는 mydata 볼륨을 /var/lib/mysql에 마운트하여, MySQL 데이터가 영구적으로 저장되도록 함.

 

도커 볼륨 구조

1. 호스트 파일시스템 상의 위치

리눅스 환경에서 기본적으로 볼륨은 /var/lib/docker/volumes/ 디렉터리 아래에 하위 폴더 형태로 생성됨.

예를 들면, /var/lib/docker/volumes/<볼륨ID>/_data/

이 위치는 도커 엔진 설정에 따라 달라질 수 있으나, 기본적으로 위 경로를 사용함.

각각의 볼륨은 고유한 UUID-like 폴더명을 가짐.

docker volume create 명령으로 볼륨을 생성하면, 해당 볼륨 이름을 별도 메타데이터로 관리하고, 내부적으로는 UUID 디렉터리를 매핑함.

볼륨 안에 실제 데이터는 _data 디렉터리 아래에 저장됨.

 

예시는 다음과 같음.

/var/lib/docker/volumes/
└── <볼륨ID_혹은_이름>/
    ├── _data/
    └── ...

 

2. 볼륨 메타데이터

docker volume inspect <볼륨이름>을 통해 보면, 아래와 같은 정보를 확인할 수 있음.

"CreatedAt": 볼륨 생성 시각

"Driver": 볼륨 드라이버 (기본값은 local)

"Mountpoint": 호스트 파일시스템 상의 실제 경로. 예: /var/lib/docker/volumes/<볼륨ID>/_data

"Labels": 사용자 정의 라벨

"Scope": 범위 (전역(Global) 또는 로컬(Local))

내부적으로 도커 데몬은 이 정보를 바탕으로 볼륨을 마운트할 위치 등을 관리함.

 

3. 볼륨 드라이버(Volume Driver)

도커 볼륨은 드라이버 개념을 통해 확장 가능함.

기본 드라이버는 local이며, 호스트의 로컬 디스크를 사용함.

외부 스토리지(예: NFS, GlusterFS, Ceph, AWS EBS, Azure Disk, GCP Persistent Disk 등)를 연결하려면 해당 스토리지에 맞는 플러그인을 설치하고, 해당 드라이버를 사용하면 됨.

예를 들면, docker volume create --driver rexray/ebs my-ebs-volume

 

볼륨 마운트 방식

1. 익명 볼륨(Anonymous Volume)

docker run -v /data 같이 볼륨 이름을 명시하지 않고 마운트할 경우, 자동으로 임의의 볼륨 이름(또는 ID)이 생성됨.

컨테이너가 삭제되어도 볼륨 자체는 남아 있지만, 이름이 없기 때문에 추적하기가 어려워, 보통은 적극적으로 사용되지 않음.

 

2. 명명된 볼륨(Named Volume)

docker run -v mydata:/data처럼 이름(또는 프리픽스)을 정해서 사용하는 방식임.

여러 컨테이너가 동일한 볼륨 이름을 통해 데이터를 공유할 수 있음.

 

3. Docker Compose 와의 연계

docker-compose.yml 파일에 volumes 섹션을 정의하고, 각 서비스 컨테이너에서 volumes 절을 통해 마운트할 수 있음.

version: '3'
services:
  db:
    image: mysql
    volumes:
      - dbdata:/var/lib/mysql

volumes:
  dbdata:
    driver: local

docker-compose up -d 시 dbdata라는 이름의 볼륨이 생성되며, db 컨테이너에서 /var/lib/mysql 디렉터리로 마운트됨.

 

볼륨 vs 바인드 마운트

1. 생성/관리 주체

볼륨 : 도커가 직접 관리

바인드 마운트 : 호스트의 디렉터리를 직접 지정

 

2. 호스트 경로

볼륨 : /var/lib/docker/volumes/.../_data

바인드 마운트 : 사용자가 지정한 경로

 

3. 라이프 사이클

볼륨 : 컨테이너와 독립적 (명시 삭제 시에만 사라짐)

바인드 마운트 : 호스트 디렉터리에 직접 종속, 디렉터리를 삭제하면 데이터도 사라짐.

 

4. 이식성

볼륨 : 도커가 추상화를 제공하므로 더 높은 이식성

바인드 마운트 : 호스트 경로 의존적 (서버 환경이 바뀌면 경로도 바뀔 수 있음)

 

5. 접근 권한

볼륨 : 도커가 UID/GID를 내부적으로 관리, 보안 설정 가능

바인드 마운트 : 호스트의 파일 권한 직접 적용, 관리가 까다로울 수 있음

 

일반적으로 도커가 관리하는 볼륨을 사용하면 데이터 이식성, 보안, 라이프사이클 관리를 보다 일관성 있게 할 수 있음.

개발 환경에서 소스 코드 변경을 실시간으로 반영해야 할 경우에는 바인드 마운트를 사용해 호스트 디렉터리와 컨테이너 디렉터리를 직접 연결하는 경우가 많음.

 

고급 기능 및 활용

1. 볼륨 드라이버 플러그인

NFS, GlusterFS, Ceph, Amazon EBS, DigitalOcean Block Storage 등 다양한 외부 스토리지를 도커 볼륨으로 사용할 수 있는 플러그인들이 존재함.

예를 들어,

docker volume create \
  --driver local \
  --opt type=nfs \
  --opt o=addr=1.2.3.4,rw \
  --opt device=:/exported/path \
  my-nfs-volume

이렇게 생성한 볼륨을 컨테이너에 마운트하면, 외부 NAS나 분산 파일시스템을 통한 영구 스토리지로 활용할 수 있음.

 

2. 볼륨 컨테이너 (옛 방식)

도커 초기에는 볼륨을 직접 사용하는 대신, "볼륨 전용 컨테이너(volume container)"를 만들어 다른 컨테이너들이 --volumes-from으로 가져다 쓰는 방식이 있었음.

현재는 볼륨 컨테이너보다, 명명된 볼륨을 직접 사용하는 것을 권장함.

 

3. 읽기 전용 볼륨 (Read-only Volume)

-v mydata:/data:ro 형태로 마운트하면 읽기 전용 볼륨이 됨.

컨테이너 내부에서 파일을 변경하려 하면 권한 오류가 발생함.

보안이나 무결성이 중요한 상황에서 유용함.

 

4. Windows/Mac 환경에서의 볼륨

Docker Desktop을 사용하는 Windows/Mac 환경에서는 내부적으로 Hyper-V 혹은 WSL2(Windows), HyperKit(Mac) 등 가상화 계층이 존재함.

볼륨은 가상 머신 내부의 /var/lib/docker/volumes에 매핑되지만, Docker Desktop이 이를 추상화하여 관리함.

일반적으로 사용자는 명령어 수준에서 동일한 방식으로 볼륨을 다룰 수 있지만, 내부적으로는 OS/가상화 환경별 차이가 존재함.

 

볼륨 관리 및 모범 사례

1. 불필요한 볼륨 정리

docker volume prune 명령을 사용해 더 이상 사용되지 않는 볼륨을 정리함.

디스크 공간을 절약하고, 혼란을 방지할 수 있음.

 

2. 볼륨 네이밍 전략

프로덕션 환경에서는 서비스명, 기능명 등 의미 있는 이름을 사용해 볼륨을 생성함.

예를 들어, docker volume create --name myapp-db-data

 

3. 백업 및 복원

/var/lib/docker/volumes 아래의 _data 디렉터리를 백업하는 방식으로 전체 볼륨을 백업할 수 있음.

또는, docker run --rm -v mydata:/data -v $(pwd):/backup busybox tar cvf /backup/mydata.tar /data 와 같이 tar으로 패킹할 수도 있음.

 

4. 보안 고려

컨테이너 내부 사용자/권한과 호스트 권한이 달라질 수 있으므로, UID/GID를 맞추거나 USER 지시어 등을 통해 관리가 필요함.

민감한 데이터를 다루는 볼륨은 외부 스토리지(암호화 파일시스템 등)와 연동하거나, 도커 시크릿/도커 스웜/Kubernetes 시크릿 등과 조합해 사용하는 것을 고려함.

 

5. 도커 오케스트레이션 환경(Kubernetes, Swarm)에서의 볼륨

쿠버네티스에서는 PV(Persistent Volume)와 PVC(Persistent Volume Claim)를 사용하여 영구 스토리지와 파드를 연결함.

도커 스웜에서는 도커 볼륨 플러그인을 사용해 여러 노드에서 공유 가능한 네트워크 스토리지(NFS, Ceph 등)를 구성할 수 있음.

 

정리

1. 구조

도커 볼륨은 기본적으로 호스트의 /var/lib/docker/volumes 디렉터리 아래에 UUID-like 디렉터리로 생성되며, _data 디렉터리에 실제 파일이 저장됨.

 

2. 관리

도커 데몬이 메타데이터를 추적하여, 컨테이너와 별개 라이프사이클로 동작함으로써 영속적 데이터 보관이 가능함.

 

3. 드라이버

기본적으로 local 드라이버를 사용하지만, 플러그인을 통해 외부 스토리지도 추상화하여 사용할 수 있음.

 

4. 마운트 방식

컨테이너 실행 시 -v 볼륨이름:마운트경로 형태로 연결하며, Docker Compose나 쿠버네티스/PV/PVC와 같은 상위 도구로 더 쉽게 볼륨을 관리할 수 있음.

 

5. 장점

호스트 디렉터리보다 이식성과 관리 편의성이 높고, 컨테이너가 사라져도 데이터가 안전하게 남음.

 

6. 운영 관점

백업, 정리, 보안, 권한 설정, 고가용성 스토리지 연동 등의 요구사항을 사전에 계획하여 구성해야 함.

 

도커 볼륨을 적절히 사용하면 데이터 영속성과 컨테이너화의 장점을 동시에 누릴 수 있음.

특히 데이터베이스, 로그, 업로드 파일, 캐시 데이터 등 다양한 용도에 유용하며, 프로덕션 환경에서는 외부 스토리지와 연동하여 고가용성과 확장성을 확보하는 것이 일반적임.