DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

영구 데이터 관리: 적절한 Docker 볼륨 유형 선택

Docker 명명된 볼륨, 바인드 마운트, tmpfs 마운트를 영구 데이터, 개발, 임시 저장소 측면에서 비교합니다.

영구 데이터 관리: 적절한 Docker 볼륨 유형 선택

Docker 컨테이너는 교체 가능하도록 설계되었습니다. 컨테이너의 쓰기 가능 레이어에 기록된 데이터는 단순한 중지/시작 시에는 유지될 수 있지만, 해당 컨테이너에 종속됩니다. 컨테이너를 제거하거나 다시 생성하면 데이터도 함께 사라집니다. 이는 데이터베이스 파일, 업로드된 자산, 큐 또는 잃어버리면 속상할 모든 것에 적합하지 않은 위치입니다.

Docker는 세 가지 일반적인 마운트 옵션을 제공합니다: 명명된 볼륨, 바인드 마운트, tmpfs 마운트. 각각 다른 문제를 해결합니다. 프로덕션 Postgres 컨테이너, 로컬 Node.js 개발 컨테이너, 임시 비밀번호를 위한 스크래치 디렉토리는 모두 동일한 스토리지 패턴을 사용해서는 안 됩니다.

Docker 스토리지 메커니즘의 개요

Docker는 원격 스토리지를 위해 볼륨 드라이버를 사용할 수 있지만, 대부분의 일상적인 결정은 Docker Engine 또는 호스트 커널이 관리하는 이 세 가지 마운트 유형으로 귀결됩니다.

1. 명명된 볼륨: 프로덕션 표준

명명된 볼륨은 대부분의 프로덕션 환경에서 영구 데이터 저장을 위한 선호 메커니즘입니다. 이는 Docker Engine에 의해 완전히 관리되며, 사용자로부터 기본 호스트 파일 시스템 경로를 추상화합니다.

특징 및 장점

  • 영속성: 데이터는 이를 생성한 컨테이너가 제거되어도 유지됩니다.
  • 이식성: 컨테이너 정의가 하드코딩된 호스트 경로에 의존하지 않으므로, 머신 간 배포 이동이 더 쉬워집니다.
  • 관리: 데이터는 일반적으로 Linux에서 /var/lib/docker/volumes/ 아래에 있는 Docker의 볼륨 영역에 저장됩니다. docker volume ls, docker volume inspect 및 백업 작업으로 관리합니다.
  • 백업 및 마이그레이션: 도우미 컨테이너, 파일 시스템 스냅샷 또는 스토리지 수준 백업을 사용하면 명명된 볼륨을 간단히 백업할 수 있습니다. 데이터베이스의 경우 일관성이 중요할 때 데이터베이스 인식 백업 도구를 사용하는 것이 좋습니다.

사용 사례

  • 실제 백업 및 복원 프로세스가 있는 데이터베이스.
  • 애플리케이션 상태 및 중요한 구성 파일.
  • 동일한 호스트의 컨테이너 간에 공유해야 하는 데이터.

실제 예: 명명된 볼륨 생성 및 연결

# 1. 볼륨 생성
docker volume create db_storage

# 2. 필요한 경로에 볼륨을 마운트하여 컨테이너 실행
docker run -d \
  --name postgres_db \
  -e POSTGRES_PASSWORD=securepass \
  --mount source=db_storage,target=/var/lib/postgresql/data \
  postgres:16

# 3. 볼륨 세부 정보 확인
docker volume inspect db_storage

2. 바인드 마운트: 로컬 개발 및 호스트 상호 작용

바인드 마운트를 사용하면 호스트 머신의 임의 파일 또는 디렉토리를 컨테이너 내부로 매핑할 수 있습니다. 명명된 볼륨과 달리 바인드 마운트는 전적으로 호스트 머신의 정확한 디렉토리 구조에 의존합니다.

특징 및 제한 사항

  • 즉시 업데이트: 주요 이점은 실시간 동기화입니다. 호스트에서 변경된 사항(예: IDE에서 코드 업데이트)은 실행 중인 컨테이너 내부에 즉시 반영되므로 개발 워크플로우에 이상적입니다.
  • 비이식성: 바인드 마운트는 호스트에 종속됩니다. 지정된 호스트 경로가 다른 머신에 존재하지 않으면 Docker는 구문 및 컨텍스트에 따라 실패하거나 디렉토리를 생성할 수 있습니다.
  • 권한 문제: 소유권 및 권한(UID/GID)은 특히 비루트 사용자로 컨테이너를 실행할 때 자주 마찰을 일으킵니다. 컨테이너 사용자는 호스트 경로에 대한 읽기/쓰기 권한이 있어야 합니다.
  • 보안 위험: 호스트 디렉토리를 노출하면 컨테이너 프로세스가 손상되거나 마운트가 실수로 쓰기 가능한 경우 위험할 수 있습니다.

사용 사례

  • 로컬 개발: 라이브 디버깅 또는 핫 리로딩을 위한 소스 코드 마운트.
  • 구성 파일: 특정 호스트 구성 또는 자격 증명(예: /etc/timezone) 주입.
  • 호스트 리소스 액세스: 로깅 또는 진단을 위한 로컬 디렉토리 마운트.

실제 예: 개발 워크플로우

현재 작업 디렉토리($(pwd))를 컨테이너 내부의 애플리케이션 소스 경로에 마운트하고, 구성 파일에 대해 읽기 전용으로 설정합니다.

# 개발을 위해 현재 디렉토리 마운트
docker run -it --rm \
  --name dev_server \
  --mount type=bind,source=$(pwd)/src,target=/app/src \
  --mount type=bind,source=$(pwd)/config/app.conf,target=/etc/app/app.conf,readonly \
  node:22

팁: 특히 볼륨 유형을 혼합할 때는 명확성을 위해 항상 --mount 구문(type=bind, source=..., target=...)을 사용하십시오. 간단한 바인드 마운트의 경우 짧은 -v 구문(/host/path:/container/path)도 여전히 일반적입니다.

3. Tmpfs 마운트: 고속, 비영구 스토리지

tmpfs 마운트는 메모리 기반 스토리지에 데이터를 저장합니다. 많은 임시 워크로드에 빠르지만 데이터는 디스크에 유지되지 않습니다. 컨테이너가 중지되거나 호스트 시스템이 재부팅되면 데이터가 사라집니다.

특징 및 제한 사항

  • 속도: 데이터가 메모리 기반 스토리지에 있기 때문에 일반적으로 빠릅니다.
  • 비영속성: 데이터는 완전히 휘발성입니다. 디스크에 남아 있어서는 안 되는 매우 민감한 데이터에 유용합니다.
  • 리소스 제한: 호스트의 사용 가능한 메모리에 의해 제한됩니다. 대규모 데이터 세트에는 적합하지 않습니다.
  • 플랫폼 범위: tmpfs는 Linux 기능입니다. Docker Desktop은 VM 내에서 Linux 컨테이너를 실행할 수 있으므로 기본 Linux 호스트와 동일하게 동작하지 않습니다.

사용 사례

  • 안전하게 사라질 수 있는 임시 세션 파일 또는 캐시 파일.
  • 캐싱 메커니즘(예: Redis 임시 파일).
  • 아티팩트를 실행 직후 즉시 파괴해야 하는 보안에 민감한 작업.

실제 예: 임시 파일 캐싱

# /app/cache 디렉토리에 tmpfs를 사용하여 컨테이너 실행
docker run -d \
  --name fast_cache \
  --mount type=tmpfs,destination=/app/cache,tmpfs-size=512m \
  my_web_server:latest

비교 요약 및 결정 매트릭스

올바른 볼륨 유형을 선택하는 것은 전적으로 필요한 영속성, 이식성 및 액세스 요구 사항에 따라 달라집니다.

기능 명명된 볼륨 바인드 마운트 Tmpfs 마운트
영속성 높음 (Docker 관리) 높음 (호스트 FS에 따라 다름) 없음 (휘발성, RAM만)
이식성 우수 낮음 (호스트 경로 종속) 해당 없음 (Linux 호스트만)
성능 일반적으로 양호, 백업 스토리지에 따라 다름 가변적, 호스트 경로 및 파일 시스템 공유에 따라 다름 일반적으로 임시 I/O에 가장 빠름
데이터 위치 Docker 내부 디렉토리 특정 호스트 디렉토리 호스트 메모리 (RAM)
관리 Docker CLI 도구 (docker volume) 호스트 OS에서 관리 자동
주요 사용 사례 프로덕션 데이터, 데이터베이스, 공유 스토리지 로컬 개발, 구성 주입 캐싱, 세션 관리, 안전한 임시 데이터

데이터 관리를 위한 모범 사례

영구 스토리지 표준화

영속성이 필요한 대부분의 단일 호스트 프로덕션 컨테이너의 경우 명명된 볼륨이 깔끔한 기본값입니다. 하드코딩된 호스트 경로를 피하고 컨테이너 정의를 재사용하기 쉽게 만듭니다. 오케스트레이션 환경에서는 로컬 Docker 볼륨으로 충분하다고 가정하지 말고 플랫폼의 영구 볼륨 시스템을 사용하십시오.

파일 권한 처리

바인드 마운트를 사용할 때 권한 불일치는 일반적인 골칫거리입니다. 컨테이너 내부의 사용자가 호스트에서 다른 사용자/그룹이 소유한 볼륨 경로에 쓰려고 하면 작업이 실패합니다.

컨테이너 내부의 사용자가 마운트된 파일의 소유권과 일치하도록 하거나 호스트 디렉토리를 의도적으로 조정하십시오. 모든 권한 문제를 루트 컨테이너로 해결하지 마십시오. 개발자 머신 전체에 루트 소유의 빌드 아티팩트를 생성할 때까지는 작동합니다.

보안을 위한 읽기 전용 마운트 사용

컨테이너가 수정해서는 안 되는 구성 파일, 정적 리소스 또는 자격 증명을 마운트하는 경우 항상 볼륨을 읽기 전용으로 지정하십시오. 이는 중요한 파일의 실수로 인한 삭제 또는 수정을 방지합니다.

# 읽기 전용 마운트 예시
docker run -d \
  --mount type=bind,source=/etc/my_key.pem,target=/app/key.pem,readonly \
  my_app

호스트 루트 바인드 마운트 방지

민감하거나 큰 루트 디렉토리(예: -v /:/host)를 바인딩하지 않는 것이 좋습니다. 이 관행은 심각한 보안 취약점을 만들고 의도하지 않은 부작용으로 인해 컨테이너 관리를 불안정하게 만들 수 있습니다.

볼륨 정리

Docker는 컨테이너가 제거될 때 명명된 볼륨을 자동으로 제거하지 않습니다. 익명 볼륨은 컨테이너가 반복적으로 다시 생성될 때 축적될 수도 있습니다. 특히 공유 호스트에서는 정리하기 전에 검사하십시오:

docker volume ls
docker system df -v

# 필요하지 않은지 확인한 후 사용하지 않는 로컬 볼륨 제거
docker volume prune

백업 및 복원이 선택을 주도해야 함

마운트 유형은 결정의 절반에 불과합니다. 나머지 절반은 나쁜 날에 데이터를 어떻게 복원할 것인지입니다.

일반 파일을 저장하는 명명된 볼륨의 경우 도우미 컨테이너가 tar 아카이브를 생성할 수 있습니다:

docker run --rm \
  --mount source=db_storage,target=/data,readonly \
  --mount type=bind,source=$(pwd),target=/backup \
  alpine:3.20 \
  tar -czf /backup/db_storage.tar.gz -C /data .

해당 패턴은 정적 파일이나 중지된 서비스에 적합합니다. 데이터베이스가 일관된 상태가 아니면 라이브 데이터베이스에는 충분하지 않습니다. Postgres, MySQL, MongoDB 및 유사한 시스템의 경우 데이터베이스 네이티브 백업 도구 또는 데이터베이스와 조정된 스토리지 스냅샷을 사용하십시오. 실행 중인 데이터베이스 디렉토리의 tarball은 백업처럼 보일 수 있지만 복원 중에 실패할 수 있습니다.

명명된 볼륨 복원은 반대 개념입니다:

docker volume create db_storage_restored
docker run --rm \
  --mount source=db_storage_restored,target=/data \
  --mount type=bind,source=$(pwd),target=/backup,readonly \
  alpine:3.20 \
  tar -xzf /backup/db_storage.tar.gz -C /data

필요하기 전에 이를 테스트하십시오. 한 번도 복원된 적이 없는 볼륨 전략은 전략이 아니라 추측입니다.

실제 프로젝트를 위한 Compose 예제

Compose에서 명명된 볼륨은 간단하고 읽기 쉽습니다:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

로컬 개발의 경우 호스트의 소스 변경 사항이 컨테이너 내부에 나타나기를 원하기 때문에 바인드 마운트가 일반적으로 더 좋습니다:

services:
  app:
    image: node:22
    working_dir: /app
    command: npm run dev
    volumes:
      - ./src:/app/src
      - ./package.json:/app/package.json:ro

package.json의 읽기 전용 플래그에 주목하십시오. 작은 습관이지만 컨테이너가 읽기만 해야 하는 파일을 다시 쓰는 것을 방지합니다.

Compose에서 tmpfs의 경우:

services:
  worker:
    image: my-worker:latest
    tmpfs:
      - /run/secrets:size=64m

스크래치 데이터에 사용하고 충돌 후 검사할 것으로 예상되는 항목에는 사용하지 마십시오.

일반적인 실패 모드

가장 일반적인 Docker 스토리지 실패는 잘못된 경로를 마운트하는 것입니다. 애플리케이션이 /var/lib/mysql에 쓰지만 이미지가 /var/lib/mysql/data를 예상하는 경우 컨테이너는 계속 실행되고 데이터를 다시 생성할 때 데이터가 사라집니다. 항상 이미지 문서를 확인하고 실행 중인 컨테이너를 검사하십시오:

docker inspect my_container --format '{{json .Mounts}}'

또 다른 일반적인 실패는 익명 볼륨과 명명된 볼륨을 혼동하는 것입니다. 이미지가 VOLUME을 선언하고 명명된 볼륨을 제공하지 않으면 Docker는 익명 볼륨을 생성할 수 있습니다. 데이터는 유지되지만 이름이 의미가 없어 정리 또는 마이그레이션 중에 사람들이 놓칠 수 있습니다.

권한은 다음 골칫거리입니다. 바인드 마운트된 디렉토리가 macOS에서 UID 501 또는 Linux에서 UID 1000이 소유하지만 컨테이너 프로세스가 UID 999로 실행되는 경우 쓰기가 실패할 수 있습니다. 명명된 볼륨은 종종 호스트 경로 혼동을 피하지만 볼륨 내부의 소유권은 여전히 중요합니다. 오류가 사라질 때까지 권한을 변경하는 대신 의도적으로 소유권을 초기화하십시오.

마지막으로 로컬 Docker 볼륨은 로컬이라는 점을 기억하십시오. 자체적으로 컨테이너를 다른 호스트로 따라가지 않습니다. Swarm, Kubernetes, Nomad 또는 클라우드 컨테이너 플랫폼에서 영구 스토리지에는 플랫폼 인식 볼륨, 원격 스토리지 또는 해당 환경에 맞게 설계된 데이터베이스 서비스가 필요합니다.

도구가 지원하는 경우 중요한 볼륨에 레이블을 지정하고 각 볼륨을 소유한 서비스를 문서화하십시오. 명확한 소유권은 정리 스크립트가 단순히 사용되지 않는 것처럼 보이는 데이터를 삭제하는 것을 방지합니다.

간단한 결정 규칙

확실하지 않을 때는 누가 데이터를 소유하는지 물어보십시오. Docker가 소유하고 호스트 경로가 중요하지 않으면 명명된 볼륨을 사용하십시오. 호스트의 사람이나 외부 도구가 소유하면 바인드 마운트를 사용하십시오. 컨테이너가 종료된 후 아무도 소유하지 않아야 하면 tmpfs를 사용하십시오.

이 규칙은 대부분의 경우를 포착합니다. 데이터베이스 디렉토리는 컨테이너 소유이므로 명명된 볼륨이 적합합니다. 소스 코드는 개발자 소유이므로 바인드 마운트가 적합합니다. 하나의 작업을 위한 임시 복호화 디렉토리는 사라져야 하므로 tmpfs가 적합합니다. 혼란스러운 경우는 공유 업로드, 로그 및 생성된 보고서입니다. 이러한 경우 마운트 유형을 선택하기 전에 컨테이너 플랫폼, 호스트 또는 외부 스토리지 서비스 중 실제 소유자가 누구인지 결정하십시오.

요약하면 컨테이너 소유의 영구 데이터에는 명명된 볼륨을, 호스트 경로 자체가 워크플로우의 일부인 경우 바인드 마운트를, 빠르고 일회용이어야 하는 데이터에는 tmpfs를 사용하십시오. 그런 다음 각 중요한 볼륨이 어떻게 백업 및 복원되는지 기록하십시오. 복원 테스트 없는 영속성은 마운트 지점이 있는 희망에 불과합니다.