[CKA] Docker Storage와 Volume
Docker Storage와 Volume의 핵심 개념과 구성 방법, 실습 풀이를 정리합니다.
Storage in Docker
Docker가 데이터를 저장하는 위치와 방법, 그리고 컨테이너의 파일 시스템을 관리하는 방법입니다
Docker가 로컬 파일 시스템에 데이터를 저장하는 방법부터 살펴봅시다. 시스템에 Docker를 설치하면 /var/lib/docker/에 이 폴더 구조가 생성됩니다.
해당 디렉토리에는 aufs, 컨테이너, 이미지, 볼륨 등 여러 폴더가 있습니다. 도커가 default로 모든 데이터를 저장하는 곳입니다.
Default로 저장되는 데이터들은 일반적으로 Docker 호스트에서 실행되는 이미지 및 컨테이너와 관련된 파일을 의미합니다. 예를 들어 컨테이너와 관련된 모든 파일은 컨테이너 폴더 아래에 저장되고 이미지와 관련된 파일은 이미지 폴더 아래에 저장됩니다.
도커 컨테이너에 의해 생성된 모든 볼륨은 볼륨 폴더 아래에 생성됩니다.
Layered Architecture
또한 이미지와 파일이 어떻게 저장되는지는 Docker의 layer를 살펴보아야 합니다.
- 기본 구조
이미지 레이어 구성
- Base Layer: 최하단에 위치한 우분투와 같은 기본 운영체제 레이어
- 중간 레이어:
- 필요한 패키지
- 애플리케이션 종속성
- 소스 코드
- Top Layer: 애플리케이션 entry point
특징
- 모든 레이어는 읽기 전용(Read-Only)입니다.
- 각 레이어는 이전 레이어로부터의 변경사항만 포함
- 레이어 수정은 새로운 빌드를 통해서만 가능
- 레이어 생성 및 저장
생성 방식
- 각 Dockerfile 명령어마다 새로운 레이어 생성:
- RUN 명령어
- COPY 명령어
- ADD 명령어
저장 구조
- 저장 위치:
/var/lib/docker/overlay2/(기본 경로) - 식별 체계: 각 레이어는 고유한 해시 ID 보유
- 공유 시스템: 동일한 레이어는 여러 이미지 간 공유 가능
-
컨테이너 실행 구조
컨테이너 레이어 -
기본 구성:
- 읽기 전용 이미지 레이어 스택
- 최상단의 읽기-쓰기 가능한 컨테이너 레이어
-
작동 방식:
docker run명령어 실행 시 컨테이너 생성- 모든 런타임 변경사항은 최상단 컨테이너 레이어에 저장
-
레이어 아키텍처의 장점
-
성능 최적화
- 빌드 캐시를 활용한 빌드 시간 단축
- 레이어 재사용을 통한 빌드 효율성 증가
-
리소스 효율성
- 레이어 공유를 통한 저장 공간 절약
- 효율적인 이미지 배포 가능
-
관리 용이성
- 체계적인 버전 관리 가능
- 레이어 단위의 세분화된 제어 가능
-
모범 사례
-
레이어 최적화
- 관련 명령어 통합으로 레이어 수 최소화
- 불필요한 파일 제거로 레이어 크기 최적화
-
캐시 활용
- 자주 변경되는 레이어는 Dockerfile 하단에 배치
- 빌드 캐시 효율적 활용을 위한 명령어 구성
정리하면 Docker run으로 실행하게 되면 Docker에서 앞서 레이어를 기반으로 새로운 컨테이너를 만들고 이미지 레이어 위에 쓰기 가능한 새 레이어를 만들게 되는데, 이러한 레이어를 컨테이너 레이어라고 지칭하며 모든 런타임 변경사항이 저장되게 됩니다.
writeable layer는 애플리케이션이 작성한 로그 파일, 컨테이너가 생성한 임시 파일 또는 해당 컨테이너에서 사용자가 수정한 파일과 같이 컨테이너가 생성한 데이터를 저장하는 데 사용됩니다. 컨테이너가 살아있는 동안만 유효하며, 소멸하면 변경 사항또한 마찬가지로 모두 소멸됩니다.
- 이미지 레이어의 특성
- 이미지 레이어는 읽기 전용(Read-only)
- 여러 컨테이너가 동일한 이미지 레이어를 공유 가능
- 애플리케이션 코드는 이미지 레이어의 일부가 됨
- Copy-on-Write 메커니즘
- 컨테이너에서 파일 수정 시:
- Docker가 자동으로 읽기-쓰기(Read-Write) 레이어에 파일 복사본 생성
- 복사된 파일을 읽기-쓰기 레이어에서 수정
- 이후 모든 수정사항은 복사본에 적용
- 이미지 변경 방법
- 이미지 자체의 변경은 불가능
- 소스 코드 수정 후
docker build명령어로 새로운 이미지를 빌드해야 함 - 새로 빌드하기 전까지는 원본 이미지가 그대로 유지됨
이 구조의 장점:
- 이미지의 일관성 유지
- 효율적인 저장공간 활용 (레이어 공유)
- 안전한 파일 수정 (원본 보존)
Volumes
컨테이너를 제거하면 컨테이너 레이어에 저장된 모든 데이터도 삭제됩니다.
볼륨을 지정하지 않는다면 익명 볼륨으로 생성되어, 운영상에서 앱에 적용한 변경 사항과 우리가 만든 새 임시 파일 또한 제거됩니다.
이러한 데이터를 보존하기 위해선 persistent volume이라고 불리는 네임드 볼륨(명명된 볼륨)을 추가하여 컨테이너에 추가할 수 있습니다.
- 볼륨 생성 및 관리
# 볼륨 생성
docker volume create data_volume
# 볼륨 위치 확인
ls -l /var/lib/docker/volumes/
# 볼륨 목록 조회
docker volume ls
docker volume create data_volume 을 사용하여 볼륨을 생성하면 Docker에서 관리하는 파일시스템으로 data_volume이라는 명명된 새로운 볼륨이 생성됩니다.
- Docker가 관리하는 볼륨을 사용
docker run 커맨드를 사용하여 docker 컨테이너를 실행할 때 이와 같이 -v 옵션을 사용하여 docker containers rewrite 레이어 내부에 이 볼륨을 마운트할 수 있습니다
# 기존 볼륨 사용
docker run -v data_volume:/var/lib/mysql mysql
# 새 볼륨 자동 생성
docker run -v data_volume2:/var/lib/mysql mysql # 볼륨이 없으면 자동 생성
특징:
/var/lib/docker/volumes/아래에 저장됩니다.- Docker가 볼륨 관리
- 데이터 지속성 보장
- 바인드 마운트 (Bind Mounting)
- 호스트의 특정 경로를 직접 마운트하여 저장하는 방식입니다.
# 호스트의 특정 경로를 컨테이너에 마운트
docker run -v /data/mysql:/var/lib/mysql mysql
- 특징:
- 호스트의 어느 위치든 사용 가능
- 기존 데이터 활용 가능
- 직접 경로 지정
일반적인 Docker 볼륨의 마운트 타입 비교하면 다음과 같습니다.
- 볼륨 마운트:
- Docker 관리 영역 내 저장
- 자동 볼륨 생성 가능
- 이식성이 좋음
- 바인드 마운트:
- 호스트 시스템 경로 직접 사용
- 기존 데이터 활용에 유용
- 호스트 시스템 의존성 있음
이러한 볼륨 사용은 특히 데이터베이스와 같이 지속성이 필요한 데이터를 다룰 때 매우 중요합니다.
-v보다 옵션을 명시적으로 적는 --mount 형식을 사용할 수 있으며
-mount 옵션의 장점:
- 키-값 형식으로 명확하게 파라미터 지정
- 가독성이 좋음
- 옵션 구성이 직관적
주요 파라미터: - type: volume 또는 bind
- source: 볼륨이름 또는 호스트 경로
- target: 컨테이너 내부 경로
긱 바인드 마운트와 볼륨 마운트 방식은 다음과 같습니다.
# 볼륨 생성
docker volume create data_volume
# -v 옵션 사용
docker run -v data_volume:/var/lib/mysql mysql
# --mount 옵션 사용
docker run --mount type=volume,source=data_volume,target=/var/lib/mysql mysql
# -v 옵션 사용
docker run -v /data/mysql:/var/lib/mysql mysql
# --mount 옵션 사용
docker run --mount type=bind,source=/data/mysql,target=/var/lib/mysql mysql
이렇게 bind와 volume에 따라 달라지는 것을 볼 수 있으며 bind 마운트의 경우 source를 호스트의 위치로 설정하게 됩니다. 이를 위해 Docker에서는 스토리지 드라이버를[ 참조하게 되며 주로 사용하는 파일시스템은 다음과 같습니다.
- AUFS
- ZFS
- BTRFS
- Device Mapper
- Overlay
- Overlay2
스토리지 드라이버 선택 기준은 운영체제(OS)에 따라 결정됩니다. - 현대 Docker 환경에서는 Overlay2가 널리 사용되며 실제 기본 드라이버는 설치 환경에서 확인해야 함
- 배포판과 Docker 버전에 따라 지원 드라이버가 달라지므로 운영 환경의 공식 지원 목록을 확인해야 함
Docker는 OS에 따라 최적의 드라이버 자동 선택되며 성능과 안정성 특성이 각각 다르므로 애플리케이션과 조직의 요구사항에 맞춰 선택 필요합니다.