Docker Image Layer와 Volume: 컨테이너 데이터는 왜 사라질까?

1. Docker Image와 Container를 다시 정리해보자

먼저 이전 글의 핵심을 짧게 복습해보자.

Docker Image는 실행에 필요한 파일 시스템과 설정을 담은 정적인 실행 단위이고,
Docker Container는 그 Image를 기반으로 실제 실행된 프로세스다.

Docker Image
└── 실행에 필요한 파일 시스템과 설정
 
Docker Container
└── Image를 기반으로 실행된 격리 프로세스

예를 들어 다음 명령어를 실행한다고 해보자.

docker run -d --name my-nginx nginx

이때 nginx는 Image이고, my-nginx는 그 Image를 기반으로 실행된 Container다.

겉으로 보면 Container는 하나의 독립된 서버처럼 보인다.
컨테이너 안에는 파일 시스템도 있고, 설정 파일도 있으며, 실행 중인 프로세스도 있다.

하지만 중요한 점은 이것이다.

• Container는 Image 자체를 직접 수정하지 않는다.
• Container는 Image 위에 별도의 쓰기 가능한 공간을 얹어서 실행된다.

즉, Container 안에서 파일을 만들거나 수정한다고 해서 원본 Image가 바뀌는 것은 아니다.

이 구조를 이해하려면 먼저 Docker Image가 어떻게 구성되는지 봐야 한다.

2. Docker Image는 여러 개의 읽기 전용 레이어로 구성된다

Docker Image는 하나의 큰 파일 덩어리처럼 보일 수 있다.
하지만 실제로는 여러 개의 레이어가 쌓인 구조에 가깝다.

Docker Image
├── Layer 4: application code
├── Layer 3: package install
├── Layer 2: runtime install
└── Layer 1: base image

각 레이어는 이전 레이어 위에 변경 사항을 추가한 결과다.
그리고 Image를 구성하는 레이어는 기본적으로 읽기 전용 이다.

• Docker Image Layer는 한 번 만들어지면 직접 수정되지 않는다.
• 새로운 변경이 필요하면 기존 레이어를 수정하는 것이 아니라, 그 위에 새로운 레이어를 추가한다.

예를 들어 다음과 같은 Dockerfile이 있다고 해보자.

FROM node:20-alpine
 
WORKDIR /app
 
COPY package.json package-lock.json ./
 
RUN npm install
 
COPY . .
 
CMD ["npm", "start"]

이 Dockerfile을 기준으로 Image를 빌드하면 대략 다음과 같은 구조로 이해할 수 있다.

node:20-alpine base image
└── WORKDIR /app
    └── COPY package.json package-lock.json ./
        └── RUN npm install
            └── COPY . .
                └── CMD ["npm", "start"]

• 다만 모든 Dockerfile 명령이 동일한 방식으로 파일 시스템 레이어를 만드는 것은 아니다.
• RUN, COPY, ADD처럼 파일 시스템을 변경하는 명령은 주로 새로운 레이어를 만든다.
• 반면 CMD, ENTRYPOINT, ENV, EXPOSE 같은 명령은 실행 설정이나 메타데이터에 가까운 역할을 한다.

Image A
├── App A Layer
└── node:20-alpine Layer
 
Image B
├── App B Layer
└── node:20-alpine Layer
 
Image C
├── App C Layer
└── node:20-alpine Layer

3. Container는 Image 위에 writable layer를 얹어 실행된다

Image Layer는 읽기 전용이다.
그렇다면 Container 안에서 파일을 만들거나 수정하면 그 변경 사항은 어디에 저장될까?

정답은 Container Writable Layer다.

Container Writable Layer는 컨테이너가 실행될 때 Image 위에 추가되는 쓰기 가능한 레이어다.

구조를 단순화하면 다음과 같다.

Container
└── Writable Layer
    └── 변경된 파일, 새로 생성된 파일, 삭제 표시
 
Docker Image
├── Read-only Layer 3
├── Read-only Layer 2
└── Read-only Layer 1

• Docker Container가 실행되면 원본 Image는 그대로 유지된다.
• 대신 Container마다 별도의 writable layer가 만들어지고
• 컨테이너 내부에서 발생하는 파일 변경은 이 writable layer에 기록된다.

예를 들어 다음과 같이 컨테이너 안에서 파일을 만든다고 해보자.

docker exec -it my-nginx sh
 
echo "hello docker" > /tmp/hello.txt

이때 /tmp/hello.txt는 Image에 저장되는 것이 아니다.
현재 실행 중인 my-nginx 컨테이너의 writable layer에 저장된다.

Image는 여러 Container가 공유할 수 있는 읽기 전용 기반이고,
Container Writable Layer는 각 Container마다 따로 만들어지는 쓰기 가능한 변경 공간이다.

즉, 같은 Image로 여러 Container를 실행해도 각 Container는 자기만의 writable layer를 가진다.

nginx Image
├── Read-only Layer 3
├── Read-only Layer 2
└── Read-only Layer 1
 
Container A
└── Writable Layer A
 
Container B
└── Writable Layer B
 
Container C
└── Writable Layer C

Container A에서 만든 파일은 Container B에 자동으로 생기지 않는다.
각 Container의 변경 사항은 각자의 writable layer에만 기록되기 때문이다.

1. 파일 읽기
Container → Image Layer의 파일을 그대로 읽음
 
2. 파일 수정
Image Layer의 파일을 Writable Layer로 복사
→ Writable Layer의 복사본을 수정

4. 컨테이너를 삭제하면 왜 데이터가 사라질까?

• Container 안에서 만든 파일이나 수정한 파일은 대부분 Container Writable Layer에 저장된다.
• 그런데 이 writable layer는 특정 Container에 종속된다.
• 따라서 Container를 삭제하면 해당 Container의 writable layer도 함께 삭제된다.

Container
└── Writable Layer
    ├── 새로 만든 파일
    ├── 수정한 파일
    └── 삭제 표시
 
docker rm container
 
Writable Layer 삭제

예를 들어 다음과 같이 컨테이너 안에 파일을 만들었다고 해보자.

docker run -it --name test-container ubuntu:22.04 bash
 
echo "important data" > /data.txt
 
exit

이후 컨테이너를 삭제한다.

docker rm test-container

그리고 같은 Image로 새 컨테이너를 다시 실행한다.

docker run -it ubuntu:22.04 bash
 
cat /data.txt

• 이때 /data.txt는 존재하지 않는다.
• 왜냐하면 /data.txt는 ubuntu:22.04 Image에 들어 있던 파일이 아니라, 삭제된 test-container의 writable layer에 저장된 파일이었기 때문이다.

즉, Container 내부 파일 시스템에 저장된 데이터는 영구 저장소가 아니다.
Container가 삭제되어도 보존해야 하는 데이터는 Container 외부에 저장해야 한다.

5. 그래서 Volume이 필요하다

Container 내부의 writable layer는 Container가 삭제되면 함께 사라진다.
그렇다면 컨테이너가 삭제되어도 유지해야 하는 데이터는 어디에 저장해야 할까?

이때 사용하는 것이 Volume이다.

Volume은 컨테이너의 수명과 분리된 Docker의 영구 저장 공간이다.

Volume을 사용하면 데이터가 Container Writable Layer가 아니라, Container 외부의 별도 저장 공간에 기록된다.

Container
├── Writable Layer
│   └── 임시 변경 사항
└── /data
    └── Volume 연결
 
Docker Volume
└── 실제 데이터 저장

즉, Container가 삭제되어도 Volume은 삭제되지 않는다.
새로운 Container를 만들 때 같은 Volume을 다시 연결하면 기존 데이터를 그대로 사용할 수 있다.

예를 들어 다음과 같이 Volume을 붙여 컨테이너를 실행할 수 있다.

docker volume create my-data
 
docker run -it --name volume-test \
  -v my-data:/data \
  ubuntu:22.04 bash

컨테이너 안에서 /data에 파일을 만든다.

echo "persistent data" > /data/hello.txt

이후 컨테이너를 삭제한다.

docker rm volume-test

그리고 같은 Volume을 새 컨테이너에 다시 연결한다.

docker run -it --name volume-test-2 \
  -v my-data:/data \
  ubuntu:22.04 bash
 
cat /data/hello.txt

• 이 경우 /data/hello.txt는 그대로 남아 있다.
• 파일이 Container Writable Layer가 아니라 my-data Volume에 저장되었기 때문이다.

Volume은 Container가 삭제되어도 보존해야 하는 데이터를 Container 밖에 분리해 저장하기 위한 방법이다.

docker run -v my-volume:/data ubuntu:22.04

docker run -v /host/path:/container/path ubuntu:22.04

6. mount는 무엇이고, Volume은 어떻게 연결될까?

Volume을 이해할 때 가장 많이 헷갈리는 지점은 이것이다.

컨테이너 내부 경로에도 저장하고, Volume에도 한 번 더 저장하는 것일까?

결론부터 말하면 그렇지 않다.

컨테이너 내부 경로에도 저장하고, Volume에도 한 번 더 저장하는 것이 아니다. 컨테이너 내부의 특정 경로가 Volume으로 연결되는 것이다.

예를 들어 다음과 같은 Volume 연결을 보자.

docker run -it
-v my-data:/data
ubuntu:22.04 bash

여기서 의미는 다음과 같다.

my-data Volume
└── 컨테이너 내부의 /data 경로에 연결됨

컨테이너 안에서는 /data라는 디렉터리로 보인다. 하지만 그 경로에 저장되는 데이터는 Container Writable Layer가 아니라 my-data Volume에 저장된다.

Container
├── Writable Layer
│ └── /tmp, /etc 등 일반 변경 사항
└── /data
└── my-data Volume으로 연결된 경로
 
Docker Volume
└── my-data
└── 실제 데이터 저장

즉, /data는 컨테이너 내부에 있는 평범한 디렉터리처럼 보이지만, 실제로는 Volume으로 연결된 진입점이다.

이런 연결 지점을 mount point라고 볼 수 있다.

• mount point는 외부 저장 공간에 접근하기 위해 사용하는 경로다.
• Docker에서는 컨테이너 내부의 특정 경로가 Volume에 접근하는 mount point가 된다.

Volume은 복사본이 아니라 연결된 저장 공간이다. 중요한 것은 Volume이 컨테이너 내부 경로의 “복사본”이 아니라는 점이다.

예를 들어 다음처럼 실행했다고 해보자.

docker run -it
-v my-data:/data
ubuntu:22.04 bash

그리고 컨테이너 안에서 다음 명령어를 실행한다.

echo "hello volume" > /data/hello.txt

이때 데이터가 저장되는 위치는 다음과 같이 이해해야 한다.

Container 내부 /data 경로
└── my-data Volume으로 연결된 mount point
 
/data/hello.txt에 쓰기
└── 실제로는 my-data Volume에 저장

• 즉, 컨테이너 입장에서는 /data/hello.txt에 파일을 쓰는 것처럼 보인다.
• 하지만 /data 경로가 Volume에 mount되어 있기 때문에, 실제 데이터는 Volume에 기록된다.

Volume이 연결된 경로에 쓰는 데이터는 Container Writable Layer에 저장되는 것이 아니라, mount된 Volume에 저장된다.

mount되면 기존 경로는 어떻게 될까?

여기서 한 가지 더 조심해야 할 점이 있다.

• Volume을 컨테이너 내부의 특정 경로에 mount하면, 그 경로는 Volume을 통해 접근하는 경로가 된다.
• 따라서 원래 Image나 Writable Layer에 있던 동일 경로의 내용은 그대로 함께 보이는 것이 아니라,
• mount된 저장 공간에 의해 가려질 수 있다.

예를 들어 Image 안에 원래 /data/default.txt가 있었다고 해보자. 그런데 컨테이너 실행 시 /data에 빈 Volume을 mount하면, 컨테이너 안에서 /data를 봤을 때 Volume의 내용이 보인다.

Container Filesystem
└── /data
└── default.txt

Container Filesystem
└── /data
└── my-data Volume이 연결됨
 
my-data Volume
└── Volume에 저장된 내용이 보임

이 말은 원래 파일이 삭제된다는 뜻은 아니다. 다만 해당 경로에 Volume이 mount되어 있는 동안에는 그 경로를 통해 Volume의 내용에 접근하게 된다는 뜻이다.

mount는 기존 경로와 외부 저장 공간을 병합해서 이중 저장하는 개념이 아니라, 특정 경로를 외부 저장 공간에 접근하는 진입점으로 연결하는 개념에 가깝다.

mount
저장 공간을 특정 경로에 연결
 
unmount
특정 경로와 저장 공간의 연결을 해제

Docker Volume
└── 컨테이너 내부의 특정 경로에 연결됨
 
컨테이너 내부 경로
└── Volume에 접근하기 위한 입구 역할

7. 왜 DB는 Volume이 필요할까?

Docker로 DB를 실행할 때 Volume이 특히 중요한 이유는 DB의 본질이 상태를 저장하는 서비스이기 때문이다.

웹 서버나 API 서버는 보통 stateless하게 설계할 수 있다.
컨테이너가 삭제되어도 같은 Image로 다시 실행하면 애플리케이션 코드는 그대로 동작한다.

하지만 DB는 다르다. DB 컨테이너 안에는 다음과 같은 데이터가 계속 쌓인다.

• 테이블 데이터
• 인덱스
• 트랜잭션 로그
• 사용자 계정 정보
• 권한 정보
• DB 설정에 따라 생성되는 내부 파일

이 데이터가 Container Writable Layer에만 저장되어 있다면, 컨테이너 삭제 시 함께 사라진다.

DB 컨테이너에서 중요한 것은 DB 프로그램 자체보다, DB가 저장하고 있는 데이터다.

예를 들어 MySQL 컨테이너를 Volume 없이 실행한다고 해보자.

docker run -d --name mysql-test \
  -e MYSQL_ROOT_PASSWORD=1234 \
  mysql:8.0

이 경우 MySQL 서버는 정상적으로 실행된다.
테이블을 만들고 데이터를 넣을 수도 있다.

하지만 이 데이터가 컨테이너 내부 파일 시스템에만 저장되어 있다면, 컨테이너 삭제 시 함께 사라질 수 있다.

docker rm -f mysql-test

그래서 DB를 Docker로 실행할 때는 데이터 디렉터리를 Volume에 연결하는 것이 일반적이다.

docker volume create mysql-data
 
docker run -d --name mysql-test \
  -e MYSQL_ROOT_PASSWORD=1234 \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

MySQL은 기본적으로 /var/lib/mysql 경로에 데이터 파일을 저장한다.
이 경로를 mysql-data Volume에 연결하면, DB 데이터는 Container Writable Layer가 아니라 Volume에 저장된다.

여기서도 중요한 점은 동일하다.

MySQL 컨테이너 내부의 /var/lib/mysql에도 저장하고, mysql-data Volume에도 한 번 더 저장하는 것이 아니다.

/var/lib/mysql 경로 자체가 mysql-data Volume으로 mount되는 것이다.

따라서 MySQL은 평소처럼 /var/lib/mysql에 데이터를 쓰지만, 그 경로가 Volume에 연결되어 있으므로 실제 데이터는 mysql-data Volume에 저장된다.

MySQL Container
└── /var/lib/mysql
    └── mysql-data Volume
 
mysql-data Volume
├── table data
├── index
├── transaction log
└── internal database files

이제 컨테이너를 삭제하더라도 mysql-data Volume은 남아 있다.
새 MySQL 컨테이너를 만들고 같은 Volume을 연결하면 기존 데이터를 다시 사용할 수 있다.

DB 컨테이너에서 Volume은 선택적인 편의 기능이 아니라, 데이터를 보존하기 위한 기본 전제에 가깝다.

7. docker compose에서 Volume을 사용하는 방식

실무나 개발 환경에서는 docker run 명령어보다 docker compose를 사용하는 경우가 많다.

예를 들어 MySQL을 compose로 실행한다면 다음과 같이 작성할 수 있다.

services:
  mysql:
    image: mysql:8.0
    container_name: mysql-test
    environment:
      MYSQL_ROOT_PASSWORD: 1234
      MYSQL_DATABASE: app_db
    ports:
      - "3306:3306"
    volumes:
      - mysql-data:/var/lib/mysql
 
volumes:
  mysql-data:

여기서 중요한 부분은 이 부분이다.

volumes:
  - mysql-data:/var/lib/mysql

이 설정은 mysql-data라는 Docker Volume을 MySQL 컨테이너의 /var/lib/mysql 경로에 mount한다는 의미다.

즉, MySQL이 /var/lib/mysql에 데이터를 쓰면 그 데이터는 컨테이너 writable layer가 아니라 mysql-data Volume에 기록된다.

그리고 아래 부분은 compose 프로젝트에서 사용할 named volume을 선언하는 부분이다.

volumes:
  mysql-data:

구조로 보면 다음과 같다.

docker compose project
├── mysql container
│   └── /var/lib/mysql
│       └── mysql-data volume 연결
└── mysql-data volume
    └── DB 데이터 저장

이제 docker compose down을 실행하면 컨테이너와 네트워크는 삭제될 수 있다.
하지만 기본적으로 named volume은 자동으로 삭제되지 않는다.

docker compose down

반대로 Volume까지 삭제하려면 명시적으로 -v 옵션을 사용해야 한다.

docker compose down -v

docker compose down은 컨테이너를 삭제하지만, named volume은 기본적으로 남긴다.
docker compose down -v를 실행해야 compose가 만든 volume까지 함께 삭제된다.

이 차이를 모르면 개발 중에 “컨테이너를 지웠는데 왜 DB 데이터가 그대로 남아 있지?” 또는 “왜 갑자기 DB 데이터가 다 사라졌지?” 같은 상황을 겪을 수 있다.

docker volume ls

docker volume create mysql-data

docker volume inspect mysql-data

docker volume prune

docker volume rm mysql-data

8. Image Layer, Writable Layer, Volume의 차이

지금까지의 내용을 정리하면 Docker의 저장 영역은 크게 세 가지로 나누어 볼 수 있다.

Docker Image Layer
└── 읽기 전용 기반 파일 시스템
 
Container Writable Layer
└── 컨테이너 실행 중 발생한 변경 사항
 
Docker Volume
└── 컨테이너와 분리된 영구 데이터 저장 공간

각 영역의 차이는 다음과 같다.

• Image Layer는 실행 환경의 기반이고,
• Writable Layer는 컨테이너 실행 중 생기는 임시 변경 공간이며,
• Volume은 컨테이너 수명과 분리된 영구 저장 공간이다.
  • 그리고 mount는 그 Volume을 컨테이너 내부의 특정 경로로 접근할 수 있게 연결하는 행위다.

이 세 가지를 구분하면 Docker에서 데이터가 어디에 저장되고, 언제 사라지는지 훨씬 명확하게 이해할 수 있다.